idnits 2.17.1 draft-ietf-tsvwg-rfc4960-errata-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 3098 has weird spacing: '...ed long crc_c...' == Line 3309 has weird spacing: '...ed long crc_c...' -- The document date (October 30, 2017) is 2370 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 2860, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Missing Reference: 'RFC0813' is mentioned on line 415, but not defined ** Obsolete undefined reference: RFC 813 (Obsoleted by RFC 7805) == Missing Reference: 'RFC1858' is mentioned on line 1665, but not defined -- Looks like a reference, but probably isn't: '256' on line 3386 ** 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: 3 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 3, 2018 Muenster Univ. of Appl. Sciences 6 M. Proshin 7 Ericsson 8 October 30, 2017 10 RFC 4960 Errata and Issues 11 draft-ietf-tsvwg-rfc4960-errata-03.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 3, 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 . . . . . . . . . . . . . 5 65 3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 6 66 3.5. CRC32c Sample Code on 64-bit Platforms . . . . . . . . . 7 67 3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 8 68 3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 9 69 3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 10 70 3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 11 71 3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 17 72 3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 18 73 3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 18 74 3.13. HEARTBEAT ACK and the association error counter . . . . . 19 75 3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 21 76 3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 22 77 3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 22 78 3.17. Automatically Confirmed Addresses . . . . . . . . . . . . 23 79 3.18. Only One Packet after Retransmission Timeout . . . . . . 24 80 3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 25 81 3.20. Zero Window Probing and Unreachable Primary Path . . . . 26 82 3.21. Normative Language in Section 10 . . . . . . . . . . . . 27 83 3.22. Increase of partial_bytes_acked in Congestion Avoidance . 31 84 3.23. Inconsistency in Notifications Handling . . . . . . . . . 32 85 3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 36 86 3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 38 87 3.26. CWND Increase in Congestion Avoidance Phase . . . . . . . 39 88 3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 41 89 3.28. Window Updates After Receiver Window Opens Up . . . . . . 42 90 3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 43 91 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 45 92 3.31. CWND Degradation due to Max.Burst . . . . . . . . . . . . 46 93 3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 47 94 3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 49 95 3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 49 96 3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 50 97 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 52 98 3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 53 99 3.38. Honoring CWND . . . . . . . . . . . . . . . . . . . . . . 54 100 3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 55 101 3.40. Updating References Regarding ECN . . . . . . . . . . . . 57 102 3.41. Host Name Address Parameter Deprecated . . . . . . . . . 59 103 3.42. Conflicting Text Regarding the Supported Address Types 104 Parameter . . . . . . . . . . . . . . . . . . . . . . . . 62 105 3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 63 106 3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 65 107 3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 67 108 3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 70 109 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 110 5. Security Considerations . . . . . . . . . . . . . . . . . . . 80 111 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80 112 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 113 7.1. Normative References . . . . . . . . . . . . . . . . . . 80 114 7.2. Informative References . . . . . . . . . . . . . . . . . 81 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 117 1. Introduction 119 This document contains a compilation of all defects found up until 120 the publishing of this document for [RFC4960] specifying the Stream 121 Control Transmission Protocol (SCTP). These defects may be of an 122 editorial or technical nature. This document may be thought of as a 123 companion document to be used in the implementation of SCTP to 124 clarify errors in the original SCTP document. 126 This document provides a history of the changes that will be compiled 127 into a BIS document for [RFC4960]. It is structured similar to 128 [RFC4460]. 130 Each error will be detailed within this document in the form of: 132 o The problem description, 133 o The text quoted from [RFC4960], 134 o The replacement text that should be placed into an upcoming BIS 135 document, 136 o A description of the solution. 138 Note that when reading this document one must use care to assure that 139 a field or item is not updated further on within the document. Each 140 section should be applied in sequence to the original [RFC4960] since 141 this document is a historical record of the sequential changes that 142 have been found necessary at various inter-op events and through 143 discussion on the list. 145 2. Conventions 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 3. Corrections to RFC 4960 153 3.1. Path Error Counter Threshold Handling 155 3.1.1. Description of the Problem 157 The handling of the 'Path.Max.Retrans' parameter is described in 158 Section 8.2 and Section 8.3 of [RFC4960] in an Inconsistent way. 159 Whereas Section 8.2 describes that a path is marked inactive when the 160 path error counter exceeds the threshold, Section 8.3 says the path 161 is marked inactive when the path error counter reaches the threshold. 163 This issue was reported as an Errata for [RFC4960] with Errata ID 164 1440. 166 3.1.2. Text Changes to the Document 168 --------- 169 Old text: (Section 8.3) 170 --------- 172 When the value of this counter reaches the protocol parameter 173 'Path.Max.Retrans', the endpoint should mark the corresponding 174 destination address as inactive if it is not so marked, and may also 175 optionally report to the upper layer the change of reachability of 176 this destination address. After this, the endpoint should continue 177 HEARTBEAT on this destination address but should stop increasing the 178 counter. 180 --------- 181 New text: (Section 8.3) 182 --------- 184 When the value of this counter exceeds the protocol parameter 185 'Path.Max.Retrans', the endpoint should mark the corresponding 186 destination address as inactive if it is not so marked, and may also 187 optionally report to the upper layer the change of reachability of 188 this destination address. After this, the endpoint should continue 189 HEARTBEAT on this destination address but should stop increasing the 190 counter. 192 3.1.3. Solution Description 194 The intended state change should happen when the threshold is 195 exceeded. 197 3.2. Upper Layer Protocol Shutdown Request Handling 199 3.2.1. Description of the Problem 201 Section 9.2 of [RFC4960] describes the handling of received SHUTDOWN 202 chunks in the SHUTDOWN-RECEIVED state instead of the handling of 203 shutdown requests from its upper layer in this state. 205 This issue was reported as an Errata for [RFC4960] with Errata ID 206 1574. 208 3.2.2. Text Changes to the Document 210 --------- 211 Old text: (Section 9.2) 212 --------- 214 Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT 215 send a SHUTDOWN in response to a ULP request, and should discard 216 subsequent SHUTDOWN chunks. 218 --------- 219 New text: (Section 9.2) 220 --------- 222 Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT 223 send a SHUTDOWN in response to a ULP request, and should discard 224 subsequent ULP shutdown requests. 226 3.2.3. Solution Description 228 The text never intended the SCTP endpoint to ignore SHUTDOWN chunks 229 from its peer. If it did the endpoints could never gracefully 230 terminate associations in some cases. 232 3.3. Registration of New Chunk Types 234 3.3.1. Description of the Problem 236 Section 14.1 of [RFC4960] should deal with new chunk types, however, 237 the text refers to parameter types. 239 This issue was reported as an Errata for [RFC4960] with Errata ID 240 2592. 242 3.3.2. Text Changes to the Document 244 --------- 245 Old text: (Section 14.1) 246 --------- 248 The assignment of new chunk parameter type codes is done through an 249 IETF Consensus action, as defined in [RFC2434]. Documentation of the 250 chunk parameter MUST contain the following information: 252 --------- 253 New text: (Section 14.1) 254 --------- 256 The assignment of new chunk type codes is done through an 257 IETF Consensus action, as defined in [RFC2434]. Documentation of the 258 chunk type MUST contain the following information: 260 3.3.3. Solution Description 262 Refer to chunk types as intended. 264 3.4. Variable Parameters for INIT Chunks 266 3.4.1. Description of the Problem 268 Newlines in wrong places break the layout of the table of variable 269 parameters for the INIT chunk in Section 3.3.2 of [RFC4960]. 271 This issue was reported as an Errata for [RFC4960] with Errata ID 272 3291 and Errata ID 3804. 274 3.4.2. Text Changes to the Document 275 --------- 276 Old text: (Section 3.3.2) 277 --------- 279 Variable Parameters Status Type Value 280 ------------------------------------------------------------- 281 IPv4 Address (Note 1) Optional 5 IPv6 Address 282 (Note 1) Optional 6 Cookie Preservative 283 Optional 9 Reserved for ECN Capable (Note 2) Optional 284 32768 (0x8000) Host Name Address (Note 3) Optional 285 11 Supported Address Types (Note 4) Optional 12 287 --------- 288 New text: (Section 3.3.2) 289 --------- 291 Variable Parameters Status Type Value 292 ------------------------------------------------------------- 293 IPv4 Address (Note 1) Optional 5 294 IPv6 Address (Note 1) Optional 6 295 Cookie Preservative Optional 9 296 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) 297 Host Name Address (Note 3) Optional 11 298 Supported Address Types (Note 4) Optional 12 300 3.4.3. Solution Description 302 Fix the formatting of the table. 304 3.5. CRC32c Sample Code on 64-bit Platforms 306 3.5.1. Description of the Problem 308 The sample code for computing the CRC32c provided in [RFC4960] 309 assumes that a variable of type unsigned long uses 32 bits. This is 310 not true on some 64-bit platforms (for example the ones using LP64). 312 This issue was reported as an Errata for [RFC4960] with Errata ID 313 3423. 315 3.5.2. Text Changes to the Document 316 --------- 317 Old text: (Appendix C) 318 --------- 320 unsigned long 321 generate_crc32c(unsigned char *buffer, unsigned int length) 322 { 323 unsigned int i; 324 unsigned long crc32 = ~0L; 326 --------- 327 New text: (Appendix C) 328 --------- 330 unsigned long 331 generate_crc32c(unsigned char *buffer, unsigned int length) 332 { 333 unsigned int i; 334 unsigned long crc32 = 0xffffffffL; 336 3.5.3. Solution Description 338 Use 0xffffffffL instead of ~0L which gives the same value on 339 platforms using 32 bits or 64 bits for variables of type unsigned 340 long. 342 3.6. Endpoint Failure Detection 344 3.6.1. Description of the Problem 346 The handling of the association error counter defined in Section 8.1 347 of [RFC4960] can result in an association failure even if the path 348 used for data transmission is available, but idle. 350 This issue was reported as an Errata for [RFC4960] with Errata ID 351 3788. 353 3.6.2. Text Changes to the Document 354 --------- 355 Old text: (Section 8.1) 356 --------- 358 An endpoint shall keep a counter on the total number of consecutive 359 retransmissions to its peer (this includes retransmissions to all the 360 destination transport addresses of the peer if it is multi-homed), 361 including unacknowledged HEARTBEAT chunks. 363 --------- 364 New text: (Section 8.1) 365 --------- 367 An endpoint shall keep a counter on the total number of consecutive 368 retransmissions to its peer (this includes data retransmissions 369 to all the destination transport addresses of the peer if it is 370 multi-homed), including the number of unacknowledged HEARTBEAT 371 chunks observed on the path which currently is used for data 372 transfer. Unacknowledged HEARTBEAT chunks observed on paths 373 different from the path currently used for data transfer shall 374 not increment the association error counter, as this could lead 375 to association closure even if the path which currently is used for 376 data transfer is available (but idle). 378 3.6.3. Solution Description 380 A more refined handling for the association error counter is defined. 382 3.7. Data Transmission Rules 384 3.7.1. Description of the Problem 386 When integrating the changes to Section 6.1 A) of [RFC2960] as 387 described in Section 2.15.2 of [RFC4460] some text was duplicated and 388 became the final paragraph of Section 6.1 A) of [RFC4960]. 390 This issue was reported as an Errata for [RFC4960] with Errata ID 391 4071. 393 3.7.2. Text Changes to the Document 394 --------- 395 Old text: (Section 6.1 A)) 396 --------- 398 The sender MUST also have an algorithm for sending new DATA chunks 399 to avoid silly window syndrome (SWS) as described in [RFC0813]. 400 The algorithm can be similar to the one described in Section 401 4.2.3.4 of [RFC1122]. 403 However, regardless of the value of rwnd (including if it is 0), 404 the data sender can always have one DATA chunk in flight to the 405 receiver if allowed by cwnd (see rule B below). This rule allows 406 the sender to probe for a change in rwnd that the sender missed 407 due to the SACK having been lost in transit from the data receiver 408 to the data sender. 410 --------- 411 New text: (Section 6.1 A)) 412 --------- 414 The sender MUST also have an algorithm for sending new DATA chunks 415 to avoid silly window syndrome (SWS) as described in [RFC0813]. 416 The algorithm can be similar to the one described in Section 417 4.2.3.4 of [RFC1122]. 419 3.7.3. Solution Description 421 Last paragraph of Section 6.1 A) removed as intended in 422 Section 2.15.2 of [RFC4460]. 424 3.8. T1-Cookie Timer 426 3.8.1. Description of the Problem 428 Figure 4 of [RFC4960] illustrates the SCTP association setup. 429 However, it incorrectly shows that the T1-init timer is used in the 430 COOKIE-ECHOED state whereas the T1-cookie timer should have been used 431 instead. 433 This issue was reported as an Errata for [RFC4960] with Errata ID 434 4400. 436 3.8.2. Text Changes to the Document 437 --------- 438 Old text: (Section 5.1.6, Figure 4) 439 --------- 441 COOKIE ECHO [Cookie_Z] ------\ 442 (Start T1-init timer) \ 443 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 444 state) 445 /---- COOKIE-ACK 446 / 447 (Cancel T1-init timer, <-----/ 448 Enter ESTABLISHED state) 450 --------- 451 New text: (Section 5.1.6, Figure 4) 452 --------- 454 COOKIE ECHO [Cookie_Z] ------\ 455 (Start T1-cookie timer) \ 456 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 457 state) 458 /---- COOKIE-ACK 459 / 460 (Cancel T1-cookie timer, <---/ 461 Enter ESTABLISHED state) 463 3.8.3. Solution Description 465 Change the figure such that the T1-cookie timer is used instead of 466 the T1-init timer. 468 3.9. Miscellaneous Typos 470 3.9.1. Description of the Problem 472 While processing [RFC4960] some typos were not catched. 474 3.9.2. Text Changes to the Document 475 --------- 476 Old text: (Section 1.6) 477 --------- 479 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. 480 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 481 2*32 - 1 is TSN = 0. 483 --------- 484 New text: (Section 1.6) 485 --------- 487 Transmission Sequence Numbers wrap around when they reach 2**32 - 1. 488 That is, the next TSN a DATA chunk MUST use after transmitting TSN = 489 2**32 - 1 is TSN = 0. 491 --------- 492 Old text: (Section 3.3.10.9) 493 --------- 495 No User Data: This error cause is returned to the originator of a 497 DATA chunk if a received DATA chunk has no user data. 499 --------- 500 New text: (Section 3.3.10.9) 501 --------- 503 No User Data: This error cause is returned to the originator of a 504 DATA chunk if a received DATA chunk has no user data. 506 --------- 507 Old text: (Section 6.7, Figure 9) 508 --------- 510 Endpoint A Endpoint Z {App 511 sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ---------- 512 -----> (ack delayed) (Start T3-rtx timer) 514 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 516 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 517 immediately send ack) 518 /----- SACK [TSN Ack=6,Block=1, 519 / Start=2,End=2] 520 <-----/ (remove 6 from out-queue, 521 and mark 7 as "1" missing report) 523 --------- 524 New text: (Section 6.7, Figure 9) 525 --------- 527 Endpoint A Endpoint Z 528 {App sends 3 messages; strm 0} 529 DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed) 530 (Start T3-rtx timer) 532 DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) 534 DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, 535 immediately send ack) 536 /----- SACK [TSN Ack=6,Block=1, 537 / Strt=2,End=2] 538 <-----/ 539 (remove 6 from out-queue, 540 and mark 7 as "1" missing report) 542 --------- 543 Old text: (Section 6.10) 544 --------- 546 An endpoint bundles chunks by simply including multiple chunks in one 547 outbound SCTP packet. The total size of the resultant IP datagram, 549 including the SCTP packet and IP headers, MUST be less that or equal 550 to the current Path MTU. 552 --------- 553 New text: (Section 6.10) 554 --------- 556 An endpoint bundles chunks by simply including multiple chunks in one 557 outbound SCTP packet. The total size of the resultant IP datagram, 558 including the SCTP packet and IP headers, MUST be less than or equal 559 to the current Path MTU. 561 --------- 562 Old text: (Section 10.1) 563 --------- 565 o Receive Unacknowledged Message 567 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 568 size, [,stream id] [, stream sequence number] [,partial 569 flag] [,payload protocol-id]) 571 --------- 572 New text: (Section 10.1) 573 --------- 575 O) Receive Unacknowledged Message 577 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 578 size, [,stream id] [, stream sequence number] [,partial 579 flag] [,payload protocol-id]) 581 --------- 582 Old text: (Appendix C) 583 --------- 585 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 586 type field is not "Destination Unreachable", "Parameter 587 Problem",, or "Packet Too Big". 589 --------- 590 New text: (Appendix C) 591 --------- 593 ICMP2) An implementation MAY ignore all ICMPv6 messages where the 594 type field is not "Destination Unreachable", "Parameter 595 Problem", or "Packet Too Big". 597 --------- 598 Old text: (Appendix C) 599 --------- 601 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 602 "Fragmentation Needed", an implementation MAY process this 603 information as defined for PATH MTU discovery. 605 --------- 606 New text: (Appendix C) 607 --------- 609 ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 610 "Fragmentation Needed", an implementation MAY process this 611 information as defined for path MTU discovery. 613 --------- 614 Old text: (Section 5.4) 615 --------- 617 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 618 is the one to which the INIT-ACK was sent. 620 --------- 621 New text: (Section 5.4) 622 --------- 624 2) For the receiver of the COOKIE ECHO, the only CONFIRMED address 625 is the one to which the INIT ACK was sent. 627 --------- 628 Old text: (Section 5.1.6, Figure 4) 629 --------- 631 COOKIE ECHO [Cookie_Z] ------\ 632 (Start T1-init timer) \ 633 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 634 state) 635 /---- COOKIE-ACK 636 / 637 (Cancel T1-init timer, <-----/ 638 Enter ESTABLISHED state) 640 --------- 641 New text: (Section 5.1.6, Figure 4) 642 --------- 644 COOKIE ECHO [Cookie_Z] ------\ 645 (Start T1-cookie timer) \ 646 (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED 647 state) 648 /---- COOKIE ACK 649 / 650 (Cancel T1-cookie timer, <---/ 651 Enter ESTABLISHED state) 653 --------- 654 Old text: (Section 5.2.5) 655 --------- 657 5.2.5. Handle Duplicate COOKIE-ACK. 659 --------- 660 New text: (Section 5.2.5) 661 --------- 663 5.2.5. Handle Duplicate COOKIE ACK. 665 --------- 666 Old text: (Section 8.3) 667 --------- 669 By default, an SCTP endpoint SHOULD monitor the reachability of the 670 idle destination transport address(es) of its peer by sending a 671 HEARTBEAT chunk periodically to the destination transport 672 address(es). HEARTBEAT sending MAY begin upon reaching the 673 ESTABLISHED state and is discontinued after sending either SHUTDOWN 674 or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a 675 HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state 676 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 677 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 678 ACK-SENT state (SHUTDOWN receiver). 680 --------- 681 New text: (Section 8.3) 682 --------- 683 By default, an SCTP endpoint SHOULD monitor the reachability of the 684 idle destination transport address(es) of its peer by sending a 685 HEARTBEAT chunk periodically to the destination transport 686 address(es). HEARTBEAT sending MAY begin upon reaching the 687 ESTABLISHED state and is discontinued after sending either SHUTDOWN 688 or SHUTDOWN ACK. A receiver of a HEARTBEAT MUST respond to a 689 HEARTBEAT with a HEARTBEAT ACK after entering the COOKIE-ECHOED state 690 (INIT sender) or the ESTABLISHED state (INIT receiver), up until 691 reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN- 692 ACK-SENT state (SHUTDOWN receiver). 694 3.9.3. Solution Description 696 Typos fixed. 698 3.10. CRC32c Sample Code 700 3.10.1. Description of the Problem 702 The CRC32c computation is described in Appendix B of [RFC4960]. 703 However, the corresponding sample code and its explanation appears at 704 the end of Appendix C, which deals with ICMP handling. 706 3.10.2. Text Changes to the Document 708 Move the sample code related to CRC32c computation and its 709 explanation from the end of Appendix C to the end of Appendix B. 711 3.10.3. Solution Description 713 Text moved to the appropriate location. 715 3.11. partial_bytes_acked after T3-rtx Expiration 717 3.11.1. Description of the Problem 719 Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked 720 should be reset to 0 after packet loss detecting from SACK but the 721 same is missed for T3-rtx timer expiration. 723 3.11.2. Text Changes to the Document 725 --------- 726 Old text: (Section 7.2.3) 727 --------- 729 When the T3-rtx timer expires on an address, SCTP should perform slow 730 start by: 732 ssthresh = max(cwnd/2, 4*MTU) 733 cwnd = 1*MTU 735 --------- 736 New text: (Section 7.2.3) 737 --------- 739 When the T3-rtx timer expires on an address, SCTP should perform slow 740 start by: 742 ssthresh = max(cwnd/2, 4*MTU) 743 cwnd = 1*MTU 744 partial_bytes_acked = 0 746 3.11.3. Solution Description 748 Specify that partial_bytes_acked should be reset to 0 after T3-rtx 749 timer expiration. 751 3.12. Order of Adjustments of partial_bytes_acked and cwnd 753 3.12.1. Description of the Problem 755 Section 7.2.2 of [RFC4960] is unclear about the order of adjustments 756 applied to partial_bytes_acked and cwnd in the congestion avoidance 757 phase. 759 3.12.2. Text Changes to the Document 761 --------- 762 Old text: (Section 7.2.2) 763 --------- 765 o When partial_bytes_acked is equal to or greater than cwnd and 766 before the arrival of the SACK the sender had cwnd or more bytes 767 of data outstanding (i.e., before arrival of the SACK, flightsize 768 was greater than or equal to cwnd), increase cwnd by MTU, and 769 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 771 --------- 772 New text: (Section 7.2.2) 773 --------- 775 o When partial_bytes_acked is equal to or greater than cwnd and 776 before the arrival of the SACK the sender had cwnd or more bytes 777 of data outstanding (i.e., before arrival of the SACK, flightsize 778 was greater than or equal to cwnd), partial_bytes_acked is reset 779 to (partial_bytes_acked - cwnd). Next, cwnd is increased by MTU. 781 3.12.3. Solution Description 783 The new text defines the exact order of adjustments of 784 partial_bytes_acked and cwnd in the congestion avoidance phase. 786 3.13. HEARTBEAT ACK and the association error counter 788 3.13.1. Description of the Problem 790 Section 8.1 and Section 8.3 of [RFC4960] prescribe that the receiver 791 of a HEARTBEAT ACK must reset the association overall error counter. 792 In some circumstances, e.g. when a router discards DATA chunks but 793 not HEARTBEAT chunks due to the larger size of the DATA chunk, it 794 might be better to not clear the association error counter on 795 reception of the HEARTBEAT ACK and reset it only on reception of the 796 SACK to avoid stalling the association. 798 3.13.2. Text Changes to the Document 799 --------- 800 Old text: (Section 8.1) 801 --------- 803 The counter shall be reset each time a DATA chunk sent to that peer 804 endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT 805 ACK is received from the peer endpoint. 807 --------- 808 New text: (Section 8.1) 809 --------- 811 The counter shall be reset each time a DATA chunk sent to that peer 812 endpoint is acknowledged (by the reception of a SACK). When a 813 HEARTBEAT ACK is received from the peer endpoint, the counter should 814 also be reset. The receiver of the HEARTBEAT ACK may choose not to 815 clear the counter if there is outstanding data on the association. 816 This allows for handling the possible difference in reachability 817 based on DATA chunks and HEARTBEAT chunks. 819 --------- 820 Old text: (Section 8.3) 821 --------- 823 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 824 should clear the error counter of the destination transport address 825 to which the HEARTBEAT was sent, and mark the destination transport 826 address as active if it is not so marked. The endpoint may 827 optionally report to the upper layer when an inactive destination 828 address is marked as active due to the reception of the latest 829 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 830 association overall error count as well (as defined in Section 8.1). 832 --------- 833 New text: (Section 8.3) 834 --------- 836 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 837 should clear the error counter of the destination transport address 838 to which the HEARTBEAT was sent, and mark the destination transport 839 address as active if it is not so marked. The endpoint may 840 optionally report to the upper layer when an inactive destination 841 address is marked as active due to the reception of the latest 842 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK should also clear 843 the association overall error counter (as defined in Section 8.1). 845 3.13.3. Solution Description 847 The new text provides a possibility to not reset the association 848 overall error counter when a HEARTBEAT ACK is received if there are 849 valid reasons for it. 851 3.14. Path for Fast Retransmission 853 3.14.1. Description of the Problem 855 [RFC4960] clearly describes where to retransmit data that is timed 856 out when the peer is multi-homed but the same is not stated for fast 857 retransmissions. 859 3.14.2. Text Changes to the Document 861 --------- 862 Old text: (Section 6.4) 863 --------- 865 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 866 retransmit a chunk that timed out to an active destination transport 867 address that is different from the last destination address to which 868 the DATA chunk was sent. 870 --------- 871 New text: (Section 6.4) 872 --------- 874 Furthermore, when its peer is multi-homed, an endpoint SHOULD try to 875 retransmit a chunk that timed out to an active destination transport 876 address that is different from the last destination address to which 877 the DATA chunk was sent. 879 When its peer is multi-homed, an endpoint SHOULD send fast 880 retransmissions to the same destination transport address where 881 original data was sent to. If the primary path has been changed and 882 original data was sent there before the fast retransmit, the 883 implementation MAY send it to the new primary path. 885 3.14.3. Solution Description 887 The new text clarifies where to send fast retransmissions. 889 3.15. Transmittal in Fast Recovery 891 3.15.1. Description of the Problem 893 The Fast Retransmit on Gap Reports algorithm intends that only the 894 very first packet may be sent regardless of cwnd in the Fast Recovery 895 phase but rule 3) of [RFC4960], Section 7.2.4, misses this 896 clarification. 898 3.15.2. Text Changes to the Document 900 --------- 901 Old text: (Section 7.2.4) 902 --------- 904 3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks 905 marked for retransmission will fit into a single packet, subject 906 to constraint of the path MTU of the destination transport 907 address to which the packet is being sent. Call this value K. 908 Retransmit those K DATA chunks in a single packet. When a Fast 909 Retransmit is being performed, the sender SHOULD ignore the value 910 of cwnd and SHOULD NOT delay retransmission for this single 911 packet. 913 --------- 914 New text: (Section 7.2.4) 915 --------- 917 3) If not in Fast Recovery, determine how many of the earliest 918 (i.e., lowest TSN) DATA chunks marked for retransmission will fit 919 into a single packet, subject to constraint of the path MTU of 920 the destination transport address to which the packet is being 921 sent. Call this value K. Retransmit those K DATA chunks in a 922 single packet. When a Fast Retransmit is being performed, the 923 sender SHOULD ignore the value of cwnd and SHOULD NOT delay 924 retransmission for this single packet. 926 3.15.3. Solution Description 928 The new text explicitly specifies to send only the first packet in 929 the Fast Recovery phase disregarding cwnd limitations. 931 3.16. Initial Value of ssthresh 932 3.16.1. Description of the Problem 934 The initial value of ssthresh should be set arbitrarily high. Using 935 the advertised receiver window of the peer is inappropriate if the 936 peer increases its window after the handshake. Furthermore, use a 937 higher requirements level, since not following the advice may result 938 in performance problems. 940 3.16.2. Text Changes to the Document 942 --------- 943 Old text: (Section 7.2.1) 944 --------- 946 o The initial value of ssthresh MAY be arbitrarily high (for 947 example, implementations MAY use the size of the receiver 948 advertised window). 950 --------- 951 New text: (Section 7.2.1) 952 --------- 954 o The initial value of ssthresh SHOULD be arbitrarily high (e.g., 955 to the size of the largest possible advertised window). 957 3.16.3. Solution Description 959 Use the same value as suggested in [RFC5681], Section 3.1, as an 960 appropriate initial value. Furthermore use the same requirements 961 level. 963 3.17. Automatically Confirmed Addresses 965 3.17.1. Description of the Problem 967 The Path Verification procedure of [RFC4960] prescribes that any 968 address passed to the sender of the INIT by its upper layer is 969 automatically CONFIRMED. This however is unclear if only addresses 970 in the request to initiate association establishment are considered 971 or any addresses provided by the upper layer in any requests (e.g. in 972 'Set Primary'). 974 3.17.2. Text Changes to the Document 975 --------- 976 Old text: (Section 5.4) 977 --------- 979 1) Any address passed to the sender of the INIT by its upper layer 980 is automatically considered to be CONFIRMED. 982 --------- 983 New text: (Section 5.4) 984 --------- 986 1) Any addresses passed to the sender of the INIT by its upper 987 layer in the request to initialize an association is 988 automatically considered to be CONFIRMED. 990 3.17.3. Solution Description 992 The new text clarifies that only addresses provided by the upper 993 layer in the request to initialize an association are automatically 994 confirmed. 996 3.18. Only One Packet after Retransmission Timeout 998 3.18.1. Description of the Problem 1000 [RFC4960] is not completely clear when it describes data transmission 1001 after T3-rtx timer expiration. Section 7.2.1 does not specify how 1002 many packets are allowed to be sent after T3-rtx timer expiration if 1003 more than one packet fit into cwnd. At the same time, Section 7.2.3 1004 has the text without normative language saying that SCTP should 1005 ensure that no more than one packet will be in flight after T3-rtx 1006 timer expiration until successful acknowledgment. It makes the text 1007 inconsistent. 1009 3.18.2. Text Changes to the Document 1010 --------- 1011 Old text: (Section 7.2.1) 1012 --------- 1014 o The initial cwnd after a retransmission timeout MUST be no more 1015 than 1*MTU. 1017 --------- 1018 New text: (Section 7.2.1) 1019 --------- 1021 o The initial cwnd after a retransmission timeout MUST be no more 1022 than 1*MTU and only one packet is allowed to be in flight 1023 until successful acknowledgement. 1025 3.18.3. Solution Description 1027 The new text clearly specifies that only one packet is allowed to be 1028 sent after T3-rtx timer expiration until successful acknowledgement. 1030 3.19. INIT ACK Path for INIT in COOKIE-WAIT State 1032 3.19.1. Description of the Problem 1034 In case of an INIT received in the COOKIE-WAIT state [RFC4960] 1035 prescribes to send an INIT ACK to the same destination address to 1036 which the original INIT has been sent. This text does not address 1037 the possibility of the upper layer to provide multiple remote IP 1038 addresses while requesting the association establishment. If the 1039 upper layer has provided multiple IP addresses and only a subset of 1040 these addresses are supported by the peer then the destination 1041 address of the original INIT may be absent in the incoming INIT and 1042 sending INIT ACK to that address is useless. 1044 3.19.2. Text Changes to the Document 1045 --------- 1046 Old text: (Section 5.2.1) 1047 --------- 1049 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1050 respond with an INIT ACK using the same parameters it sent in its 1051 original INIT chunk (including its Initiate Tag, unchanged). When 1052 responding, the endpoint MUST send the INIT ACK back to the same 1053 address that the original INIT (sent by this endpoint) was sent. 1055 --------- 1056 New text: (Section 5.2.1) 1057 --------- 1059 Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST 1060 respond with an INIT ACK using the same parameters it sent in its 1061 original INIT chunk (including its Initiate Tag, unchanged). When 1062 responding, the following rules MUST be applied: 1064 1) The INIT ACK MUST only be sent to an address passed by the upper 1065 layer in the request to initialize the association. 1067 2) The INIT ACK MUST only be sent to an address reported in the 1068 incoming INIT. 1070 3) The INIT ACK SHOULD be sent to the source address of the 1071 received INIT. 1073 3.19.3. Solution Description 1075 The new text requires sending INIT ACK to the destination address 1076 that is passed by the upper layer and reported in the incoming INIT. 1077 If the source address of the INIT fulfills it then sending the INIT 1078 ACK to the source address of the INIT is the preferred behavior. 1080 3.20. Zero Window Probing and Unreachable Primary Path 1082 3.20.1. Description of the Problem 1084 Section 6.1 of [RFC4960] states that when sending zero window probes, 1085 SCTP should neither increment the association counter nor increment 1086 the destination address error counter if it continues to receive new 1087 packets from the peer. But receiving new packets from the peer does 1088 not guarantee peer's accessibility and, if the destination address 1089 becomes unreachable during zero window probing, SCTP cannot get a 1090 changed rwnd until it switches the destination address for probes. 1092 3.20.2. Text Changes to the Document 1094 --------- 1095 Old text: (Section 6.1) 1096 --------- 1098 If the sender continues to receive new packets from the receiver 1099 while doing zero window probing, the unacknowledged window probes 1100 should not increment the error counter for the association or any 1101 destination transport address. This is because the receiver MAY 1102 keep its window closed for an indefinite time. Refer to Section 1103 6.2 on the receiver behavior when it advertises a zero window. 1105 --------- 1106 New text: (Section 6.1) 1107 --------- 1109 If the sender continues to receive SACKs from the peer 1110 while doing zero window probing, the unacknowledged window probes 1111 should not increment the error counter for the association or any 1112 destination transport address. This is because the receiver MAY 1113 keep its window closed for an indefinite time. Refer to Section 1114 6.2 on the receiver behavior when it advertises a zero window. 1116 3.20.3. Solution Description 1118 The new text clarifies that if the receiver continues to send SACKs, 1119 the sender of probes should not increment the error counter of the 1120 association and the destination address even if the SACKs do not 1121 acknowledge the probes. 1123 3.21. Normative Language in Section 10 1125 3.21.1. Description of the Problem 1127 Section 10 of [RFC4960] is informative and normative language such as 1128 MUST and MAY cannot be used there. However, there are several places 1129 in Section 10 where MUST and MAY are used. 1131 3.21.2. Text Changes to the Document 1133 --------- 1134 Old text: (Section 10.1) 1135 --------- 1137 E) Send 1139 Format: SEND(association id, buffer address, byte count [,context] 1141 [,stream id] [,life time] [,destination transport address] 1142 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 1143 -> result 1145 ... 1147 o no-bundle flag - instructs SCTP not to bundle this user data with 1148 other outbound DATA chunks. SCTP MAY still bundle even when this 1149 flag is present, when faced with network congestion. 1151 --------- 1152 New text: (Section 10.1) 1153 --------- 1155 E) Send 1157 Format: SEND(association id, buffer address, byte count [,context] 1158 [,stream id] [,life time] [,destination transport address] 1159 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 1160 -> result 1162 ... 1164 o no-bundle flag - instructs SCTP not to bundle this user data with 1165 other outbound DATA chunks. SCTP may still bundle even when this 1166 flag is present, when faced with network congestion. 1168 --------- 1169 Old text: (Section 10.1) 1170 --------- 1172 G) Receive 1174 Format: RECEIVE(association id, buffer address, buffer size 1175 [,stream id]) 1176 -> byte count [,transport address] [,stream id] [,stream sequence 1177 number] [,partial flag] [,delivery number] [,payload protocol-id] 1179 ... 1181 o partial flag - if this returned flag is set to 1, then this 1182 Receive contains a partial delivery of the whole message. When 1183 this flag is set, the stream id and Stream Sequence Number MUST 1184 accompany this receive. When this flag is set to 0, it indicates 1185 that no more deliveries will be received for this Stream Sequence 1186 Number. 1188 --------- 1189 New text: (Section 10.1) 1190 --------- 1192 G) Receive 1194 Format: RECEIVE(association id, buffer address, buffer size 1195 [,stream id]) 1196 -> byte count [,transport address] [,stream id] [,stream sequence 1197 number] [,partial flag] [,delivery number] [,payload protocol-id] 1199 ... 1201 o partial flag - if this returned flag is set to 1, then this 1202 Receive contains a partial delivery of the whole message. When 1203 this flag is set, the stream id and Stream Sequence Number must 1204 accompany this receive. When this flag is set to 0, it indicates 1205 that no more deliveries will be received for this Stream Sequence 1206 Number. 1208 --------- 1209 Old text: (Section 10.1) 1210 --------- 1212 N) Receive Unsent Message 1214 Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer 1215 size [,stream id] [, stream sequence number] [,partial 1216 flag] [,payload protocol-id]) 1218 ... 1220 o partial flag - if this returned flag is set to 1, then this 1221 message is a partial delivery of the whole message. When this 1222 flag is set, the stream id and Stream Sequence Number MUST 1223 accompany this receive. When this flag is set to 0, it indicates 1224 that no more deliveries will be received for this Stream Sequence 1225 Number. 1227 --------- 1228 New text: (Section 10.1) 1229 --------- 1231 N) Receive Unsent Message 1233 Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer 1234 size [,stream id] [, stream sequence number] [,partial 1235 flag] [,payload protocol-id]) 1237 ... 1239 o partial flag - if this returned flag is set to 1, then this 1240 message is a partial delivery of the whole message. When this 1241 flag is set, the stream id and Stream Sequence Number must 1242 accompany this receive. When this flag is set to 0, it indicates 1243 that no more deliveries will be received for this Stream Sequence 1244 Number. 1246 --------- 1247 Old text: (Section 10.1) 1248 --------- 1250 O) Receive Unacknowledged Message 1252 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 1253 size, [,stream id] [, stream sequence number] [,partial 1254 flag] [,payload protocol-id]) 1256 ... 1258 o partial flag - if this returned flag is set to 1, then this 1259 message is a partial delivery of the whole message. When this 1260 flag is set, the stream id and Stream Sequence Number MUST 1261 accompany this receive. When this flag is set to 0, it indicates 1262 that no more deliveries will be received for this Stream Sequence 1263 Number. 1265 --------- 1266 New text: (Section 10.1) 1267 --------- 1269 O) Receive Unacknowledged Message 1271 Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer 1272 size, [,stream id] [, stream sequence number] [,partial 1273 flag] [,payload protocol-id]) 1275 ... 1277 o partial flag - if this returned flag is set to 1, then this 1278 message is a partial delivery of the whole message. When this 1279 flag is set, the stream id and Stream Sequence Number must 1280 accompany this receive. When this flag is set to 0, it indicates 1281 that no more deliveries will be received for this Stream Sequence 1282 Number. 1284 3.21.3. Solution Description 1286 The normative language is removed from Section 10. 1288 3.22. Increase of partial_bytes_acked in Congestion Avoidance 1290 3.22.1. Description of the Problem 1292 Two issues have been discovered with the partial_bytes_acked handling 1293 described in Section 7.2.2 of [RFC4960]: 1295 o If the Cumulative TSN Ack Point is not advanced but the SACK chunk 1296 acknowledges new TSNs in the Gap Ack Blocks, these newly 1297 acknowledged TSNs are not considered for partial_bytes_acked 1298 although these TSNs were successfully received by the peer. 1299 o Duplicate TSNs are not considered in partial_bytes_acked although 1300 they confirm that the DATA chunks were successfully received by 1301 the peer. 1303 3.22.2. Text Changes to the Document 1305 --------- 1306 Old text: (Section 7.2.2) 1307 --------- 1309 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1310 that advances the Cumulative TSN Ack Point, increase 1311 partial_bytes_acked by the total number of bytes of all new chunks 1312 acknowledged in that SACK including chunks acknowledged by the new 1313 Cumulative TSN Ack and by Gap Ack Blocks. 1315 --------- 1316 New text: (Section 7.2.2) 1317 --------- 1319 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1320 increase partial_bytes_acked by the total number of bytes of all 1321 new chunks acknowledged in that SACK including chunks acknowledged 1322 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1323 of bytes of duplicated chunks reported in Duplicate TSNs. 1325 3.22.3. Solution Description 1327 Now partial_bytes_acked is increased by TSNs reported as duplicated 1328 as well as TSNs newly acknowledged in Gap Ack Blocks even if the 1329 Cumulative TSN Ack Point is not advanced. 1331 3.23. Inconsistency in Notifications Handling 1333 3.23.1. Description of the Problem 1335 [RFC4960] uses inconsistent normative and non-normative language when 1336 describing rules for sending notifications to the upper layer. E.g. 1337 Section 8.2 of [RFC4960] says that when a destination address becomes 1338 inactive due to an unacknowledged DATA chunk or HEARTBEAT chunk, SCTP 1339 SHOULD send a notification to the upper layer while Section 8.3 of 1340 [RFC4960] says that when a destination address becomes inactive due 1341 to an unacknowledged HEARTBEAT chunk, SCTP may send a notification to 1342 the upper layer. 1344 This makes the text inconsistent. 1346 3.23.2. Text Changes to the Document 1348 The following cahnge is based on the change described in Section 3.6. 1350 --------- 1351 Old text: (Section 8.1) 1352 --------- 1354 An endpoint shall keep a counter on the total number of consecutive 1355 retransmissions to its peer (this includes data retransmissions 1356 to all the destination transport addresses of the peer if it is 1357 multi-homed), including the number of unacknowledged HEARTBEAT 1358 chunks observed on the path which currently is used for data 1359 transfer. Unacknowledged HEARTBEAT chunks observed on paths 1360 different from the path currently used for data transfer shall 1361 not increment the association error counter, as this could lead 1362 to association closure even if the path which currently is used for 1363 data transfer is available (but idle). If the value of this 1364 counter exceeds the limit indicated in the protocol parameter 1365 'Association.Max.Retrans', the endpoint shall consider the peer 1366 endpoint unreachable and shall stop transmitting any more data to it 1367 (and thus the association enters the CLOSED state). In addition, the 1368 endpoint MAY report the failure to the upper layer and optionally 1369 report back all outstanding user data remaining in its outbound 1370 queue. The association is automatically closed when the peer 1371 endpoint becomes unreachable. 1373 --------- 1374 New text: (Section 8.1) 1375 --------- 1377 An endpoint shall keep a counter on the total number of consecutive 1378 retransmissions to its peer (this includes data retransmissions 1379 to all the destination transport addresses of the peer if it is 1380 multi-homed), including the number of unacknowledged HEARTBEAT 1381 chunks observed on the path which currently is used for data 1382 transfer. Unacknowledged HEARTBEAT chunks observed on paths 1383 different from the path currently used for data transfer shall 1384 not increment the association error counter, as this could lead 1385 to association closure even if the path which currently is used for 1386 data transfer is available (but idle). If the value of this 1387 counter exceeds the limit indicated in the protocol parameter 1388 'Association.Max.Retrans', the endpoint shall consider the peer 1389 endpoint unreachable and shall stop transmitting any more data to it 1390 (and thus the association enters the CLOSED state). In addition, the 1391 endpoint SHOULD report the failure to the upper layer and optionally 1392 report back all outstanding user data remaining in its outbound 1393 queue. The association is automatically closed when the peer 1394 endpoint becomes unreachable. 1396 The following changes are based on [RFC4960]. 1398 --------- 1399 Old text: (Section 8.2) 1400 --------- 1402 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1403 address is acknowledged with a HEARTBEAT ACK, the endpoint shall 1404 clear the error counter of the destination transport address to which 1405 the DATA chunk was last sent (or HEARTBEAT was sent). When the peer 1406 endpoint is multi-homed and the last chunk sent to it was a 1407 retransmission to an alternate address, there exists an ambiguity as 1408 to whether or not the acknowledgement should be credited to the 1409 address of the last chunk sent. However, this ambiguity does not 1410 seem to bear any significant consequence to SCTP behavior. If this 1411 ambiguity is undesirable, the transmitter may choose not to clear the 1412 error counter if the last chunk sent was a retransmission. 1414 --------- 1415 New text: (Section 8.2) 1416 --------- 1418 When an outstanding TSN is acknowledged or a HEARTBEAT sent to that 1419 address is acknowledged with a HEARTBEAT ACK, the endpoint shall 1420 clear the error counter of the destination transport address to which 1421 the DATA chunk was last sent (or HEARTBEAT was sent), and SHOULD 1422 also report to the upper layer when an inactive destination address 1423 is marked as active. When the peer endpoint is multi-homed and the 1424 last chunk sent to it was a retransmission to an alternate address, 1425 there exists an ambiguity as to whether or not the acknowledgement 1426 should be credited to the address of the last chunk sent. However, 1427 this ambiguity does not seem to bear any significant consequence to 1428 SCTP behavior. If this ambiguity is undesirable, the transmitter may 1429 choose not to clear the error counter if the last chunk sent was a 1430 retransmission. 1432 --------- 1433 Old text: (Section 8.3) 1434 --------- 1436 When the value of this counter reaches the protocol parameter 1437 'Path.Max.Retrans', the endpoint should mark the corresponding 1438 destination address as inactive if it is not so marked, and may also 1439 optionally report to the upper layer the change of reachability of 1440 this destination address. After this, the endpoint should continue 1441 HEARTBEAT on this destination address but should stop increasing the 1442 counter. 1444 --------- 1445 New text: (Section 8.3) 1446 --------- 1448 When the value of this counter exceeds the protocol parameter 1449 'Path.Max.Retrans', the endpoint should mark the corresponding 1450 destination address as inactive if it is not so marked, and SHOULD 1451 also report to the upper layer the change of reachability of this 1452 destination address. After this, the endpoint should continue 1453 HEARTBEAT on this destination address but should stop increasing the 1454 counter. 1456 --------- 1457 Old text: (Section 8.3) 1458 --------- 1460 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1461 should clear the error counter of the destination transport address 1462 to which the HEARTBEAT was sent, and mark the destination transport 1463 address as active if it is not so marked. The endpoint may 1464 optionally report to the upper layer when an inactive destination 1465 address is marked as active due to the reception of the latest 1466 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the 1467 association overall error count as well (as defined in Section 8.1). 1469 --------- 1470 New text: (Section 8.3) 1471 --------- 1473 Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT 1474 should clear the error counter of the destination transport address 1475 to which the HEARTBEAT was sent, and mark the destination transport 1476 address as active if it is not so marked. The endpoint SHOULD 1477 report to the upper layer when an inactive destination address 1478 is marked as active due to the reception of the latest 1479 HEARTBEAT ACK. The receiver of the HEARTBEAT ACK should also clear 1480 the association overall error counter (as defined in Section 8.1). 1482 --------- 1483 Old text: (Section 9.2) 1484 --------- 1486 An endpoint should limit the number of retransmissions of the 1487 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1488 If this threshold is exceeded, the endpoint should destroy the TCB 1489 and MUST report the peer endpoint unreachable to the upper layer (and 1490 thus the association enters the CLOSED state). 1492 --------- 1493 New text: (Section 9.2) 1494 --------- 1496 An endpoint should limit the number of retransmissions of the 1497 SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. 1498 If this threshold is exceeded, the endpoint should destroy the TCB 1499 and SHOULD report the peer endpoint unreachable to the upper layer 1500 (and thus the association enters the CLOSED state). 1502 --------- 1503 Old text: (Section 9.2) 1504 --------- 1506 The sender of the SHUTDOWN ACK should limit the number of 1507 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1508 'Association.Max.Retrans'. If this threshold is exceeded, the 1509 endpoint should destroy the TCB and may report the peer endpoint 1510 unreachable to the upper layer (and thus the association enters the 1511 CLOSED state). 1513 --------- 1514 New text: (Section 9.2) 1515 --------- 1517 The sender of the SHUTDOWN ACK should limit the number of 1518 retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 1519 'Association.Max.Retrans'. If this threshold is exceeded, the 1520 endpoint should destroy the TCB and SHOULD report the peer endpoint 1521 unreachable to the upper layer (and thus the association enters the 1522 CLOSED state). 1524 3.23.3. Solution Description 1526 The inconsistencies are removed by using consistently SHOULD. 1528 3.24. SACK.Delay Not Listed as a Protocol Parameter 1530 3.24.1. Description of the Problem 1532 SCTP as specified in [RFC4960] supports delaying SACKs. The timer 1533 value for this is a parameter and Section 6.2 of [RFC4960] specifies 1534 a default and maximum value for it. However, defining a name for 1535 this parameter and listing it in the table of protocol parameters in 1536 Section 15 of [RFC4960] is missing. 1538 This issue was reported as an Errata for [RFC4960] with Errata ID 1539 4656. 1541 3.24.2. Text Changes to the Document 1543 --------- 1544 Old text: (Section 6.2) 1545 --------- 1547 An implementation MUST NOT allow the maximum delay to be configured 1548 to be more than 500 ms. In other words, an implementation MAY lower 1549 this value below 500 ms but MUST NOT raise it above 500 ms. 1551 --------- 1552 New text: (Section 6.2) 1553 --------- 1555 An implementation MUST NOT allow the maximum delay (protocol 1556 parameter 'SACK.Delay') to be configured to be more than 500 ms. 1557 In other words, an implementation MAY lower the value of 1558 SACK.Delay below 500 ms but MUST NOT raise it above 500 ms. 1560 --------- 1561 Old text: (Section 15) 1562 --------- 1564 The following protocol parameters are RECOMMENDED: 1566 RTO.Initial - 3 seconds 1567 RTO.Min - 1 second 1568 RTO.Max - 60 seconds 1569 Max.Burst - 4 1570 RTO.Alpha - 1/8 1571 RTO.Beta - 1/4 1572 Valid.Cookie.Life - 60 seconds 1573 Association.Max.Retrans - 10 attempts 1574 Path.Max.Retrans - 5 attempts (per destination address) 1575 Max.Init.Retransmits - 8 attempts 1576 HB.interval - 30 seconds 1577 HB.Max.Burst - 1 1579 --------- 1580 New text: (Section 15) 1581 --------- 1583 The following protocol parameters are RECOMMENDED: 1585 RTO.Initial - 3 seconds 1586 RTO.Min - 1 second 1587 RTO.Max - 60 seconds 1588 Max.Burst - 4 1589 RTO.Alpha - 1/8 1590 RTO.Beta - 1/4 1591 Valid.Cookie.Life - 60 seconds 1592 Association.Max.Retrans - 10 attempts 1593 Path.Max.Retrans - 5 attempts (per destination address) 1594 Max.Init.Retransmits - 8 attempts 1595 HB.interval - 30 seconds 1596 HB.Max.Burst - 1 1597 SACK.Delay - 200 milliseconds 1599 3.24.3. Solution Description 1601 The parameter was given a name and added to the list of protocol 1602 parameters. 1604 3.25. Processing of Chunks in an Incoming SCTP Packet 1606 3.25.1. Description of the Problem 1608 There are a few places in [RFC4960] where the receiver of a packet 1609 must discard it while processing the chunks of the packet. It is 1610 unclear whether the receiver has to rollback state changes already 1611 performed while processing the packet or not. 1613 The intention of [RFC4960] is to process an incoming packet chunk by 1614 chunk and do not perform any prescreening of chunks in the received 1615 packet so the receiver must only discard a chunk causing discard and 1616 all further chunks. 1618 3.25.2. Text Changes to the Document 1620 --------- 1621 Old text: (Section 3.2) 1622 --------- 1624 00 - Stop processing this SCTP packet and discard it, do not 1625 process any further chunks within it. 1627 01 - Stop processing this SCTP packet and discard it, do not 1628 process any further chunks within it, and report the 1629 unrecognized chunk in an 'Unrecognized Chunk Type'. 1631 --------- 1632 New text: (Section 3.2) 1633 --------- 1635 00 - Stop processing this SCTP packet, discard the unrecognized 1636 chunk and all further chunks. 1638 01 - Stop processing this SCTP packet, discard the unrecognized 1639 chunk and all further chunks, and report the unrecognized 1640 chunk in an 'Unrecognized Chunk Type'. 1642 --------- 1643 Old text: (Section 11.3) 1644 --------- 1646 It is helpful for some firewalls if they can inspect just the first 1647 fragment of a fragmented SCTP packet and unambiguously determine 1648 whether it corresponds to an INIT chunk (for further information, 1649 please refer to [RFC1858]). Accordingly, we stress the requirements, 1650 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1651 with any other chunk in a packet, and (2) a packet containing an INIT 1652 chunk MUST have a zero Verification Tag. Furthermore, we require 1653 that the receiver of an INIT chunk MUST enforce these rules by 1654 silently discarding an arriving packet with an INIT chunk that is 1655 bundled with other chunks or has a non-zero verification tag and 1656 contains an INIT-chunk. 1658 --------- 1659 New text: (Section 11.3) 1660 --------- 1662 It is helpful for some firewalls if they can inspect just the first 1663 fragment of a fragmented SCTP packet and unambiguously determine 1664 whether it corresponds to an INIT chunk (for further information, 1665 please refer to [RFC1858]). Accordingly, we stress the requirements, 1666 stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled 1667 with any other chunk in a packet, and (2) a packet containing an INIT 1668 chunk MUST have a zero Verification Tag. Furthermore, we require 1669 that the receiver of an INIT chunk MUST enforce these rules by 1670 silently discarding the INIT chunk and all further chunks if the INIT 1671 chunk is bundled with other chunks or the packet has a non-zero 1672 verification tag. 1674 3.25.3. Solution Description 1676 The new text makes it clear that chunks can be processed from the 1677 beginning to the end and no rollback or pre-screening is required. 1679 3.26. CWND Increase in Congestion Avoidance Phase 1681 3.26.1. Description of the Problem 1683 [RFC4960] in Section 7.2.2 prescribes to increase cwnd by 1*MTU per 1684 RTT if the sender has cwnd or more bytes of outstanding data to the 1685 corresponding address in the Congestion Avoidance phase. However, 1686 this is described without normative language. Moreover, 1687 Section 7.2.2 includes an algorithm how an implementation can achieve 1688 it but this algorithm is underspecified and actually allows 1689 increasing cwnd by more than 1*MTU per RTT. 1691 3.26.2. Text Changes to the Document 1693 --------- 1694 Old text: (Section 7.2.2) 1695 --------- 1697 When cwnd is greater than ssthresh, cwnd should be incremented by 1698 1*MTU per RTT if the sender has cwnd or more bytes of data 1699 outstanding for the corresponding transport address. 1701 --------- 1702 New text: (Section 7.2.2) 1703 --------- 1705 When cwnd is greater than ssthresh, cwnd should be incremented by 1706 1*MTU per RTT if the sender has cwnd or more bytes of data 1707 outstanding for the corresponding transport address. The basic 1708 guidelines for incrementing cwnd during congestion avoidance are: 1710 o SCTP MAY increment cwnd by 1*MTU. 1712 o SCTP SHOULD increment cwnd by one 1*MTU once per RTT when 1713 the sender has cwnd or more bytes of data outstanding for 1714 the corresponding transport address. 1716 o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT. 1718 --------- 1719 Old text: (Section 7.2.2) 1720 --------- 1722 o Whenever cwnd is greater than ssthresh, upon each SACK arrival 1723 that advances the Cumulative TSN Ack Point, increase 1724 partial_bytes_acked by the total number of bytes of all new chunks 1725 acknowledged in that SACK including chunks acknowledged by the new 1726 Cumulative TSN Ack and by Gap Ack Blocks. 1728 o When partial_bytes_acked is equal to or greater than cwnd and 1729 before the arrival of the SACK the sender had cwnd or more bytes 1730 of data outstanding (i.e., before arrival of the SACK, flightsize 1731 was greater than or equal to cwnd), increase cwnd by MTU, and 1732 reset partial_bytes_acked to (partial_bytes_acked - cwnd). 1734 --------- 1735 New text: (Section 7.2.2) 1736 --------- 1738 o Whenever cwnd is greater than ssthresh, upon each SACK arrival, 1739 increase partial_bytes_acked by the total number of bytes of all 1740 new chunks acknowledged in that SACK including chunks acknowledged 1741 by the new Cumulative TSN Ack, by Gap Ack Blocks and by the number 1742 of bytes of duplicated chunks reported in Duplicate TSNs. 1744 o When partial_bytes_acked is greater than cwnd and before the 1745 arrival of the SACK the sender had less bytes of data outstanding 1746 than cwnd (i.e., before arrival of the SACK, flightsize was less 1747 than cwnd), reset partial_bytes_acked to cwnd. 1749 o When partial_bytes_acked is equal to or greater than cwnd and 1750 before the arrival of the SACK the sender had cwnd or more bytes 1751 of data outstanding (i.e., before arrival of the SACK, flightsize 1752 was greater than or equal to cwnd), partial_bytes_acked is reset 1753 to (partial_bytes_acked - cwnd). Next, cwnd is increased by MTU. 1755 3.26.3. Solution Description 1757 The basic guidelines for incrementing cwnd during congestion 1758 avoidance phase are added into Section 7.2.2. The guidelines include 1759 the normative language and are aligned with [RFC5681]. 1761 The algorithm from Section 7.2.2 is improved to not allow increasing 1762 cwnd by more than 1*MTU per RTT. 1764 3.27. Refresh of cwnd and ssthresh after Idle Period 1766 3.27.1. Description of the Problem 1768 [RFC4960] prescribes to adjust cwnd per RTO if the endpoint does not 1769 transmit data on a given transport address. In addition to that, it 1770 prescribes to set cwnd to the initial value after a sufficiently long 1771 idle period. The latter is excessive. Moreover, it is unclear what 1772 is a sufficiently long idle period. 1774 [RFC4960] doesn't specify the handling of ssthresh in the idle case. 1775 If ssthres is reduced due to a packet loss, ssthresh is never 1776 recovered. So traffic can end up in Congestion Avoidance all the 1777 time, resulting in a low sending rate and bad performance. The 1778 problem is even more serious for SCTP because in a multi-homed SCTP 1779 association traffic switch back to the previously failed primary path 1780 will also lead to the situation where traffic ends up in Congestion 1781 Avoidance. 1783 3.27.2. Text Changes to the Document 1785 --------- 1786 Old text: (Section 7.2.1) 1787 --------- 1789 o The initial cwnd before DATA transmission or after a sufficiently 1790 long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 1791 bytes)). 1793 --------- 1794 New text: (Section 7.2.1) 1795 --------- 1797 o The initial cwnd before DATA transmission MUST be set to 1798 min(4*MTU, max (2*MTU, 4380 bytes)). 1800 --------- 1801 Old text: (Section 7.2.1) 1802 --------- 1804 o When the endpoint does not transmit data on a given transport 1805 address, the cwnd of the transport address should be adjusted to 1806 max(cwnd/2, 4*MTU) per RTO. 1808 --------- 1809 New text: (Section 7.2.1) 1810 --------- 1811 o When the endpoint does not transmit data on a given transport 1812 address, the cwnd of the transport address should be adjusted to 1813 max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the 1814 ssthresh of the transport address should be adjusted to the cwnd. 1816 3.27.3. Solution Description 1818 A rule about cwnd adjustment after a sufficiently long idle period is 1819 removed. 1821 The text is updated to refresh ssthresh after the idle period. When 1822 the idle period is detected, the cwnd value is stored to the ssthresh 1823 value. 1825 3.28. Window Updates After Receiver Window Opens Up 1826 3.28.1. Description of the Problem 1828 The sending of SACK chunks for window updates is only indirectly 1829 referenced in [RFC4960], Section 6.2, where it is stated that an SCTP 1830 receiver must not generate more than one SACK for every incoming 1831 packet, other than to update the offered window. 1833 However, the sending of window updates when the receiver window opens 1834 up is necessary to avoid performance problems. 1836 3.28.2. Text Changes to the Document 1838 --------- 1839 Old text: (Section 6.2) 1840 --------- 1842 An SCTP receiver MUST NOT generate more than one SACK for every 1843 incoming packet, other than to update the offered window as the 1844 receiving application consumes new data. 1846 --------- 1847 New text: (Section 6.2) 1848 --------- 1850 An SCTP receiver MUST NOT generate more than one SACK for every 1851 incoming packet, other than to update the offered window as the 1852 receiving application consumes new data. When the window opens 1853 up, an SCTP receiver SHOULD send additional SACK chunks to update 1854 the window even if no new data is received. The receiver MUST avoid 1855 sending large burst of window updates. 1857 3.28.3. Solution Description 1859 The new text makes clear that additional SACK chunks for window 1860 updates should be sent as long as excessive bursts are avoided. 1862 3.29. Path of DATA and Reply Chunks 1864 3.29.1. Description of the Problem 1866 Section 6.4 of [RFC4960] describes the transmission policy for multi- 1867 homed SCTP endpoints. However, there are the following issues with 1868 it: 1870 o It states that a SACK should be sent to the source address of an 1871 incoming DATA. However, it is known that other SACK policies 1872 (e.g. sending SACKs always to the primary path) may be more 1873 beneficial in some situations. 1874 o Initially it states that an endpoint should always transmit DATA 1875 chunks to the primary path. Then it states that the rule for 1876 transmittal of reply chunks should also be followed if the 1877 endpoint is bundling DATA chunks together with the reply chunk 1878 which contradicts with the first statement to always transmit DATA 1879 chunks to the primary path. Some implementations were having 1880 problems with it and sent DATA chunks bundled with reply chunks to 1881 a different destination address than the primary path that caused 1882 many gaps. 1884 3.29.2. Text Changes to the Document 1886 --------- 1887 Old text: (Section 6.4) 1888 --------- 1890 An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, 1891 etc.) to the same destination transport address from which it 1892 received the DATA or control chunk to which it is replying. This 1893 rule should also be followed if the endpoint is bundling DATA chunks 1894 together with the reply chunk. 1896 However, when acknowledging multiple DATA chunks received in packets 1897 from different source addresses in a single SACK, the SACK chunk may 1898 be transmitted to one of the destination transport addresses from 1899 which the DATA or control chunks being acknowledged were received. 1901 --------- 1902 New text: (Section 6.4) 1903 --------- 1905 An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK, 1906 HEARTBEAT ACK, etc.) in response to control chunks to the same 1907 destination transport address from which it received the control 1908 chunk to which it is replying. 1910 The selection of the destination transport address for packets 1911 containing SACK chunks is implementation dependent. However, an endpoint 1912 SHOULD NOT vary the destination transport address of a SACK when it 1913 receives DATA chunks from the same source address. 1915 When acknowledging multiple DATA chunks received in packets 1916 from different source addresses in a single SACK, the SACK chunk MAY 1917 be transmitted to one of the destination transport addresses from 1918 which the DATA or control chunks being acknowledged were received. 1920 3.29.3. Solution Description 1922 The SACK transmission policy is left implementation dependent but it 1923 is specified to not vary the destination address of a packet 1924 containing a SACK chunk unless there are reasons for it as it may 1925 negatively impact RTT measurement. 1927 A confusing statement that prescribes to follow the rule for 1928 transmittal of reply chunks when the endpoint is bundling DATA chunks 1929 together with the reply chunk is removed. 1931 3.30. Outstanding Data, Flightsize and Data In Flight Key Terms 1933 3.30.1. Description of the Problem 1935 [RFC4960] uses outstanding data, flightsize and data in flight key 1936 terms in formulas and statements but their definitions are not 1937 provided in Section 1.3. Furthermore, outstanding data does not 1938 include DATA chunks which are classified as lost but which has not 1939 been retransmitted yet and there is a paragraph in Section 6.1 of 1940 [RFC4960] where this statement is broken. 1942 3.30.2. Text Changes to the Document 1944 --------- 1945 Old text: (Section 1.3) 1946 --------- 1948 o Congestion window (cwnd): An SCTP variable that limits the data, 1949 in number of bytes, a sender can send to a particular destination 1950 transport address before receiving an acknowledgement. 1952 ... 1954 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 1955 DATA chunk) that has been sent by the endpoint but for which it 1956 has not yet received an acknowledgement. 1958 --------- 1959 New text: (Section 1.3) 1960 --------- 1962 o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated 1963 DATA chunk) that has been sent by the endpoint but for which it 1964 has not yet received an acknowledgement. 1966 o Outstanding data (or Data outstanding or Data in flight): The 1967 total amount of the DATA chunks associated with outstanding TSNs. 1969 A retransmitted DATA chunk is counted once in outstanding data. 1970 A DATA chunk which is classified as lost but which has not been 1971 retransmitted yet is not in outstanding data. 1973 o Flightsize: The amount of bytes of outstanding data to a 1974 particular destination transport address at any given time. 1976 o Congestion window (cwnd): An SCTP variable that limits outstanding 1977 data, in number of bytes, a sender can send to a particular 1978 destination transport address before receiving an acknowledgement. 1980 --------- 1981 Old text: (Section 6.1) 1982 --------- 1984 C) When the time comes for the sender to transmit, before sending new 1985 DATA chunks, the sender MUST first transmit any outstanding DATA 1986 chunks that are marked for retransmission (limited by the current 1987 cwnd). 1989 --------- 1990 New text: (Section 6.1) 1991 --------- 1993 C) When the time comes for the sender to transmit, before sending new 1994 DATA chunks, the sender MUST first transmit any DATA chunks that 1995 are marked for retransmission (limited by the current cwnd). 1997 3.30.3. Solution Description 1999 Now Section 1.3, Key Terms, includes explanations of outstanding 2000 data, data in flight and flightsize key terms. Section 6.1 is 2001 corrected to properly use the outstanding data term. 2003 3.31. CWND Degradation due to Max.Burst 2005 3.31.1. Description of the Problem 2007 Some implementations were experiencing a degradation of cwnd because 2008 of the Max.Burst limit. This was due to misinterpretation of the 2009 suggestion in [RFC4960], Section 6.1, on how to use the Max.Burst 2010 parameter when calculating the number of packets to transmit. 2012 3.31.2. Text Changes to the Document 2013 --------- 2014 Old text: (Section 6.1) 2015 --------- 2017 D) When the time comes for the sender to transmit new DATA chunks, 2018 the protocol parameter Max.Burst SHOULD be used to limit the 2019 number of packets sent. The limit MAY be applied by adjusting 2020 cwnd as follows: 2022 if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + 2023 Max.Burst*MTU 2025 Or it MAY be applied by strictly limiting the number of packets 2026 emitted by the output routine. 2028 --------- 2029 New text: (Section 6.1) 2030 --------- 2032 D) When the time comes for the sender to transmit new DATA chunks, 2033 the protocol parameter Max.Burst SHOULD be used to limit the 2034 number of packets sent. The limit MAY be applied by adjusting 2035 cwnd as follows: 2037 if((flightsize + Max.Burst*MTU) < cwnd) 2038 cwnd = flightsize + Max.Burst*MTU 2040 Or it MAY be applied by strictly limiting the number of packets 2041 emitted by the output routine. When calculating the number of 2042 packets to transmit and particularly using the formula above, 2043 cwnd SHOULD NOT be changed. 2045 3.31.3. Solution Description 2047 The new text clarifies that cwnd should not be changed when appling 2048 the Max.Burst limit. This mitigates packet bursts related to the 2049 reception of SACK chunks, but not bursts related to an application 2050 sending a burst of user messages. 2052 3.32. Reduction of RTO.Initial 2054 3.32.1. Description of the Problem 2056 [RFC4960] uses 3 seconds as the default value for RTO.Initial in 2057 accordance with Section 4.3.2.1 of [RFC1122]. [RFC6298] updates 2058 [RFC1122] and lowers the initial value of the retransmission timer 2059 from 3 seconds to 1 second. 2061 3.32.2. Text Changes to the Document 2063 --------- 2064 Old text: (Section 15) 2065 --------- 2067 The following protocol parameters are RECOMMENDED: 2069 RTO.Initial - 3 seconds 2070 RTO.Min - 1 second 2071 RTO.Max - 60 seconds 2072 Max.Burst - 4 2073 RTO.Alpha - 1/8 2074 RTO.Beta - 1/4 2075 Valid.Cookie.Life - 60 seconds 2076 Association.Max.Retrans - 10 attempts 2077 Path.Max.Retrans - 5 attempts (per destination address) 2078 Max.Init.Retransmits - 8 attempts 2079 HB.interval - 30 seconds 2080 HB.Max.Burst - 1 2081 SACK.Delay - 200 milliseconds 2083 --------- 2084 New text: (Section 15) 2085 --------- 2087 The following protocol parameters are RECOMMENDED: 2089 RTO.Initial - 1 second 2090 RTO.Min - 1 second 2091 RTO.Max - 60 seconds 2092 Max.Burst - 4 2093 RTO.Alpha - 1/8 2094 RTO.Beta - 1/4 2095 Valid.Cookie.Life - 60 seconds 2096 Association.Max.Retrans - 10 attempts 2097 Path.Max.Retrans - 5 attempts (per destination address) 2098 Max.Init.Retransmits - 8 attempts 2099 HB.interval - 30 seconds 2100 HB.Max.Burst - 1 2101 SACK.Delay - 200 milliseconds 2103 3.32.3. Solution Description 2105 The value RTO.Initial has been lowered to 1 second to be in tune with 2106 [RFC6298]. 2108 3.33. Ordering of Bundled SACK and ERROR Chunks 2110 3.33.1. Description of the Problem 2112 When an SCTP endpoint receives a DATA chunk with an invalid stream 2113 identifier it shall acknowledge it by sending a SACK chunk and 2114 indicate that the stream identifier was invalid by sending an ERROR 2115 chunk. These two chunks may be bundled. However, [RFC4960] requires 2116 in case of bundling that the ERROR chunk follows the SACK chunk. 2117 This restriction of the ordering is not necessary and might only 2118 limit interoperability. 2120 3.33.2. Text Changes to the Document 2122 --------- 2123 Old text: (Section 6.5) 2124 --------- 2126 Every DATA chunk MUST carry a valid stream identifier. If an 2127 endpoint receives a DATA chunk with an invalid stream identifier, it 2128 shall acknowledge the reception of the DATA chunk following the 2129 normal procedure, immediately send an ERROR chunk with cause set to 2130 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2131 DATA chunk. The endpoint may bundle the ERROR chunk in the same 2132 packet as the SACK as long as the ERROR follows the SACK. 2134 --------- 2135 New text: (Section 6.5) 2136 --------- 2138 Every DATA chunk MUST carry a valid stream identifier. If an 2139 endpoint receives a DATA chunk with an invalid stream identifier, it 2140 shall acknowledge the reception of the DATA chunk following the 2141 normal procedure, immediately send an ERROR chunk with cause set to 2142 "Invalid Stream Identifier" (see Section 3.3.10), and discard the 2143 DATA chunk. The endpoint may bundle the ERROR chunk and the SACK Chunk 2144 in the same packet. 2146 3.33.3. Solution Description 2148 The unnecessary restriction regarding the ordering of the SACK and 2149 ERROR chunk has been removed. 2151 3.34. Undefined Parameter Returned by RECEIVE Primitive 2152 3.34.1. Description of the Problem 2154 [RFC4960] provides a description of an abstract API. In the 2155 definition of the RECEIVE primitive an optional parameter with name 2156 "delivery number" is mentioned. However, no definition of this 2157 parameter is given in [RFC4960] and the parameter is unnecessary. 2159 3.34.2. Text Changes to the Document 2161 --------- 2162 Old text: (Section 10.1) 2163 --------- 2165 G) Receive 2167 Format: RECEIVE(association id, buffer address, buffer size 2168 [,stream id]) 2169 -> byte count [,transport address] [,stream id] [,stream sequence 2170 number] [,partial flag] [,delivery number] [,payload protocol-id] 2172 --------- 2173 New text: (Section 10.1) 2174 --------- 2176 G) Receive 2178 Format: RECEIVE(association id, buffer address, buffer size 2179 [,stream id]) 2180 -> byte count [,transport address] [,stream id] [,stream sequence 2181 number] [,partial flag] [,payload protocol-id] 2183 3.34.3. Solution Description 2185 The undefined parameter has been removed. 2187 3.35. DSCP Changes 2189 3.35.1. Description of the Problem 2191 The upper layer can change the Differentiated Services Code Point 2192 (DSCP) used for packets being sent. A change of the DSCP can result 2193 in packets hitting different queues on the path and therefore the 2194 congestion control should be initialized when the DSCP is changed by 2195 the upper layer. This is not described in [RFC4960]. 2197 3.35.2. Text Changes to the Document 2199 --------- 2200 New text: (Section 7.2.5) 2201 --------- 2203 SCTP implementations MAY allow an application to configure the 2204 Differentiated Services Code Point (DSCP) used for sending packets. 2205 If a DSCP change might result in outgoing packets being queued in 2206 different queues, the congestion control parameters for all affected 2207 destination addresses MUST be reset to their initial values. 2209 --------- 2210 Old text: (Section 10.1) 2211 --------- 2213 M) Set Protocol Parameters 2215 Format: SETPROTOCOLPARAMETERS(association id, 2216 [,destination transport address,] 2217 protocol parameter list) 2218 -> result 2220 This primitive allows the local SCTP to customize the protocol 2221 parameters. 2223 Mandatory attributes: 2225 o association id - local handle to the SCTP association. 2227 o protocol parameter list - the specific names and values of the 2228 protocol parameters (e.g., Association.Max.Retrans; see Section 2229 15) that the SCTP user wishes to customize. 2231 --------- 2232 Old text: (Section 10.1) 2233 --------- 2235 M) Set Protocol Parameters 2237 Format: SETPROTOCOLPARAMETERS(association id, 2238 [,destination transport address,] 2239 protocol parameter list) 2240 -> result 2242 This primitive allows the local SCTP to customize the protocol 2243 parameters. 2245 Mandatory attributes: 2247 o association id - local handle to the SCTP association. 2249 o protocol parameter list - the specific names and values of the 2250 protocol parameters (e.g., Association.Max.Retrans; see Section 2251 15, or other parameters like the DSCP) that the SCTP user wishes 2252 to customize. 2254 3.35.3. Solution Description 2256 Text describing the required action on DSCP changes has been added. 2258 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages 2260 3.36.1. Description of the Problem 2262 Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6 2263 messages. The text explicitly describes the handling of ICMPv6 2264 packets indicating reachability problems, but does not do the same 2265 for the corresponding ICMPv4 packets. 2267 3.36.2. Text Changes to the Document 2268 --------- 2269 Old text: (Appendix C) 2270 --------- 2272 ICMP3) An implementation MAY ignore any ICMPv4 messages where the 2273 code does not indicate "Protocol Unreachable" or 2274 "Fragmentation Needed". 2276 --------- 2277 New text: 2278 --------- 2280 ICMP3) An implementation SHOULD ignore any ICMPv4 messages where the 2281 code indicates "Port Unreachable". 2283 --------- 2284 Old text: (Appendix C) 2285 --------- 2287 ICMP9) If the ICMPv6 code is "Destination Unreachable", the 2288 implementation MAY mark the destination into the unreachable 2289 state or alternatively increment the path error counter. 2291 --------- 2292 New text: 2293 --------- 2295 ICMP9) If the ICMP type is "Destination Unreachable", the 2296 implementation MAY mark the destination into the unreachable 2297 state or alternatively increment the path error counter. 2299 3.36.3. Solution Description 2301 The text has been changed to not limit the processing of ICMPv4 2302 packets with type "Destination Unreachable" by rewording the third 2303 rule. Furthermore, remove in the ninth rule the limitation to 2304 ICMPv6. 2306 3.37. Handling of Soft Errors 2308 3.37.1. Description of the Problem 2310 [RFC1122] defines the handling of soft errors and hard errors for 2311 TCP. Appendix C of [RFC4960] only deals with hard errors. 2313 3.37.2. Text Changes to the Document 2315 --------- 2316 Old text: (Appendix C) 2317 --------- 2319 ICMP8) If the ICMP type is "Destination Unreachable", the 2320 implementation MAY mark the destination into the unreachable 2321 state or alternatively increment the path error counter. 2323 --------- 2324 New text: (Appendix C) 2325 --------- 2327 ICMP8) If the ICMP type is "Destination Unreachable", the 2328 implementation MAY mark the destination into the unreachable 2329 state or alternatively increment the path error counter. 2330 SCTP MAY provide information to the upper layer indicating 2331 the reception of ICMP messages when reporting a network status 2332 change. 2334 3.37.3. Solution Description 2336 Text has been added allowing the SCTP to notify the application in 2337 case of soft errors. 2339 3.38. Honoring CWND 2341 3.38.1. Description of the Problem 2343 When using the slow start algorithm, SCTP increases the congestion 2344 window only when it is being fully utilized. Since SCTP uses DATA 2345 chunks and does not use the congestion window to fragment user 2346 messages, this requires that some overbooking of the congestion 2347 window is allowed. 2349 3.38.2. Text Changes to the Document 2350 --------- 2351 Old text: (Section 6.1) 2352 --------- 2354 B) At any given time, the sender MUST NOT transmit new data to a 2355 given transport address if it has cwnd or more bytes of data 2356 outstanding to that transport address. 2358 --------- 2359 New text: (Section 6.1) 2360 --------- 2362 B) At any given time, the sender MUST NOT transmit new data to a 2363 given transport address if it has cwnd + (PMTU - 1) or more bytes 2364 of data outstanding to that transport address. If data is 2365 available the sender SHOULD exceed cwnd by up to (PMTU-1) bytes on 2366 a new data transmission if the flightsize does not currently reach 2367 cwnd. The breach of cwnd MUST constitute one packet only. 2369 --------- 2370 Old text: (Section 7.2.1) 2371 --------- 2373 o Whenever cwnd is greater than zero, the endpoint is allowed to 2374 have cwnd bytes of data outstanding on that transport address. 2376 --------- 2377 New text: (Section 7.2.1) 2378 --------- 2379 o Whenever cwnd is greater than zero, the endpoint is allowed to 2380 have cwnd bytes of data outstanding on that transport address. 2381 A limited overbooking as described in B) of Section 6.1 should 2382 be supported. 2384 3.38.3. Solution Description 2386 Text was added that to clarify how the CWND limit should be handled. 2388 3.39. Zero Window Probing 2390 3.39.1. Description of the Problem 2392 The text describing zero window probing was not clearly handling the 2393 case where the window was not zero, but too small for the next DATA 2394 chunk to be transmitted. Even in this case, zero window probing has 2395 to be performed to avoid deadlocks. 2397 3.39.2. Text Changes to the Document 2399 --------- 2400 Old text: (Section 6.1) 2401 --------- 2403 A) At any given time, the data sender MUST NOT transmit new data to 2404 any destination transport address if its peer's rwnd indicates 2405 that the peer has no buffer space (i.e., rwnd is 0; see Section 2406 6.2.1). However, regardless of the value of rwnd (including if it 2407 is 0), the data sender can always have one DATA chunk in flight to 2408 the receiver if allowed by cwnd (see rule B, below). This rule 2409 allows the sender to probe for a change in rwnd that the sender 2410 missed due to the SACK's having been lost in transit from the data 2411 receiver to the data sender. 2413 When the receiver's advertised window is zero, this probe is 2414 called a zero window probe. Note that a zero window probe SHOULD 2415 only be sent when all outstanding DATA chunks have been 2416 cumulatively acknowledged and no DATA chunks are in flight. Zero 2417 window probing MUST be supported. 2419 --------- 2420 New text: (Section 6.1) 2421 --------- 2423 A) At any given time, the data sender MUST NOT transmit new data to 2424 any destination transport address if its peer's rwnd indicates 2425 that the peer has no buffer space (i.e., rwnd is smaller than the 2426 size of the next DATA chunk; see Section 6.2.1). 2427 However, regardless of the value of rwnd (including if it is 0), 2428 the data sender can always have one DATA chunk in flight to 2429 the receiver if allowed by cwnd (see rule B, below). This rule 2430 allows the sender to probe for a change in rwnd that the sender 2431 missed due to the SACK's having been lost in transit from the data 2432 receiver to the data sender. 2434 When the receiver has no buffer space, this probe is 2435 called a zero window probe. Note that a zero window probe SHOULD 2436 only be sent when all outstanding DATA chunks have been 2437 cumulatively acknowledged and no DATA chunks are in flight. Zero 2438 window probing MUST be supported. 2440 3.39.3. Solution Description 2442 The terminology is used in a cleaner way. 2444 3.40. Updating References Regarding ECN 2446 3.40.1. Description of the Problem 2448 [RFC4960] refers for ECN only to [RFC3168], which will be updated by 2449 [I-D.ietf-tsvwg-ecn-experimentation]. This needs to be reflected 2450 when referring to ECN. 2452 3.40.2. Text Changes to the Document 2454 --------- 2455 Old text: (Appendix A) 2456 --------- 2458 ECN [RFC3168] describes a proposed extension to IP that details a 2459 method to become aware of congestion outside of datagram loss. 2461 --------- 2462 New text: (Appendix A) 2463 --------- 2465 ECN as specified in [RFC3168] updated by 2466 [I-D.ietf-tsvwg-ecn-experimentation] describes a proposed extension 2467 to IP that details a method to become aware of congestion outside 2468 of datagram loss. 2470 --------- 2471 Old text: (Appendix A) 2472 --------- 2474 In general, [RFC3168] should be followed with the following 2475 exceptions. 2477 --------- 2478 New text: (Appendix A) 2479 --------- 2481 In general, [RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] 2482 should be followed with the following exceptions. 2484 --------- 2485 Old text: (Appendix A) 2486 --------- 2488 [RFC3168] details negotiation of ECN during the SYN and SYN-ACK 2489 stages of a TCP connection. 2491 --------- 2492 New text: (Appendix A) 2493 --------- 2495 [RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] details 2496 negotiation of ECN during the SYN and SYN-ACK stages of a TCP 2497 connection. 2499 --------- 2500 Old text: (Appendix A) 2501 --------- 2503 [RFC3168] details a specific bit for a receiver to send back in its 2504 TCP acknowledgements to notify the sender of the Congestion 2505 Experienced (CE) bit having arrived from the network. 2507 --------- 2508 New text: (Appendix A) 2509 --------- 2511 [RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] 2512 details a specific bit for a receiver to send back in its 2513 TCP acknowledgements to notify the sender of the Congestion 2514 Experienced (CE) bit having arrived from the network. 2516 --------- 2517 Old text: (Appendix A) 2518 --------- 2520 [RFC3168] details a specific bit for a sender to send in the header 2521 of its next outbound TCP segment to indicate to its peer that it has 2522 reduced its congestion window. 2523 --------- 2524 New text: (Appendix A) 2525 --------- 2527 [RFC3168] updated by [I-D.ietf-tsvwg-ecn-experimentation] 2528 details a specific bit for a sender to send in the header 2529 of its next outbound TCP segment to indicate to its peer that it has 2530 reduced its congestion window. 2532 3.40.3. Solution Description 2534 References to [I-D.ietf-tsvwg-ecn-experimentation] have been added. 2536 3.41. Host Name Address Parameter Deprecated 2538 3.41.1. Description of the Problem 2540 [RFC4960] defines three types of address parameters to be used with 2541 INIT and INIT ACK chunks: 2543 1. IPv4 Address parameters. 2544 2. IPv6 Address parameters. 2545 3. Host Name Address parameters. 2547 The first two are supported by the SCTP kernel implementations of 2548 FreeBSD, Linux and Solaris, but the third one is not. In addition, 2549 the first two where successfully tested in all nine interoperability 2550 tests for SCTP, but the third one has never been successfully tested. 2551 Therefore, the Host Name Address parameter should be deprecated. 2553 3.41.2. Text Changes to the Document 2555 --------- 2556 Old text: (Section 3.3.2) 2557 --------- 2559 Note 3: An INIT chunk MUST NOT contain more than one Host Name 2560 Address parameter. Moreover, the sender of the INIT MUST NOT combine 2561 any other address types with the Host Name Address in the INIT. The 2562 receiver of INIT MUST ignore any other address types if the Host Name 2563 Address parameter is present in the received INIT chunk. 2565 --------- 2566 New text: (Section 3.3.2) 2567 --------- 2569 Note 3: An INIT chunk MUST NOT contain the Host Name Address 2570 parameter. The receiver of an INIT chunk containing an Host Name 2571 Address parameter MUST send an ABORT and MAY include an Error Cause 2572 indicating an Unresolvable Address. 2574 --------- 2575 Old text: (Section 3.3.2.1) 2576 --------- 2578 The sender of INIT uses this parameter to pass its Host Name (in 2579 place of its IP addresses) to its peer. The peer is responsible for 2580 resolving the name. Using this parameter might make it more likely 2581 for the association to work across a NAT box. 2583 --------- 2584 New text: (Section 3.3.2.1) 2585 --------- 2587 The sender of an INIT chunk MUST NOT include this parameter. The 2588 usage of the Host Name Address parameter is deprecated. 2590 --------- 2591 Old text: (Section 3.3.2.1) 2592 --------- 2594 Address Type: 16 bits (unsigned integer) 2596 This is filled with the type value of the corresponding address 2597 TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11). 2599 --------- 2600 New text: (Section 3.3.2.1) 2601 --------- 2602 Address Type: 16 bits (unsigned integer) 2604 This is filled with the type value of the corresponding address 2605 TLV (e.g., IPv4 = 5, IPv6 = 6). The value indicating the Host 2606 Name Address parameter (Host name = 11) MUST NOT be used. 2608 --------- 2609 Old text: (Section 3.3.3) 2610 --------- 2612 Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name 2613 Address parameter. Moreover, the sender of the INIT ACK MUST NOT 2614 combine any other address types with the Host Name Address in the 2615 INIT ACK. The receiver of the INIT ACK MUST ignore any other address 2616 types if the Host Name Address parameter is present. 2618 --------- 2619 New text: (Section 3.3.3) 2620 --------- 2622 Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address 2623 parameter. The receiver of INIT ACK chunks containing an Host Name 2624 Address parameter MUST send an ABORT and MAY include an Error Cause 2625 indicating an Unresolvable Address. 2627 --------- 2628 Old text: (Section 5.1.2) 2629 --------- 2631 B) If there is a Host Name parameter present in the received INIT or 2632 INIT ACK chunk, the endpoint shall resolve that host name to a 2633 list of IP address(es) and derive the transport address(es) of 2634 this peer by combining the resolved IP address(es) with the SCTP 2635 source port. 2637 The endpoint MUST ignore any other IP Address parameters if they 2638 are also present in the received INIT or INIT ACK chunk. 2640 The time at which the receiver of an INIT resolves the host name 2641 has potential security implications to SCTP. If the receiver of 2642 an INIT resolves the host name upon the reception of the chunk, 2643 and the mechanism the receiver uses to resolve the host name 2644 involves potential long delay (e.g., DNS query), the receiver may 2645 open itself up to resource attacks for the period of time while it 2646 is waiting for the name resolution results before it can build the 2647 State Cookie and release local resources. 2649 Therefore, in cases where the name translation involves potential 2650 long delay, the receiver of the INIT MUST postpone the name 2651 resolution till the reception of the COOKIE ECHO chunk from the 2652 peer. In such a case, the receiver of the INIT SHOULD build the 2653 State Cookie using the received Host Name (instead of destination 2654 transport addresses) and send the INIT ACK to the source IP 2655 address from which the INIT was received. 2657 The receiver of an INIT ACK shall always immediately attempt to 2658 resolve the name upon the reception of the chunk. 2660 The receiver of the INIT or INIT ACK MUST NOT send user data 2661 (piggy-backed or stand-alone) to its peer until the host name is 2662 successfully resolved. 2664 If the name resolution is not successful, the endpoint MUST 2665 immediately send an ABORT with "Unresolvable Address" error cause 2666 to its peer. The ABORT shall be sent to the source IP address 2667 from which the last peer packet was received. 2669 --------- 2670 New text: (Section 5.1.2) 2671 --------- 2673 B) If there is a Host Name parameter present in the received INIT or 2674 INIT ACK chunk, the endpoint MUST immediately send an ABORT and 2675 MAY include an Error Cause indicating an Unresolvable Address to 2676 its peer. The ABORT shall be sent to the source IP address 2677 from which the last peer packet was received. 2679 --------- 2680 Old text: (Section 11.2.4.1) 2681 --------- 2683 The use of the host name feature in the INIT chunk could be used to 2684 flood a target DNS server. A large backlog of DNS queries, resolving 2685 the host name received in the INIT chunk to IP addresses, could be 2686 accomplished by sending INITs to multiple hosts in a given domain. 2687 In addition, an attacker could use the host name feature in an 2688 indirect attack on a third party by sending large numbers of INITs to 2689 random hosts containing the host name of the target. In addition to 2690 the strain on DNS resources, this could also result in large numbers 2691 of INIT ACKs being sent to the target. One method to protect against 2692 this type of attack is to verify that the IP addresses received from 2693 DNS include the source IP address of the original INIT. If the list 2694 of IP addresses received from DNS does not include the source IP 2695 address of the INIT, the endpoint MAY silently discard the INIT. 2696 This last option will not protect against the attack against the DNS. 2698 --------- 2699 New text: (Section 11.2.4.1) 2700 --------- 2702 The support of the Host Name Address parameter has been removed from 2703 the protocol. Endpoints receiving INIT or INIT ACK chunks containing 2704 the Host Name Address parameter MUST send an ABORT chunk in response 2705 an MAY include an Error Cause indicating an Unresolvable Address. 2707 3.41.3. Solution Description 2709 The usage of the Host Name Address parameter has been deprecated. 2711 3.42. Conflicting Text Regarding the Supported Address Types Parameter 2713 3.42.1. Description of the Problem 2715 When receiving an SCTP packet containing an INIT chunk sent from an 2716 address for which the corresponding address type is not listed in the 2717 Supported Address Types, there is conflicting text in Section 5.1.2 2718 of [RFC4960]. It is stated that the association MUST be aborted and 2719 also that the association SHOULD be established and there SHOULD NOT 2720 be any error indication. 2722 3.42.2. Text Changes to the Document 2723 --------- 2724 Old text: (Section 5.1.2) 2725 --------- 2727 The sender of INIT may include a 'Supported Address Types' parameter 2728 in the INIT to indicate what types of address are acceptable. When 2729 this parameter is present, the receiver of INIT (initiate) MUST 2730 either use one of the address types indicated in the Supported 2731 Address Types parameter when responding to the INIT, or abort the 2732 association with an "Unresolvable Address" error cause if it is 2733 unwilling or incapable of using any of the address types indicated by 2734 its peer. 2736 --------- 2737 New text: (Section 5.1.2) 2738 --------- 2740 The sender of INIT may include a 'Supported Address Types' parameter 2741 in the INIT to indicate what types of address are acceptable. 2743 3.42.3. Solution Description 2745 The conflicting text has been removed. 2747 3.43. Integration of RFC 6096 2749 3.43.1. Description of the Problem 2751 [RFC6096] updates [RFC4960] by adding a Chunk Flags Registry. This 2752 should be integrated into the base specification. 2754 3.43.2. Text Changes to the Document 2756 --------- 2757 Old text: (Section 14.1) 2758 --------- 2760 14.1. IETF-Defined Chunk Extension 2762 The assignment of new chunk parameter type codes is done through an 2763 IETF Consensus action, as defined in [RFC2434]. Documentation of the 2764 chunk parameter MUST contain the following information: 2766 a) A long and short name for the new chunk type. 2768 b) A detailed description of the structure of the chunk, which MUST 2769 conform to the basic structure defined in Section 3.2. 2771 c) A detailed definition and description of intended use of each 2772 field within the chunk, including the chunk flags if any. 2774 d) A detailed procedural description of the use of the new chunk type 2775 within the operation of the protocol. 2777 The last chunk type (255) is reserved for future extension if 2778 necessary. 2780 --------- 2781 New text: (Section 14.1) 2782 --------- 2784 14.1. IETF-Defined Chunk Extension 2786 The assignment of new chunk type codes is done through an IETF Review 2787 action, as defined in [RFC5226]. Documentation of a new chunk MUST 2788 contain the following information: 2790 a) A long and short name for the new chunk type; 2792 b) A detailed description of the structure of the chunk, which MUST 2793 conform to the basic structure defined in Section 3.2 of 2794 [RFC4960]; 2796 c) A detailed definition and description of intended use of each 2797 field within the chunk, including the chunk flags if any. 2798 Defined chunk flags will be used as initial entries in the chunk 2799 flags table for the new chunk type; 2801 d) A detailed procedural description of the use of the new chunk 2802 type within the operation of the protocol. 2804 The last chunk type (255) is reserved for future extension if 2805 necessary. 2807 For each new chunk type, IANA creates a registration table for the 2808 chunk flags of that type. The procedure for registering particular 2809 chunk flags is described in the following Section 14.2. 2811 --------- 2812 New text: (Section 14.2) 2813 --------- 2815 14.2. New IETF Chunk Flags Registration 2817 The assignment of new chunk flags is done through an RFC required 2818 action, as defined in [RFC5226]. Documentation of the chunk flags 2819 MUST contain the following information: 2821 a) A name for the new chunk flag; 2823 b) A detailed procedural description of the use of the new chunk 2824 flag within the operation of the protocol. It MUST be considered 2825 that implementations not supporting the flag will send '0' on 2826 transmit and just ignore it on receipt. 2828 IANA selects a chunk flags value. This must be one of 0x01, 0x02, 2829 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within 2830 the chunk flag values for the specific chunk type. 2832 Please note that Sections 14.2, 14.3, 14.4, and 14.5 need to be 2833 renumbered. 2835 3.43.3. Solution Description 2837 [RFC6096] was integrated. 2839 3.44. Integration of RFC 6335 2841 3.44.1. Description of the Problem 2843 [RFC6335] updates [RFC4960] by updating Procedures for the Port 2844 Numbers Registry. This should be integrated into the base 2845 specification. While there, update the reference to the RFC giving 2846 guidelines for writing IANA sections to [RFC8126]. 2848 3.44.2. Text Changes to the Document 2850 --------- 2851 Old text: (Section 14.5) 2852 --------- 2854 SCTP services may use contact port numbers to provide service to 2855 unknown callers, as in TCP and UDP. IANA is therefore requested to 2856 open the existing Port Numbers registry for SCTP using the following 2857 rules, which we intend to mesh well with existing Port Numbers 2858 registration procedures. An IESG-appointed Expert Reviewer supports 2859 IANA in evaluating SCTP port allocation requests, according to the 2860 procedure defined in [RFC2434]. 2862 Port numbers are divided into three ranges. The Well Known Ports are 2863 those from 0 through 1023, the Registered Ports are those from 1024 2864 through 49151, and the Dynamic and/or Private Ports are those from 2865 49152 through 65535. Well Known and Registered Ports are intended 2866 for use by server applications that desire a default contact point on 2867 a system. On most systems, Well Known Ports can only be used by 2868 system (or root) processes or by programs executed by privileged 2869 users, while Registered Ports can be used by ordinary user processes 2870 or programs executed by ordinary users. Dynamic and/or Private Ports 2871 are intended for temporary use, including client-side ports, out-of- 2872 band negotiated ports, and application testing prior to registration 2873 of a dedicated port; they MUST NOT be registered. 2875 The Port Numbers registry should accept registrations for SCTP ports 2876 in the Well Known Ports and Registered Ports ranges. Well Known and 2877 Registered Ports SHOULD NOT be used without registration. Although 2878 in some cases -- such as porting an application from TCP to SCTP -- 2879 it may seem natural to use an SCTP port before registration 2880 completes, we emphasize that IANA will not guarantee registration of 2881 particular Well Known and Registered Ports. Registrations should be 2882 requested as early as possible. 2884 Each port registration SHALL include the following information: 2886 o A short port name, consisting entirely of letters (A-Z and a-z), 2887 digits (0-9), and punctuation characters from "-_+./*" (not 2888 including the quotes). 2890 o The port number that is requested for registration. 2892 o A short English phrase describing the port's purpose. 2894 o Name and contact information for the person or entity performing 2895 the registration, and possibly a reference to a document defining 2896 the port's use. Registrations coming from IETF working groups 2897 need only name the working group, but indicating a contact person 2898 is recommended. 2900 Registrants are encouraged to follow these guidelines when submitting 2901 a registration. 2903 o A port name SHOULD NOT be registered for more than one SCTP port 2904 number. 2906 o A port name registered for TCP MAY be registered for SCTP as well. 2907 Any such registration SHOULD use the same port number as the 2908 existing TCP registration. 2910 o Concrete intent to use a port SHOULD precede port registration. 2911 For example, existing TCP ports SHOULD NOT be registered in 2912 advance of any intent to use those ports for SCTP. 2914 --------- 2915 New text: (Section 14.5) 2916 --------- 2918 SCTP services may use contact port numbers to provide service to 2919 unknown callers, as in TCP and UDP. IANA is therefore requested to 2920 open the existing Port Numbers registry for SCTP using the following 2921 rules, which we intend to mesh well with existing Port Numbers 2922 registration procedures. An IESG-appointed Expert Reviewer supports 2923 IANA in evaluating SCTP port allocation requests, according to the 2924 procedure defined in [RFC8126]. The details of this process are 2925 defined in [RFC6335]. 2927 3.44.3. Solution Description 2929 [RFC6335] was integrated and the reference was updated to [RFC8126]. 2931 3.45. Integration of RFC 7053 2933 3.45.1. Description of the Problem 2935 [RFC7053] updates [RFC4960] by adding the I bit to the DATA chunk. 2936 This should be integrated into the base specification. 2938 3.45.2. Text Changes to the Document 2940 --------- 2941 Old text: (Section 3.3.1) 2942 --------- 2944 The following format MUST be used for the DATA chunk: 2946 0 1 2 3 2947 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 2948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2949 | Type = 0 | Reserved|U|B|E| Length | 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2951 | TSN | 2952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2953 | Stream Identifier S | Stream Sequence Number n | 2954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2955 | Payload Protocol Identifier | 2956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2957 \ \ 2958 / User Data (seq n of Stream S) / 2959 \ \ 2960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2962 Reserved: 5 bits 2963 Should be set to all '0's and ignored by the receiver. 2965 --------- 2966 New text: (Section 3.3.1) 2967 --------- 2969 0 1 2 3 2970 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 2971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2972 | Type = 0 | Res |I|U|B|E| Length | 2973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2974 | TSN | 2975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2976 | Stream Identifier S | Stream Sequence Number n | 2977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2978 | Payload Protocol Identifier | 2979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2980 \ \ 2981 / User Data (seq n of Stream S) / 2982 \ \ 2983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2985 Res: 4 bits 2987 Should be set to all '0's and ignored by the receiver. 2989 I bit: 1 bit 2991 The (I)mmediate Bit MAY be set by the sender, whenever the sender of 2992 a DATA chunk can benefit from the corresponding SACK chunk being sent 2993 back without delay. See [RFC7053] for a discussion about 2995 --------- 2996 New text: (Append to Section 6.1) 2997 --------- 2999 Whenever the sender of a DATA chunk can benefit from the 3000 corresponding SACK chunk being sent back without delay, the sender 3001 MAY set the I bit in the DATA chunk header. Please note that why the 3002 sender has set the I bit is irrelevant to the receiver. 3004 Reasons for setting the I bit include, but are not limited to (see 3005 Section 4 of [RFC7053] for the benefits): 3007 o The application requests to set the I bit of the last DATA chunk 3008 of a user message when providing the user message to the SCTP 3009 implementation (see Section 7). 3011 o The sender is in the SHUTDOWN-PENDING state. 3013 o The sending of a DATA chunk fills the congestion or receiver 3014 window. 3016 --------- 3017 Old text: (Section 6.2) 3018 --------- 3020 Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. 3021 Therefore, the endpoint should use a SACK instead of the SHUTDOWN 3022 chunk to acknowledge DATA chunks received out of order. 3024 --------- 3025 New text: (Section 6.2) 3026 --------- 3028 Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. 3029 Therefore, the endpoint should use a SACK instead of the SHUTDOWN 3030 chunk to acknowledge DATA chunks received out of order. 3032 Upon receipt of an SCTP packet containing a DATA chunk with the I bit 3033 set, the receiver SHOULD NOT delay the sending of the corresponding 3034 SACK chunk, i.e., the receiver SHOULD immediately respond with the 3035 corresponding SACK chunk. 3037 --------- 3038 Old text: (Section 10.1) 3039 --------- 3041 E) Send 3043 Format: SEND(association id, buffer address, byte count [,context] 3044 [,stream id] [,life time] [,destination transport address] 3045 [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) 3046 -> result 3048 --------- 3049 New text: (Section 10.1) 3050 --------- 3052 E) Send 3054 Format: SEND(association id, buffer address, byte count [,context] 3055 [,stream id] [,life time] [,destination transport address] 3056 [,unordered flag] [,no-bundle flag] [,payload protocol-id] 3057 [,sack immediately] ) 3059 -> result 3061 --------- 3062 New text: (Append optional parameter in Subsection E of Section 10.1) 3063 --------- 3065 o sack immediately - set the I bit on the last DATA chunk used for 3066 sending buffer. 3068 Please note that the change in Section 6.2 is only about adding a 3069 paragraph. 3071 3.45.3. Solution Description 3073 [RFC7053] was integrated. 3075 3.46. CRC32c Code Improvements 3077 3.46.1. Description of the Problem 3079 The code given for the CRC32c computations uses types like long which 3080 may have different length on different operating systems or 3081 processors. Therefore the code is changed to use specific types like 3082 uint32_t. 3084 While there, fix also some syntax errors. 3086 3.46.2. Text Changes to the Document 3088 --------- 3089 Old text: (Appendix B) 3090 --------- 3091 /* Example of the crc table file */ 3092 #ifndef __crc32cr_table_h__ 3093 #define __crc32cr_table_h__ 3095 #define CRC32C_POLY 0x1EDC6F41 3096 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 3098 unsigned long crc_c[256] = 3099 { 3100 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 3101 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 3102 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 3103 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 3104 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 3105 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 3106 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 3107 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 3108 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 3109 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 3110 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 3111 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 3112 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, 3114 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 3115 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 3116 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 3117 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 3118 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 3119 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 3120 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 3121 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 3122 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 3123 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 3124 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, 3125 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 3126 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 3127 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 3128 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 3129 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 3130 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 3131 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 3132 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 3133 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 3134 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 3135 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 3136 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 3137 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 3138 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, 3139 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 3140 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 3141 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 3142 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 3143 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 3144 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 3145 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 3146 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 3147 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 3148 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 3149 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 3150 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 3151 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 3152 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 3153 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 3154 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 3155 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 3156 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 3157 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 3158 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 3159 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 3160 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 3161 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, 3163 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 3164 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 3165 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, 3166 }; 3168 #endif 3170 --------- 3171 New text: (Appendix B) 3172 --------- 3174 /* Example of the crc table file */ 3175 #ifndef __crc32cr_h__ 3176 #define __crc32cr_h__ 3178 #define CRC32C_POLY 0x1EDC6F41UL 3179 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) 3181 uint32_t crc_c[256] = 3182 { 3183 0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL, 3184 0xC79A971FUL, 0x35F1141CUL, 0x26A1E7E8UL, 0xD4CA64EBUL, 3185 0x8AD958CFUL, 0x78B2DBCCUL, 0x6BE22838UL, 0x9989AB3BUL, 3186 0x4D43CFD0UL, 0xBF284CD3UL, 0xAC78BF27UL, 0x5E133C24UL, 3187 0x105EC76FUL, 0xE235446CUL, 0xF165B798UL, 0x030E349BUL, 3188 0xD7C45070UL, 0x25AFD373UL, 0x36FF2087UL, 0xC494A384UL, 3189 0x9A879FA0UL, 0x68EC1CA3UL, 0x7BBCEF57UL, 0x89D76C54UL, 3190 0x5D1D08BFUL, 0xAF768BBCUL, 0xBC267848UL, 0x4E4DFB4BUL, 3191 0x20BD8EDEUL, 0xD2D60DDDUL, 0xC186FE29UL, 0x33ED7D2AUL, 3192 0xE72719C1UL, 0x154C9AC2UL, 0x061C6936UL, 0xF477EA35UL, 3193 0xAA64D611UL, 0x580F5512UL, 0x4B5FA6E6UL, 0xB93425E5UL, 3194 0x6DFE410EUL, 0x9F95C20DUL, 0x8CC531F9UL, 0x7EAEB2FAUL, 3195 0x30E349B1UL, 0xC288CAB2UL, 0xD1D83946UL, 0x23B3BA45UL, 3196 0xF779DEAEUL, 0x05125DADUL, 0x1642AE59UL, 0xE4292D5AUL, 3197 0xBA3A117EUL, 0x4851927DUL, 0x5B016189UL, 0xA96AE28AUL, 3198 0x7DA08661UL, 0x8FCB0562UL, 0x9C9BF696UL, 0x6EF07595UL, 3199 0x417B1DBCUL, 0xB3109EBFUL, 0xA0406D4BUL, 0x522BEE48UL, 3200 0x86E18AA3UL, 0x748A09A0UL, 0x67DAFA54UL, 0x95B17957UL, 3201 0xCBA24573UL, 0x39C9C670UL, 0x2A993584UL, 0xD8F2B687UL, 3202 0x0C38D26CUL, 0xFE53516FUL, 0xED03A29BUL, 0x1F682198UL, 3203 0x5125DAD3UL, 0xA34E59D0UL, 0xB01EAA24UL, 0x42752927UL, 3204 0x96BF4DCCUL, 0x64D4CECFUL, 0x77843D3BUL, 0x85EFBE38UL, 3205 0xDBFC821CUL, 0x2997011FUL, 0x3AC7F2EBUL, 0xC8AC71E8UL, 3206 0x1C661503UL, 0xEE0D9600UL, 0xFD5D65F4UL, 0x0F36E6F7UL, 3207 0x61C69362UL, 0x93AD1061UL, 0x80FDE395UL, 0x72966096UL, 3208 0xA65C047DUL, 0x5437877EUL, 0x4767748AUL, 0xB50CF789UL, 3209 0xEB1FCBADUL, 0x197448AEUL, 0x0A24BB5AUL, 0xF84F3859UL, 3210 0x2C855CB2UL, 0xDEEEDFB1UL, 0xCDBE2C45UL, 0x3FD5AF46UL, 3211 0x7198540DUL, 0x83F3D70EUL, 0x90A324FAUL, 0x62C8A7F9UL, 3212 0xB602C312UL, 0x44694011UL, 0x5739B3E5UL, 0xA55230E6UL, 3213 0xFB410CC2UL, 0x092A8FC1UL, 0x1A7A7C35UL, 0xE811FF36UL, 3214 0x3CDB9BDDUL, 0xCEB018DEUL, 0xDDE0EB2AUL, 0x2F8B6829UL, 3215 0x82F63B78UL, 0x709DB87BUL, 0x63CD4B8FUL, 0x91A6C88CUL, 3216 0x456CAC67UL, 0xB7072F64UL, 0xA457DC90UL, 0x563C5F93UL, 3217 0x082F63B7UL, 0xFA44E0B4UL, 0xE9141340UL, 0x1B7F9043UL, 3218 0xCFB5F4A8UL, 0x3DDE77ABUL, 0x2E8E845FUL, 0xDCE5075CUL, 3219 0x92A8FC17UL, 0x60C37F14UL, 0x73938CE0UL, 0x81F80FE3UL, 3220 0x55326B08UL, 0xA759E80BUL, 0xB4091BFFUL, 0x466298FCUL, 3221 0x1871A4D8UL, 0xEA1A27DBUL, 0xF94AD42FUL, 0x0B21572CUL, 3222 0xDFEB33C7UL, 0x2D80B0C4UL, 0x3ED04330UL, 0xCCBBC033UL, 3223 0xA24BB5A6UL, 0x502036A5UL, 0x4370C551UL, 0xB11B4652UL, 3224 0x65D122B9UL, 0x97BAA1BAUL, 0x84EA524EUL, 0x7681D14DUL, 3225 0x2892ED69UL, 0xDAF96E6AUL, 0xC9A99D9EUL, 0x3BC21E9DUL, 3226 0xEF087A76UL, 0x1D63F975UL, 0x0E330A81UL, 0xFC588982UL, 3227 0xB21572C9UL, 0x407EF1CAUL, 0x532E023EUL, 0xA145813DUL, 3228 0x758FE5D6UL, 0x87E466D5UL, 0x94B49521UL, 0x66DF1622UL, 3229 0x38CC2A06UL, 0xCAA7A905UL, 0xD9F75AF1UL, 0x2B9CD9F2UL, 3230 0xFF56BD19UL, 0x0D3D3E1AUL, 0x1E6DCDEEUL, 0xEC064EEDUL, 3231 0xC38D26C4UL, 0x31E6A5C7UL, 0x22B65633UL, 0xD0DDD530UL, 3232 0x0417B1DBUL, 0xF67C32D8UL, 0xE52CC12CUL, 0x1747422FUL, 3233 0x49547E0BUL, 0xBB3FFD08UL, 0xA86F0EFCUL, 0x5A048DFFUL, 3234 0x8ECEE914UL, 0x7CA56A17UL, 0x6FF599E3UL, 0x9D9E1AE0UL, 3235 0xD3D3E1ABUL, 0x21B862A8UL, 0x32E8915CUL, 0xC083125FUL, 3236 0x144976B4UL, 0xE622F5B7UL, 0xF5720643UL, 0x07198540UL, 3237 0x590AB964UL, 0xAB613A67UL, 0xB831C993UL, 0x4A5A4A90UL, 3238 0x9E902E7BUL, 0x6CFBAD78UL, 0x7FAB5E8CUL, 0x8DC0DD8FUL, 3239 0xE330A81AUL, 0x115B2B19UL, 0x020BD8EDUL, 0xF0605BEEUL, 3240 0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL, 3241 0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL, 3242 0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL, 3243 0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL, 3244 0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL, 3245 0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL, 3246 0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL, 3247 }; 3249 #endif 3250 --------- 3251 Old text: (Appendix B) 3252 --------- 3254 /* Example of table build routine */ 3256 #include 3257 #include 3259 #define OUTPUT_FILE "crc32cr.h" 3260 #define CRC32C_POLY 0x1EDC6F41L 3261 FILE *tf; 3262 unsigned long 3263 reflect_32 (unsigned long b) 3264 { 3265 int i; 3266 unsigned long rw = 0L; 3268 for (i = 0; i < 32; i++){ 3269 if (b & 1) 3270 rw |= 1 << (31 - i); 3271 b >>= 1; 3272 } 3273 return (rw); 3274 } 3276 unsigned long 3277 build_crc_table (int index) 3278 { 3279 int i; 3280 unsigned long rb; 3282 rb = reflect_32 (index); 3284 for (i = 0; i < 8; i++){ 3285 if (rb & 0x80000000L) 3286 rb = (rb << 1) ^ CRC32C_POLY; 3287 else 3288 rb <<= 1; 3289 } 3290 return (reflect_32 (rb)); 3291 } 3293 main () 3294 { 3295 int i; 3297 printf ("\nGenerating CRC-32c table file <%s>\n", 3298 OUTPUT_FILE); 3299 if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){ 3300 printf ("Unable to open %s\n", OUTPUT_FILE); 3301 exit (1); 3302 } 3303 fprintf (tf, "#ifndef __crc32cr_table_h__\n"); 3304 fprintf (tf, "#define __crc32cr_table_h__\n\n"); 3305 fprintf (tf, "#define CRC32C_POLY 0x%08lX\n", 3306 CRC32C_POLY); 3307 fprintf (tf, 3308 "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 3309 fprintf (tf, "\nunsigned long crc_c[256] =\n{\n"); 3310 for (i = 0; i < 256; i++){ 3311 fprintf (tf, "0x%08lXL, ", build_crc_table (i)); 3312 if ((i & 3) == 3) 3313 fprintf (tf, "\n"); 3314 } 3315 fprintf (tf, "};\n\n#endif\n"); 3317 if (fclose (tf) != 0) 3318 printf ("Unable to close <%s>." OUTPUT_FILE); 3319 else 3320 printf ("\nThe CRC-32c table has been written to <%s>.\n", 3321 OUTPUT_FILE); 3322 } 3324 --------- 3325 New text: (Appendix B) 3326 --------- 3328 /* Example of table build routine */ 3330 #include 3331 #include 3333 #define OUTPUT_FILE "crc32cr.h" 3334 #define CRC32C_POLY 0x1EDC6F41UL 3336 static FILE *tf; 3338 static uint32_t 3339 reflect_32(uint32_t b) 3340 { 3341 int i; 3342 uint32_t rw = 0UL; 3344 for (i = 0; i < 32; i++) { 3345 if (b & 1) 3346 rw |= 1 << (31 - i); 3347 b >>= 1; 3348 } 3349 return (rw); 3350 } 3352 static uint32_t 3353 build_crc_table(int index) 3354 { 3355 int i; 3356 uint32_t rb; 3358 rb = reflect_32(index); 3360 for (i = 0; i < 8; i++) { 3361 if (rb & 0x80000000UL) 3362 rb = (rb << 1) ^ (uint32_t)CRC32C_POLY; 3363 else 3364 rb <<= 1; 3365 } 3366 return (reflect_32 (rb)); 3367 } 3369 int 3370 main (void) 3371 { 3372 int i; 3374 printf("\nGenerating CRC-32c table file <%s>\n", 3375 OUTPUT_FILE); 3376 if ((tf = fopen (OUTPUT_FILE, "w")) == NULL) { 3377 printf ("Unable to open %s\n", OUTPUT_FILE); 3378 exit (1); 3379 } 3380 fprintf(tf, "#ifndef __crc32cr_h__\n"); 3381 fprintf(tf, "#define __crc32cr_h__\n\n"); 3382 fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n", 3383 (uint32_t)CRC32C_POLY); 3384 fprintf(tf, 3385 "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); 3386 fprintf(tf, "\nuint32_t crc_c[256] =\n{\n"); 3387 for (i = 0; i < 256; i++) { 3388 fprintf(tf, "0x%08XUL,", build_crc_table (i)); 3389 if ((i & 3) == 3) 3390 fprintf(tf, "\n"); 3391 else 3392 fprintf(tf, " "); 3393 } 3394 fprintf(tf, "};\n\n#endif\n"); 3396 if (fclose (tf) != 0) 3397 printf("Unable to close <%s>.", OUTPUT_FILE); 3398 else 3399 printf("\nThe CRC-32c table has been written to <%s>.\n", 3400 OUTPUT_FILE); 3401 } 3403 --------- 3404 Old text: (Appendix B) 3405 --------- 3407 /* Example of crc insertion */ 3409 #include "crc32cr.h" 3411 unsigned long 3412 generate_crc32c(unsigned char *buffer, unsigned int length) 3413 { 3414 unsigned int i; 3415 unsigned long crc32 = ~0L; 3416 unsigned long result; 3417 unsigned char byte0,byte1,byte2,byte3; 3419 for (i = 0; i < length; i++){ 3420 CRC32C(crc32, buffer[i]); 3421 } 3423 result = ~crc32; 3425 /* result now holds the negated polynomial remainder; 3426 * since the table and algorithm is "reflected" [williams95]. 3427 * That is, result has the same value as if we mapped the message 3428 * to a polynomial, computed the host-bit-order polynomial 3429 * remainder, performed final negation, then did an end-for-end 3430 * bit-reversal. 3431 * Note that a 32-bit bit-reversal is identical to four inplace 3432 * 8-bit reversals followed by an end-for-end byteswap. 3433 * In other words, the bytes of each bit are in the right order, 3434 * but the bytes have been byteswapped. So we now do an explicit 3435 * byteswap. On a little-endian machine, this byteswap and 3436 * the final ntohl cancel out and could be elided. 3437 */ 3439 byte0 = result & 0xff; 3440 byte1 = (result>>8) & 0xff; 3441 byte2 = (result>>16) & 0xff; 3442 byte3 = (result>>24) & 0xff; 3443 crc32 = ((byte0 << 24) | 3444 (byte1 << 16) | 3445 (byte2 << 8) | 3446 byte3); 3447 return ( crc32 ); 3448 } 3450 int 3451 insert_crc32(unsigned char *buffer, unsigned int length) 3452 { 3453 SCTP_message *message; 3454 unsigned long crc32; 3455 message = (SCTP_message *) buffer; 3456 message->common_header.checksum = 0L; 3457 crc32 = generate_crc32c(buffer,length); 3458 /* and insert it into the message */ 3459 message->common_header.checksum = htonl(crc32); 3460 return 1; 3461 } 3463 int 3464 validate_crc32(unsigned char *buffer, unsigned int length) 3465 { 3466 SCTP_message *message; 3467 unsigned int i; 3468 unsigned long original_crc32; 3469 unsigned long crc32 = ~0L; 3471 /* save and zero checksum */ 3472 message = (SCTP_message *) buffer; 3473 original_crc32 = ntohl(message->common_header.checksum); 3474 message->common_header.checksum = 0L; 3475 crc32 = generate_crc32c(buffer,length); 3476 return ((original_crc32 == crc32)? 1 : -1); 3477 } 3479 --------- 3480 New text: (Appendix B) 3481 --------- 3483 /* Example of crc insertion */ 3485 #include "crc32cr.h" 3487 unsigned long 3488 generate_crc32c(unsigned char *buffer, unsigned int length) 3489 { 3490 unsigned int i; 3491 uint32_t crc32 = 0xffffffffUL; 3492 uint32_t result; 3493 uint8_t byte0, byte1, byte2, byte3; 3495 for (i = 0; i < length; i++) { 3496 CRC32C(crc32, buffer[i]); 3497 } 3499 result = ~crc32; 3501 /* result now holds the negated polynomial remainder; 3502 * since the table and algorithm is "reflected" [williams95]. 3503 * That is, result has the same value as if we mapped the message 3504 * to a polynomial, computed the host-bit-order polynomial 3505 * remainder, performed final negation, then did an end-for-end 3506 * bit-reversal. 3507 * Note that a 32-bit bit-reversal is identical to four inplace 3508 * 8-bit reversals followed by an end-for-end byteswap. 3509 * In other words, the bytes of each bit are in the right order, 3510 * but the bytes have been byteswapped. So we now do an explicit 3511 * byteswap. On a little-endian machine, this byteswap and 3512 * the final ntohl cancel out and could be elided. 3513 */ 3515 byte0 = result & 0xff; 3516 byte1 = (result>>8) & 0xff; 3517 byte2 = (result>>16) & 0xff; 3518 byte3 = (result>>24) & 0xff; 3519 crc32 = ((byte0 << 24) | 3520 (byte1 << 16) | 3521 (byte2 << 8) | 3522 byte3); 3523 return (crc32); 3524 } 3526 int 3527 insert_crc32(unsigned char *buffer, unsigned int length) 3528 { 3529 SCTP_message *message; 3530 uint32_t crc32; 3531 message = (SCTP_message *) buffer; 3532 message->common_header.checksum = 0UL; 3533 crc32 = generate_crc32c(buffer,length); 3534 /* and insert it into the message */ 3535 message->common_header.checksum = htonl(crc32); 3536 return 1; 3537 } 3538 int 3539 validate_crc32(unsigned char *buffer, unsigned int length) 3540 { 3541 SCTP_message *message; 3542 unsigned int i; 3543 uint32_t original_crc32; 3544 uint32_t crc32; 3546 /* save and zero checksum */ 3547 message = (SCTP_message *)buffer; 3548 original_crc32 = ntohl(message->common_header.checksum); 3549 message->common_header.checksum = 0L; 3550 crc32 = generate_crc32c(buffer, length); 3551 return ((original_crc32 == crc32)? 1 : -1); 3552 } 3554 3.46.3. Solution Description 3556 The code was changed to use platform independent types. 3558 4. IANA Considerations 3560 This document does not require any actions from IANA. 3562 5. Security Considerations 3564 This document does not add any security considerations to those given 3565 in [RFC4960]. 3567 6. Acknowledgments 3569 The authors wish to thank Pontus Andersson, Eric W. Biederman, 3570 Cedric Bonnet, Lionel Morand, Jeff Morriss, Karen E. E. Nielsen, 3571 Tom Petch, Julien Pourtet, and Michael Welzl for their invaluable 3572 comments. 3574 7. References 3576 7.1. Normative References 3578 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3579 Requirement Levels", BCP 14, RFC 2119, 3580 DOI 10.17487/RFC2119, March 1997, 3581 . 3583 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 3584 RFC 4960, DOI 10.17487/RFC4960, September 2007, 3585 . 3587 7.2. Informative References 3589 [I-D.ietf-tsvwg-ecn-experimentation] 3590 Black, D., "Relaxing Restrictions on Explicit Congestion 3591 Notification (ECN) Experimentation", draft-ietf-tsvwg-ecn- 3592 experimentation-07 (work in progress), October 2017. 3594 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 3595 Communication Layers", STD 3, RFC 1122, 3596 DOI 10.17487/RFC1122, October 1989, 3597 . 3599 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 3600 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 3601 Zhang, L., and V. Paxson, "Stream Control Transmission 3602 Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, 3603 . 3605 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3606 of Explicit Congestion Notification (ECN) to IP", 3607 RFC 3168, DOI 10.17487/RFC3168, September 2001, 3608 . 3610 [RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and 3611 M. Tuexen, "Stream Control Transmission Protocol (SCTP) 3612 Specification Errata and Issues", RFC 4460, 3613 DOI 10.17487/RFC4460, April 2006, 3614 . 3616 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3617 IANA Considerations Section in RFCs", RFC 5226, 3618 DOI 10.17487/RFC5226, May 2008, 3619 . 3621 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 3622 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 3623 . 3625 [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission 3626 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 3627 DOI 10.17487/RFC6096, January 2011, 3628 . 3630 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 3631 "Computing TCP's Retransmission Timer", RFC 6298, 3632 DOI 10.17487/RFC6298, June 2011, 3633 . 3635 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 3636 Cheshire, "Internet Assigned Numbers Authority (IANA) 3637 Procedures for the Management of the Service Name and 3638 Transport Protocol Port Number Registry", BCP 165, 3639 RFC 6335, DOI 10.17487/RFC6335, August 2011, 3640 . 3642 [RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 3643 IMMEDIATELY Extension for the Stream Control Transmission 3644 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 3645 . 3647 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3648 Writing an IANA Considerations Section in RFCs", BCP 26, 3649 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3650 . 3652 Authors' Addresses 3654 Randall R. Stewart 3655 Netflix, Inc. 3656 Chapin, SC 29036 3657 United States 3659 Email: randall@lakerest.net 3661 Michael Tuexen 3662 Muenster University of Applied Sciences 3663 Stegerwaldstrasse 39 3664 48565 Steinfurt 3665 Germany 3667 Email: tuexen@fh-muenster.de 3669 Maksim Proshin 3670 Ericsson 3671 Kistavaegen 25 3672 Stockholm 164 80 3673 Sweden 3675 Email: mproshin@tieto.mera.ru