idnits 2.17.1 draft-ietf-sigtran-addip-sctp-01.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 3 longer pages, the longest (page 11) being 61 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 15 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC2402], [RFC2026], [RFC2119], [RFC2960], [RELREQ], [REL-REQ]), 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 80: '... The keywords MUST, MUST NOT, REQUI...' RFC 2119 keyword, line 81: '... SHOULD NOT, RECOMMENDED, NOT RECOM...' RFC 2119 keyword, line 124: '... MUST NOT attempt to add an address...' RFC 2119 keyword, line 182: '... [RFC2960]). The receiver MAY mark this as its primary upon...' RFC 2119 keyword, line 315: '...knowledged the sender MUST NOT use the...' (34 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 23, 2001) is 8456 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 535 looks like a reference -- Missing reference section? 'RFC2960' on line 530 looks like a reference -- Missing reference section? 'RELREQ' on line 544 looks like a reference -- Missing reference section? 'RFC2119' on line 538 looks like a reference -- Missing reference section? 'REL-REQ' on line 200 looks like a reference -- Missing reference section? 'RFC2402' on line 541 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 Cisco Systems 3 Q. Xie 4 Motorola 5 M. Tuexen 6 Siemens AG 7 I. Rytina 8 Ericsson 10 expires in six months February 23, 2001 12 SCTP Dynamic Addition of IP addresses 13 15 Status of This Memo 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are 19 working documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes an extension to the Stream Control 32 Transmission Protocol (SCTP) [RFC2960] to provide a method to add or 33 delete an IP address from an existing association or to request the 34 peer to change its primary destination address. The benefit of this 35 extension is for machines with hot pluggable interface cards the 36 ability to add (and/or delete) IP addresses dynamically without 37 forcing an SCTP association restart. 39 TABLE OF CONTENTS 40 1. Introduction............................................... 2 41 2. Conventions................................................ 2 42 3. New Reliable Request/Acknowledgement Parameters............ 2 43 3.1 New REL-REQ Parameters.................................... 2 44 3.1.1 Add IP Address.......................................... 3 45 3.1.2 Delete IP Address....................................... 3 46 3.1.3 Set Primary IP Address.................................. 4 47 3.2 New REL-ACK Parameters.................................... 4 48 3.2.1 Error Cause: Request to Delete Last IP Address.......... 5 49 3.2.2 Error Cause: Operation Refused due to Resource Shortage. 5 50 3.2.3 Error Cause: Request to Delete Source IP Address........ 6 51 3.3 New Error Causes.......................................... 6 52 3.3.1 Request to delete last IP address....................... 6 53 4. Procedures................................................. 6 54 4.1 IP address addition and deletion.......................... 6 55 4.2 Setting of the Primary Address............................ 9 56 5. Security Considerations.................................... 9 57 6. IANA considerations........................................10 58 7. Authors' Addresses.........................................10 59 8. References.................................................11 61 1. Introduction 63 Taking advantage of the extensibility of SCTP, and the generic 64 method for transmitting reliable SCTP control chunks [RELREQ], 65 this document introduces a use of the reliable control chunk, 66 to allow an existing SCTP association to add or delete IP addresses 67 without the currently required restart of the association. 69 This enables SCTP to have dynamic IP addresses added and subtracted 70 for those machines that allow addition/removal of an interface card. 71 It also provides a method for a endpoint request that its peer set 72 its primary destination address to an alternate, this can be useful 73 when an address is about to be deleted. As an example application, 74 this will provide the same type of services that exist in telephony 75 signalling, which allow a link set to add an additional link without 76 interfering with the operation of the link set. 78 2. Conventions 80 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 81 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 82 they appear in this document, are to be interpreted as described in 83 RFC 2119 [RFC2119]. 85 3. New Reliable Request/Acknowledgement Parameters 87 This section describes the addition of three new REL-REQ Parameters 88 to allow for the dynamic addition, deletion and setting of the 89 primary, of IP addresses to an existing SCTP association. The format 90 of these REL-REQ parameters within the Reliable Request Chunk is 91 descibed in [REL-REQ]. We also describe a REL-ACK parameter that is 92 carried to communicate errors or rejections of REL-REQ parameters. 94 3.1 New REL-REQ Parameters 96 The three new REL-REQ Parameters added follow the format defined in 97 [REL-REQ] section 3.1.1. Table 2 describes the three new REL-REQ 98 Parameters. 100 REL-REQ Parameter Type Value 101 ------------------------------------------------- 102 Add IP Address 49153 (0xC001) 103 Delete IP Address 49154 (0xC002) 104 Set Primary Address 49159 (0xC007) 106 Table 1: REL-REQ Parameters 108 3.1.1 Add IP Address 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Type = 49153 | Length = Variable | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Address Parameter | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Address Parameter: TLV 120 This field contains an IPv4 or IPv6 address parameter as described 121 in 3.3.2.1 of RFC2960. The complete TLV is wrapped within this 122 parameter. It informs the receiver that the Address specified is to 123 be added to the existing association. The sender of this request 124 MUST NOT attempt to add an address type that is not supported by 125 its peer. 127 An example TLV adding the IPv4 address 10.1.1.1 to an existing 128 association would look as follows: 130 +--------------------------------+ 131 | Type=49153 | Length = 12 | 132 +--------------------------------+ 133 | Type=5 | Length = 8 | 134 +----------------+---------------+ 135 | Value=0x0a010101 | 136 +----------------+---------------+ 138 3.1.2 Delete IP Address 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Type = 49154 | Length = Variable | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Address Parameter | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Address Parameter: TLV 150 This field contains an IPv4 or IPv6 address parameter as described in 151 3.3.2.1 of [RFC2960]. The complete TLV is wrapped within this 152 parameter. It informs the receiver that the Address specified is to 153 be removed from the existing association. 155 An example TLV deleting the IPv4 address 10.1.1.1 from an existing 156 association would look as follows: 158 +--------------------------------+ 159 | Type=49154 | Length = 12 | 160 +--------------------------------+ 161 | Type=5 | Length = 8 | 162 +----------------+---------------+ 163 | Value=0x0a010101 | 164 +----------------+---------------+ 166 3.1.3 Set Primary IP Address 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Type = 49159 | Length = Variable | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Address Parameter | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Address Parameter: TLV 178 This field contains an IPv4 or IPv6 address parameter as described in 179 3.3.2.1 of [RFC2960]. The complete TLV is wrapped within this 180 parameter. It requests the receiver to mark the specified address 181 as the primary address to send data to (see section 5.1.2 of 182 [RFC2960]). The receiver MAY mark this as its primary upon 183 receiving this request. 185 An example TLV requesting that the IPv4 address 10.1.1.1 be made the 186 primary destination addrss would look as follows: 188 +--------------------------------+ 189 | Type=49159 | Length = 12 | 190 +--------------------------------+ 191 | Type=5 | Length = 8 | 192 +----------------+---------------+ 193 | Value=0x0a010101 | 194 +----------------+---------------+ 196 3.2 New REL-ACK Parameters 198 Three new Error Causes are added to the SCTP Operational Errors, 199 primarily for use as part of the REL-REQ Parameter Error in the 200 REL-ACK (as outlined in [REL-REQ] section 3.1.2). 202 Cause Code 203 Value Cause Code 204 --------- ---------------- 205 11 Request to delete last IP address. 206 12 Operation Refused due to resource shortage. 207 13 Request to delete source IP address. 209 3.2.1 Error Cause: Request to Delete Last IP Address 211 Cause of error 212 --------------- 213 Request to delete last IP address: The receiver of this error sent a 214 request to delete the last IP address from its association with its 215 peer. This error indicates that the request is rejected. 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Cause Code=11 | Cause Length=var | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 \ TLV-Copied-From-REL-REQ / 221 / \ 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 An example of a failed delete in an Error Cause TLV would look as 225 follows in the response REL-ACK message: 227 +--------------------------------+ 228 | Type = 0xC005 | Length = 20 | 229 +--------------------------------+ 230 | Cause=11 | Length = 16 | 231 +----------------+---------------+ 232 | Type=49154 | Length = 12 | 233 +----------------+---------------+ 234 | Type=5 | Length = 8 | 235 +----------------+---------------+ 236 | Value=0x0a010101 | 237 +----------------+---------------+ 239 3.2.2 Error Cause: Operation Refused due to Resource Shortage 241 Cause of error 242 --------------- 243 This error cause is used to report a failure by the receiver to 244 perform the requested operation due to a lack of resources. The 245 entire TLV that is refused is copied from the REL-REQ into the error 246 cause. 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Cause Code=12 | Cause Length=Var | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 \ TLV-Copied-From-REL-REQ / 252 / \ 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 An example of a failed addition in an Error Cause TLV would look as 256 follows in the response REL-ACK message: 258 +--------------------------------+ 259 | Type = 0xC005 | Length = 20 | 260 +--------------------------------+ 261 | Cause=12 | Length = 16 | 262 +----------------+---------------+ 263 | Type=49153 | Length = 12 | 264 +--------------------------------+ 265 | Type=5 | Length = 8 | 266 +----------------+---------------+ 267 | Value=0x0a010101 | 268 +----------------+---------------+ 270 3.2.3 Error Cause: Request to Delete Source IP Address 272 Cause of error 273 --------------- 274 Request to delete source IP address: The receiver of this error sent 275 a request to delete the source IP address of the REL-REQ 276 message. This error indicates that the request is rejected. 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Cause Code=13 | Cause Length=VAR | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 \ TLV-Copied-From-REL-REQ / 282 / \ 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 An example of a failed delete in an Error Cause TLV would look as 286 follows in the response REL-ACK message: 288 +--------------------------------+ 289 | Type = 0xC005 | Length = 20 | 290 +--------------------------------+ 291 | Cause=13 | Length = 16 | 292 +----------------+---------------+ 293 | Type=49154 | Length = 12 | 294 +----------------+---------------+ 295 | Type=5 | Length = 8 | 296 +----------------+---------------+ 297 | Value=0x0a010101 | 298 +----------------+---------------+ 300 4. Procedures 302 This section will lay out the specific procedures for the add/delete 303 IP address REL-REQ Parameter. The generic procedures for 304 transmitting reliable SCTP control chunks are covered in [RELREQ]. 306 4.1 IP address addition and deletion 308 When building TLV parameters for the REL-REQ Chunk messages that 309 will add or delete IP addresses the following rules should be 310 applied: 312 D1) When adding an IP address to an association, the IP address is 313 NOT considered fully added to the association until the REL-ACK 314 arrives. This means that until such time as the REL-REQ 315 containing the add is acknowledged the sender MUST NOT use the 316 new IP address as a source for ANY SCTP packet. 318 D2) After the REL-ACK of an IP address add arrives, the endpoint MAY 319 begin using the added IP address as a source address. 321 D3) If an endpoint receives an Error Cause TLV indicating that the 322 IP address Add, IP address Deletion, or Set Primary IP Address 323 REL-REQ parameters was not understood, the endpoint MUST 324 consider the operation failed and MUST NOT attempt to 325 send any subsequent Add, Delete or Set Primary requests to 326 the peer. 328 D4) When deleting an IP address from an association, the IP address 329 MUST be considered a valid source address for DATA chunks 330 until the REL-ACK arrives. This means that any datagrams that 331 arrive before the REL-ACK destined to the IP address being 332 deleted MUST be considered part of the current association. 333 One special consideration is that ABORT chunks arriving destined 334 to the IP address being deleted MUST be ignored (see Section 335 4.1 for futher details). 337 D5) An endpoint MUST NOT delete its last IP address from an 338 association. In other words if an endpoint is NOT multi-homed it 339 MUST NOT use the delete IP address. Or if an endpoint sends 340 multiple requests to delete IP addresses it MUST NOT delete all 341 of the IP addresses that the peer has listed for the requester. 343 D6) An endpoint MUST NOT use the source address (of the IP packet 344 containing the SCTP packet) for a REL-REQ to delete an IP 345 address from the address being deleted. 347 D7) If a request is received to delete the last IP address of a peer 348 endpoint, the receiver MUST send an Error Cause TLV with the 349 error cause set to the new error code 'Request to delete last IP 350 address'. The requested delete MUST NOT be performed or acted 351 upon, other than to send the REL-ACK. 353 D8) If a request is received to delete an IP address which is also 354 the source address of the IP packet which contained the REL-REQ 355 chunk, the receiver MUST reject this request. To reject the 356 request the receiver MUST send a Error Cause TLV set to the new 357 error code "Request to Delete Source IP Address" (unless Rule D5 358 has also been violated, in which case the error code 'Request to 359 delete last IP address' is sent). 361 D9) After the REL-ACK of an IP address deletion arrives, the 362 endpoint MUST NOT use the deleted IP address as a source of any 363 SCTP packet. 365 D10) If an endpoint receives an ADD IP address request and does not 366 have the local resources to add this new address to the 367 association, it MUST return an Error Cause TLV set to the new 368 error code "Operation Refused due to Resource Shourtage". 370 D11) If an endpoint receives an 'Out of Resource' error when adding 371 an IP address to an association, it must either ABORT the 372 association or not source any packets from this address. In 373 other words if the endpoint does not ABORT the association, it 374 must consider the add attempt failed and NOT use this address. 376 D12) When an endpoint receiving a REL-REQ to add an IP address sends 377 an 'Out of Resource' in its response, it MUST also fail any 378 subsequent add or delete requests bundled in the REL-REQ. The 379 receiver MUST NOT reject an ADD and then accept a subsequent 380 DELETE of an IP address in the same REL-REQ chunk. In other 381 words, once a receiver begins failing any ADD or DELETE request, 382 it must fail all subsequent ADD or DELETE requests contained in 383 that single REL-REQ. 385 D13) When an endpoint receives a request to delete an IP address that 386 is the current primary address, it is an implementation decision 387 as to how that endpoint chooses the new primary address. 389 During the time interval between sending out the REL-REQ and 390 receiving the REL-ACK it MAY be possible to receive DATA chunks out 391 of order. The following examples illustrate these problems: 393 Endpoint-A Endpoint-Z 394 ---------- ---------- 395 REL-REQ[Add-IP:X]------------------------------> 396 /--REL-ACK 397 / 398 /--------/---New DATA: 399 / / Destination 400 <-------------------/ / IP:X 401 / 402 <--------------------------/ 404 In the above example we see a new IP address (X) being added to 405 the Endpoint-A. However due to packet re-ordering in the network 406 a new DATA chunk is sent and arrives at Endpoint-A before 407 the REL-ACK confirming the add of the address to the association. 409 A similar problem exists with the deletion of an IP address as 410 follows: 412 Endpoint-A Endpoint-Z 413 ---------- ---------- 414 /------------New DATA: 415 / Destination 416 / IP:X 417 REL-REQ[DEL-IP:X]---------/----------------> 418 <-----------------/------------------REL-ACK 419 / 420 / 421 <-------------/ 423 In this example we see a DATA chunk destined to the IP:X (which is 424 about to be deleted) arriving after the deletion is complete. 426 For the ADD case an endpoint SHOULD consider the newly adding IP 427 address valid for the association to receive data from during the 428 interval when awaiting the REL-ACK. The endpoint MUST NOT source data 429 from this new address until the REL-ACK arrives but it may receive out 430 of order data as illustrated and MUST NOT treat this data as an OOTB 431 datagram (please see [RFC2960] section 8.4). It MAY drop the data 432 silently or it MAY consider it part of the association but it MUST NOT 433 respond with an ABORT. 435 For the DELETE case, an endpoint MAY respond to the late arriving DATA 436 packet as an OOTB datagram or it MAY hold the deleting IP address for a 437 small period of time as still valid. If it treats the DATA packet as 438 an OOTB the peer will silently discard the ABORT (since by the time 439 the ABORT is sent the peer will have removed the IP address from this 440 association). If the endpoint elects to hold the IP address valid for 441 a period of time, it MUST NOT hold it valid longer than 2 RTO 442 intervals for the destination being removed. 444 Another case worth mentioning is illustrated below: 446 Endpoint-A Endpoint-Z 447 ---------- ---------- 449 New DATA:------------\ 450 Source IP:X \ 451 \ 452 REL-REQ[DEL-IP:X]-------\------------------> 453 \ /---------REL-ACK 454 \ / 455 \----/-----------> OOTB 456 (Ignored ----------------------/-------------ABORT 457 by rule D4) / 458 <---------------------/ 460 For this case, during the deletion of an IP address, an 461 Abort MUST be ignored if the destination address of the 462 Abort message is that of the destination being deleted. 464 4.2 Setting of the primary address 466 A sender of this option may elect to send this combined with 467 a deletion request for an address. A sender MUST only send 468 a set primary request to an address that is considered 469 part of the association. In other words a sender MUST NOT 470 bundle a set primary with an add of a new IP address unless 471 the add request is to be processed BEFORE the set primary. 473 The request to set an address as the primary path is an option the 474 receiver MAY perform. It is considered a hint to the receiver of the 475 best destination address to use in sending SCTP packets (in the 476 requestors view). It is possible that the receiver may have other 477 knowledge that it may act upon and NOT set the specified address as 478 primary. If a request arrives that asks the receiver to set an 479 address as primary that does not exist, the receiver should NOT 480 honor the request, leaving its existing primary address unchanged. 482 5. Security Considerations 484 The ADD/DELETE of an IP address to an existing association does 485 provide an additional mechanism by which existing associations can 486 be hijacked. Where the attacker is able to intercept and or alter 487 the packets sent and received in an association the use of this 488 feature MAY increase the ease at which an association may be 489 overtaken. This threat SHOULD be considered when deploying a version 490 of SCTP that use this feature. The IP Authentication Header 491 [RFC2402] SHOULD be used when the threat environment requires 492 stronger integrity protections, but does not require 493 confidentiality. It should be noted that in the base SCTP 494 specification [RFC2960], if an attacker is able to intercept and or 495 alter packets, even without this feature it is possible to hijack an 496 existing association, please refer to Section 11 of RFC2960. 498 6. IANA considerations 500 Three REL-REQ Parmeter Types and three new SCTP Error Causes are 501 being defined within this document. 503 7. Authors' Addresses 505 Randall R. Stewart Tel: +1-815-477-2127 506 Cisco Systems, Inc. EMail: rrs@cisco.com 507 8745 W. Higgins Road, Suite 200 508 Chicago, Ill 60631 509 USA 511 Qiaobing Xie Tel: +1-847-632-3028 512 Motorola, Inc. EMail: qxie1@email.mot.com 513 1501 W. Shure Drive, #2309 514 Arlington Heights, IL 60004 515 USA 517 Michael Tuexen Tel: +49-89-722-47210 518 SIEMENS AG EMail: Michael.Tuexen@icn.siemens.de 519 Hofmannstr. 51 520 81359 Munich 521 Germany 523 Ian Rytina Tel: +61-3-9301-6164 524 Ericsson Australia EMail:ian.rytina@ericsson.com 525 37/360 Elizabeth Street 526 Melbourne, Victoria 3000 527 Australia 528 8. References 530 [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, 531 H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, 532 and, V. Paxson, "Stream Control Transmission Protocol," RFC 533 2960, October 2000. 535 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 536 3", RFC 2026, October 1996. 538 [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, March 1997. 541 [RFC2402] S. Kent, R. Atkinson., "IP Authentication Header.", RFC 542 2402, November 1998. 544 [RELREQ] "Generic Method for Transmitting Reliable SCTP Control 545 Chunks", draft-stewart-relreq-sctp-sigtran-00.txt, work in 546 progress. 548 This Internet Draft expires in 6 months from February, 2001