doc/draft-ietf-tsvwg-addip-sctp-15.txt

   1
   2
   3
   4
   5 Network Working Group                                         R. Stewart
   6 Internet-Draft                                                M. Ramalho
   7 Expires: December 2, 2006                            Cisco Systems, Inc.
   8                                                                   Q. Xie
   9                                                           Motorola, Inc.
  10                                                                M. Tuexen
  11                                       Univ. of Applied Sciences Muenster
  12                                                                P. Conrad
  13                                                   University of Delaware
  14                                                             May 31, 2006
  15
  16
  17       Stream Control Transmission Protocol (SCTP) Dynamic Address
  18                             Reconfiguration
  19                    draft-ietf-tsvwg-addip-sctp-15.txt
  20
  21 Status of this Memo
  22
  23    By submitting this Internet-Draft, each author represents that any
  24    applicable patent or other IPR claims of which he or she is aware
  25    have been or will be disclosed, and any of which he or she becomes
  26    aware will be disclosed, in accordance with Section 6 of BCP 79.
  27
  28    Internet-Drafts are working documents of the Internet Engineering
  29    Task Force (IETF), its areas, and its working groups.  Note that
  30    other groups may also distribute working documents as Internet-
  31    Drafts.
  32
  33    Internet-Drafts are draft documents valid for a maximum of six months
  34    and may be updated, replaced, or obsoleted by other documents at any
  35    time.  It is inappropriate to use Internet-Drafts as reference
  36    material or to cite them other than as "work in progress."
  37
  38    The list of current Internet-Drafts can be accessed at
  39    http://www.ietf.org/ietf/1id-abstracts.txt.
  40
  41    The list of Internet-Draft Shadow Directories can be accessed at
  42    http://www.ietf.org/shadow.html.
  43
  44    This Internet-Draft will expire on December 2, 2006.
  45
  46 Copyright Notice
  47
  48    Copyright (C) The Internet Society (2006).
  49
  50 Abstract
  51
  52    This document describes extensions to the Stream Control Transmission
  53
  54
  55
  56 Stewart, et al.         Expires December 2, 2006                [Page 1]
  57 \f
  58 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
  59
  60
  61    Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP
  62    address information on an existing association.
  63
  64
  65 Table of Contents
  66
  67    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
  68    2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
  69    3.  Additional Chunks and Parameters . . . . . . . . . . . . . . .  4
  70      3.1.  New Chunk Types  . . . . . . . . . . . . . . . . . . . . .  5
  71        3.1.1.  Address Configuration Change Chunk (ASCONF)  . . . . .  5
  72        3.1.2.  Address Configuration Acknowledgment Chunk
  73                (ASCONF-ACK) . . . . . . . . . . . . . . . . . . . . .  6
  74      3.2.  New Parameter Types  . . . . . . . . . . . . . . . . . . .  7
  75        3.2.1.  Add IP Address . . . . . . . . . . . . . . . . . . . .  8
  76        3.2.2.  Delete IP Address  . . . . . . . . . . . . . . . . . .  9
  77        3.2.3.  Error Cause Indication . . . . . . . . . . . . . . . . 10
  78        3.2.4.  Set Primary IP Address . . . . . . . . . . . . . . . . 11
  79        3.2.5.  Success Indication . . . . . . . . . . . . . . . . . . 12
  80        3.2.6.  Adaptation Layer Indication  . . . . . . . . . . . . . 13
  81        3.2.7.  Supported Extensions Parameter . . . . . . . . . . . . 13
  82      3.3.  New Error Causes . . . . . . . . . . . . . . . . . . . . . 14
  83        3.3.1.  Error Cause: Request to Delete Last Remaining IP
  84                Address  . . . . . . . . . . . . . . . . . . . . . . . 14
  85        3.3.2.  Error Cause: Operation Refused Due to Resource
  86                Shortage . . . . . . . . . . . . . . . . . . . . . . . 15
  87        3.3.3.  Error Cause: Request to Delete Source IP Address . . . 16
  88        3.3.4.  Error Cause: Association Aborted due to illegal
  89                ASCONF-ACK . . . . . . . . . . . . . . . . . . . . . . 17
  90        3.3.5.  Error Cause: Request refused - no authorization. . . . 17
  91    4.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18
  92      4.1.  ASCONF Chunk Procedures  . . . . . . . . . . . . . . . . . 18
  93        4.1.1.  Congestion Control of ASCONF Chunks  . . . . . . . . . 19
  94      4.2.  Upon reception of an ASCONF Chunk. . . . . . . . . . . . . 20
  95      4.3.  General rules for address manipulation . . . . . . . . . . 22
  96        4.3.1.  A special case for OOTB ABORT chunks . . . . . . . . . 25
  97        4.3.2.  A special case for changing an address.  . . . . . . . 26
  98      4.4.  Setting of the primary address . . . . . . . . . . . . . . 26
  99    5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
 100    6.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 28
 101    7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 28
 102    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
 103    Appendix A.  Abstract Address Handling . . . . . . . . . . . . . . 29
 104      A.1.  General remarks  . . . . . . . . . . . . . . . . . . . . . 29
 105      A.2.  Generalized endpoints  . . . . . . . . . . . . . . . . . . 29
 106      A.3.  Associations . . . . . . . . . . . . . . . . . . . . . . . 30
 107      A.4.  Relationship with RFC 2960 . . . . . . . . . . . . . . . . 31
 108      A.5.  Rules for address manipulation . . . . . . . . . . . . . . 31
 109
 110
 111
 112 Stewart, et al.         Expires December 2, 2006                [Page 2]
 113 \f
 114 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 115
 116
 117    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
 118    Intellectual Property and Copyright Statements . . . . . . . . . . 35
 119
 120
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168 Stewart, et al.         Expires December 2, 2006                [Page 3]
 169 \f
 170 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 171
 172
 173 1.  Introduction
 174
 175    To extend the utility and application scenarios of SCTP, this
 176    document introduces optional extensions that provide SCTP with the
 177    ability to:
 178
 179    1.  reconfigure IP address information on an existing association.
 180    2.  set the remote primary path.
 181    3.  exchange adaptation layer information during association setup.
 182
 183    These extensions enable SCTP to be utilized in the following
 184    applications:
 185
 186    1.  For computational or networking platforms that allow addition/
 187        removal of physical interface cards this feature can provide a
 188        graceful method to add to the interfaces of an existing
 189        association.  For IPv6 this feature allows renumbering of
 190        existing associations.
 191    2.  This provides a method for an endpoint to request that its peer
 192        set its primary destination address.  This can be useful when an
 193        address is about to be deleted, or when an endpoint has some
 194        predetermined knowledge about which is the preferred address to
 195        receive SCTP packets upon.
 196    3.  This feature can be used to extend the usability of SCTP without
 197        modifying it by allowing endpoints to exchange some information
 198        during association setup.
 199
 200
 201 2.  Conventions
 202
 203    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
 204    SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
 205    they appear in this document, are to be interpreted as described in
 206    RFC2119 [RFC2119].
 207
 208
 209 3.  Additional Chunks and Parameters
 210
 211    This section describes the addition of two new chunks and, seven new
 212    parameters to allow:
 213
 214    o  Dynamic addition of IP Addresses to an association.
 215    o  Dynamic deletion of IP Addresses from an association.
 216    o  A request to set the primary address the peer will use when
 217       sending to an endpoint.
 218
 219    Additionally, this section describes three new error causes that
 220    support these new chunks and parameters.
 221
 222
 223
 224 Stewart, et al.         Expires December 2, 2006                [Page 4]
 225 \f
 226 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 227
 228
 229 3.1.  New Chunk Types
 230
 231    This section defines two new chunk types that will be used to
 232    transfer the control information reliably.  Table 1 illustrates the
 233    two new chunk types.
 234
 235         Chunk Type  Chunk Name
 236         --------------------------------------------------------------
 237         0xC1    Address Configuration Change Chunk        (ASCONF)
 238         0x80    Address Configuration Acknowledgment      (ASCONF-ACK)
 239
 240               Table 1: Address Configuration Chunks
 241
 242    It should be noted that the ASCONF Chunk format requires the receiver
 243    to report to the sender if it does not understand the ASCONF Chunk.
 244    This is accomplished by setting the upper bits in the chunk type as
 245    described in RFC2960 [RFC2960] section 3.2.  Note that the upper two
 246    bits in the ASCONF Chunk are set to one.  As defined in RFC2960
 247    [RFC2960] section 3.2, setting these upper bits in this manner will
 248    cause the receiver that does not understand this chunk to skip the
 249    chunk and continue processing, but report in an Operation Error Chunk
 250    using the 'Unrecognized Chunk Type' cause of error.
 251
 252 3.1.1.  Address Configuration Change Chunk (ASCONF)
 253
 254    This chunk is used to communicate to the remote endpoint one of the
 255    configuration change requests that MUST be acknowledged.  The
 256    information carried in the ASCONF Chunk uses the form of a Type-
 257    Length-Value (TLV), as described in "3.2.1 Optional/Variable-length
 258    Parameter Format" in RFC2960 [RFC2960], for all variable parameters.
 259    This chunk MUST be sent in an authenticated way by using the
 260    mechanism defined in SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth].  If this
 261    chunk is received unauthenticated it MUST be silently discarded as
 262    described in SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth].
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280 Stewart, et al.         Expires December 2, 2006                [Page 5]
 281 \f
 282 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 283
 284
 285         0                   1                   2                   3
 286         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
 287        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 288        | Type = 0xC1   |  Chunk Flags  |      Chunk Length             |
 289        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 290        |                       Serial Number                           |
 291        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 292        |                    Address Parameter                          |
 293        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 294        |                     ASCONF Parameter #1                       |
 295        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 296        \                                                               \
 297        /                             ....                              /
 298        \                                                               \
 299        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 300        |                     ASCONF Parameter #N                       |
 301        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 302
 303    Serial Number : 32 bits (unsigned integer)
 304
 305    This value represents a Serial Number for the ASCONF Chunk.  The
 306    valid range of Serial Number is from 0 to 4294967295 (2**32 - 1).
 307    Serial Numbers wrap back to 0 after reaching 4294967295.
 308
 309    Address Parameter : 8 or 20 bytes (depending on type)
 310
 311    This field contains an address parameter, either IPv6 or IPv4, from
 312    RFC2960 [RFC2960].  The address is an address of the sender of the
 313    ASCONF chunk, the address MUST be considered part of the association
 314    by the peer endpoint (the receiver of the ASCONF chunk).  This field
 315    may be used by the receiver of the ASCONF to help in finding the
 316    association.  If the address 0.0.0.0 or ::0 is provided the receiver
 317    MAY lookup the association by other information provided in the
 318    packet.  This parameter MUST be present in every ASCONF message i.e.
 319    it is a mandatory TLV parameter.
 320
 321    Note the host name address parameter is NOT allowed and MUST be
 322    ignored if received in any ASCONF message.
 323
 324    ASCONF Parameter: TLV format
 325
 326    Each Address configuration change is represented by a TLV parameter
 327    as defined in Section 3.2.  One or more requests may be present in an
 328    ASCONF Chunk.
 329
 330 3.1.2.  Address Configuration Acknowledgment Chunk (ASCONF-ACK)
 331
 332    This chunk is used by the receiver of an ASCONF Chunk to acknowledge
 333
 334
 335
 336 Stewart, et al.         Expires December 2, 2006                [Page 6]
 337 \f
 338 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 339
 340
 341    the reception.  It carries zero or more results for any ASCONF
 342    Parameters that were processed by the receiver.  This chunk MUST be
 343    sent in an authenticated way by using the mechanism defined in SCTP-
 344    AUTH [I-D.ietf-tsvwg-sctp-auth].  If this chunk is received
 345    unauthenticated it MUST be silently discarded as described in SCTP-
 346    AUTH [I-D.ietf-tsvwg-sctp-auth].
 347
 348         0                   1                   2                   3
 349         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
 350        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 351        | Type = 0x80   |  Chunk Flags  |      Chunk Length             |
 352        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 353        |                       Serial Number                           |
 354        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 355        |                 ASCONF Parameter Response#1                   |
 356        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 357        \                                                               \
 358        /                             ....                              /
 359        \                                                               \
 360        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 361        |                 ASCONF Parameter Response#N                   |
 362        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 363
 364    Serial Number : 32 bits (unsigned integer)
 365
 366    This value represents the Serial Number for the received ASCONF Chunk
 367    that is acknowledged by this chunk.  This value is copied from the
 368    received ASCONF Chunk.
 369
 370    ASCONF Parameter Response : TLV format
 371
 372    The ASCONF Parameter Response is used in the ASCONF-ACK to report
 373    status of ASCONF processing.  By default, if a responding endpoint
 374    does not include any Error Cause, a success is indicated.  Thus a
 375    sender of an ASCONF-ACK MAY indicate complete success of all TLVs in
 376    an ASCONF by returning only the Chunk Type, Chunk Flags, Chunk Length
 377    (set to 8) and the Serial Number.
 378
 379 3.2.  New Parameter Types
 380
 381    The seven new parameters added follow the format defined in section
 382    3.2.1 of RFC2960 [RFC2960].  Table 2, 3 and 4 describes the
 383    parameters.
 384
 385
 386
 387
 388
 389
 390
 391
 392 Stewart, et al.         Expires December 2, 2006                [Page 7]
 393 \f
 394 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 395
 396
 397         Address Configuration Parameters   Parameter Type
 398         -------------------------------------------------
 399         Set Primary Address                  0xC004
 400         Adaptation Layer Indication          0xC006
 401         Supported Extensions                 0x8008
 402
 403         Table 2: Parameters that can be used in INIT/INIT-ACK chunk
 404
 405
 406         Address Configuration Parameters   Parameter Type
 407         -------------------------------------------------
 408         Add IP Address                       0xC001
 409         Delete IP Address                    0xC002
 410         Set Primary Address                  0xC004
 411
 412         Table 3: Parameters used in ASCONF Parameter
 413
 414
 415         Address Configuration Parameters   Parameter Type
 416         -------------------------------------------------
 417         Error Cause Indication               0xC003
 418         Success Indication                   0xC005
 419
 420         Table 4: Parameters used in ASCONF Parameter Response
 421
 422
 423    Any parameter that appears where it is not allowed (for example a
 424    0xC002 parameter appearing within an INIT or INIT-ACK) MAY be
 425    responded to with an ABORT by the receiver of the invalid parameter.
 426
 427 3.2.1.  Add IP Address
 428
 429         0                   1                   2                   3
 430         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
 431        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 432        |        Type = 0xC001          |    Length = Variable          |
 433        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 434        |               ASCONF-Request Correlation ID                   |
 435        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 436        |                       Address Parameter                       |
 437        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 438
 439    ASCONF-Request Correlation ID: 32 bits
 440
 441    This is an opaque integer assigned by the sender to identify each
 442    request parameter.  It is in host byte order and is only meaningful
 443    to the sender.  The receiver of the ASCONF Chunk will copy this 32
 444    bit value into the ASCONF Response Correlation ID field of the
 445
 446
 447
 448 Stewart, et al.         Expires December 2, 2006                [Page 8]
 449 \f
 450 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 451
 452
 453    ASCONF-ACK response parameter.  The sender of the ASCONF can use this
 454    same value in the ASCONF-ACK to find which request the response is
 455    for.
 456
 457    Address Parameter: TLV
 458
 459    This field contains an IPv4 or IPv6 address parameter as described in
 460    3.3.2.1 of RFC2960 [RFC2960].  The complete TLV is wrapped within
 461    this parameter.  It informs the receiver that the address specified
 462    is to be added to the existing association.  This parameter MUST NOT
 463    contain a broadcast or multicast address.  If the address 0.0.0.0 or
 464    ::0 is provided, the source address of the packet MUST be added.
 465
 466    An example TLV requesting that the IPv4 address 10.1.1.1 be added to
 467    the association would look as follows:
 468
 469            +--------------------------------+
 470            |  Type=0xC001   | Length = 16   |
 471            +--------------------------------+
 472            |       C-ID = 0x01023474        |
 473            +--------------------------------+
 474            |  Type=5        | Length = 8    |
 475            +----------------+---------------+
 476            |       Value=0x0a010101         |
 477            +----------------+---------------+
 478
 479    Valid Chunk Appearance
 480
 481    The Add IP Address parameter may only appear in the ASCONF Chunk
 482    type.
 483
 484 3.2.2.  Delete IP Address
 485
 486         0                   1                   2                   3
 487         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
 488        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 489        |        Type =0xC002           |    Length = Variable          |
 490        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 491        |               ASCONF-Request Correlation ID                   |
 492        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 493        |                       Address Parameter                       |
 494        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 495
 496    ASCONF-Request Correlation ID: 32 bits
 497
 498    This is an opaque integer assigned by the sender to identify each
 499    request parameter.  It is in host byte order and is only meaningful
 500    to the sender.  The receiver of the ASCONF Chunk will copy this 32
 501
 502
 503
 504 Stewart, et al.         Expires December 2, 2006                [Page 9]
 505 \f
 506 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 507
 508
 509    bit value into the ASCONF Response Correlation ID field of the
 510    ASCONF-ACK response parameter.  The sender of the ASCONF can use this
 511    same value in the ASCONF-ACK to find which request the response is
 512    for.
 513
 514    Address Parameter: TLV
 515
 516    This field contains an IPv4 or IPv6 address parameter as described in
 517    3.3.2.1 of RFC2960 [RFC2960].  The complete TLV is wrapped within
 518    this parameter.  It informs the receiver that the address specified
 519    is to be removed from the existing association.  This parameter MUST
 520    NOT contain a broadcast or multicast address.  If the address 0.0.0.0
 521    or ::0 is provided, all addresses of the peer except the source
 522    address of the packet MUST be deleted.
 523
 524    An example TLV deleting the IPv4 address 10.1.1.1 from an existing
 525    association would look as follows:
 526
 527            +--------------------------------+
 528            |  Type=0xC002   | Length = 16   |
 529            +--------------------------------+
 530            |       C-ID = 0x01023476        |
 531            +--------------------------------+
 532            |  Type=5        | Length = 8    |
 533            +----------------+---------------+
 534            |       Value=0x0a010101         |
 535            +----------------+---------------+
 536
 537    Valid Chunk Appearance
 538
 539    The Delete IP Address parameter may only appear in the ASCONF Chunk
 540    type.
 541
 542 3.2.3.  Error Cause Indication
 543
 544         0                   1                   2                   3
 545         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
 546        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 547        |    Type = 0xC003              |      Length = Variable        |
 548        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 549        |             ASCONF-Response Correlation ID                    |
 550        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 551        |             Error Cause(s) or Return Info on Success          |
 552        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 553
 554    ASCONF-Response Correlation ID: 32 bits
 555
 556    This is an opaque integer assigned by the sender to identify each
 557
 558
 559
 560 Stewart, et al.         Expires December 2, 2006               [Page 10]
 561 \f
 562 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 563
 564
 565    request parameter.  The receiver of the ASCONF Chunk will copy this
 566    32 bit value from the ASCONF-Request Correlation ID into the ASCONF
 567    Response Correlation ID field so the peer can easily correlate the
 568    request to this response.
 569
 570    Error Cause(s): TLV(s)
 571
 572    When reporting an error this response parameter is used to wrap one
 573    or more standard error causes normally found within an SCTP
 574    Operational Error or SCTP Abort (as defined in RFC2960 [RFC2960]).
 575    The Error Cause(s) follow the format defined in section 3.3.10 of
 576    RFC2960 [RFC2960].
 577
 578    Valid Chunk Appearance
 579
 580    The Error Cause Indication parameter may only appear in the ASCONF-
 581    ACK chunk type.
 582
 583 3.2.4.  Set Primary IP Address
 584
 585         0                   1                   2                   3
 586         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
 587        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 588        |        Type =0xC004           |    Length = Variable          |
 589        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 590        |               ASCONF-Request Correlation ID                   |
 591        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 592        |                       Address Parameter                       |
 593        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 594
 595    ASCONF-Request Correlation ID: 32 bits
 596
 597    This is an opaque integer assigned by the sender to identify each
 598    request parameter.  It is in host byte order and is only meaningful
 599    to the sender.  The receiver of the ASCONF Chunk will copy this 32
 600    bit value into the ASCONF Response Correlation ID field of the
 601    ASCONF-ACK response parameter.  The sender of the ASCONF can use this
 602    same value in the ASCONF-ACK to find which request the response is
 603    for.
 604
 605    Address Parameter: TLV
 606
 607    This field contains an IPv4 or IPv6 address parameter as described in
 608    3.3.2.1 of RFC2960 [RFC2960].  The complete TLV is wrapped within
 609    this parameter.  It requests the receiver to mark the specified
 610    address as the primary address to send data to (see section 5.1.2 of
 611    RFC2960 [RFC2960]).  The receiver MAY mark this as its primary upon
 612    receiving this request.  If the address 0.0.0.0 or ::0 is provided,
 613
 614
 615
 616 Stewart, et al.         Expires December 2, 2006               [Page 11]
 617 \f
 618 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 619
 620
 621    the receiver MAY mark the source address of the packet as its
 622    primary.
 623
 624    An example TLV requesting that the IPv4 address 10.1.1.1 be made the
 625    primary destination address would look as follows:
 626
 627            +--------------------------------+
 628            |  Type=0xC004   | Length = 16   |
 629            +--------------------------------+
 630            |       C-ID = 0x01023479        |
 631            +--------------------------------+
 632            |  Type=5        | Length = 8    |
 633            +----------------+---------------+
 634            |       Value=0x0a010101         |
 635            +----------------+---------------+
 636
 637    Valid Chunk Appearance
 638
 639    The Set Primary IP Address parameter may appear in the ASCONF Chunk,
 640    the INIT, or the INIT-ACK chunk type.  The inclusion of this
 641    parameter in the INIT or INIT-ACK can be used to indicate an initial
 642    preference of primary address.
 643
 644 3.2.5.  Success Indication
 645
 646         0                   1                   2                   3
 647         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
 648        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 649        |        Type = 0xC005          |      Length = 8               |
 650        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 651        |               ASCONF-Response Correlation ID                  |
 652        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 653
 654    By default if a responding endpoint does not report an error for any
 655    requested TLV, a success is implicitly indicated.  Thus a sender of a
 656    ASCONF-ACK MAY indicate complete success of all TLVs in an ASCONF by
 657    returning only the Chunk Type, Chunk Flags, Chunk Length (set to 8)
 658    and the Serial Number.
 659
 660    The responding endpoint MAY also choose to explicitly report a
 661    success for a requested TLV, by returning a success report ASCONF
 662    Parameter Response.
 663
 664    ASCONF-Response Correlation ID: 32 bits
 665
 666    This is an opaque integer assigned by the sender to identify each
 667    request parameter.  The receiver of the ASCONF Chunk will copy this
 668    32 bit value from the ASCONF-Request Correlation ID into the ASCONF
 669
 670
 671
 672 Stewart, et al.         Expires December 2, 2006               [Page 12]
 673 \f
 674 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 675
 676
 677    Response Correlation ID field so the peer can easily correlate the
 678    request to this response.
 679
 680    Valid Chunk Appearance
 681
 682    The Success Indication parameter may only appear in the ASCONF-ACK
 683    chunk type.
 684
 685 3.2.6.  Adaptation Layer Indication
 686
 687         0                   1                   2                   3
 688         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
 689        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 690        |        Type =0xC006           |    Length = 8                 |
 691        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 692        |                   Adaptation Code point                       |
 693        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 694
 695    This parameter is specified for the communication of peer upper layer
 696    protocols.  It is envisioned to be used for flow control and other
 697    adaptation layers that require an indication to be carried in the
 698    INIT and INIT-ACK.  Each adaptation layer that is defined that wishes
 699    to use this parameter MUST specify a an adaptation code point in an
 700    appropriate RFC defining its use and meaning.  This parameter SHOULD
 701    NOT be examined by the receiving SCTP implementation and should be
 702    passed opaquely to the upper layer protocol.
 703
 704    Valid Chunk Appearance
 705
 706    The Adaptation Layer Indication parameter may appear in INIT or INIT-
 707    ACK chunk and SHOULD be passed to the receivers upper layer protocol.
 708    This parameter MUST NOT appear in a ASCONF chunk.
 709
 710 3.2.7.  Supported Extensions Parameter
 711
 712    This parameter is used at startup to identify any additional
 713    extensions that the sender supports.  The sender MUST support both
 714    the sending and the receiving of any chunk types listed within the
 715    Supported Extensions Parameter.
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728 Stewart, et al.         Expires December 2, 2006               [Page 13]
 729 \f
 730 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 731
 732
 733         0                   1                   2                   3
 734         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
 735        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 736        |     Parameter Type = 0x8008   |      Parameter Length         |
 737        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 738        | CHUNK TYPE 1  |  CHUNK TYPE 2 |  CHUNK TYPE 3 |  CHUNK TYPE 4 |
 739        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 740        |                             ....                              |
 741        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 742        | CHUNK TYPE N  |      PAD      |      PAD      |      PAD      |
 743        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 744
 745
 746    Parameter Type This field holds the IANA defined parameter type for
 747       Supported Extensions Parameter.  The suggested value of this field
 748       for IANA is 0x8008.
 749    Parameter Type Length This field holds the length of the parameter,
 750       including the Parameter Type, Parameter Length and any addition
 751       supported extensions.  Note the length MUST NOT include any
 752       padding.
 753    CHUNK TYPE X This field(s) hold the chunk type of any SCTP
 754       extension(s) that are currently supported by the sending SCTP.
 755       Multiple chunk types may be defined listing each additional
 756       feature that the sender supports.  The sender MUST NOT include
 757       multiple Supported Extensions Parameter within any chunk.
 758    Parameter Appearance This parameter may appear in the INIT or INIT-
 759       ACK chunk.  This parameter MUST NOT appear in any other chunk.
 760
 761 3.3.  New Error Causes
 762
 763    Five new Error Causes are added to the SCTP Operational Errors,
 764    primarily for use in the ASCONF-ACK chunk.
 765
 766        Cause Code
 767        Value          Cause Code
 768        ---------      ----------------
 769        0x0100          Request to Delete Last Remaining IP Address.
 770        0x0101          Operation Refused Due to Resource Shortage.
 771        0x0102          Request to Delete Source IP Address.
 772        0x0103          Association Aborted due to illegal ASCONF-ACK
 773        0x0104          Request refused - no authorization.
 774
 775              Table 5: New Error Causes
 776
 777 3.3.1.  Error Cause: Request to Delete Last Remaining IP Address
 778
 779    Cause of error
 780
 781
 782
 783
 784 Stewart, et al.         Expires December 2, 2006               [Page 14]
 785 \f
 786 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 787
 788
 789    Request to Delete Last Remaining IP address: The receiver of this
 790    error sent a request to delete the last IP address from its
 791    association with its peer.  This error indicates that the request is
 792    rejected.
 793
 794         0                   1                   2                   3
 795         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
 796        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 797        |     Cause Code=0x0100         |      Cause Length=Variable    |
 798        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 799        \                     TLV-Copied-From-ASCONF                    /
 800        /                                                               \
 801        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 802
 803    An example of a failed delete in an Error Cause TLV would look as
 804    follows in the response ASCONF-ACK message:
 805
 806            +--------------------------------+
 807            | Type = 0xC003  | Length = 28   |
 808            +----------------+---------------+
 809            |       C-ID = 0x01023476        |
 810            +--------------------------------+
 811            |  Cause=0x0100  | Length = 20   |
 812            +----------------+---------------+
 813            |  Type= 0xC002  | Length = 16   |
 814            +----------------+---------------+
 815            |       C-ID = 0x01023476        |
 816            +--------------------------------+
 817            |   Type=0x0005  | Length = 8    |
 818            +----------------+---------------+
 819            |       Value=0x0A010101         |
 820            +----------------+---------------+
 821
 822 3.3.2.  Error Cause: Operation Refused Due to Resource Shortage
 823
 824    Cause of error
 825
 826    This error cause is used to report a failure by the receiver to
 827    perform the requested operation due to a lack of resources.  The
 828    entire TLV that is refused is copied from the ASCONF into the error
 829    cause.
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840 Stewart, et al.         Expires December 2, 2006               [Page 15]
 841 \f
 842 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 843
 844
 845         0                   1                   2                   3
 846         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
 847        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 848        |     Cause Code=0x0101         |      Cause Length=Variable    |
 849        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 850        \                  TLV-Copied-From-ASCONF                      /
 851        /                                                              \
 852        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 853
 854    An example of a failed addition in an Error Cause TLV would look as
 855    follows in the response ASCONF-ACK message:
 856
 857            +--------------------------------+
 858            | Type = 0xC003  | Length = 28   |
 859            +--------------------------------+
 860            |       C-ID = 0x01023474        |
 861            +--------------------------------+
 862            |  Cause=0x0101  | Length = 20   |
 863            +----------------+---------------+
 864            |  Type=0xC001   | Length = 16   |
 865            +--------------------------------+
 866            |       C-ID = 0x01023474        |
 867            +--------------------------------+
 868            |  Type=0x0005   | Length = 8    |
 869            +----------------+---------------+
 870            |       Value=0x0A010101         |
 871            +----------------+---------------+
 872
 873 3.3.3.  Error Cause: Request to Delete Source IP Address
 874
 875    Cause of error
 876
 877    Request to Delete Source IP Address: The receiver of this error sent
 878    a request to delete the source IP address of the ASCONF message.
 879    This error indicates that the request is rejected.
 880
 881         0                   1                   2                   3
 882         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
 883        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 884        |     Cause Code=0x0102         |      Cause Length=Variable    |
 885        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 886        \                    TLV-Copied-From-ASCONF                     /
 887        /                                                               \
 888        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 889
 890    An example of a failed delete in an Error Cause TLV would look as
 891    follows in the response ASCONF-ACK message:
 892
 893
 894
 895
 896 Stewart, et al.         Expires December 2, 2006               [Page 16]
 897 \f
 898 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 899
 900
 901            +--------------------------------+
 902            | Type = 0xC003  | Length = 28   |
 903            +--------------------------------+
 904            |       C-ID = 0x01023476        |
 905            +--------------------------------+
 906            |  Cause=0x0102  | Length = 20   |
 907            +----------------+---------------+
 908            |  Type=0xC002   | Length = 16   |
 909            +----------------+---------------+
 910            |       C-ID = 0x01023476        |
 911            +--------------------------------+
 912            |   Type=0x0005  | Length = 8    |
 913            +----------------+---------------+
 914            |       Value=0x0A010101         |
 915            +----------------+---------------+
 916
 917    IMPLEMENTATION NOTE: It is unlikely that an endpoint would source a
 918    packet from the address being deleted, unless the endpoint does not
 919    do proper source address selection.
 920
 921 3.3.4.  Error Cause: Association Aborted due to illegal ASCONF-ACK
 922
 923    This error is to be included in an ABORT that is generated due to the
 924    reception of an ASCONF-ACK that was not expected but is larger than
 925    the current sequence number (see Section 4.3 Rule D0 ).  Note that a
 926    sequence number is larger than the last acked sequence number if it
 927    is either the next sequence or no more than 2^^31-1 greater than the
 928    current sequence number.
 929
 930         0                   1                   2                   3
 931         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
 932        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 933        |     Cause Code=0x0103         |      Cause Length=4           |
 934        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 935
 936 3.3.5.  Error Cause: Request refused - no authorization.
 937
 938    Cause of error
 939
 940    This error cause may be included to reject a request based on local
 941    security policies.
 942
 943
 944
 945
 946
 947
 948
 949
 950
 951
 952 Stewart, et al.         Expires December 2, 2006               [Page 17]
 953 \f
 954 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
 955
 956
 957         0                   1                   2                   3
 958         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
 959        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 960        |     Cause Code=0x0104         |      Cause Length=Variable    |
 961        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 962        \                     TLV-Copied-From-ASCONF                    /
 963        /                                                               \
 964        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 965
 966
 967 4.  Procedures
 968
 969    This section will lay out the specific procedures for address
 970    configuration change chunk type and its processing.
 971
 972 4.1.  ASCONF Chunk Procedures
 973
 974    When an endpoint has an ASCONF signaled change to be sent to the
 975    remote endpoint it should do the following:
 976
 977    A1) Create an ASCONF Chunk as defined in Section 3.1.1.  The chunk
 978       should contain all of the TLV(s) of information necessary to be
 979       sent to the remote endpoint, and unique correlation identities for
 980       each request.
 981    A2) A serial number should be assigned to the Chunk.  The serial
 982       number should be a monotonically increasing number.  The serial
 983       number MUST be initialized at the start of the association to the
 984       same value as the Initial TSN and every time a new ASCONF chunk is
 985       created it is incremented by one after assigning the serial number
 986       to the newly created chunk .
 987    A3) If no ASCONF Chunk is outstanding (un-acknowledged) with the
 988       remote peer, send the chunk.
 989    A4) Start a T-4 RTO timer, using the RTO value of the selected
 990       destination address (normally the primary path; see RFC2960
 991       [RFC2960] section 6.4 for details).
 992    A5) When the ASCONF-ACK that acknowledges the serial number last sent
 993       arrives, stop the T-4 RTO timer, and clear the appropriate
 994       association and destination error counters as defined in RFC2960
 995       [RFC2960] section 8.1 and 8.2.
 996    A6) Process all of the TLVs within the ASCONF-ACK to find out
 997       particular status information returned to the various requests
 998       that were sent.  Use the Correlation IDs to correlate the request
 999       and the responses.
