[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                    R. R. Stewart
INTERNET-DRAFT                                           Cisco Systems
                                                                Q. Xie
                                                              Motorola
                                                             M. Tuexen
                                                            Siemens AG
                                                             I. Rytina
                                                              Ericsson

expires in six months                                February 23, 2001


                     SCTP Dynamic Addition of IP addresses
                   <draft-ietf-sigtran-addip-sctp-01.txt>

    Status of This Memo

    This document is an Internet-Draft and is in full conformance with all
    provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts are
    working documents of the Internet Engineering Task Force (IETF), its areas,
    and its working groups. Note that other groups may also distribute
    working documents as Internet-Drafts.

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.


    Abstract

    This document describes an extension to the Stream Control
    Transmission Protocol (SCTP) [RFC2960] to provide a method to add or
    delete an IP address from an existing association or to request the
    peer to change its primary destination address. The benefit of this
    extension is for machines with hot pluggable interface cards the
    ability to add (and/or delete) IP addresses dynamically without
    forcing an SCTP association restart.

                        TABLE OF CONTENTS
    1. Introduction............................................... 2
    2. Conventions................................................ 2
    3. New Reliable Request/Acknowledgement Parameters............ 2
    3.1 New REL-REQ Parameters.................................... 2
    3.1.1 Add IP Address.......................................... 3
    3.1.2 Delete IP Address....................................... 3
    3.1.3 Set Primary IP Address.................................. 4
    3.2 New REL-ACK Parameters.................................... 4
    3.2.1 Error Cause: Request to Delete Last IP Address.......... 5
    3.2.2 Error Cause: Operation Refused due to Resource Shortage. 5
    3.2.3 Error Cause: Request to Delete Source IP Address........ 6
    3.3 New Error Causes.......................................... 6
    3.3.1 Request to delete last IP address....................... 6
    4. Procedures................................................. 6

Stewart et.al.                                                  [Page 1]


Internet Draft    SCTP Dynamic Addition of IP addresses    February 2001

    4.1 IP address addition and deletion.......................... 6
    4.2 Setting of the Primary Address............................ 9
    5. Security Considerations.................................... 9
    6. IANA considerations........................................10
    7. Authors' Addresses.........................................10
    8. References.................................................11

    1. Introduction

    Taking advantage of the extensibility of SCTP, and the generic
    method for transmitting reliable SCTP control chunks [RELREQ],
    this document introduces a use of the reliable control chunk,
    to allow an existing SCTP association to add or delete IP addresses
    without the currently required restart of the association.

    This enables SCTP to have dynamic IP addresses added and subtracted
    for those machines that allow addition/removal of an interface card.
    It also provides a method for a endpoint request that its peer set
    its primary destination address to an alternate, this can be useful
    when an address is about to be deleted. As an example application,
    this will provide the same type of services that exist in telephony
    signalling, which allow a link set to add an additional link without
    interfering with the operation of the link set.


    2. Conventions

    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
    SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
    they appear in this document, are to be interpreted as described in
    RFC 2119 [RFC2119].

    3. New Reliable Request/Acknowledgement Parameters

    This section describes the addition of three new REL-REQ Parameters
    to allow for the dynamic addition, deletion and setting of the
    primary, of IP addresses to an existing SCTP association. The format
    of these REL-REQ parameters within the Reliable Request Chunk is
    descibed in [REL-REQ]. We also describe a REL-ACK parameter that is
    carried to communicate errors or rejections of REL-REQ parameters.

    3.1 New REL-REQ Parameters

    The three new REL-REQ Parameters added follow the format defined in
    [REL-REQ] section 3.1.1. Table 2 describes the three new REL-REQ
    Parameters.

    REL-REQ Parameter                Type Value
    -------------------------------------------------
    Add IP Address                     49153 (0xC001)
    Delete IP Address                  49154 (0xC002)
    Set Primary Address                49159 (0xC007)

                 Table 1: REL-REQ Parameters

Stewart et.al.                                                  [Page 2]


Internet Draft    SCTP Dynamic Addition of IP addresses    February 2001


    3.1.1 Add IP Address

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Type = 49153            |    Length = Variable        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Address Parameter                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Address Parameter: TLV

    This field contains an IPv4 or IPv6 address parameter as described
    in 3.3.2.1 of RFC2960. The complete TLV is wrapped within this
    parameter.  It informs the receiver that the Address specified is to
    be added to the existing association. The sender of this request
    MUST NOT attempt to add an address type that is not supported by
    its peer.

    An example TLV adding the IPv4 address 10.1.1.1 to an existing
    association would look as follows:

        +--------------------------------+
        |  Type=49153    | Length = 12   |
        +--------------------------------+
        |  Type=5        | Length = 8    |
        +----------------+---------------+
        |       Value=0x0a010101         |
        +----------------+---------------+

    3.1.2 Delete IP Address

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Type = 49154             |    Length = Variable        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Address Parameter                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Address Parameter: TLV

    This field contains an IPv4 or IPv6 address parameter as described in
    3.3.2.1 of [RFC2960]. The complete TLV is wrapped within this
    parameter.  It informs the receiver that the Address specified is to
    be removed from the existing association.

    An example TLV deleting the IPv4 address 10.1.1.1 from an existing
    association would look as follows:

Stewart et.al.                                                  [Page 3]


Internet Draft    SCTP Dynamic Addition of IP addresses    February 2001

        +--------------------------------+
        |  Type=49154    | Length = 12   |
        +--------------------------------+
        |  Type=5        | Length = 8    |
        +----------------+---------------+
        |       Value=0x0a010101         |
        +----------------+---------------+

    3.1.3 Set Primary IP Address

     0                   1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Type = 49159             |    Length = Variable        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Address Parameter                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Address Parameter: TLV

    This field contains an IPv4 or IPv6 address parameter as described in
    3.3.2.1 of [RFC2960]. The complete TLV is wrapped within this
    parameter.  It requests the receiver to mark the specified address
    as the primary address to send data to (see section 5.1.2 of
    [RFC2960]). The receiver MAY mark this as its primary upon
    receiving this request.

    An example TLV requesting that the IPv4 address 10.1.1.1 be made the
    primary destination addrss would look as follows:

        +--------------------------------+
        |  Type=49159    | Length = 12   |
        +--------------------------------+
        |  Type=5        | Length = 8    |
        +----------------+---------------+
        |       Value=0x0a010101         |
        +----------------+---------------+

    3.2  New REL-ACK Parameters

    Three new Error Causes are added to the SCTP Operational Errors,
    primarily for use as part of the REL-REQ Parameter Error in the
    REL-ACK (as outlined in [REL-REQ] section 3.1.2).

    Cause Code
    Value          Cause Code
    ---------      ----------------
    11             Request to delete last IP address.
    12             Operation Refused due to resource shortage.
    13             Request to delete source IP address.

Stewart et.al.                                                  [Page 4]


Internet Draft    SCTP Dynamic Addition of IP addresses    February 2001

    3.2.1 Error Cause: Request to Delete Last IP Address

    Cause of error
    ---------------
    Request to delete last IP address: The receiver of this error sent a
    request to delete the last IP address from its association with its
    peer. This error indicates that the request is rejected.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Cause Code=11             |      Cause Length=var         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                     TLV-Copied-From-REL-REQ                   /
    /                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    An example of a failed delete in an Error Cause TLV would look as
    follows in the response REL-ACK message:

        +--------------------------------+
        | Type = 0xC005  | Length = 20   |
        +--------------------------------+
        |  Cause=11      | Length = 16   |
        +----------------+---------------+
        |  Type=49154    | Length = 12   |
        +----------------+---------------+
        |   Type=5       | Length = 8    |
        +----------------+---------------+
        |       Value=0x0a010101         |
        +----------------+---------------+

    3.2.2 Error Cause: Operation Refused due to Resource Shortage

    Cause of error
    ---------------
    This error cause is used to report a failure by the receiver to
    perform the requested operation due to a lack of resources.  The
    entire TLV that is refused is copied from the REL-REQ into the error
    cause.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Cause Code=12             |      Cause Length=Var         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                  TLV-Copied-From-REL-REQ                     /
    /                                                              \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    An example of a failed addition in an Error Cause TLV would look as
    follows in the response REL-ACK message:

        +--------------------------------+
        | Type = 0xC005  | Length = 20   |
        +--------------------------------+
        |  Cause=12      | Length = 16   |
        +----------------+---------------+
        |  Type=49153    | Length = 12   |
        +--------------------------------+

Stewart et.al.                                                  [Page 5]


Internet Draft    SCTP Dynamic Addition of IP addresses    February 2001

        |  Type=5        | Length = 8    |
        +----------------+---------------+
        |       Value=0x0a010101         |
        +----------------+---------------+

    3.2.3 Error Cause: Request to Delete Source IP Address

    Cause of error
    ---------------
    Request to delete source IP address: The receiver of this error sent
    a request to delete the source IP address of the REL-REQ
    message. This error indicates that the request is rejected.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Cause Code=13             |      Cause Length=VAR         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \                    TLV-Copied-From-REL-REQ                    /
    /                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    An example of a failed delete in an Error Cause TLV would look as
    follows in the response REL-ACK message:

        +--------------------------------+
        | Type = 0xC005  | Length = 20   |
        +--------------------------------+
        |  Cause=13      | Length = 16   |
        +----------------+---------------+
        |  Type=49154    | Length = 12   |
        +----------------+---------------+
        |   Type=5       | Length = 8    |
        +----------------+---------------+
        |       Value=0x0a010101         |
        +----------------+---------------+

    4. Procedures

    This section will lay out the specific procedures for the add/delete
    IP address REL-REQ Parameter. The generic procedures for
    transmitting reliable SCTP control chunks are covered in [RELREQ].

    4.1 IP address addition and deletion

    When building TLV parameters for the REL-REQ Chunk messages that
    will add or delete IP addresses the following rules should be
    applied:

    D1) When adding an IP address to an association, the IP address is
        NOT considered fully added to the association until the REL-ACK
        arrives. This means that until such time as the REL-REQ
        containing the add is acknowledged the sender MUST NOT use the
        new IP address as a source for ANY SCTP packet.

    D2) After the REL-ACK of an IP address add arrives, the endpoint MAY

