idnits 2.17.1 draft-ietf-tsvwg-addip-sctp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 31 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2402], [RFC2026], [RFC2119], [RFC2960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 140: '... The keywords MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 141: '... SHOULD NOT, RECOMMENDED, NOT RECOM...' RFC 2119 keyword, line 187: '...ge requests that MUST be acknowledged....' RFC 2119 keyword, line 307: '...of an ASCONF-ACK MAY indicate complete...' RFC 2119 keyword, line 467: '... [RFC2960]). The receiver MAY mark this as its primary upon...' (93 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: R7) An ASCONF-ACK SHOULD not be larger than the path MTU. In some circumstances a ASCONF-ACK may exceed the path MTU and in such a case IP fragmentation must be used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the sender of an ASCONF Chunk receives a Operational Error indicating that the ASCONF chunk type is not understood, then the sender MUST not send subsequent ASCONF Chunks to the peer. The endpoint should also inform the upper layer application that the peer endpoint does not support any of the extensions detailed in this document. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Z1) If an Operational Error is received that indicates that the 'Stream Byte Limit Request' is not understood, the sender of the limit request MUST not send subsequent limit requests. The endpoint SHOULD also inform the upper layer application that the peer endpoint does not support this feature. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Z2) If an Operational Error is received that indicates that the 'Stream Message Limit Request' is not understood, the sender of the limit request MUST not send subsequent limit requests. The endpoint SHOULD also inform the upper layer application that the peer endpoint does not support this feature. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 2001) is 8309 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2026' on line 1430 looks like a reference -- Missing reference section? 'RFC2960' on line 1425 looks like a reference -- Missing reference section? 'RFC2119' on line 1433 looks like a reference -- Missing reference section? 'RFC2402' on line 1436 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. R. Stewart 2 INTERNET-DRAFT M. A. Ramalho 3 Cisco Systems 4 Q. Xie 5 Motorola 6 M. Tuexen 7 Siemens AG 8 I. Rytina 9 Ericsson 10 P. Conrad 11 Temple University 13 expires in six months June 29, 2001 15 SCTP Extensions for Dynamic Reconfiguration of IP Addresses 16 and Enforcement of Flow and Message Limits 18 20 Status of This Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts 24 are working documents of the Internet Engineering Task Force (IETF), 25 its areas, and its working groups. Note that other groups may also 26 distribute working documents as Internet-Drafts. 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes extensions to the Stream Control 37 Transmission Protocol (SCTP) [RFC2960] that provide methods to (1) 38 reconfigure IP address information on an existing association and 39 (2) request that a peer set flow limits in units of bytes or 40 messages, either on a per-stream or per-association basis. 42 TABLE OF CONTENTS 43 1. Introduction............................................... 2 44 2. Conventions................................................ 3 45 3. Additional Chunks and Parameters........................... 3 46 3.1 New Chunk Types........................................... 4 47 3.1.1 Address/Stream Configuration Change Chunk (ASCONF)...... 4 48 3.1.2 Address/Stream Configuration Acknowledgment Chunk 49 (ASCONF-ACK)............................................ 5 50 3.2 New Parameter Types....................................... 6 51 3.2.1 Add IP Address.......................................... 7 52 3.2.2 Delete IP Address....................................... 7 53 3.2.3 Stream Flow Limit Change................................ 8 54 3.2.4 Error Cause Indication.................................. 9 55 3.2.5 Set Primary IP Address.................................. 9 56 3.2.6 Success Indication......................................10 57 3.2.7 Stream Message Limit Change.............................10 58 3.2.8 Association Message Limit Change........................11 59 3.3 New Error Causes..........................................11 60 3.3.1 Error Cause: Request to Delete Last Remaining IP 61 Address.................................................12 62 3.3.2 Error Cause: Operation Refused Due to Resource Shortage.12 63 3.3.3 Error Cause: Request to Delete Source IP Address........13 64 4. Procedures.................................................13 65 4.1 ASCONF Chunk Procedures...................................14 66 4.1.1 Congestion Control of ASCONF Chunks.....................15 67 4.2 Upon reception of an ASCONF Chunk.........................16 68 4.3 General rules for address manipulation....................18 69 4.3.1 A special case for OOTB ABORT chunks....................20 70 4.3.2 A special case for changing an address..................21 71 4.4 Setting of the primary address............................21 72 4.5 Stream Flow/Message Limit Procedures......................22 73 4.5.1 Stream receiver side procedures.........................22 74 4.5.2 Stream sender side procedures...........................23 75 4.5.3 ULP considerations on the use of SCTP flow limit 76 facility................................................24 77 4.6 Association Message Limit Procedures......................25 78 4.6.1 Receiver side procedures................................25 79 4.6.2 Sender side procedures..................................25 80 5. Security Considerations....................................26 81 6. IANA considerations........................................26 82 7. Authors' Addresses.........................................26 83 8. References.................................................27 85 1. Introduction 87 To extend the utility and application scenarios of SCTP, this 88 document introduces optional extensions that provide SCTP with the 89 ability to reconfigure IP address information on an existing 90 association or to request that the peer set flow limits in units 91 of bytes or messages, either on a per-stream or per-association 92 basis. 94 These extensions enable SCTP to be utilized in the following 95 applications: 97 - Dynamic IP address reconfiguration extension: For 98 computational or networking platforms that allow addition/removal of 99 physical interface cards this feature can provide: 101 A) a graceful method to add to the interfaces of an existing 102 association. For IPv6 this feature allows renumbering 103 of existing associations. 105 B) a method for an endpoint to request that its peer set 106 its primary destination address. This can be useful 107 when an address is about to be deleted, or when an endpoint 108 has some predetermined knowledge about which is the 109 preferred address to receive SCTP packets upon. 111 - The SCTP flow limit extension: This extension enables 112 a receiver to request that a sender impose a byte limit on the 113 outstanding data present on a per-stream basis. 115 The SCTP flow limit extension provides: 117 A) The ability to minimize the occurrence of a single stream 118 monopolizing all transport level resources (e.g. a_rwnd 119 "deadlock"). 121 B) The ability to dynamically change the stream buffering 122 limits as the application deems appropriate at any particular 123 instant. 125 - The SCTP message limit extension: This extension enables a 126 receiver to request that a sender impose a limit on the number 127 of outstanding messages present on: 129 A) each stream, and/or 131 B) the whole association. 133 The SCTP message limit extension provides a method for minimizing 134 the occurrence of a lack of resources needed for messages even 135 when resources for payload data are still available. This can 136 become important when handling a large number of short messages. 138 2. Conventions 140 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 141 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 142 they appear in this document, are to be interpreted as described in 143 RFC 2119 [RFC2119]. 145 3. Additional Chunks and Parameters 147 This section describes the addition of two new chunks and, eight 148 new parameters to allow: 150 - Dynamic addition of IP Addresses to an association. 151 - Dynamic deletion of IP Addresses to an association. 152 - A request to set the primary address the peer will 153 use when sending to an endpoint. 154 - The setting of stream byte limits. 155 - The setting of stream message limits. 156 - The setting of association message limits. 158 Additionally, this section describes three new error causes that 159 support these new chunks and parameters. 161 3.1 New Chunk Types 163 This section defines two new chunk types that will be used to 164 transfer the control information reliably. Table 1 illustrates the 165 two new chunk types. 167 Chunk Type Chunk Name 168 -------------------------------------------------------------- 169 0xC1 Address/Stream Configuration Change Chunk (ASCONF) 170 0x80 Address Configuration Acknowledgment (ASCONF-ACK) 172 Table 1: Address/Stream Configuration Chunks 174 It should be noted that the ASCONF Chunk format requires the 175 receiver to report to the sender if it does not understand the 176 ASCONF Chunk. This is accomplished by setting the upper bits in the 177 chunk type as described in [RFC2960] section 3.2. Note that the 178 upper two bits in the ASCONF Chunk are set to one. As defined in 179 [RFC2960] section 3.2, setting these upper bits in this manner will 180 cause the receiver that does not understand this chunk to skip the 181 chunk and continue processing, but report in an Operation Error 182 Chunk using the 'Unrecognized Chunk Type' cause of error. 184 3.1.1 Address/Stream Configuration Change Chunk (ASCONF) 186 This chunk is used to communicate to the remote endpoint one of the 187 configuration change requests that MUST be acknowledged. The 188 information carried in the ASCONF Chunk uses the form of a 189 Tag-Length-Value (TLV), as described in "3.2.1 190 Optional/Variable-length Parameter Format" in [RFC2960], for 191 all variable parameters. 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Type = 0xC1 | Chunk Flags | Chunk Length | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Serial Number | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Reserved | Addr Type | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Address Bytes 0-3 | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Address Bytes 4-7 | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Address Bytes 8-11 | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Address Bytes 12-15 | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | ASCONF-Request Correlation ID #1 | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | ASCONF Parameter #1 | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 \ \ 215 / .... / 216 \ \ 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | ASCONF-Request Correlation ID #N | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | ASCONF Parameter #N | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Serial Number : 32 bits (unsigned integer) 225 This value represents a Serial Number for the ASCONF Chunk. The 226 valid range of Serial Number is from 0 to 4294967295 (2**32 - 1). 227 Serial Numbers wrap back to 0 after reaching 4294967295. 229 Reserved: 24 bits 231 Reserved, set to 0 by the sender and ignored by the 232 receiver. 234 Address Type : 8 bits (unsigned char) 236 This value determines the type of address found in the 237 Address Bytes field. If the value is 5 then the first 238 4 bytes of the Address Bytes field contain an IPv4 address, 239 in network byte order. If the value is 6 then the first 240 16 bytes of the Address Bytes field contain an IPv6 address, 241 in network byte order. 243 Address Bytes: 16 bytes (unsigned chars) 245 This field contains an address which is part of the association. 246 This field may be used by the receiver of the ASCONF to help 247 in finding the association. 249 ASCONF-Request Correlation ID: 32 bits (unsigned integer) 251 This is an opaque integer assigned by the sender to identify each 252 request parameter. It is in host byte order and is only meaningful 253 to the sender. The receiver of the ASCONF Chunk will copy this 32 254 bit value into the ASCONF Correlation ID field of the 255 ASCONF-ACK. The sender of the ASCONF can use this same value in the 256 ASCONF-ACK to find which request the response is for. 258 ASCONF Parameter: TLV format 260 Each Address configuration change is represented by a TLV 261 parameter as defined in Section 3.2. One or more requests 262 may be present in an ASCONF Chunk. 264 3.1.2 Address/Stream Configuration Acknowledgment Chunk (ASCONF-ACK) 266 This chunk is used by the receiver of an ASCONF Chunk to acknowledge 267 the reception. It carries zero or more results for any ASCONF 268 Parameters that were processed by the receiver. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Type = 0x80 | Chunk Flags | Chunk Length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Serial Number | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | ASCONF-Request Correlation ID #1 | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | ASCONF Parameter Response#1 | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 \ \ 282 / .... / 283 \ \ 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | ASCONF-Request Correlation ID #N | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | ASCONF Parameter Response#N | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Serial Number : 32 bits (unsigned integer) 292 This value represents the Serial Number for the received ASCONF Chunk 293 that is acknowledged by this chunk. This value is 294 copied from the received ASCONF Chunk. 296 ASCONF-Request Correlation ID: 32 bits (unsigned integer) 298 This value is copied from the ASCONF Correlation ID received in the 299 ASCONF Chunk. It is used by the receiver of the ASCONF-ACK to identify 300 which ASCONF parameter this response is associated with. 302 ASCONF Parameter Response : TLV format 304 The ASCONF Parameter Response is used in the ASCONF-ACK to report 305 status of ASCONF processing. By default, if a responding endpoint 306 does not include any Error Cause, a success is indicated. Thus a 307 sender of an ASCONF-ACK MAY indicate complete success of all TLVs in 308 an ASCONF by returning only the Chunk Type, Chunk Flags, Chunk Length 309 (set to 8) and the Serial Number. 311 3.2 New Parameter Types 313 The eight new parameters added follow the format defined in section 314 3.2.1 of [RFC2960]. Table 2 describes the parameters. 316 Address Configuration Parameters Parameter Type 317 ------------------------------------------------- 318 Add IP Address 0xC001 319 Delete IP Address 0xC002 320 Stream Byte Limit Request 0xC003 321 Error Cause Indication 0xC004 322 Set Primary Address 0xC005 323 Success report 0xC006 324 Stream Message Limit Request 0xC007 325 Association Message Limit Request 0xC008 327 Table 2: Address Configuration Parameters 329 3.2.1 Add IP Address 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type = 0xC001 | Length = Variable | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Address Parameter | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Address Parameter: TLV 341 This field contains an IPv4 or IPv6 address parameter as described 342 in 3.3.2.1 of RFC2960. The complete TLV is wrapped within this 343 parameter. It informs the receiver that the address specified is to 344 be added to the existing association. 346 An example TLV requesting that the IPv4 address 10.1.1.1 be 347 added to the association would look as follows: 349 +--------------------------------+ 350 | Type=0xC001 | Length = 12 | 351 +--------------------------------+ 352 | Type=5 | Length = 8 | 353 +----------------+---------------+ 354 | Value=0x0a010101 | 355 +----------------+---------------+ 357 Valid Chunk Appearance 359 The Add IP Address parameter may only appear in the ASCONF Chunk 360 type. 362 3.2.2 Delete IP Address 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type =0xC002 | Length = Variable | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Address Parameter | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Address Parameter: TLV 374 This field contains an IPv4 or IPv6 address parameter as described in 375 3.3.2.1 of [RFC2960]. The complete TLV is wrapped within this 376 parameter. It informs the receiver that the address specified is to 377 be removed from the existing association. 379 An example TLV deleting the IPv4 address 10.1.1.1 from an existing 380 association would look as follows: 382 +--------------------------------+ 383 | Type=0xC002 | Length = 12 | 384 +--------------------------------+ 385 | Type=5 | Length = 8 | 386 +----------------+---------------+ 387 | Value=0x0a010101 | 388 +----------------+---------------+ 390 Valid Chunk Appearance 392 The Delete IP Address parameter may only appear in the ASCONF Chunk 393 type. 395 3.2.3 Stream Flow Limit Change 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type =0xC003 | Length = Variable | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Stream Number 1 | Byte Limit 1 | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 \ / 405 / \ 406 \ / 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Stream Number N | Byte Limit N | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Stream Number n : 16 bits (unsigned integer) 413 This is the stream number for which a limit is to be enforced. 415 Byte Limit n : 16 bits (unsigned integer) 417 This is the limit (in bytes) that the receiver (sending the chunk) 418 is requesting that the sender (receiver of the chunk) enforce as 419 the maximum amount of outstanding data permitted at any time on 420 this stream, as per the rules in Section 4.5. Note that the value 421 '0' holds a special meaning described in Section 4.5.1 423 Valid Chunk Appearance 425 The Stream Flow Limit Change parameter may appear in the ASCONF 426 chunk, the INIT, or the INIT-ACK chunk type. The inclusion of this 427 parameter in the INIT or INIT-ACK can be used to indicate initial 428 byte limits. 430 3.2.4 Error Cause Indication 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type = 0xC004 | Length = Variable | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Error Cause(s) or Return Info on Success | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 When reporting an error this response parameter is used to wrap 441 one or more standard error causes normally found within an SCTP 442 Operational Error or SCTP Abort (as defined in [RFC2960]). The 443 Error Cause(s) follow the format defined in section 3.3.10 of 444 [RFC2960]. 446 Valid Chunk Appearance 448 The Error Cause Indication parameter may only appear in the 449 ASCONF-ACK chunk type. 451 3.2.5 Set Primary IP Address 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Type =0xC005 | Length = Variable | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Address Parameter | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Address Parameter: TLV 463 This field contains an IPv4 or IPv6 address parameter as described in 464 3.3.2.1 of [RFC2960]. The complete TLV is wrapped within this 465 parameter. It requests the receiver to mark the specified address 466 as the primary address to send data to (see section 5.1.2 of 467 [RFC2960]). The receiver MAY mark this as its primary upon 468 receiving this request. 470 An example TLV requesting that the IPv4 address 10.1.1.1 be made the 471 primary destination address would look as follows: 473 +--------------------------------+ 474 | Type=0xC005 | Length = 12 | 475 +--------------------------------+ 476 | Type=5 | Length = 8 | 477 +----------------+---------------+ 478 | Value=0x0a010101 | 479 +----------------+---------------+ 481 Valid Chunk Appearance 482 The Set Primary IP Address parameter may appear in the ASCONF Chunk, 483 the INIT, or the INIT-ACK chunk type. The inclusion of this parameter 484 in the INIT or INIT-ACK can be used to indicate an initial preference 485 of primary address. 487 3.2.6 Success Indication 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Type = 0xC006 | Length = 4 | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 By default if a responding endpoint does not report an error for any 496 requested TLV, a success is implicitly indicated. Thus a sender of a 497 ASCONF-ACK MAY indicate complete success of all TLVs in an ASCONF by 498 returning only the Chunk Type, Chunk Flags, Chunk Length (set to 8) 499 and the Serial Number. 501 The responding endpoint MAY also choose to explicitly report a 502 success for a requested TLV, by returning a success report ASCONF 503 Parameter Response. 505 Valid Chunk Appearance 507 The Success Indication parameter may only appear in the ASCONF-ACK 508 chunk type. 510 3.2.7 Stream Message Limit Change 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Type =0xC007 | Length = Variable | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Stream Number 1 | Message Limit 1 | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 \ / 520 / \ 521 \ / 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Stream Number N | Message Limit N | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Stream Number n : 16 bits (unsigned integer) 528 This is the stream number for which a limit is to be enforced. 530 Message Limit n : 16 bits (unsigned integer) 532 This is the limit (in messages) that the receiver (sending the 533 chunk) is requesting that the sender (receiver of the chunk) 534 enforce as the maximum number of outstanding messages permitted at 535 any time on this stream, as per the rules in Section 4.5. Note 536 that the value '0' holds a special meaning described in Section 537 4.5.1. 539 Valid Chunk Appearance 541 The Stream Message Limit Change parameter may appear in the ASCONF 542 chunk, the INIT, or the INIT-ACK chunk type. The inclusion of this 543 parameter in the INIT or INIT-ACK can be used to indicate initial 544 stream message limits. 546 3.2.8 Association Message Limit Change 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Type =0xC008 | Length = 8 | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Association Message Limit | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Association Message Limit n : 32 bits (unsigned integer) 558 This is the limit (in messages) that the receiver (sending the 559 chunk) is requesting that the sender (receiver of the chunk) 560 enforce as the maximum number of outstanding messages permitted at 561 any time on the association, as per the rules in Section 4.6. 562 Note that the value 0 holds a special meaning described in Section 563 4.5.1 565 Valid Chunk Appearance 567 The Association Message Limit Change parameter may appear in the 568 ASCONF Chunk, the INIT, or the INIT-ACK chunk type. The inclusion 569 of this parameter in the INIT or INIT-ACK can be used to indicate 570 an initial association message limit. 572 3.3 New Error Causes 574 Three new Error Causes are added to the SCTP Operational Errors, 575 primarily for use in the ASCONF-ACK chunk. 577 Cause Code 578 Value Cause Code 579 --------- ---------------- 580 0xC Request to Delete Last Remaining IP Address. 581 0xD Operation Refused Due to Resource Shortage. 582 0xE Request to Delete Source IP Address. 584 Table 3: New Error Causes 586 3.3.1 Error Cause: Request to Delete Last Remaining IP Address 588 Cause of error 589 --------------- 590 Request to Delete Last Remaining IP address: The receiver of this 591 error sent a request to delete the last IP address from its 592 association with its peer. This error indicates that the request is 593 rejected. 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Cause Code=0x000C | Cause Length=Variable | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 \ TLV-Copied-From-ASCONF / 601 / \ 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 An example of a failed delete in an Error Cause TLV would look as 605 follows in the response ASCONF-ACK message: 607 +--------------------------------+ 608 | Type = 0xC004 | Length = 20 | 609 +--------------------------------+ 610 | Cause=0x000C | Length = 16 | 611 +----------------+---------------+ 612 | Type= 0xC002 | Length = 12 | 613 +----------------+---------------+ 614 | Type=0x0005 | Length = 8 | 615 +----------------+---------------+ 616 | Value=0x0A010101 | 617 +----------------+---------------+ 619 3.3.2 Error Cause: Operation Refused Due to Resource Shortage 621 Cause of error 622 --------------- 623 This error cause is used to report a failure by the receiver to 624 perform the requested operation due to a lack of resources. The 625 entire TLV that is refused is copied from the ASCONF-REQ into the 626 error cause. 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Cause Code=0x000D | Cause Length=Variable | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 \ TLV-Copied-From-ASCONF / 634 / \ 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 An example of a failed addition in an Error Cause TLV would look as 638 follows in the response ASCONF-ACK message: 640 +--------------------------------+ 641 | Type = 0xC004 | Length = 20 | 642 +--------------------------------+ 643 | Cause=0x000D | Length = 16 | 644 +----------------+---------------+ 645 | Type=0xC001 | Length = 12 | 646 +--------------------------------+ 647 | Type=0x0005 | Length = 8 | 648 +----------------+---------------+ 649 | Value=0x0A010101 | 650 +----------------+---------------+ 652 3.3.3 Error Cause: Request to Delete Source IP Address 654 Cause of error 655 --------------- 656 Request to Delete Source IP Address: The receiver of this error sent 657 a request to delete the source IP address of the ASCONF 658 message. This error indicates that the request is rejected. 660 0 1 2 3 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Cause Code=0x000E | Cause Length=Variable | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 \ TLV-Copied-From-ASCONF / 666 / \ 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 An example of a failed delete in an Error Cause TLV would look as 670 follows in the response ASCONF-ACK message: 672 +--------------------------------+ 673 | Type = 0xC004 | Length = 20 | 674 +--------------------------------+ 675 | Cause=0x000E | Length = 16 | 676 +----------------+---------------+ 677 | Type=0xC002 | Length = 12 | 678 +----------------+---------------+ 679 | Type=0x0005 | Length = 8 | 680 +----------------+---------------+ 681 | Value=0x0A010101 | 682 +----------------+---------------+ 684 IMPLEMENTATION NOTE: It is unlikely that an endpoint would source 685 a packet from the address being deleted, unless the endpoint 686 does not do proper source address selection. 688 4. Procedures 690 This section will lay out the specific procedures for address/stream 691 configuration change chunk type and its processing. 693 4.1 ASCONF Chunk Procedures 695 When an endpoint has an ASCONF signaled change to be sent to the 696 remote endpoint it should do the following: 698 A1) Create an ASCONF Chunk as defined in section 3.1.1. The chunk 699 should contain all of the TLV(s) of information necessary to be 700 sent to the remote endpoint, and unique correlation identities for 701 each request. 703 A2) A serial number should be assigned to the Chunk. The serial 704 number should be a monotonically increasing number. All serial 705 numbers are defined to be initialized at the start of the 706 association to the same value as the Initial TSN. 708 A3) If no ASCONF Chunk is outstanding (un-acknowledged) with the 709 remote peer, AND there is less than cwnd bytes of user data 710 outstanding, send the chunk. 712 A4) Start a T-4 RTO timer, using the RTO value of the selected 713 destination address (normally the primary path; see [RFC2960] section 714 6.4 for details). 716 A5) When the ASCONF-ACK that acknowledges the serial number last 717 sent arrives, stop the T-4 RTO timer, and clear the appropriate 718 association and destination error counters as defined in [RFC2960] 719 section 8.1 and 8.2. 721 A6) Process all of the TLVs within the ASCONF-ACK to find out 722 particular status information returned to the various requests that 723 were sent. Use the Correlation IDs to correlate the request and the 724 responses. 726 A7) If an error response is received for a TLV parameter, 727 all TLVs with no response before the failed TLV are considered 728 successful if not reported. All TLVs after the failed response are 729 considered unsuccessful unless a specific success indication is 730 present for the parameter. 732 A8) If there is no response(s) to specific TLV parameter(s), and no 733 failures are indicated, then all request(s) are considered 734 successful. 736 If the T-4 RTO timer expires the endpoint should do the following: 738 B1) Increment the error counters and perform path failure detection 739 on the appropriate destination address as defined in [RFC2960] 740 section 8.1 and 8.2. Note error counters include the per destination 741 error counter as well as the overall association error counter. 743 B2) Increment the association error counters and perform endpoint 744 failure detection on the association as defined in [RFC2960] section 745 8.1 and 8.2. Note error counters include the per destination 746 error counter as well as the overall association error counter. 748 B3) Back-off the destination address RTO timer to which the ASCONF 749 chunk was sent by doubling the RTO timer value. 751 B4) Re-transmit the ASCONF Chunk last sent and if possible choose an 752 alternate destination address (please refer to [RFC2960] section 753 6.4.1). An endpoint MUST NOT add new parameters to this chunk, it 754 MUST be the same (including its serial number) as the last ASCONF 755 sent. 757 B5) Restart the T-4 RTO timer. Note that if a different destination is 758 selected, then the RTO used will be that of the new destination 759 address. 761 Note: the total number of re-transmissions is limited by B2 762 above. If the maximum is reached, the association will fail and enter 763 a CLOSED state (see [RFC2960] section 6.4.1 for details). 765 4.1.1 Congestion Control of ASCONF Chunks 767 In defining the ASCONF Chunk transfer procedures, it is essential 768 that these transfers MUST NOT cause congestion within the network. 769 To achieve this, we place these restrictions on the transfer of 770 ASCONF Chunks: 772 R1) One and only one ASCONF Chunk MAY be in transit and 773 unacknowledged at any one time. If a sender, after sending an ASCONF 774 chunk, decides it needs to transfer another ASCONF Chunk, it MUST 775 wait until the ASCONF-ACK Chunk returns from the previous ASCONF 776 Chunk before sending a subsequent ASCONF. Note this restriction 777 binds each side, so at any time two ASCONF may be in-transit on any 778 given association (one sent from each endpoint). 780 R2) A ASCONF MUST NOT be sent if there is no room in the current 781 cwnd. If there is room in the cwnd of the destination network, the 782 Chunk may be sent regardless of the value of rwnd. 784 R3) A ASCONF may be bundled with any other chunk type (except other 785 ASCONF Chunks) as long as the source address in the IP header of 786 the packet is already a part of the association. If the ASCONF 787 chunk is using an alternate source address as the source in 788 the IP header, then NO other chunks may be bundled with the ASCONF 789 chunk. 791 R4) A ASCONF-ACK may be bundled with any other chunk type except 792 other ASCONF-ACKs. 794 R5) Both ASCONF and ASCONF-ACK chunks MUST NOT be sent in any SCTP 795 state except ESTABLISHED. 797 R6) An ASCONF MUST NOT be larger than the path MTU of the destination. 799 R7) An ASCONF-ACK SHOULD not be larger than the path MTU. In some 800 circumstances a ASCONF-ACK may exceed the path MTU and in such 801 a case IP fragmentation must be used. 803 If the sender of an ASCONF Chunk receives a Operational Error 804 indicating that the ASCONF chunk type is not understood, then the 805 sender MUST not send subsequent ASCONF Chunks to the peer. The 806 endpoint should also inform the upper layer application that the 807 peer endpoint does not support any of the extensions detailed in this 808 document. 810 4.2 Upon reception of an ASCONF Chunk. 812 When an endpoint receives an ASCONF Chunk from the remote peer 813 special procedures MAY be needed to identify the association 814 the ASCONF Chunk is associated with. To properly find the 815 association the following procedures should be followed: 817 L1) Use the source address and port number of the sender to 818 attempt to identify the association (i.e. use the same method 819 defined in [RFC2960] used for all other SCTP chunks ). If found 820 proceed to rule L5. 822 L2) If the association is not found, use the address found 823 in the Address Bytes field combined with the port number 824 found in the SCTP common header. If found proceed to rule 825 L4. 827 L3) If neither L1 or L2 locates the association, treat 828 the chunk as an Out Of The Blue chunk as defined in 829 [RFC2960]. 831 L4) Verify that no other chunk is bundled with the ASCONF 832 chunk. If other chunks are bundled with the ASCONF Chunk 833 then the receiver MUST silently discard the ASCONF chunk. 835 L5) Follow the normal rules to validate the SCTP verification 836 tag found in [RFC2960]. 838 After identification and verification of the association, 839 the following should be performed to properly process the ASCONF Chunk: 841 C1) Compare the value of the serial number to the value the endpoint 842 stored in a new association variable 'Peer-Serial-Number'. This 843 value MUST be initialized to the Initial TSN value minus 1. 845 C2) If the value found in the serial number is equal to the the 846 ('Peer-Serial-Number' + 1), the endpoint should: 848 V1) Process the TLVs contained within the Chunk performing the 849 appropriate actions as indicated by each TLV type. The TLVs MUST 850 be processed in order within the Chunk. For example, if the sender 851 puts 3 TLVs in one chunk, the first TLV (the one closest to the 852 Chunk Header) in the Chunk MUST be processed first. The next TLV in 853 the chunk (the middle one) MUST be processed second and finally the 854 last TLV in the Chunk MUST be processed last. 856 V2) In processing the chunk, the receiver should build a response 857 message with the appropriate error TLVs, as specified in the 858 Parameter type bits for any ASCONF Parameter it does not understand. 859 To indicate an unrecognized parameter, parameter type 8 as defined 860 in in the INIT-ACK in 3.3.3 of [RFC2960] should be used. The 861 endpoint may also use the response to carry rejections for other 862 reasons such as resource shortages etc using the Error Cause TLV and 863 an appropriate error condition. 865 Note: a positive response is implied if no error is indicated by the 866 sender. 868 V3) All error responses MUST copy the ASCONF-Request Correlation ID 869 field received in the ASCONF, from the TLV being responded to, into 870 the ASCONF-Request Correlation ID field. The ASCONF-Request 871 Correlation ID always precedes the request TLV. 873 V4) After processing the entire Chunk, it MUST send all TLVs for 874 both unrecognized parameters and any other status TLVs inside the 875 ASCONF-ACK chunk that acknowledges the arrival and processing of the 876 ASCONF Chunk. 878 V5) Update the 'Peer-Serial-Number' to the value found in the serial 879 number field. 881 C3) If the value found in the serial number is equal to the value 882 stored in the 'Peer-Serial-Number', the endpoint should: 884 X1) Parse the ASCONF Chunk TLVs but the endpoint MUST NOT take any 885 action on the TLVs parsed (since it has already performed these 886 actions). 888 X2) Build a response message with the appropriate response TLVs 889 as specified in the ASCONF Parameter type bits, for any 890 parameter it does not understand or could not process. 892 X3) After parsing the entire Chunk, it MUST send any response 893 TLV errors and status with an ASCONF-ACK chunk acknowledging the 894 arrival and processing of the ASCONF Chunk. 896 X4) The endpoint MUST NOT update its 'Peer-Serial-Number'. 898 IMPLEMENTATION NOTE: As an optimization a receiver may wish to save 899 the last ASCONF-ACK for some predetermined period of time and 900 instead of re-processing the ASCONF (with the same serial number) it 901 may just re-transmit the ASCONF-ACK. It may wish to use the arrival 902 of a new serial number to discard the previously saved ASCONF-ACK or 903 any other means it may choose to expire the saved ASCONF-ACK. 905 C4) Otherwise, the ASCONF Chunk is discarded since it must be either 906 a stale packet or from an attacker. A receiver of such a packet MAY 907 log the event for security purposes. 909 C5) In both cases C2 and C3 the ASCONF-ACK MUST be sent back to the 910 source address contained in the IP header of the ASCONF being 911 responded to. 913 4.3 General rules for address manipulation 915 When building TLV parameters for the ASCONF Chunk that 916 will add or delete IP addresses the following rules should be 917 applied: 919 D1) When adding an IP address to an association, the IP address is 920 NOT considered fully added to the association until the ASCONF-ACK 921 arrives. This means that until such time as the ASCONF containing 922 the add is acknowledged the sender MUST NOT use the new IP address 923 as a source for ANY SCTP chunks besides an ASCONF Chunk. 924 The receiver of the add IP address request may use the 925 address as a destination immediately. 927 D2) After the ASCONF-ACK of an IP address add arrives, the 928 endpoint MAY begin using the added IP address as a source 929 address for any type of SCTP chunk. 931 D3a) If an endpoint receives an Error Cause TLV indicating that the 932 IP address Add or IP address Deletion parameters was not understood, 933 the endpoint MUST consider the operation failed and MUST NOT attempt 934 to send any subsequent Add or Delete requests to the peer. 936 D3b) If an endpoint receives an Error Cause TLV indicating that the 937 IP address Set Primary IP Address parameter was not understood, 938 the endpoint MUST consider the operation failed and MUST NOT attempt 939 to send any subsequent Set Primary IP Address requests to the peer. 941 D4) When deleting an IP address from an association, the IP address 942 MUST be considered a valid destination address for the reception of 943 SCTP packets until the ASCONF-ACK arrives and MUST NOT be used as a 944 source address for any subsequent packets. This means that any 945 datagrams that arrive before the ASCONF-ACK destined to the IP address 946 being deleted MUST be considered part of the current 947 association. One special consideration is that ABORT chunks arriving 948 destined to the IP address being deleted MUST be ignored (see 949 Section 4.3.1 for further details). 951 D5) An endpoint MUST NOT delete its last remaining IP address from an 952 association. In other words if an endpoint is NOT multi-homed it 953 MUST NOT use the delete IP address. Or if an endpoint sends multiple 954 requests to delete IP addresses it MUST NOT delete all of the IP 955 addresses that the peer has listed for the requester. 957 D6) An endpoint MUST NOT set a IP header source address for an SCTP 958 packet holding the ASCONF Chunk to be the same as an address being 959 deleted by the ASCONF Chunk. 961 D7) If a request is received to delete the last remaining IP address 962 of a peer endpoint, the receiver MUST send an Error Cause TLV with 963 the error cause set to the new error code 'Request to Delete Last 964 Remaining IP Address'. The requested delete MUST NOT be performed or 965 acted upon, other than to send the ASCONF-ACK. 967 D8) If a request is received to delete an IP address which is also 968 the source address of the IP packet which contained the ASCONF 969 chunk, the receiver MUST reject this request. To reject the request 970 the receiver MUST send an Error Cause TLV set to the new error code 971 'Request to Delete Source IP Address' (unless Rule D5 has also been 972 violated, in which case the error code 'Request to Delete Last 973 Remaining IP Address' is sent). 975 D9) If an endpoint receives an ADD IP address request and does not 976 have the local resources to add this new address to the association, 977 it MUST return an Error Cause TLV set to the new error code 978 'Operation Refused Due to Resource Shortage'. 980 D10) If an endpoint receives an 'Out of Resource' error in response 981 to its request to ADD an IP address to an association, it must 982 either ABORT the association or not consider the address part of the 983 association. In other words if the endpoint does not ABORT the 984 association, it must consider the add attempt failed and NOT use 985 this address and treat SCTP packets destined to the address as Out 986 Of The Blue packets. 988 D11) When an endpoint receiving an ASCONF to add an IP address sends 989 an 'Out of Resource' in its response, it MUST also fail any 990 subsequent add or delete requests bundled in the ASCONF. The 991 receiver MUST NOT reject an ADD and then accept a subsequent DELETE 992 of an IP address in the same ASCONF Chunk. In other words, once a 993 receiver begins failing any ADD or DELETE request, it must fail all 994 subsequent ADD or DELETE requests contained in that single ASCONF. 996 D12) When an endpoint receives a request to delete an IP address 997 that is the current primary address, it is an implementation 998 decision as to how that endpoint chooses the new primary address. 1000 D13) When an endpoint receives a valid request to DELETE an IP 1001 address the endpoint MUST consider the address no longer as part of 1002 the association. It MUST NOT send SCTP packets for the association 1003 to that address and it MUST treat subsequent packets received from 1004 that address as Out Of The Blue. 1006 During the time interval between sending out the ASCONF and 1007 receiving the ASCONF-ACK it MAY be possible to receive DATA chunks 1008 out of order. The following examples illustrate these problems: 1010 Endpoint-A Endpoint-Z 1011 ---------- ---------- 1012 ASCONF[Add-IP:X]------------------------------> 1013 /--ASCONF-ACK 1014 / 1016 /--------/---New DATA: 1017 / / Destination 1018 <-------------------/ / IP:X 1019 / 1020 <--------------------------/ 1022 In the above example we see a new IP address (X) being added to 1023 the Endpoint-A. However due to packet re-ordering in the network 1024 a new DATA chunk is sent and arrives at Endpoint-A before 1025 the ASCONF-ACK confirming the add of the address to the association. 1027 A similar problem exists with the deletion of an IP address as 1028 follows: 1030 Endpoint-A Endpoint-Z 1031 ---------- ---------- 1032 /------------New DATA: 1033 / Destination 1034 / IP:X 1035 ASCONF [DEL-IP:X]---------/----------------> 1036 <-----------------/------------------ASCONF-ACK 1037 / 1038 / 1039 <-------------/ 1041 In this example we see a DATA chunk destined to the IP:X (which is 1042 about to be deleted) arriving after the deletion is complete. 1043 For the ADD case an endpoint SHOULD consider the newly adding IP 1044 address valid for the association to receive data from during the 1045 interval when awaiting the ASCONF-ACK. The endpoint MUST NOT source 1046 data from this new address until the ASCONF-ACK arrives but it may 1047 receive out of order data as illustrated and MUST NOT treat this 1048 data as an OOTB datagram (please see [RFC2960] section 8.4). It MAY 1049 drop the data silently or it MAY consider it part of the association 1050 but it MUST NOT respond with an ABORT. 1052 For the DELETE case, an endpoint MAY respond to the late arriving DATA 1053 packet as an OOTB datagram or it MAY hold the deleting IP address for a 1054 small period of time as still valid. If it treats the DATA packet as 1055 an OOTB the peer will silently discard the ABORT (since by the time 1056 the ABORT is sent the peer will have removed the IP address from this 1057 association). If the endpoint elects to hold the IP address valid for 1058 a period of time, it MUST NOT hold it valid longer than 2 RTO 1059 intervals for the destination being removed. 1061 4.3.1 A special case for OOTB ABORT chunks 1063 Another case worth mentioning is illustrated below: 1065 Endpoint-A Endpoint-Z 1066 ---------- ---------- 1068 New DATA:------------\ 1069 Source IP:X \ 1070 \ 1071 ASCONF-REQ[DEL-IP:X]----\------------------> 1072 \ /---------ASCONF-ACK 1073 \ / 1074 \----/-----------> OOTB 1075 (Ignored <---------------------/-------------ABORT 1076 by rule D4) / 1077 <---------------------/ 1079 For this case, during the deletion of an IP address, an 1080 Abort MUST be ignored if the destination address of the 1081 Abort message is that of a destination being deleted. 1083 4.3.2 A special case for changing an address. 1085 In some instances the sender may only have one IP address in an 1086 association that is being renumbered. When this occurs, the sender 1087 may not be able to send to the peer the appropriate ADD/DELETE pair 1088 and use the old address as a source in the IP header. For this 1089 reason the sender MUST fill in the Address Bytes field with an 1090 address that is part of the association (in this case the one being 1091 deleted). This will allow the receiver to locate the association 1092 without using the source address found in the IP header. Such 1093 an SCTP packet MUST NOT be bundled with any other chunk. 1095 The receiver of such an ASCONF chunk MUST NOT process the 1096 SCTP packet if any other chunks are contained inside the SCTP 1097 packet. The receiver MUST always first use the source address 1098 found in the IP header in looking up the association. The 1099 receiver should attempt to use the address found in the Address 1100 Bytes field only if the lookup fails using the source address from 1101 the IP header. The receiver MUST NOT reply to the source address 1102 of the packet in this special case, but to the new address that 1103 was added by the ASCONF (since the old address is no longer a part 1104 of the association after processing). 1106 4.4 Setting of the primary address 1108 A sender of this option may elect to send this combined with 1109 a deletion or addition of an address. A sender SHOULD only send 1110 a set primary request to an address that is already considered 1111 part of the association. In other words if a sender combines 1112 a set primary with an add of a new IP address the set primary 1113 will be discarded unless the add request is to be processed 1114 BEFORE the set primary (i.e. it precedes the set primary). 1116 A request to set primary MAY also appear in a INIT or INIT-ACK 1117 chunk. This can give advice to the peer endpoint as to which 1118 of its addresses the sender of the INIT or INIT-ACK would like 1119 to be used as the primary address. 1121 The request to set an address as the primary path is an option the 1122 receiver SHOULD perform. It is considered advice to the receiver of 1123 the best destination address to use in sending SCTP packets (in the 1124 requester's view). If a request arrives that asks the receiver to 1125 set an address as primary that does not exist, the receiver should 1126 NOT honor the request, leaving its existing primary address 1127 unchanged. 1129 4.5 Stream Flow Limit and Message Limit Procedures 1131 A stream in SCTP is an uni-directional logical channel established 1132 from one to another associated SCTP endpoint, within which all user 1133 messages are delivered in sequence except for those submitted to the 1134 un-ordered delivery service which may arrive out of sequence. Since 1135 each stream is uni-directional and no feedback mechanism exists to 1136 limit a sender, it is possible for one unique stream to monopolize 1137 all of the transport level receiver window space. The mechanism 1138 defined here attempts to alleviate this problem by allowing the 1139 receiver side to communicate to the sender a limit on how much 1140 outstanding data may be sent within a particular stream. 1142 The procedures defined here are broken down into two sides: 1144 o The stream receiver side or peer requesting the limit. And, 1146 o the stream sender side or peer that MUST honor the limit request. 1148 The receiver's side is mainly involved with sending the request to 1149 the peer. The sender's side is where the actual flow or message 1150 limit will be enforced. Note that the stream receiver is the 1151 endpoint that sends the ASCONF, INIT or INIT-ACK message (see 1152 Section 4.5.1), whereas the stream sender is the endpoint that 1153 receives the ASCONF, INIT or INIT-ACK message (see Section 4.5.2). 1155 4.5.1 Stream receiver side procedures 1157 The receiver side SCTP requests byte or message limits in response 1158 to an upper layer request. An upper layer may request, via an API 1159 interface, that a byte or message limit be imposed on all or a 1160 subset of the active streams that send data to the upper layer 1161 receiver, or that a message limit be imposed on the association. 1162 The basis on which the upper layer determines these limits is 1163 outside the scope of this document. 1165 Any time during an association that limits are requested of the SCTP 1166 endpoint by the upper layer, the receiver side SHOULD create an 1167 ASCONF Chunk and attach to a Stream Flow Limit Change, Stream 1168 Message Limit Change, or Association Message Limit Change parameter 1169 as appropriate. These parameter types MAY also be placed in an INIT 1170 or INIT-ACK chunk at the beginning of an association to request 1171 initial values for the appropriate limits. 1173 The Stream Flow Limit Change and Stream Message Limit Changes 1174 parameters contain a sequence of one or more pairs, each of which 1175 consists of a specific stream number, and a byte or message limit 1176 to be applied to that stream. 1178 If the receiver wishes to remove the flow limit or message limit 1179 for a specific stream, it may do so by placing the special value 1180 '0' in the Flow Limit or Message Limit field. Once acknowledged 1181 by the peer endpoint the receiver should consider the limit in 1182 place. 1184 In the case of flow or message limits contained within an INIT 1185 chunk, any such limit is considered acknowledged with the arrival of 1186 the INIT-ACK, provided that the peer indicates that it understands 1187 the requested limit by NOT placing an 'unrecognized parameter' error 1188 in the INIT-ACK. 1190 Similarly, for flow or message limits contained within an INIT-ACK 1191 chunk, any such limit is considered acknowledged with the arrival of 1192 the cookie, provided that the peer indicates that it understands the 1193 requested limit by NOT placing an 'unrecognized parameter' error in 1194 the cookie. 1196 To send initial limits, ASCONF chunks are NOT bundled with the INIT 1197 or INIT-ACK. Instead the TLV is added to the variable parameters 1198 section of the INIT or INIT-ACK. 1200 Note that the parameter type field upper two bits dictates that any 1201 parameter not understood should be skipped and reported to the 1202 sender with an Operational Error. With this in mind we make the 1203 following rules for the sender of the request: 1205 Z1) If an Operational Error is received that indicates that the 1206 'Stream Byte Limit Request' is not understood, the sender of the 1207 limit request MUST not send subsequent limit requests. The 1208 endpoint SHOULD also inform the upper layer application that 1209 the peer endpoint does not support this feature. 1211 Z2) If an Operational Error is received that indicates that the 1212 'Stream Message Limit Request' is not understood, the sender of 1213 the limit request MUST not send subsequent limit requests. The 1214 endpoint SHOULD also inform the upper layer application that the 1215 peer endpoint does not support this feature. 1217 4.5.2 Stream Sender side procedures 1219 When a 'Stream Byte Limit Request' or 'Stream Message Limit 1220 Request' is received the sender MUST record each limit with its 1221 appropriate stream. 1223 After a limit is set on a stream the sender MUST obey the following 1224 rules when sending to the peer on that stream: 1226 S1) When the upper layer application attempts to send to the peer on 1227 a stream, check 1228 - the number of outstanding bytes sent to that stream 1229 (those TSNs in queue to be sent, which the Cumulative TSN 1230 Acknowledgment has not passed, on this stream) versus the limit set 1231 for that stream (The last received limit for this stream is 1232 henceforth termed the current limit). 1233 - the number of outstanding messages sent on that stream (for which 1234 not all TSNs are passed by the Cumulative TSN Acknowledgment) 1235 versus the limit for this stream. 1237 S2a) If the number of outstanding bytes is greater than or equal to 1238 the current limit, the SCTP endpoint MUST reject the request and NOT 1239 queue the data for transmit. Instead it SHOULD return an error 1240 to the sending application. 1242 S2b) If the number of outstanding messages is greater or equal to 1243 the current limit, the SCTP endpoint MUST reject the request and NOT 1244 queue the data for transmit. Instead it SHOULD return an error 1245 to the sending application. 1247 S3a) If the number of outstanding bytes is less than the current 1248 limit, validate that the data to be sent plus the number of 1249 outstanding bytes is smaller than or equal to this limit. If the 1250 user data plus the number of outstanding bytes is smaller than or 1251 equal to the current limit accept the data for transmit and queue 1252 the user data (increasing the number of outstanding data bytes on 1253 this stream). If the user data plus the number of outstanding bytes 1254 is larger than the current limit for this stream, the SCTP endpoint 1255 MUST reject the request and NOT queue the data for transmit and 1256 instead SHOULD return an error to the application. 1258 S3b) If the number of outstanding messages is less than the current 1259 limit, accept the data for transmit and queue the user data 1260 (increasing the number of outstanding messages on this stream). 1262 S4) Any time a stream limit is updated to the value of 0, consider 1263 this indication to mean no limit is in effect for this stream. 1265 S5) Any stream number NOT mentioned in a limit request MUST be left 1266 unchanged. In other words failure to mention a stream in a 1267 limit request leaves the un-mentioned stream unchanged. 1269 S6) If a stream limit is reduced and the stream already exceeds 1270 the stream limit, no changes are made with respect to the 1271 outstanding data. New data request MUST be rejected however, 1272 until the streams limit will allow the sending of data (rules 1273 S2 and S3 above). 1275 NOTE: Stream limits do NOT change the underlying SCTP rwnd and 1276 its usage as defined in [RFC2960]. The association MUST still 1277 honor the rwnd when sending to the peer endpoint as defined in 1278 [RFC2960]. 1280 4.5.3 ULP considerations on the use of SCTP flow limit facility 1282 A side-effect of rule S3 in section 4.5.2 is that an upper limit 1283 is imposed on the size of messages that may be sent to any stream 1284 where a flow limit is in place. Once a flow limit is in effect, 1285 if the sending Upper Layer Protocol (ULP) wishes to send a message 1286 that is larger than that permitted by the imposed stream limit, 1287 the ULP will need to provide a mechanism for fragmentation and 1288 re-assembly. 1290 This ULP mechanism is in addition to any fragmentation and 1291 re-assembly that may be provided by SCTP. It is the sole 1292 responsibility of the ULP to handle the case of a single user 1293 message being larger than the stream byte limit, if applicable. 1295 4.6 Association Message Limit Procedures 1297 Using the stream flow/message limit functionality described 1298 in 4.5 it is possible for a receiver to limit the sender in 1299 a way the receiver thinks is appropriate. For an overall 1300 (per association) byte based limit the receiver can make use 1301 of the rwnd field in SACK-chunks. 1303 An overall message based limit is provided by the 'Association 1304 Message Limit Request'. This can be useful to make better use of 1305 message oriented pools (e.g. mbufs) and to limit the delivery time 1306 for messages. 1308 The procedures defined here are broken down into two sides: 1310 o The receiver side or peer requesting the limit. And, 1312 o the sender side or peer that MUST honor the limit request. 1314 The receiver's side is mainly involved with sending the request to 1315 the peer. The sender's side is where the actual limitations and flow 1316 message limit will occur. Note in section 4.6.1 the receiver 1317 is the endpoint that sends the ASCONF, INIT or INIT-ACK message, in 1318 section 4.6.2 the sender side is the endpoint that receives 1319 the ASCONF, INIT or INIT-ACK message. 1321 4.6.1 Receiver side procedures 1323 The same rules as given in 4.5.1 for the stream limits apply to the 1324 association limit. 1326 4.6.2 Sender side procedures 1328 When an 'Association Message Limit Request' is received the sender MUST 1329 record this limit for the association. 1331 After a limit is set for the association the sender MUST obey the 1332 following rules when sending to the peer on that stream: 1334 S1) When the upper layer application attempts to send to the peer on 1335 a stream, check the number of outstanding messages sent on the 1336 association (for which not all TSNs are passed by the Cumulative TSN 1337 Acknowledgment) versus the limit for this association. 1339 S2) If the number of outstanding messages is greater or equal to 1340 the current limit, the SCTP endpoint MUST reject the request and NOT 1341 queue the data for transmit. Instead it SHOULD return an error 1342 to the sending application. 1344 S3) If the number of outstanding messages is less than the current 1345 limit, accept the data for transmit and queue the user data 1346 (increasing the number of outstanding messages on this association). 1348 S4) Any time the association limit is updated to the value of 0, 1349 consider this indication to mean no limit is in effect for the 1350 Association. 1352 5. Security Considerations 1354 The ADD/DELETE of an IP address to an existing association does 1355 provide an additional mechanism by which existing associations can 1356 be hijacked. Where the attacker is able to intercept and or alter 1357 the packets sent and received in an association, the use of this 1358 feature MAY increase the ease with which an association may be 1359 overtaken. This threat SHOULD be considered when deploying a version 1360 of SCTP that makes use of this feature. The IP Authentication Header 1361 [RFC2402] SHOULD be used when the threat environment requires 1362 stronger integrity protections, but does not require 1363 confidentiality. It should be noted that in the base SCTP 1364 specification [RFC2960], if an attacker is able to intercept and or 1365 alter packets, even without this feature it is possible to hijack an 1366 existing association; please refer to Section 11 of RFC2960. 1368 6. IANA considerations 1370 This document defines the following new SCTP parameters, chunks 1371 and errors: 1373 - Two new chunk types, 1374 - Eight parameter types, and 1375 - Three new SCTP error causes. 1377 7. Acknowledgments 1379 The authors wish to thank Jon Berger, John Loughney, Ivan Arias 1380 Rodriguez, Marshall Rose, and Chip Sharp for their invaluable 1381 comments. 1383 8. Authors' Addresses 1385 Randall R. Stewart Tel: +1-815-477-2127 1386 Cisco Systems, Inc. EMail: rrs@cisco.com 1387 8745 W. Higgins Road, Suite 200 1388 Chicago, Ill 60631 1389 USA 1391 Micheal A. Ramalho Tel: +1-732-809-0188 1392 Cisco Systems, Inc. EMail: mramalho@cisco.com 1393 1802 Rue de la Porte 1394 Wall Township, NJ 0719-3784 1396 Qiaobing Xie Tel: +1-847-632-3028 1397 Motorola, Inc. EMail: qxie1@email.mot.com 1398 1501 W. Shure Drive, #2309 1399 Arlington Heights, IL 60004 1400 USA 1402 Michael Tuexen Tel: +49-89-722-47210 1403 SIEMENS AG EMail: Michael.Tuexen@icn.siemens.de 1404 Hofmannstr. 51 1405 81359 Munich 1406 Germany 1408 Ian Rytina Tel: +61-3-9301-6164 1409 Ericsson Australia EMail:ian.rytina@ericsson.com 1410 37/360 Elizabeth Street 1411 Melbourne, Victoria 3000 1412 Australia 1414 Phil Conrad Tel: +1-215-204-7910 1415 Netlab Research Group Email conrad@acm.org 1416 Dept. Of Computer & 1417 Information Sciences 1418 Temple University 1419 1805 N Broad St. 1420 Philadelphia, PA 19122 1421 USA 1423 9. References 1425 [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, 1426 H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, 1427 and, V. Paxson, "Stream Control Transmission Protocol," RFC 1428 2960, October 2000. 1430 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1431 3", RFC 2026, October 1996. 1433 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 1434 Requirement Levels", BCP 14, RFC 2119, March 1997. 1436 [RFC2402] S. Kent, R. Atkinson., "IP Authentication Header.", RFC 1437 2402, November 1998. 1439 This Internet Draft expires in 6 months from May, 2001