1000    A7) If an error response is received for a TLV parameter, all TLVs
1001       with no response before the failed TLV are considered successful
1002       if not reported.  All TLVs after the failed response are
1003       considered unsuccessful unless a specific success indication is
1004       present for the parameter.
1005
1006
1007
1008 Stewart, et al.         Expires December 2, 2006               [Page 18]
1009 \f
1010 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1011
1012
1013    A8) If there is no response(s) to specific TLV parameter(s), and no
1014       failures are indicated, then all request(s) are considered
1015       successful.
1016    A9) If the peer responds to an ASCONF with an ERROR chunk reporting
1017       that it did not recognize the ASCONF chunk type, the sender of the
1018       ASCONF MUST NOT send any further ASCONF chunks and MUST stop its
1019       T-4 timer.
1020
1021    If the T-4 RTO timer expires the endpoint should do the following:
1022
1023    B1) Increment the error counters and perform path failure detection
1024       on the appropriate destination address as defined in RFC2960
1025       [RFC2960] section 8.1 and 8.2.
1026    B2) Increment the association error counters and perform endpoint
1027       failure detection on the association as defined in RFC2960
1028       [RFC2960] section 8.1 and 8.2.
1029    B3) Back-off the destination address RTO value to which the ASCONF
1030       chunk was sent by doubling the RTO timer value.
1031       Note: The RTO value is used in the setting of all timer types for
1032       SCTP.  Each destination address has a single RTO estimate.
1033    B4) Re-transmit the ASCONF Chunk last sent and if possible choose an
1034       alternate destination address (please refer to RFC2960 [RFC2960]
1035       section 6.4.1).  An endpoint MUST NOT add new parameters to this
1036       chunk, it MUST be the same (including its serial number) as the
1037       last ASCONF sent.
1038    B5) Restart the T-4 RTO timer.  Note that if a different destination
1039       is selected, then the RTO used will be that of the new destination
1040       address.
1041
1042    Note: the total number of re-transmissions is limited by B2 above.
1043    If the maximum is reached, the association will fail and enter into
1044    the CLOSED state (see RFC2960 [RFC2960] section 6.4.1 for details).
1045
1046 4.1.1.  Congestion Control of ASCONF Chunks
1047
1048    In defining the ASCONF Chunk transfer procedures, it is essential
1049    that these transfers MUST NOT cause congestion within the network.
1050    To achieve this, we place these restrictions on the transfer of
1051    ASCONF Chunks:
1052
1053    R1) One and only one ASCONF Chunk MAY be in transit and
1054       unacknowledged at any one time.  If a sender, after sending an
1055       ASCONF chunk, decides it needs to transfer another ASCONF Chunk,
1056       it MUST wait until the ASCONF-ACK Chunk returns from the previous
1057       ASCONF Chunk before sending a subsequent ASCONF.  Note this
1058       restriction binds each side, so at any time two ASCONF may be in-
1059       transit on any given association (one sent from each endpoint).
1060
1061
1062
1063
1064 Stewart, et al.         Expires December 2, 2006               [Page 19]
1065 \f
1066 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1067
1068
1069    R2) An ASCONF may be bundled with any other chunk type (except other
1070       ASCONF Chunks).
1071    R3) An ASCONF-ACK may be bundled with any other chunk type except
1072       other ASCONF-ACKs.
1073    R4) Both ASCONF and ASCONF-ACK chunks MUST NOT be sent in any SCTP
1074       state except ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-RECEIVED and
1075       SHUTDOWN-SENT.
1076    R5) An ASCONF MUST NOT be larger than the path MTU of the
1077       destination.
1078    R6) An ASCONF-ACK SHOULD not be larger than the path MTU.  In some
1079       circumstances an ASCONF-ACK may exceed the path MTU and in such a
1080       case IP fragmentation should be used to transmit the chunk.
1081
1082    If the sender of an ASCONF Chunk receives an Operational Error
1083    indicating that the ASCONF chunk type is not understood, then the
1084    sender MUST NOT send subsequent ASCONF Chunks to the peer.  The
1085    endpoint should also inform the upper layer application that the peer
1086    endpoint does not support any of the extensions detailed in this
1087    document.
1088
1089 4.2.  Upon reception of an ASCONF Chunk.
1090
1091    When an endpoint receives an ASCONF Chunk from the remote peer
1092    special procedures MAY be needed to identify the association the
1093    ASCONF Chunk is associated with.  To properly find the association
1094    the following procedures should be followed:
1095
1096    L1) Use the source address and port number of the sender to attempt
1097       to identify the association (i.e. use the same method defined in
1098       RFC2960 [RFC2960] used for all other SCTP chunks).  If found
1099       proceed to rule L4.
1100    L2) If the association is not found, use the address found in the
1101       Address Parameter TLV combined with the port number found in the
1102       SCTP common header.  If found proceed to rule L4.
1103    L3) If neither L1 or L2 locates the association, treat the chunk as
1104       an Out Of The Blue chunk as defined in RFC2960 [RFC2960].
1105    L4) Follow the normal rules to validate the SCTP verification tag
1106       found in RFC2960 [RFC2960].
1107
1108    After identification and verification of the association, the
1109    following should be performed to properly process the ASCONF Chunk:
1110
1111    C1) Compare the value of the serial number to the value the endpoint
1112       stored in a new association variable 'Peer-Serial-Number'.  This
1113       value MUST be initialized to the Initial TSN value minus 1.
1114
1115
1116
1117
1118
1119
1120 Stewart, et al.         Expires December 2, 2006               [Page 20]
1121 \f
1122 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1123
1124
1125    C2) If the value found in the serial number is equal to the ('Peer-
1126       Serial-Number' + 1), the endpoint MUST:
1127
1128       V1) Process the TLVs contained within the Chunk performing the
1129          appropriate actions as indicated by each TLV type.  The TLVs
1130          MUST be processed in order within the Chunk.  For example, if
1131          the sender puts 3 TLVs in one chunk, the first TLV (the one
1132          closest to the Chunk Header) in the Chunk MUST be processed
1133          first.  The next TLV in the chunk (the middle one) MUST be
1134          processed second and finally the last TLV in the Chunk MUST be
1135          processed last.  If the association was found via L2, the first
1136          parameter MUST be an Add IP address parameter for the source
1137          address of the packet.  If it is not the case the ASCONF is
1138          silently discarded.  Please note that this new address can not
1139          be deleted by a later parameter in the chunk because it is the
1140          source address of the packet.
1141       V2) In processing the chunk, the receiver should build a response
1142          message with the appropriate error TLVs, as specified in the
1143          Parameter type bits for any ASCONF Parameter it does not
1144          understand.  To indicate an unrecognized parameter, cause type
1145          8 as defined in the ERROR in 3.3.10.8 of RFC2960 [RFC2960]
1146          should be used.  The endpoint may also use the response to
1147          carry rejections for other reasons such as resource shortages
1148          etc, using the Error Cause TLV and an appropriate error
1149          condition.
1150          Note: a positive response is implied if no error is indicated
1151          by the sender.
1152       V3) All responses MUST copy the ASCONF-Request Correlation ID
1153          field received in the ASCONF parameter, from the TLV being
1154          responded to, into the ASCONF-Request Correlation ID field in
1155          the response parameter.
1156       V4) After processing the entire Chunk, the receiver of the ASCONF
1157          MUST send all TLVs for both unrecognized parameters and any
1158          other status TLVs inside the ASCONF-ACK chunk that acknowledges
1159          the arrival and processing of the ASCONF Chunk.
1160       V5) Update the 'Peer-Serial-Number' to the value found in the
1161          serial number field.
1162    C3) If the value found in the serial number is equal to the value
1163       stored in the 'Peer-Serial-Number', the endpoint should:
1164
1165       X1) Parse the ASCONF Chunk TLVs but the endpoint MUST NOT take any
1166          action on the TLVs parsed (since it has already performed these
1167          actions).
1168       X2) Build a response message with the appropriate response TLVs as
1169          specified in the ASCONF Parameter type bits, for any parameter
1170          it does not understand or could not process.
1171
1172
1173
1174
1175
1176 Stewart, et al.         Expires December 2, 2006               [Page 21]
1177 \f
1178 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1179
1180
1181       X3) After parsing the entire Chunk, it MUST send any response TLV
1182          errors and status with an ASCONF-ACK chunk acknowledging the
1183          arrival and processing of the ASCONF Chunk.
1184       X4) The endpoint MUST NOT update its 'Peer-Serial-Number'.
1185       Note: the response to the retransmitted ASCONF MUST be the same as
1186       the original response.  This MAY mean an implementation must keep
1187       state in order to respond with the same exact answer (including
1188       resource considerations that may have made the implementation
1189       refuse a request).
1190       IMPLEMENTATION NOTE: As an optimization a receiver may wish to
1191       save the last ASCONF-ACK for some predetermined period of time and
1192       instead of re-processing the ASCONF (with the same serial number)
1193       it may just re-transmit the ASCONF-ACK.  It may wish to use the
1194       arrival of a new serial number to discard the previously saved
1195       ASCONF-ACK or any other means it may choose to expire the saved
1196       ASCONF-ACK.
1197    C4) Otherwise, the ASCONF Chunk is discarded since it must be either
1198       a stale packet or from an attacker.  A receiver of such a packet
1199       MAY log the event for security purposes.
1200    C5) In both cases C2 and C3 the ASCONF-ACK MUST be sent back to the
1201       source address contained in the IP header of the ASCONF being
1202       responded to.
1203
1204 4.3.  General rules for address manipulation
1205
1206    When building TLV parameters for the ASCONF Chunk that will add or
1207    delete IP addresses the following rules should be applied:
1208
1209    D0) If an endpoint receives an ASCONF-ACK that is greater than or
1210       equal to the next serial number to be used but no ASCONF chunk is
1211       outstanding the endpoint MUST ABORT the association.  Note that a
1212       sequence number is greater than if it is no more than 2^^31-1
1213       larger than the current sequence number (using serial arithmetic).
1214    D1) When adding an IP address to an association, the IP address is
1215       NOT considered fully added to the association until the ASCONF-ACK
1216       arrives.  This means that until such time as the ASCONF containing
1217       the add is acknowledged the sender MUST NOT use the new IP address
1218       as a source for ANY SCTP packet except on carrying an ASCONF
1219       chunk.  The receiver of the add IP address request may use the
1220       address as a destination immediately.  The receiver MUST use the
1221       path verification procedure for the added address before using
1222       that address.  The receiver MUST NOT send packets to the new
1223       address except for the corresponding ASCONF-ACK chunk or HEARTBEAT
1224       chunks for path verification before the new path is verified.  If
1225       the ASCONF-ACK is sent to the new address it MAY be bundled with
1226       the HEARTBEAT chunk for path verification.
1227
1228
1229
1230
1231
1232 Stewart, et al.         Expires December 2, 2006               [Page 22]
1233 \f
1234 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1235
1236
1237    D2) After the ASCONF-ACK of an IP address add arrives, the endpoint
1238       MAY begin using the added IP address as a source address for any
1239       type of SCTP chunk.
1240    D3a) If an endpoint receives an Error Cause TLV indicating that the
1241       IP address Add or IP address Deletion parameters was not
1242       understood, the endpoint MUST consider the operation failed and
1243       MUST NOT attempt to send any subsequent Add or Delete requests to
1244       the peer.
1245    D3b) If an endpoint receives an Error Cause TLV indicating that the
1246       IP address Set Primary IP Address parameter was not understood,
1247       the endpoint MUST consider the operation failed and MUST NOT
1248       attempt to send any subsequent Set Primary IP Address requests to
1249       the peer.
1250    D4) When deleting an IP address from an association, the IP address
1251       MUST be considered a valid destination address for the reception
1252       of SCTP packets until the ASCONF-ACK arrives and MUST NOT be used
1253       as a source address for any subsequent packets.  This means that
1254       any datagrams that arrive before the ASCONF-ACK destined to the IP
1255       address being deleted MUST be considered part of the current
1256       association.  One special consideration is that ABORT chunks
1257       arriving destined to the IP address being deleted MUST be ignored
1258       (see Section 4.3.1 for further details).
1259    D5) An endpoint MUST NOT delete its last remaining IP address from an
1260       association.  In other words if an endpoint is NOT multi-homed it
1261       MUST NOT use the delete IP address without an add IP address
1262       preceding the delete parameter in the ASCONF chunk.  Or if an
1263       endpoint sends multiple requests to delete IP addresses it MUST
1264       NOT delete all of the IP addresses that the peer has listed for
1265       the requester.
1266    D6) An endpoint MUST NOT set an IP header source address for an SCTP
1267       packet holding the ASCONF Chunk to be the same as an address being
1268       deleted by the ASCONF Chunk.
1269    D7) If a request is received to delete the last remaining IP address
1270       of a peer endpoint, the receiver MUST send an Error Cause TLV with
1271       the error cause set to the new error code 'Request to Delete Last
1272       Remaining IP Address'.  The requested delete MUST NOT be performed
1273       or acted upon, other than to send the ASCONF-ACK.
1274    D8) If a request is received to delete an IP address which is also
1275       the source address of the IP packet which contained the ASCONF
1276       chunk, the receiver MUST reject this request.  To reject the
1277       request the receiver MUST send an Error Cause TLV set to the new
1278       error code 'Request to Delete Source IP Address' (unless Rule D5
1279       has also been violated, in which case the error code 'Request to
1280       Delete Last Remaining IP Address' is sent).
1281
1282
1283
1284
1285
1286
1287
1288 Stewart, et al.         Expires December 2, 2006               [Page 23]
1289 \f
1290 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1291
1292
1293    D9) If an endpoint receives an ADD IP address request and does not
1294       have the local resources to add this new address to the
1295       association, it MUST return an Error Cause TLV set to the new
1296       error code 'Operation Refused Due to Resource Shortage'.
1297    D10) If an endpoint receives an 'Out of Resource' error in response
1298       to its request to ADD an IP address to an association, it must
1299       either ABORT the association or not consider the address part of
1300       the association.  In other words if the endpoint does not ABORT
1301       the association, it must consider the add attempt failed and NOT
1302       use this address since its peer will treat SCTP packets destined
1303       to the address as Out Of The Blue packets.
1304    D11) When an endpoint receiving an ASCONF to add an IP address sends
1305       an 'Out of Resource' in its response, it MUST also fail any
1306       subsequent add or delete requests bundled in the ASCONF.  The
1307       receiver MUST NOT reject an ADD and then accept a subsequent
1308       DELETE of an IP address in the same ASCONF Chunk.  In other words,
1309       once a receiver begins failing any ADD or DELETE request, it must
1310       fail all subsequent ADD or DELETE requests contained in that
1311       single ASCONF.
1312    D12) When an endpoint receives a request to delete an IP address that
1313       is the current primary address, it is an implementation decision
1314       as to how that endpoint chooses the new primary address.
1315    D13) When an endpoint receives a valid request to DELETE an IP
1316       address the endpoint MUST consider the address no longer as part
1317       of the association.  It MUST NOT send SCTP packets for the
1318       association to that address and it MUST treat subsequent packets
1319       received from that address as Out Of The Blue.
1320       During the time interval between sending out the ASCONF and
1321       receiving the ASCONF-ACK it MAY be possible to receive DATA chunks
1322       out of order.  The following examples illustrate these problems:
1323
1324
1325
1326        Endpoint-A                                     Endpoint-Z
1327        ----------                                     ----------
1328        ASCONF[Add-IP:X]------------------------------>
1329                                                /--ASCONF-ACK
1330                                               /
1331                                     /--------/---New DATA:
1332                                    /        /    Destination
1333               <-------------------/        /     IP:X
1334                                           /
1335               <--------------------------/
1336
1337
1338    In the above example we see a new IP address (X) being added to the
1339    Endpoint-A.  However due to packet re-ordering in the network a new
1340    DATA chunk is sent and arrives at Endpoint-A before the ASCONF-ACK
1341
1342
1343
1344 Stewart, et al.         Expires December 2, 2006               [Page 24]
1345 \f
1346 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1347
1348
1349    confirming the add of the address to the association.
1350
1351    A similar problem exists with the deletion of an IP address as
1352    follows:
1353
1354
1355        Endpoint-A                                     Endpoint-Z
1356        ----------                                     ----------
1357                                     /------------New DATA:
1358                                    /             Destination
1359                                   /              IP:X
1360        ASCONF [DEL-IP:X]---------/---------------->
1361               <-----------------/------------------ASCONF-ACK
1362                                /
1363                               /
1364                <-------------/
1365
1366    In this example we see a DATA chunk destined to the IP:X (which is
1367    about to be deleted) arriving after the deletion is complete.  For
1368    the ADD case an endpoint SHOULD consider the newly adding IP address
1369    valid for the association to receive data from during the interval
1370    when awaiting the ASCONF-ACK.  The endpoint MUST NOT source data from
1371    this new address until the ASCONF-ACK arrives but it may receive out
1372    of order data as illustrated and MUST NOT treat this data as an OOTB
1373    datagram (please see RFC2960 [RFC2960] section 8.4).  It MAY drop the
1374    data silently or it MAY consider it part of the association but it
1375    MUST NOT respond with an ABORT.
1376
1377    For the DELETE case, an endpoint MAY respond to the late arriving
1378    DATA packet as an OOTB datagram or it MAY hold the deleting IP
1379    address for a small period of time as still valid.  If it treats the
1380    DATA packet as an OOTB the peer will silently discard the ABORT
1381    (since by the time the ABORT is sent the peer will have removed the
1382    IP address from this association).  If the endpoint elects to hold
1383    the IP address valid for a period of time, it MUST NOT hold it valid
1384    longer than 2 RTO intervals for the destination being removed.
1385
1386 4.3.1.  A special case for OOTB ABORT chunks
1387
1388    Another case worth mentioning is illustrated below:
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400 Stewart, et al.         Expires December 2, 2006               [Page 25]
1401 \f
1402 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1403
1404
1405        Endpoint-A                                     Endpoint-Z
1406        ----------                                     ----------
1407
1408        New DATA:------------\
1409        Source IP:X           \
1410                               \
1411        ASCONF-REQ[DEL-IP:X]----\------------------>
1412                                 \        /---------ASCONF-ACK
1413                                  \      /
1414                                   \----/-----------> OOTB
1415        (Ignored <---------------------/-------------ABORT
1416         by rule D4)                  /
1417               <---------------------/
1418
1419
1420    For this case, during the deletion of an IP address, an Abort MUST be
1421    ignored if the destination address of the Abort message is that of a
1422    destination being deleted.
1423
1424 4.3.2.  A special case for changing an address.
1425
1426    In some instances the sender may only have one IP address in an
1427    association that is being renumbered.  When this occurs, the sender
1428    may not be able to send to the peer the appropriate ADD/DELETE pair
1429    and use the old address as a source in the IP header.  For this
1430    reason the sender MUST fill in the Address Parameter field with an
1431    address that is part of the association (in this case the one being
1432    deleted).  This will allow the receiver to locate the association
1433    without using the source address found in the IP header.
1434
1435    The receiver of such a chunk MUST always first use the source address
1436    found in the IP header in looking up the association.  The receiver
1437    should attempt to use the address found in the Address Bytes field
1438    only if the lookup fails using the source address from the IP header.
1439    The receiver MUST reply to the source address of the packet in this
1440    case which is the new address that was added by the ASCONF (since the
1441    old address is no longer a part of the association after processing).
1442
1443 4.4.  Setting of the primary address
1444
1445    A sender of this option may elect to send this combined with a
1446    deletion or addition of an address.  A sender SHOULD only send a set
1447    primary request to an address that is already considered part of the
1448    association.  In other words if a sender combines a set primary with
1449    an add of a new IP address the set primary will be discarded unless
1450    the add request is to be processed BEFORE the set primary (i.e. it
1451    precedes the set primary).
1452
1453
1454
1455
1456 Stewart, et al.         Expires December 2, 2006               [Page 26]
1457 \f
1458 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1459
1460
1461    A request to set primary MAY also appear in an INIT or INIT-ACK
1462    chunk.  This can give advice to the peer endpoint as to which of its
1463    addresses the sender of the INIT or INIT-ACK would prefer to be used
1464    as the primary address.
1465
1466    The request to set an address as the primary path is an option the
1467    receiver SHOULD perform.  It is considered advice to the receiver of
1468    the best destination address to use in sending SCTP packets (in the
1469    requesters view).  If a request arrives that asks the receiver to set
1470    an address as primary that does not exist, the receiver should NOT
1471    honor the request, leaving its existing primary address unchanged.
1472
1473
1474 5.  Security Considerations
1475
1476    The addition and or deletion of an IP address to an existing
1477    association does provide an additional mechanism by which existing
1478    associations can be hijacked.  Therefore this document requires the
1479    use of the authentication mechanism defined in SCTP-AUTH [I-D.ietf-
1480    tsvwg-sctp-auth] to limit the ability of an attacker to hijack an
1481    association.
1482
1483    Hijacking an association by using the addition and deletion of an IP
1484    address is only possible for an attacker who is able to intercept the
1485    initial two packets of the association setup when the SCTP-AUTH
1486    extension is used without pre-shared keys..  If such a threat is
1487    considered a possibility, then the SCTP-AUTH [I-D.ietf-tsvwg-sctp-
1488    auth] extension MUST be used with a preconfigured shared end-point
1489    pair key to mitigate this threat.  For a more detailed analysis see
1490    SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth].
1491
1492    If an SCTP endpoint that supports this extension receives an INIT
1493    that indicates that the peer supports the ASCONF extension but does
1494    NOT support the SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth] extension, the
1495    receiver of such an INIT MUST send an ABORT in response to such an
1496    INIT.  Note that an implementation is allowed to silently discard
1497    such an INIT as an option as well but under NO circumstance is an
1498    implementation allowed to proceed with the association setup by
1499    sending an INIT-ACK in response.
1500
1501    An implementation that receives an INIT-ACK that indicates that the
1502    peer does not support the SCTP-AUTH [I-D.ietf-tsvwg-sctp-auth]
1503    extension MUST NOT send the COOKIE-ECHO to establish the association.
1504    Instead the implementation MUST discard the INIT-ACK and report to
1505    the upper layer user that an association cannot be established
1506    destroying the TCB.
1507
1508
1509
1510
1511
1512 Stewart, et al.         Expires December 2, 2006               [Page 27]
1513 \f
1514 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1515
1516
1517 6.  IANA considerations
1518
1519    This document defines the following new SCTP parameters, chunks and
1520    errors:
1521
1522    o  Two new chunk types,
1523    o  Seven parameter types, and
1524    o  Five new SCTP error causes.
1525
1526    One of the two new chunk types must come from the range of chunk
1527    types where the upper two bits are one, we recommend 0xC1 but any
1528    other available code point with the upper bits set is also
1529    acceptable.  The second chunk type must come from the range where
1530    only the upper bit is set to one.  We recommend 0x80 but any other
1531    available code point with the upper bit set is also acceptable.  The
1532    suggested chunk types are listed in Table 1.
1533
1534    All but one of the parameter types must come from the range of types
1535    where the upper two bits are set, we recommend 0xC001 - 0xC006, as
1536    specified in this document.  The other parameter type must come from
1537    the 0x8000 range, we recommend 0x8008.  Note that for any of these
1538    values a different unique parameter type may be assigned by IANA as
1539    long as the upper bits correspond to the ones specified in this
1540    document.  The suggested parameter types are listed in Table 2, Table
1541    3, and Table 4.
1542
1543    The five new error causes can be any value, in this document we have
1544    used 0x0100-0x0104 in an attempt to separate these from the common
1545    ranges of error codes.  Any other unassigned values are also
1546    acceptable.  The suggested error causes are listed in Table 5.
1547
1548    This document also defines a Adaptation code point.  The adaptation
1549    code point is a 32 bit integer that is assigned by IANA through an
1550    IETF Consensus action as defined in RFC2434 [RFC2434].
1551
1552
1553 7.  Acknowledgments
1554
1555    The authors wish to thank Jon Berger, Greg Kendall, Seok Koh, Peter
1556    Lei, John Loughney, Ivan Arias Rodriguez, Renee Revis, Marshall Rose,
1557    Chip Sharp, and Irene Ruengeler for their invaluable comments.
1558
1559    The authors would also like to give special mention to Maria-Carmen
1560    Belinchon and Ian Rytina for there early contributions to this
1561    document and their thoughtful comments.
1562
1563
1564
1565
1566
1567
1568 Stewart, et al.         Expires December 2, 2006               [Page 28]
1569 \f
1570 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1571
1572
1573 8.  References
1574
1575    [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
1576               3", BCP 9, RFC 2026, October 1996.
1577
1578    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1579               Requirement Levels", BCP 14, RFC 2119, March 1997.
1580
1581    [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header",
1582               RFC 2402, November 1998.
1583
1584    [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
1585               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
1586               October 1998.
1587
1588    [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
1589               June 1999.
1590
1591    [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
1592               Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
1593               Zhang, L., and V. Paxson, "Stream Control Transmission
1594               Protocol", RFC 2960, October 2000.
1595
1596    [I-D.ietf-tsvwg-sctp-auth]
1597               Tuexen, M., "Authenticated Chunks for Stream Control
1598               Transmission Protocol (SCTP)",
1599               draft-ietf-tsvwg-sctp-auth-02 (work in progress),
1600               March 2006.
1601
1602
1603 Appendix A.  Abstract Address Handling
1604
1605 A.1.  General remarks
1606
1607    The following text provides a working definition of the endpoint
1608    notion to discuss address reconfiguration.  It is not intended to
1609    restrict implementations in any way, its goal is to provide as set of
1610    definitions only.  Using these definitions should make a discussion
1611    about address issues easier.
1612
1613 A.2.  Generalized endpoints
1614
1615    A generalized endpoint is a pair of a set of IP addresses and a port
1616    number at any given point of time.  The precise definition is as
1617    follows:
1618
1619    A generalized endpoint gE at time t is given by
1620
1621
1622
1623
1624 Stewart, et al.         Expires December 2, 2006               [Page 29]
1625 \f
1626 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1627
1628
1629                   gE(t) = ({IP1, ..., IPn}, Port)
1630
1631    where {IP1, ..., IPn} is a non empty set of IP addresses.
1632
1633    Please note that the dynamic addition and deletion of IP-addresses
1634    described in this document allows the set of IP-addresses of a
1635    generalized endpoint to be changed at some point of time.  The port
1636    number can never be changed.
1637
1638    The set of IP addresses of a generalized endpoint gE at a time t is
1639    defined as
1640
1641                Addr(gE)(t) = {IP1, ..., IPn}
1642
1643    if gE(t) = ({IP1, ..., IPn}, Port) holds at time t.
1644
1645    The port number of a generalized endpoint gE is defined as
1646
1647                Port(gE) = Port
1648
1649    if gE(t) = ({IP1, ..., IPn}, Port) holds at time t.
1650
1651    There is one fundamental rule which restricts all generalized
1652    endpoints:
1653
1654    For two different generalized endpoints gE' and gE'' with the same
1655    port number Port(gE') = Port(gE'') the address sets Addr(gE')(t) and
1656    Addr(gE'')(t) must be disjoint at every point of time.
1657
1658 A.3.  Associations
1659
1660    Associations consists of two generalized endpoints and the two
1661    address sets known by the peer at any time.  The precise definition
1662    is as follows:
1663
1664    An association A between to different generalized endpoints gE' and
1665    gE'' is given by
1666
1667                   A = (gE', S', gE'', S'')
1668
1669    where S'(t) and S''(t) are set of addresses at any time t such that
1670    S'(t) is a non-empty subset of Addr(gE')(t) and S''(t) is a non-empty
1671    subset of Addr(gE'')(t).
1672
1673    If A = (gE', S', gE'', S'') is an association between the generalized
1674    endpoints gE' and gE'' the following notion is used:
1675
1676                   Addr(A, gE') = S'   and  Addr(A, gE'') = S''.
1677
1678
1679
1680 Stewart, et al.         Expires December 2, 2006               [Page 30]
1681 \f
1682 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1683
1684
1685    If the dependency on time is important the notion Addr(A, gE')(t) =
1686    S'(t) will be used.
1687
1688    If A is an association between gE' and gE'' then Addr(A, gE') is the
1689    subset of IP addresses of gE' which is known by gE'' and used by gE'.
1690
1691    Association establishment between gE' and gE'' can be seen as:
1692
1693    1.  gE' and gE'' do exist before the association.
1694    2.  If an INIT has to be send from gE' to gE'' address scoping rules
1695        and other limitations are applied to calculate the subset S' from
1696        Addr(gE').  The addresses of S' are included in the INIT chunk.
1697    3.  If an INIT-ACK has to be send from gE'' to gE' address scoping
1698        rules and other limitations are applied to calculate the subset
1699        S'' from Addr(gE'').  The addresses of S'' are included in the
1700        INIT-ACK chunk.
1701    4.  After the handshake the association A = (gE', S', gE'', S'') has
1702        been established.
1703    5.  Right after the association establishment Addr(A, gE') and
1704        Addr(A, gE'') are the addresses which have been seen on the wire
1705        during the handshake.
1706
1707 A.4.  Relationship with RFC 2960
1708
1709    RFC2960 [RFC2960] defines the notion of an endpoint.  This subsection
1710    will show that these endpoints are also (special) generalized
1711    endpoints.
1712
1713    RFC2960 [RFC2960] has no notion of address scoping or other address
1714    handling limitations and provides no mechanism to change the
1715    addresses of an endpoint.
1716
1717    This means that an endpoint is simply a generalized endpoint which
1718    does not depend on the time.  Neither the Port nor the address list
1719    changes.
1720
1721    During association setup no address scoping rules or other
1722    limitations will be applied.  This means that for an association A
1723    between two endpoints gE' and gE'' the following is true:
1724
1725    Addr(A, gE') = Addr(gE') and Addr(A, gE'') = Addr(gE'').
1726
1727 A.5.  Rules for address manipulation
1728
1729    The rules for address manipulation can now be stated in a simple way:
1730    1.  An address can be added to a generalized endpoint gE only if this
1731        address is not an address of a different generalized endpoint
1732        with the same port number.
1733
1734
1735
1736 Stewart, et al.         Expires December 2, 2006               [Page 31]
1737 \f
1738 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1739
1740
1741    2.  An address can be added to an association A with generalized
1742        endpoint gE if it has been added to the generalized endpoint gE
1743        first.  This means that the address must be an element of
1744        Addr(gE) first and then it can become an element of Addr(A, gE).
1745        But this is not necessary.  If the association does not allow the
1746        reconfiguration of the addresses only Addr(gE) can be modified.
1747    3.  An address can be deleted from an association A with generalized
1748        endpoint gE as long as Addr(A, gE) stays non-empty.
1749    4.  An address can be deleted from an generalized endpoint gE only if
1750        it has been removed from all associations having gE as a
1751        generalized endpoint.
1752
1753    These rules simply make sure that the rules for the endpoints and
1754    associations given above are always fulfilled.
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792 Stewart, et al.         Expires December 2, 2006               [Page 32]
1793 \f
1794 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1795
1796
1797 Authors' Addresses
1798
1799    Randall R. Stewart
1800    Cisco Systems, Inc.
1801    4875 Forest Drive
1802    Suite 200
1803    Columbia, SC  29206
1804    US
1805
1806    Phone:
1807    Email: rrs@cisco.com
1808
1809
1810    Michael A. Ramalho
1811    Cisco Systems, Inc.
1812    1802 Rue de la Porte
1813    Wall Township, NJ  07719-3784
1814    USA
1815
1816    Phone: +1.732.449.5762
1817    Email: mramalho@cisco.com
1818
1819
1820    Qiaobing Xie
1821    Motorola, Inc.
1822    1501 W. Shure Drive, #2309
1823    Arlington Heights, IL  60004
1824    USA
1825
1826    Phone: +1-847-632-3028
1827    Email: qxie1@email.mot.com
1828
1829
1830    Michael Tuexen
1831    Univ. of Applied Sciences Muenster
1832    Stegerwaldstr. 39
1833    48565 Steinfurt
1834    Germany
1835
1836    Email: tuexen@fh-muenster.de
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848 Stewart, et al.         Expires December 2, 2006               [Page 33]
1849 \f
1850 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1851
1852
1853    Phillip T. Conrad
1854    University of Delaware
1855    Department of Computer and Information Sciences
1856    Newark, DE  19716
1857    US
1858
1859    Phone: +1 302 831 8622
1860    Email: conrad@acm.org
1861    URI:   http://www.cis.udel.edu/~pconrad
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904 Stewart, et al.         Expires December 2, 2006               [Page 34]
1905 \f
1906 Internet-Draft    SCTP Dynamic Address Reconfiguration          May 2006
1907
1908
1909 Intellectual Property Statement
1910
1911    The IETF takes no position regarding the validity or scope of any
1912    Intellectual Property Rights or other rights that might be claimed to
1913    pertain to the implementation or use of the technology described in
1914    this document or the extent to which any license under such rights
1915    might or might not be available; nor does it represent that it has
1916    made any independent effort to identify any such rights.  Information
1917    on the procedures with respect to rights in RFC documents can be
1918    found in BCP 78 and BCP 79.
1919
1920    Copies of IPR disclosures made to the IETF Secretariat and any
1921    assurances of licenses to be made available, or the result of an
1922    attempt made to obtain a general license or permission for the use of
1923    such proprietary rights by implementers or users of this
1924    specification can be obtained from the IETF on-line IPR repository at
1925    http://www.ietf.org/ipr.
1926
1927    The IETF invites any interested party to bring to its attention any
1928    copyrights, patents or patent applications, or other proprietary
1929    rights that may cover technology that may be required to implement
1930    this standard.  Please address the information to the IETF at
1931    ietf-ipr@ietf.org.
1932
1933
1934 Disclaimer of Validity
1935
1936    This document and the information contained herein are provided on an
1937    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1938    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1939    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1940    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1941    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1942    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1943
1944
1945 Copyright Statement
1946
1947    Copyright (C) The Internet Society (2006).  This document is subject
1948    to the rights, licenses and restrictions contained in BCP 78, and
1949    except as set forth therein, the authors retain all their rights.
1950
1951
1952 Acknowledgment
1953
1954    Funding for the RFC Editor function is currently provided by the
1955    Internet Society.
1956
1957
1958
1959
1960 Stewart, et al.         Expires December 2, 2006               [Page 35]
1961 \f
1962