Stewart et.al.                                                  [Page 6]


Internet Draft    SCTP Dynamic Addition of IP addresses    February 2001

        begin using the added IP address as a source address.

    D3) If an endpoint receives an Error Cause TLV indicating that the
        IP address Add, IP address Deletion,  or Set Primary IP Address
        REL-REQ parameters was not understood, the endpoint MUST
        consider the operation failed and MUST NOT attempt to
        send any subsequent Add, Delete or Set Primary requests to
        the peer.

    D4) When deleting an IP address from an association, the IP address
        MUST be considered a valid source address for DATA chunks
        until the REL-ACK arrives. This means that any datagrams that
        arrive before the REL-ACK destined to the IP address being
        deleted MUST be considered part of the current association.
        One special consideration is that ABORT chunks arriving destined
        to the IP address being deleted MUST be ignored (see Section
        4.1 for futher details).

    D5) An endpoint MUST NOT delete its last IP address from an
        association. In other words if an endpoint is NOT multi-homed it
        MUST NOT use the delete IP address. Or if an endpoint sends
        multiple requests to delete IP addresses it MUST NOT delete all
        of the IP addresses that the peer has listed for the requester.

    D6) An endpoint MUST NOT use the source address (of the IP packet
        containing the SCTP packet) for a REL-REQ to delete an IP
        address from the address being deleted.

    D7) If a request is received to delete the last IP address of a peer
        endpoint, the receiver MUST send an Error Cause TLV with the
        error cause set to the new error code 'Request to delete last IP
        address'. The requested delete MUST NOT be performed or acted
        upon, other than to send the REL-ACK.

    D8) If a request is received to delete an IP address which is also
        the source address of the IP packet which contained the REL-REQ
        chunk, the receiver MUST reject this request.  To reject the
        request the receiver MUST send a Error Cause TLV set to the new
        error code "Request to Delete Source IP Address" (unless Rule D5
        has also been violated, in which case the error code 'Request to
        delete last IP address' is sent).

    D9) After the REL-ACK of an IP address deletion arrives, the
        endpoint MUST NOT use the deleted IP address as a source of any
        SCTP packet.

    D10) If an endpoint receives an ADD IP address request and does not
        have the local resources to add this new address to the
        association, it MUST return an Error Cause TLV set to the new
        error code "Operation Refused due to Resource Shourtage".


