idnits 2.17.1 draft-ietf-tsvwg-addip-sctp-04.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 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 5 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 99: '... The keywords MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 100: '... SHOULD NOT, RECOMMENDED, NOT RECOM...' RFC 2119 keyword, line 143: '...ge requests that MUST be acknowledged....' RFC 2119 keyword, line 202: '...unk, the address MUST be considered pa...' RFC 2119 keyword, line 265: '...of an ASCONF-ACK MAY indicate complete...' (74 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 871 has weird spacing: '...er will treat...' == 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. -- 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 (January 29, 2002) is 8113 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 1090 looks like a reference -- Missing reference section? 'RFC2960' on line 1085 looks like a reference -- Missing reference section? 'RFC2119' on line 1093 looks like a reference -- Missing reference section? 'RFC2402' on line 1096 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 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 January 29, 2002 15 SCTP Extensions for Dynamic Reconfiguration of IP Addresses 17 19 Status of This Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts 23 are working documents of the Internet Engineering Task Force (IETF), 24 its areas, and its working groups. Note that other groups may also 25 distribute working documents as Internet-Drafts. 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes extensions to the Stream Control 36 Transmission Protocol (SCTP) [RFC2960] that provide methods to (1) 37 reconfigure IP address information on an existing association and 38 (2) request that a peer set flow limits in units of bytes or 39 messages, either on a per-stream or per-association basis. 41 TABLE OF CONTENTS 42 1. Introduction............................................... 2 43 2. Conventions................................................ 2 44 3. Additional Chunks and Parameters........................... 3 45 3.1 New Chunk Types........................................... 3 46 3.1.1 Address/Stream Configuration Change Chunk (ASCONF)...... 3 47 3.1.2 Address/Stream Configuration Acknowledgment Chunk 48 (ASCONF-ACK)............................................ 5 49 3.2 New Parameter Types....................................... 6 50 3.2.1 Add IP Address.......................................... 6 51 3.2.2 Delete IP Address....................................... 6 52 3.2.3 Error Cause Indication.................................. 7 53 3.2.4 Set Primary IP Address.................................. 8 54 3.2.5 Success Indication...................................... 8 55 3.2.6 Adaption Layer Indication............................... 9 56 3.3 New Error Causes.......................................... 9 57 3.3.1 Error Cause: Request to Delete Last Remaining IP Address 9 58 3.3.2 Error Cause: Operation Refused Due to Resource Shortage.10 59 3.3.3 Error Cause: Request to Delete Source IP Address........11 60 4. Procedures.................................................11 61 4.1 ASCONF Chunk Procedures...................................11 62 4.1.1 Congestion Control of ASCONF Chunks.....................13 63 4.2 Upon reception of an ASCONF Chunk.........................14 64 4.3 General rules for address manipulation....................15 65 4.3.1 A special case for OOTB ABORT chunks....................18 66 4.3.2 A special case for changing an address..................19 67 4.4 Setting of the primary address............................19 68 5. Security Considerations....................................20 69 6. IANA considerations........................................20 70 7. Authors' Addresses.........................................20 71 8. References.................................................21 73 1. Introduction 75 To extend the utility and application scenarios of SCTP, this 76 document introduces optional extensions that provide SCTP with the 77 ability to reconfigure IP address information on an existing 78 association. 80 This extension enable SCTP to be utilized in the following 81 applications: 83 - Dynamic IP address reconfiguration extension: For 84 computational or networking platforms that allow addition/removal of 85 physical interface cards this feature can provide: 87 A) a graceful method to add to the interfaces of an existing 88 association. For IPv6 this feature allows renumbering 89 of existing associations. 91 B) a method for an endpoint to request that its peer set 92 its primary destination address. This can be useful 93 when an address is about to be deleted, or when an endpoint 94 has some predetermined knowledge about which is the 95 preferred address to receive SCTP packets upon. 97 2. Conventions 99 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 100 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 101 they appear in this document, are to be interpreted as described in 102 RFC 2119 [RFC2119]. 104 3. Additional Chunks and Parameters 106 This section describes the addition of two new chunks and, eight 107 new parameters to allow: 109 - Dynamic addition of IP Addresses to an association. 110 - Dynamic deletion of IP Addresses to an association. 111 - A request to set the primary address the peer will 112 use when sending to an endpoint. 114 Additionally, this section describes three new error causes that 115 support these new chunks and parameters. 117 3.1 New Chunk Types 119 This section defines two new chunk types that will be used to 120 transfer the control information reliably. Table 1 illustrates the 121 two new chunk types. 123 Chunk Type Chunk Name 124 -------------------------------------------------------------- 125 0xC1 Address/Stream Configuration Change Chunk (ASCONF) 126 0x80 Address Configuration Acknowledgment (ASCONF-ACK) 128 Table 1: Address/Stream Configuration Chunks 130 It should be noted that the ASCONF Chunk format requires the 131 receiver to report to the sender if it does not understand the 132 ASCONF Chunk. This is accomplished by setting the upper bits in the 133 chunk type as described in [RFC2960] section 3.2. Note that the 134 upper two bits in the ASCONF Chunk are set to one. As defined in 135 [RFC2960] section 3.2, setting these upper bits in this manner will 136 cause the receiver that does not understand this chunk to skip the 137 chunk and continue processing, but report in an Operation Error 138 Chunk using the 'Unrecognized Chunk Type' cause of error. 140 3.1.1 Address/Stream Configuration Change Chunk (ASCONF) 142 This chunk is used to communicate to the remote endpoint one of the 143 configuration change requests that MUST be acknowledged. The 144 information carried in the ASCONF Chunk uses the form of a 145 Tag-Length-Value (TLV), as described in "3.2.1 146 Optional/Variable-length Parameter Format" in [RFC2960], for 147 all variable parameters. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type = 0xC1 | Chunk Flags | Chunk Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Serial Number | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Reserved | Addr Type | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Address Bytes 0-3 | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Address Bytes 4-7 | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Address Bytes 8-11 | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Address Bytes 12-15 | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | ASCONF-Request Correlation ID #1 | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | ASCONF Parameter #1 | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 \ \ 171 / .... / 172 \ \ 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | ASCONF-Request Correlation ID #N | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | ASCONF Parameter #N | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Serial Number : 32 bits (unsigned integer) 181 This value represents a Serial Number for the ASCONF Chunk. The 182 valid range of Serial Number is from 0 to 4294967295 (2**32 - 1). 183 Serial Numbers wrap back to 0 after reaching 4294967295. 185 Reserved: 24 bits 187 Reserved, set to 0 by the sender and ignored by the 188 receiver. 190 Address Type : 8 bits (unsigned char) 192 This value determines the type of address found in the 193 Address Bytes field. If the value is 5 then the first 194 4 bytes of the Address Bytes field contain an IPv4 address, 195 in network byte order. If the value is 6 then the first 196 16 bytes of the Address Bytes field contain an IPv6 address, 197 in network byte order. 199 Address Bytes: 16 bytes (unsigned chars) 201 This field contains an IP address of the sender of the ASCONF 202 chunk, the address MUST be considered part of the association 203 by the peer endpoint (the receiver of the ASCONF chunk). 204 This field may be used by the receiver of the ASCONF to help 205 in finding the association. 207 ASCONF-Request Correlation ID: 32 bits (unsigned integer) 209 This is an opaque integer assigned by the sender to identify each 210 request parameter. It is in host byte order and is only meaningful 211 to the sender. The receiver of the ASCONF Chunk will copy this 32 212 bit value into the ASCONF Correlation ID field of the 213 ASCONF-ACK. The sender of the ASCONF can use this same value in the 214 ASCONF-ACK to find which request the response is for. 216 ASCONF Parameter: TLV format 218 Each Address configuration change is represented by a TLV 219 parameter as defined in Section 3.2. One or more requests 220 may be present in an ASCONF Chunk. 222 3.1.2 Address/Stream Configuration Acknowledgment Chunk (ASCONF-ACK) 224 This chunk is used by the receiver of an ASCONF Chunk to acknowledge 225 the reception. It carries zero or more results for any ASCONF 226 Parameters that were processed by the receiver. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type = 0x80 | Chunk Flags | Chunk Length | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Serial Number | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | ASCONF-Request Correlation ID #1 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | ASCONF Parameter Response#1 | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 \ \ 240 / .... / 241 \ \ 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | ASCONF-Request Correlation ID #N | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | ASCONF Parameter Response#N | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Serial Number : 32 bits (unsigned integer) 250 This value represents the Serial Number for the received ASCONF Chunk 251 that is acknowledged by this chunk. This value is 252 copied from the received ASCONF Chunk. 254 ASCONF-Request Correlation ID: 32 bits (unsigned integer) 256 This value is copied from the ASCONF Correlation ID received in the 257 ASCONF Chunk. It is used by the receiver of the ASCONF-ACK to identify 258 which ASCONF parameter this response is associated with. 260 ASCONF Parameter Response : TLV format 262 The ASCONF Parameter Response is used in the ASCONF-ACK to report 263 status of ASCONF processing. By default, if a responding endpoint 264 does not include any Error Cause, a success is indicated. Thus a 265 sender of an ASCONF-ACK MAY indicate complete success of all TLVs in 266 an ASCONF by returning only the Chunk Type, Chunk Flags, Chunk Length 267 (set to 8) and the Serial Number. 269 3.2 New Parameter Types 271 The six new parameters added follow the format defined in section 272 3.2.1 of [RFC2960]. Table 2 describes the parameters. 274 Address Configuration Parameters Parameter Type 275 ------------------------------------------------- 276 Add IP Address 0xC001 277 Delete IP Address 0xC002 278 Error Cause Indication 0xC003 279 Set Primary Address 0xC004 280 Success report 0xC005 281 Adaption Layer Indication 0xC006 283 Table 2: Address Configuration Parameters 285 3.2.1 Add IP Address 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type = 0xC001 | Length = Variable | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Address Parameter | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Address Parameter: TLV 297 This field contains an IPv4 or IPv6 address parameter as described 298 in 3.3.2.1 of RFC2960. The complete TLV is wrapped within this 299 parameter. It informs the receiver that the address specified is to 300 be added to the existing association. 302 An example TLV requesting that the IPv4 address 10.1.1.1 be 303 added to the association would look as follows: 305 +--------------------------------+ 306 | Type=0xC001 | Length = 12 | 307 +--------------------------------+ 308 | Type=5 | Length = 8 | 309 +----------------+---------------+ 310 | Value=0x0a010101 | 311 +----------------+---------------+ 313 Valid Chunk Appearance 315 The Add IP Address parameter may only appear in the ASCONF Chunk 316 type. 318 3.2.2 Delete IP Address 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type =0xC002 | Length = Variable | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Address Parameter | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Address Parameter: TLV 329 This field contains an IPv4 or IPv6 address parameter as described in 330 3.3.2.1 of [RFC2960]. The complete TLV is wrapped within this 331 parameter. It informs the receiver that the address specified is to 332 be removed from the existing association. 334 An example TLV deleting the IPv4 address 10.1.1.1 from an existing 335 association would look as follows: 337 +--------------------------------+ 338 | Type=0xC002 | Length = 12 | 339 +--------------------------------+ 340 | Type=5 | Length = 8 | 341 +----------------+---------------+ 342 | Value=0x0a010101 | 343 +----------------+---------------+ 345 Valid Chunk Appearance 347 The Delete IP Address parameter may only appear in the ASCONF Chunk 348 type. 350 3.2.3 Error Cause Indication 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Type = 0xC003 | Length = Variable | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Error Cause(s) or Return Info on Success | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 When reporting an error this response parameter is used to wrap 361 one or more standard error causes normally found within an SCTP 362 Operational Error or SCTP Abort (as defined in [RFC2960]). The 363 Error Cause(s) follow the format defined in section 3.3.10 of 364 [RFC2960]. 366 Valid Chunk Appearance 368 The Error Cause Indication parameter may only appear in the 369 ASCONF-ACK chunk type. 371 3.2.4 Set Primary IP Address 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Type =0xC004 | Length = Variable | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Address Parameter | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Address Parameter: TLV 383 This field contains an IPv4 or IPv6 address parameter as described in 384 3.3.2.1 of [RFC2960]. The complete TLV is wrapped within this 385 parameter. It requests the receiver to mark the specified address 386 as the primary address to send data to (see section 5.1.2 of 387 [RFC2960]). The receiver MAY mark this as its primary upon 388 receiving this request. 390 An example TLV requesting that the IPv4 address 10.1.1.1 be made the 391 primary destination address would look as follows: 393 +--------------------------------+ 394 | Type=0xC004 | Length = 12 | 395 +--------------------------------+ 396 | Type=5 | Length = 8 | 397 +----------------+---------------+ 398 | Value=0x0a010101 | 399 +----------------+---------------+ 401 Valid Chunk Appearance 403 The Set Primary IP Address parameter may appear in the ASCONF Chunk, 404 the INIT, or the INIT-ACK chunk type. The inclusion of this parameter 405 in the INIT or INIT-ACK can be used to indicate an initial preference 406 of primary address. 408 3.2.5 Success Indication 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Type = 0xC005 | Length = 4 | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 By default if a responding endpoint does not report an error for any 417 requested TLV, a success is implicitly indicated. Thus a sender of a 418 ASCONF-ACK MAY indicate complete success of all TLVs in an ASCONF by 419 returning only the Chunk Type, Chunk Flags, Chunk Length (set to 8) 420 and the Serial Number. 422 The responding endpoint MAY also choose to explicitly report an 423 success for a requested TLV, by returning a success report ASCONF 424 Parameter Response. 426 Valid Chunk Appearance 428 The Success Indication parameter may only appear in the ASCONF-ACK 429 chunk type. 431 3.2.6 Adaption Layer Indication 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Type =0xC006 | Length = Variable | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Reserved Bit Fields | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 This parameter is specified for the communication of peer upper 442 layer protocols. It is envisioned to be used for flow control 443 and other adaption layers that require an indication to be 444 carried in the INITand INIT-ACK. Each adaption layer that 445 is defined that wishes to use this parameter MUST specify 446 a bit int the reserved bit field in an appropriate RFC. This 447 parameter SHOULD NOT be examined by the receiving SCTP 448 implementation and should be passed opaquely to the upper 449 layer protocol. 451 Valid Chunk Appearance 453 The Adaption Layer Indication parameter may appear in INIT or 454 INIT-ACK chunk and SHOULD be passed to the receivers upper layer 455 protocol. 457 3.3 New Error Causes 459 Three new Error Causes are added to the SCTP Operational Errors, 460 primarily for use in the ASCONF-ACK chunk. 462 Cause Code 463 Value Cause Code 464 --------- ---------------- 465 0xB Request to Delete Last Remaining IP Address. 466 0xC Operation Refused Due to Resource Shortage. 467 0xD Request to Delete Source IP Address. 469 Table 3: New Error Causes 471 3.3.1 Error Cause: Request to Delete Last Remaining IP Address 473 Cause of error 474 --------------- 475 Request to Delete Last Remaining IP address: The receiver of this 476 error sent a request to delete the last IP address from its 477 association with its peer. This error indicates that the request is 478 rejected. 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Cause Code=0x000B | Cause Length=Variable | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 \ TLV-Copied-From-ASCONF / 486 / \ 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 An example of a failed delete in an Error Cause TLV would look as 490 follows in the response ASCONF-ACK message: 492 +--------------------------------+ 493 | Type = 0xC003 | Length = 20 | 494 +--------------------------------+ 495 | Cause=0x000B | Length = 16 | 496 +----------------+---------------+ 497 | Type= 0xC002 | Length = 12 | 498 +----------------+---------------+ 499 | Type=0x0005 | Length = 8 | 500 +----------------+---------------+ 501 | Value=0x0A010101 | 502 +----------------+---------------+ 504 3.3.2 Error Cause: Operation Refused Due to Resource Shortage 506 Cause of error 507 --------------- 508 This error cause is used to report a failure by the receiver to 509 perform the requested operation due to a lack of resources. The 510 entire TLV that is refused is copied from the ASCONF-REQ into the 511 error cause. 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Cause Code=0x000C | Cause Length=Variable | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 \ TLV-Copied-From-ASCONF / 519 / \ 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 An example of a failed addition in an Error Cause TLV would look as 523 follows in the response ASCONF-ACK message: 525 +--------------------------------+ 526 | Type = 0xC003 | Length = 20 | 527 +--------------------------------+ 528 | Cause=0x000C | Length = 16 | 529 +----------------+---------------+ 530 | Type=0xC001 | Length = 12 | 531 +--------------------------------+ 532 | Type=0x0005 | Length = 8 | 533 +----------------+---------------+ 534 | Value=0x0A010101 | 535 +----------------+---------------+ 537 3.3.3 Error Cause: Request to Delete Source IP Address 539 Cause of error 540 --------------- 541 Request to Delete Source IP Address: The receiver of this error sent 542 a request to delete the source IP address of the ASCONF 543 message. This error indicates that the request is rejected. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Cause Code=0x000D | Cause Length=Variable | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 \ TLV-Copied-From-ASCONF / 551 / \ 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 An example of a failed delete in an Error Cause TLV would look as 555 follows in the response ASCONF-ACK message: 557 +--------------------------------+ 558 | Type = 0xC003 | Length = 20 | 559 +--------------------------------+ 560 | Cause=0x000D | Length = 16 | 561 +----------------+---------------+ 562 | Type=0xC002 | Length = 12 | 563 +----------------+---------------+ 564 | Type=0x0005 | Length = 8 | 565 +----------------+---------------+ 566 | Value=0x0A010101 | 567 +----------------+---------------+ 569 IMPLEMENTATION NOTE: It is unlikely that an endpoint would source 570 a packet from the address being deleted, unless the endpoint 571 does not do proper source address selection. 573 4. Procedures 575 This section will lay out the specific procedures for address/stream 576 configuration change chunk type and its processing. 578 4.1 ASCONF Chunk Procedures 580 When an endpoint has an ASCONF signaled change to be sent to the 581 remote endpoint it should do the following: 583 A1) Create an ASCONF Chunk as defined in section 3.1.1. The chunk 584 should contain all of the TLV(s) of information necessary to be 585 sent to the remote endpoint, and unique correlation identities for 586 each request. 588 A2) A serial number should be assigned to the Chunk. The serial 589 number should be a monotonically increasing number. All serial 590 numbers are defined to be initialized at the start of the 591 association to the same value as the Initial TSN. 593 A3) If no ASCONF Chunk is outstanding (un-acknowledged) with the 594 remote peer, AND there is less than cwnd bytes of user data 595 outstanding, send the chunk. 597 A4) Start a T-4 RTO timer, using the RTO value of the selected 598 destination address (normally the primary path; see [RFC2960] section 599 6.4 for details). 601 A5) When the ASCONF-ACK that acknowledges the serial number last 602 sent arrives, stop the T-4 RTO timer, and clear the appropriate 603 association and destination error counters as defined in [RFC2960] 604 section 8.1 and 8.2. 606 A6) Process all of the TLVs within the ASCONF-ACK to find out 607 particular status information returned to the various requests that 608 were sent. Use the Correlation IDs to correlate the request and the 609 responses. 611 A7) If an error response is received for a TLV parameter, 612 all TLVs with no response before the failed TLV are considered 613 successful if not reported. All TLVs after the failed response are 614 considered unsuccessful unless a specific success indication is 615 present for the parameter. 617 A8) If there is no response(s) to specific TLV parameter(s), and no 618 failures are indicated, then all request(s) are considered 619 successful. 621 If the T-4 RTO timer expires the endpoint should do the following: 623 B1) Increment the error counters and perform path failure detection 624 on the appropriate destination address as defined in [RFC2960] 625 section 8.1 and 8.2. 627 B2) Increment the association error counters and perform endpoint 628 failure detection on the association as defined in [RFC2960] section 629 8.1 and 8.2. 631 B3) Back-off the destination address RTO value to which the ASCONF 632 chunk was sent by doubling the RTO timer value. 634 Note: The RTO value is used in the setting of all timer types 635 for SCTP. Each destination address a single RTO estimate. 637 B4) Re-transmit the ASCONF Chunk last sent and if possible choose an 638 alternate destination address (please refer to [RFC2960] section 639 6.4.1). An endpoint MUST NOT add new parameters to this chunk, it 640 MUST be the same (including its serial number) as the last ASCONF 641 sent. 643 B5) Restart the T-4 RTO timer. Note that if a different destination is 644 selected, then the RTO used will be that of the new destination 645 address. 647 Note: the total number of re-transmissions is limited by B2 648 above. If the maximum is reached, the association will fail and enter 649 a CLOSED state (see [RFC2960] section 6.4.1 for details). 651 4.1.1 Congestion Control of ASCONF Chunks 653 In defining the ASCONF Chunk transfer procedures, it is essential 654 that these transfers MUST NOT cause congestion within the network. 655 To achieve this, we place these restrictions on the transfer of 656 ASCONF Chunks: 658 R1) One and only one ASCONF Chunk MAY be in transit and 659 unacknowledged at any one time. If a sender, after sending an ASCONF 660 chunk, decides it needs to transfer another ASCONF Chunk, it MUST 661 wait until the ASCONF-ACK Chunk returns from the previous ASCONF 662 Chunk before sending a subsequent ASCONF. Note this restriction 663 binds each side, so at any time two ASCONF may be in-transit on any 664 given association (one sent from each endpoint). 666 R2) A ASCONF MUST NOT be sent if there is no room in the current 667 cwnd. If there is room in the cwnd of the destination network, the 668 Chunk may be sent regardless of the value of rwnd. 670 R3) A ASCONF may be bundled with any other chunk type (except other 671 ASCONF Chunks). 673 R4) A ASCONF-ACK may be bundled with any other chunk type except 674 other ASCONF-ACKs. 676 R5) Both ASCONF and ASCONF-ACK chunks MUST NOT be sent in any SCTP 677 state except ESTABLISHED. 679 R6) An ASCONF MUST NOT be larger than the path MTU of the destination. 681 R7) An ASCONF-ACK SHOULD not be larger than the path MTU. In some 682 circumstances a ASCONF-ACK may exceed the path MTU and in such 683 a case IP fragmentation must be used. 685 If the sender of an ASCONF Chunk receives a Operational Error 686 indicating that the ASCONF chunk type is not understood, then the 687 sender MUST not send subsequent ASCONF Chunks to the peer. The 688 endpoint should also inform the upper layer application that the 689 peer endpoint does not support any of the extensions detailed in this 690 document. 692 4.2 Upon reception of an ASCONF Chunk. 694 When an endpoint receives an ASCONF Chunk from the remote peer 695 special procedures MAY be needed to identify the association 696 the ASCONF Chunk is associated with. To properly find the 697 association the following procedures should be followed: 699 L1) Use the source address and port number of the sender to 700 attempt to identify the association (i.e. use the same method 701 defined in [RFC2960] used for all other SCTP chunks ). If found 702 proceed to rule L4. 704 L2) If the association is not found, use the address found 705 in the Address Bytes field combined with the port number 706 found in the SCTP common header. If found proceed to rule 707 L4. 709 L3) If neither L1 or L2 locates the association, treat 710 the chunk as an Out Of The Blue chunk as defined in 711 [RFC2960]. 713 L4) Follow the normal rules to validate the SCTP verification 714 tag found in [RFC2960]. 716 After identification and verification of the association, 717 the following should be performed to properly process the ASCONF Chunk: 719 C1) Compare the value of the serial number to the value the endpoint 720 stored in a new association variable 'Peer-Serial-Number'. This 721 value MUST be initialized to the Initial TSN value minus 1. 723 C2) If the value found in the serial number is equal to the 724 ('Peer-Serial-Number' + 1), the endpoint MUST: 726 V1) Process the TLVs contained within the Chunk performing the 727 appropriate actions as indicated by each TLV type. The TLVs MUST 728 be processed in order within the Chunk. For example, if the sender 729 puts 3 TLVs in one chunk, the first TLV (the one closest to the 730 Chunk Header) in the Chunk MUST be processed first. The next TLV in 731 the chunk (the middle one) MUST be processed second and finally the 732 last TLV in the Chunk MUST be processed last. 734 V2) In processing the chunk, the receiver should build a response 735 message with the appropriate error TLVs, as specified in the 736 Parameter type bits for any ASCONF Parameter it does not understand. 737 To indicate an unrecognized parameter, cause type 8 as defined 738 in in the INIT-ACK in 3.3.10.8 of [RFC2960] should be used. The 739 endpoint may also use the response to carry rejections for other 740 reasons such as resource shortages etc using the Error Cause TLV and 741 an appropriate error condition. 743 Note: a positive response is implied if no error is indicated by the 744 sender. 746 V3) All error responses MUST copy the ASCONF-Request Correlation ID 747 field received in the ASCONF, from the TLV being responded to, into 748 the ASCONF-Request Correlation ID field. The ASCONF-Request 749 Correlation ID always precedes the request TLV. Note that a 750 TLV sent in a ASCONF-ACK MUST be accompanied by a Correlation ID 751 and a Correlation ID MUST NOT be sent without a TLV i.e. the two 752 are atomic. 754 V4) After processing the entire Chunk, it MUST send all TLVs for 755 both unrecognized parameters and any other status TLVs inside the 756 ASCONF-ACK chunk that acknowledges the arrival and processing of the 757 ASCONF Chunk. 759 V5) Update the 'Peer-Serial-Number' to the value found in the serial 760 number field. 762 C3) If the value found in the serial number is equal to the value 763 stored in the 'Peer-Serial-Number', the endpoint should: 765 X1) Parse the ASCONF Chunk TLVs but the endpoint MUST NOT take any 766 action on the TLVs parsed (since it has already performed these 767 actions). 769 X2) Build a response message with the appropriate response TLVs 770 as specified in the ASCONF Parameter type bits, for any 771 parameter it does not understand or could not process. 773 X3) After parsing the entire Chunk, it MUST send any response 774 TLV errors and status with an ASCONF-ACK chunk acknowledging the 775 arrival and processing of the ASCONF Chunk. 777 X4) The endpoint MUST NOT update its 'Peer-Serial-Number'. 779 IMPLEMENTATION NOTE: As an optimization a receiver may wish to save 780 the last ASCONF-ACK for some predetermined period of time and 781 instead of re-processing the ASCONF (with the same serial number) it 782 may just re-transmit the ASCONF-ACK. It may wish to use the arrival 783 of a new serial number to discard the previously saved ASCONF-ACK or 784 any other means it may choose to expire the saved ASCONF-ACK. 786 C4) Otherwise, the ASCONF Chunk is discarded since it must be either 787 a stale packet or from an attacker. A receiver of such a packet MAY 788 log the event for security purposes. 790 C5) In both cases C2 and C3 the ASCONF-ACK MUST be sent back to the 791 source address contained in the IP header of the ASCONF being 792 responded to. 794 4.3 General rules for address manipulation 795 When building TLV parameters for the ASCONF Chunk that 796 will add or delete IP addresses the following rules should be 797 applied: 799 D0) If an endpoint receives an ASCONF-ACK but no ASCONF chunk 800 is outstanding AND the sequence number of the ASCONF-ACK matches 801 what WOULD be the next sequence number sent by the endpoint 802 the endpoint MUST abort the association. 804 D1) When adding an IP address to an association, the IP address is 805 NOT considered fully added to the association until the ASCONF-ACK 806 arrives. This means that until such time as the ASCONF containing 807 the add is acknowledged the sender MUST NOT use the new IP address 808 as a source for ANY SCTP packet except on carrying an ASCONF chunk. 809 The receiver of the add IP address request may use the 810 address as a destination immediately. 812 D2) After the ASCONF-ACK of an IP address add arrives, the 813 endpoint MAY begin using the added IP address as a source 814 address for any type of SCTP chunk. 816 D3a) If an endpoint receives an Error Cause TLV indicating that the 817 IP address Add or IP address Deletion parameters was not understood, 818 the endpoint MUST consider the operation failed and MUST NOT attempt 819 to send any subsequent Add or Delete requests to the peer. 821 D3b) If an endpoint receives an Error Cause TLV indicating that the 822 IP address Set Primary IP Address parameter was not understood, 823 the endpoint MUST consider the operation failed and MUST NOT attempt 824 to send any subsequent Set Primary IP Address requests to the peer. 826 D4) When deleting an IP address from an association, the IP address 827 MUST be considered a valid destination address for the reception of 828 SCTP packets until the ASCONF-ACK arrives and MUST NOT be used as a 829 source address for any subsequent packets. This means that any 830 datagrams that arrive before the ASCONF-ACK destined to the IP address 831 being deleted MUST be considered part of the current 832 association. One special consideration is that ABORT chunks arriving 833 destined to the IP address being deleted MUST be ignored (see 834 Section 4.3.1 for further details). 836 D5) An endpoint MUST NOT delete its last remaining IP address from an 837 association. In other words if an endpoint is NOT multi-homed it 838 MUST NOT use the delete IP address without an add IP address preceding 839 the delete parameter in the ASCONF chunk. Or if an endpoint sends 840 multiple requests to delete IP addresses it MUST NOT delete all 841 of the IP addresses that the peer has listed for the requester. 843 D6) An endpoint MUST NOT set a IP header source address for an SCTP 844 packet holding the ASCONF Chunk to be the same as an address being 845 deleted by the ASCONF Chunk. 847 D7) If a request is received to delete the last remaining IP address 848 of a peer endpoint, the receiver MUST send an Error Cause TLV with 849 the error cause set to the new error code 'Request to Delete Last 850 Remaining IP Address'. The requested delete MUST NOT be performed or 851 acted upon, other than to send the ASCONF-ACK. 853 D8) If a request is received to delete an IP address which is also 854 the source address of the IP packet which contained the ASCONF 855 chunk, the receiver MUST reject this request. To reject the request 856 the receiver MUST send an Error Cause TLV set to the new error code 857 'Request to Delete Source IP Address' (unless Rule D5 has also been 858 violated, in which case the error code 'Request to Delete Last 859 Remaining IP Address' is sent). 861 D9) If an endpoint receives an ADD IP address request and does not 862 have the local resources to add this new address to the association, 863 it MUST return an Error Cause TLV set to the new error code 864 'Operation Refused Due to Resource Shortage'. 866 D10) If an endpoint receives an 'Out of Resource' error in response 867 to its request to ADD an IP address to an association, it must 868 either ABORT the association or not consider the address part of the 869 association. In other words if the endpoint does not ABORT the 870 association, it must consider the add attempt failed and NOT use 871 this address since its peer will treat SCTP packets destined to 872 the address as Out Of The Blue packets. 874 D11) When an endpoint receiving an ASCONF to add an IP address sends 875 an 'Out of Resource' in its response, it MUST also fail any 876 subsequent add or delete requests bundled in the ASCONF. The 877 receiver MUST NOT reject an ADD and then accept a subsequent DELETE 878 of an IP address in the same ASCONF Chunk. In other words, once a 879 receiver begins failing any ADD or DELETE request, it must fail all 880 subsequent ADD or DELETE requests contained in that single ASCONF. 882 D12) When an endpoint receives a request to delete an IP address 883 that is the current primary address, it is an implementation 884 decision as to how that endpoint chooses the new primary address. 886 D13) When an endpoint receives a valid request to DELETE an IP 887 address the endpoint MUST consider the address no longer as part of 888 the association. It MUST NOT send SCTP packets for the association 889 to that address and it MUST treat subsequent packets received from 890 that address as Out Of The Blue. 892 During the time interval between sending out the ASCONF and 893 receiving the ASCONF-ACK it MAY be possible to receive DATA chunks 894 out of order. The following examples illustrate these problems: 896 Endpoint-A Endpoint-Z 897 ---------- ---------- 898 ASCONF[Add-IP:X]------------------------------> 899 /--ASCONF-ACK 900 / 901 /--------/---New DATA: 902 / / Destination 904 <-------------------/ / IP:X 905 / 906 <--------------------------/ 908 In the above example we see a new IP address (X) being added to 909 the Endpoint-A. However due to packet re-ordering in the network 910 a new DATA chunk is sent and arrives at Endpoint-A before 911 the ASCONF-ACK confirming the add of the address to the association. 913 A similar problem exists with the deletion of an IP address as 914 follows: 916 Endpoint-A Endpoint-Z 917 ---------- ---------- 918 /------------New DATA: 919 / Destination 920 / IP:X 921 ASCONF [DEL-IP:X]---------/----------------> 922 <-----------------/------------------ASCONF-ACK 923 / 924 / 925 <-------------/ 927 In this example we see a DATA chunk destined to the IP:X (which is 928 about to be deleted) arriving after the deletion is complete. 929 For the ADD case an endpoint SHOULD consider the newly adding IP 930 address valid for the association to receive data from during the 931 interval when awaiting the ASCONF-ACK. The endpoint MUST NOT source 932 data from this new address until the ASCONF-ACK arrives but it may 933 receive out of order data as illustrated and MUST NOT treat this 934 data as an OOTB datagram (please see [RFC2960] section 8.4). It MAY 935 drop the data silently or it MAY consider it part of the association 936 but it MUST NOT respond with an ABORT. 938 For the DELETE case, an endpoint MAY respond to the late arriving DATA 939 packet as an OOTB datagram or it MAY hold the deleting IP address for a 940 small period of time as still valid. If it treats the DATA packet as 941 an OOTB the peer will silently discard the ABORT (since by the time 942 the ABORT is sent the peer will have removed the IP address from this 943 association). If the endpoint elects to hold the IP address valid for 944 a period of time, it MUST NOT hold it valid longer than 2 RTO 945 intervals for the destination being removed. 947 4.3.1 A special case for OOTB ABORT chunks 949 Another case worth mentioning is illustrated below: 951 Endpoint-A Endpoint-Z 952 ---------- ---------- 954 New DATA:------------\ 955 Source IP:X \ 956 \ 957 ASCONF-REQ[DEL-IP:X]----\------------------> 958 \ /---------ASCONF-ACK 959 \ / 960 \----/-----------> OOTB 961 (Ignored <---------------------/-------------ABORT 962 by rule D4) / 963 <---------------------/ 965 For this case, during the deletion of an IP address, an 966 Abort MUST be ignored if the destination address of the 967 Abort message is that of a destination being deleted. 969 4.3.2 A special case for changing an address. 971 In some instances the sender may only have one IP address in an 972 association that is being renumbered. When this occurs, the sender 973 may not be able to send to the peer the appropriate ADD/DELETE pair 974 and use the old address as a source in the IP header. For this 975 reason the sender MUST fill in the Address Bytes field with an 976 address that is part of the association (in this case the one being 977 deleted). This will allow the receiver to locate the association 978 without using the source address found in the IP header. 980 The receiver of such a chunk MUST always first use the source address 981 found in the IP header in looking up the association. The 982 receiver should attempt to use the address found in the Address 983 Bytes field only if the lookup fails using the source address from 984 the IP header. The receiver MUST reply to the source address 985 of the packet in this case which is the new address that 986 was added by the ASCONF (since the old address is no longer a part 987 of the association after processing). 989 4.4 Setting of the primary address 991 A sender of this option may elect to send this combined with 992 a deletion or addition of an address. A sender SHOULD only send 993 a set primary request to an address that is already considered 994 part of the association. In other words if a sender combines 995 a set primary with an add of a new IP address the set primary 996 will be discarded unless the add request is to be processed 997 BEFORE the set primary (i.e. it precedes the set primary). 999 A request to set primary MAY also appear in a INIT or INIT-ACK 1000 chunk. This can give advice to the peer endpoint as to which 1001 of its addresses the sender of the INIT or INIT-ACK would prefer 1002 to be used as the primary address. 1004 The request to set an address as the primary path is an option the 1005 receiver SHOULD perform. It is considered advice to the receiver of 1006 the best destination address to use in sending SCTP packets (in the 1007 requester's view). If a request arrives that asks the receiver to 1008 set an address as primary that does not exist, the receiver should 1009 NOT honor the request, leaving its existing primary address 1010 unchanged. 1012 5. Security Considerations 1014 The ADD/DELETE of an IP address to an existing association does 1015 provide an additional mechanism by which existing associations can 1016 be hijacked. Where the attacker is able to intercept and or alter 1017 the packets sent and received in an association, the use of this 1018 feature MAY increase the ease with which an association may be 1019 overtaken. This threat SHOULD be considered when deploying a version 1020 of SCTP that makes use of this feature. The IP Authentication Header 1021 [RFC2402] SHOULD be used when the threat environment requires 1022 stronger integrity protections, but does not require 1023 confidentiality. It should be noted that in the base SCTP 1024 specification [RFC2960], if an attacker is able to intercept and or 1025 alter packets, even without this feature it is possible to hijack an 1026 existing association; please refer to Section 11 of RFC2960. 1028 6. IANA considerations 1030 This document defines the following new SCTP parameters, chunks 1031 and errors: 1033 - Two new chunk types, 1034 - Six parameter types, and 1035 - Three new SCTP error causes. 1037 7. Acknowledgments 1039 The authors wish to thank Maria-Carmen Belinchon, Jon Berger, 1040 Peter Lei, John Loughney, Ivan Arias Rodriguez, Renee Revis, 1041 Marshall Rose, and Chip Sharp for their invaluable comments. 1043 8. Authors' Addresses 1045 Randall R. Stewart Tel: +1-815-477-2127 1046 Cisco Systems, Inc. EMail: rrs@cisco.com 1047 8745 W. Higgins Road, Suite 200 1048 Chicago, Ill 60631 1049 USA 1051 Micheal A. Ramalho Tel: +1-732-809-0188 1052 Cisco Systems, Inc. EMail: mramalho@cisco.com 1053 1802 Rue de la Porte 1054 Wall Township, NJ 0719-3784 1056 Qiaobing Xie Tel: +1-847-632-3028 1057 Motorola, Inc. EMail: qxie1@email.mot.com 1058 1501 W. Shure Drive, #2309 1059 Arlington Heights, IL 60004 1060 USA 1062 Michael Tuexen Tel: +49-89-722-47210 1063 SIEMENS AG EMail: Michael.Tuexen@icn.siemens.de 1064 Hofmannstr. 51 1065 81359 Munich 1066 Germany 1068 Ian Rytina Tel: +61-3-9301-6164 1069 Ericsson Australia EMail:ian.rytina@ericsson.com 1070 37/360 Elizabeth Street 1071 Melbourne, Victoria 3000 1072 Australia 1074 Phil Conrad Tel: +1-215-204-7910 1075 Netlab Research Group Email conrad@acm.org 1076 Dept. Of Computer & 1077 Information Sciences 1078 Temple University 1079 1805 N Broad St. 1080 Philadelphia, PA 19122 1081 USA 1083 9. References 1085 [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, 1086 H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, 1087 and, V. Paxson, "Stream Control Transmission Protocol," RFC 1088 2960, October 2000. 1090 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1091 3", RFC 2026, October 1996. 1093 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 1094 Requirement Levels", BCP 14, RFC 2119, March 1997. 1096 [RFC2402] S. Kent, R. Atkinson., "IP Authentication Header.", RFC 1097 2402, November 1998. 1099 This Internet Draft expires in 6 months from May, 2001