Stewart et.al.                                                  [Page 7]


Internet Draft    SCTP Dynamic Addition of IP addresses    February 2001

    D11) If an endpoint receives an 'Out of Resource' error when adding
        an IP address to an association, it must either ABORT the
        association or not source any packets from this address. In
        other words if the endpoint does not ABORT the association, it
        must consider the add attempt failed and NOT use this address.

    D12) When an endpoint receiving a REL-REQ to add an IP address sends
         an 'Out of Resource' in its response, it MUST also fail any
         subsequent add or delete requests bundled in the REL-REQ.  The
         receiver MUST NOT reject an ADD and then accept a subsequent
         DELETE of an IP address in the same REL-REQ chunk. In other
         words, once a receiver begins failing any ADD or DELETE request,
         it must fail all subsequent ADD or DELETE requests contained in
         that single REL-REQ.

    D13) When an endpoint receives a request to delete an IP address that
         is the current primary address, it is an implementation decision
         as to how that endpoint chooses the new primary address.

    During the time interval between sending out the REL-REQ and
    receiving the REL-ACK it MAY be possible to receive DATA chunks out
    of order. The following examples illustrate these problems:

    Endpoint-A                                     Endpoint-Z
    ----------                                     ----------
    REL-REQ[Add-IP:X]------------------------------>
                                            /--REL-ACK
                                           /
                                 /--------/---New DATA:
                                /        /    Destination
           <-------------------/        /     IP:X
                                       /
           <--------------------------/

    In the above example we see a new IP address (X) being added to
    the Endpoint-A. However due to packet re-ordering in the network
    a new DATA chunk is sent and arrives at Endpoint-A before
    the REL-ACK confirming the add of the address to the association.

    A similar problem exists with the deletion of an IP address as
    follows:

    Endpoint-A                                     Endpoint-Z
    ----------                                     ----------
                                 /------------New DATA:
                                /             Destination
                               /              IP:X
    REL-REQ[DEL-IP:X]---------/---------------->
           <-----------------/------------------REL-ACK
                            /
                           /
            <-------------/

    In this example we see a DATA chunk destined to the IP:X (which is
    about to be deleted) arriving after the deletion is complete.

Stewart et.al.                                                  [Page 8]


Internet Draft    SCTP Dynamic Addition of IP addresses    February 2001


    For the ADD case an endpoint SHOULD consider the newly adding IP
    address valid for the association to receive data from during the
    interval when awaiting the REL-ACK. The endpoint MUST NOT source data
    from this new address until the REL-ACK arrives but it may receive out
    of order data as illustrated and MUST NOT treat this data as an OOTB
    datagram (please see [RFC2960] section 8.4). It MAY drop the data
    silently or it MAY consider it part of the association but it MUST NOT
    respond with an ABORT.

    For the DELETE case, an endpoint MAY respond to the late arriving DATA
    packet as an OOTB datagram or it MAY hold the deleting IP address for a
    small period of time as still valid. If it treats the DATA packet as
    an OOTB the peer will silently discard the ABORT (since by the time
    the ABORT is sent the peer will have removed the IP address from this
    association). If the endpoint elects to hold the IP address valid for
    a period of time, it MUST NOT hold it valid longer than 2 RTO
    intervals for the destination being removed.


    Another case worth mentioning is illustrated below:

    Endpoint-A                                     Endpoint-Z
    ----------                                     ----------

    New DATA:------------\
    Source IP:X           \
                           \
    REL-REQ[DEL-IP:X]-------\------------------>
                             \        /---------REL-ACK
                              \      /
                               \----/-----------> OOTB
    (Ignored ----------------------/-------------ABORT
     by rule D4)                  /
           <---------------------/

    For this case, during the deletion of an IP address, an
    Abort MUST be ignored if the destination address of the
    Abort message is that of the destination being deleted.

    4.2 Setting of the primary address

    A sender of this option may elect to send this combined with
    a deletion request for an address. A sender MUST only send
    a set primary request to an address that is considered
    part of the association. In other words a sender MUST NOT
    bundle a set primary with an add of a new IP address unless
    the add request is to be processed BEFORE the set primary.

    The request to set an address as the primary path is an option the
    receiver MAY perform. It is considered a hint to the receiver of the
    best destination address to use in sending SCTP packets (in the
    requestors view). It is possible that the receiver may have other
    knowledge that it may act upon and NOT set the specified address as

Stewart et.al.                                                  [Page 9]


Internet Draft    SCTP Dynamic Addition of IP addresses    February 2001

    primary.  If a request arrives that asks the receiver to set an
    address as primary that does not exist, the receiver should NOT
    honor the request, leaving its existing primary address unchanged.

    5. Security Considerations

    The ADD/DELETE of an IP address to an existing association does
    provide an additional mechanism by which existing associations can
    be hijacked.  Where the attacker is able to intercept and or alter
    the packets sent and received in an association the use of this
    feature MAY increase the ease at which an association may be
    overtaken. This threat SHOULD be considered when deploying a version
    of SCTP that use this feature. The IP Authentication Header
    [RFC2402] SHOULD be used when the threat environment requires
    stronger integrity protections, but does not require
    confidentiality. It should be noted that in the base SCTP
    specification [RFC2960], if an attacker is able to intercept and or
    alter packets, even without this feature it is possible to hijack an
    existing association, please refer to Section 11 of RFC2960.

    6. IANA considerations

    Three REL-REQ Parmeter Types and three new SCTP Error Causes are
    being defined within this document.

    7. Authors' Addresses

    Randall R. Stewart                      Tel: +1-815-477-2127
    Cisco Systems, Inc.                     EMail: rrs@cisco.com
    8745 W. Higgins Road, Suite 200
    Chicago, Ill  60631
    USA

    Qiaobing Xie                            Tel: +1-847-632-3028
    Motorola, Inc.                    EMail: qxie1@email.mot.com
    1501 W. Shure Drive, #2309
    Arlington Heights, IL 60004
    USA

    Michael Tuexen                          Tel: +49-89-722-47210
    SIEMENS AG               EMail: Michael.Tuexen@icn.siemens.de
    Hofmannstr. 51
    81359 Munich
    Germany

    Ian Rytina                              Tel: +61-3-9301-6164
    Ericsson Australia                      EMail:ian.rytina@ericsson.com
    37/360 Elizabeth Street
    Melbourne, Victoria 3000
    Australia

Stewart et.al.                                                 [Page 10]


Internet Draft    SCTP Dynamic Addition of IP addresses    February 2001

    8. References

    [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp,
        H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang,
        and, V. Paxson, "Stream Control Transmission Protocol," RFC
        2960, October 2000.

    [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
        3", RFC 2026, October 1996.

    [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997.

    [RFC2402] S. Kent, R. Atkinson., "IP Authentication Header.", RFC
        2402, November 1998.

    [RELREQ] "Generic Method for Transmitting Reliable SCTP Control
        Chunks", draft-stewart-relreq-sctp-sigtran-00.txt, work in
        progress.


      This Internet Draft expires in 6 months from February, 2001




































Stewart et.al.                                                 [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/