tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4460

 
 
 

Stream Control Transmission Protocol (SCTP) Specification Errata and Issues

Part 3 of 4, p. 58 to 87
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 58 
2.28.  Handling of IP Address Parameters

2.28.1.  Description of the Problem

   It is not stated clearly in RFC 2960 [5] how an SCTP endpoint that
   supports either IPv4 addresses or IPv6 addresses should respond if
   IPv4 and IPv6 addresses are presented by the peer in the INIT or
   INIT-ACK chunk.

2.28.2.  Text Changes to the Document

   ---------
   Old text: (Section 5.1.2)
   ---------

      IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
      fails to resolve the address parameter due to an unsupported type,
      it can abort the initiation process and then attempt a
      re-initiation by using a 'Supported Address Types' parameter in
      the new INIT to indicate what types of address it prefers.

   ---------
   New text: (Section 5.1.2)
   ---------

      IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
      fails to resolve the address parameter due to an unsupported type,
      it can abort the initiation process and then attempt a re-
      initiation by using a 'Supported Address Types' parameter in the
      new INIT to indicate what types of address it prefers.

      IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either
      IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-
      ACK chunk from its peer, it MUST use all the addresses belonging
      to the supported address family.  The other addresses MAY be
      ignored.  The endpoint SHOULD NOT respond with any kind of error
      indication.

2.28.3.  Solution Description

   The procedure of handling IP address parameters has been described
   clearly.

Top      Up      ToC       Page 59 
2.29.  Handling of COOKIE ECHO Chunks When a TCB Exists

2.29.1.  Description of the Problem

   The description of the behavior in RFC 2960 [5] when a COOKIE ECHO
   chunk and a TCB exist could be misunderstood.  When a COOKIE ECHO is
   received, a TCB exists and the local tag and peer's tag match, it is
   stated that the endpoint should enter the ESTABLISHED state if it has
   not already done so and send a COOKIE ACK.  It was not clear that, in
   the case the endpoint has already left the ESTABLISHED state again,
   then it should not go back to established.  In case D, the endpoint
   can only enter state ESTABLISHED from COOKIE-ECHOED because in state
   CLOSED it has no TCB and in state COOKIE-WAIT it has a TCB but knows
   nothing about the peer's tag, which is requested to match in this
   case.

2.29.2.  Text Changes to the Document

   ---------
   Old text: (Section 5.2.4)
   ---------
      D) When both local and remote tags match the endpoint should
         always enter the ESTABLISHED state, if it has not already
         done so.  It should stop any init or cookie timers that may
         be running and send a COOKIE ACK.

   ---------
   New text: (Section 5.2.4)
   ---------
      D) When both local and remote tags match, the endpoint should
         enter the ESTABLISHED state, if it is in the COOKIE-ECHOED
         state.  It should stop any cookie timer that may
         be running and send a COOKIE ACK.

2.29.3.  Solution Description

   The procedure of handling of COOKIE-ECHO chunks when a TCB exists has
   been described clearly.

2.30.  The Initial Congestion Window Size

2.30.1.  Description of the Problem

   RFC 2960 was published with the intention of having the same
   congestion control properties as TCP.  Since the publication of RFC
   2960, TCP's initial congestion window size has been increased via RFC>
   3390.  This same update will be needed for SCTP to keep SCTP's
   congestion control properties equivalent to that of TCP.

Top      Up      ToC       Page 60 
2.30.2.  Text Changes to the Document

   ---------
   Old text: (Section 7.2.1)
   ---------
      o  The initial cwnd before DATA transmission or after a
         sufficiently long idle period MUST be <= 2*MTU.

   ---------
   New text: (Section 7.2.1)
   ---------
      o  The initial cwnd before DATA transmission or after a
         sufficiently long idle period MUST be set to
         min(4*MTU, max (2*MTU, 4380 bytes)).

   ---------
   Old text: (Section 7.2.1)
   ---------
      o  When the endpoint does not transmit data on a given transport
         address, the cwnd of the transport address should be adjusted
         to max(cwnd/2, 2*MTU) per RTO.

   ---------
   New text: (Section 7.2.1)
   ---------
      o  When the endpoint does not transmit data on a given transport
         address, the cwnd of the transport address should be adjusted
         to max(cwnd/2, 4*MTU) per RTO.

   ---------
   Old text: (Section 7.2.2)
   ---------
      o  Same as in the slow start, when the sender does not transmit
         DATA on a given transport address, the cwnd of the transport
         address should be adjusted to max(cwnd / 2, 2*MTU) per RTO.

   ---------
   New text: (Section 7.2.2)
   ---------
      o  Same as in the slow start, when the sender does not transmit
         DATA on a given transport address, the cwnd of the transport
         address should be adjusted to max(cwnd / 2, 4*MTU) per RTO.

Top      Up      ToC       Page 61 
   ---------
   Old text: (Section 7.2.3)
   ---------

   7.2.3.  Congestion Control

      Upon detection of packet losses from SACK  (see Section 7.2.4), an
      endpoint should do the following:

         ssthresh = max(cwnd/2, 2*MTU)
         cwnd = ssthresh

      Basically, a packet loss causes cwnd to be cut in half.

      When the T3-rtx timer expires on an address, SCTP should perform
      slow start by

         ssthresh = max(cwnd/2, 2*MTU)
         cwnd = 1*MTU

   ---------
   New text: (Section 7.2.3)
   ---------

   7.2.3 Congestion Control

      Upon detection of packet losses from SACK  (see Section 7.2.4), An
      endpoint should do the following:

         ssthresh = max(cwnd/2, 4*MTU)
         cwnd = ssthresh

      Basically, a packet loss causes cwnd to be cut in half.

      When the T3-rtx timer expires on an address, SCTP should perform
      slow start by:

         ssthresh = max(cwnd/2, 4*MTU)
         cwnd = 1*MTU

2.30.3.  Solution Description

   The change to SCTP's initial congestion window will allow it to
   continue to maintain the same congestion control properties as TCP.

Top      Up      ToC       Page 62 
2.31.  Stream Sequence Numbers in Figures

2.31.1.  Description of the Problem

   In Section 2.24 of this document, it is clarified that the SSN are
   initialized with 0.  Two figures in RFC 2960 [5] illustrate that they
   start with 1.

Top      Up      ToC       Page 63 
2.31.2.  Text Changes to the Document

   ---------
   Old text: (Section 7.2.1)
   ---------

    Endpoint A                                          Endpoint Z
    {app sets association with Z}
    (build TCB)
    INIT [I-Tag=Tag_A
          & other info]  ------\
    (Start T1-init timer)       \
    (Enter COOKIE-WAIT state)    \---> (compose temp TCB and Cookie_Z)
                                   /-- INIT ACK [Veri Tag=Tag_A,
                                  /             I-Tag=Tag_Z,
    (Cancel T1-init timer) <-----/               Cookie_Z, & other info]
                                           (destroy temp TCB)
    COOKIE ECHO [Cookie_Z] ------\
    (Start T1-init timer)         \
    (Enter COOKIE-ECHOED state)    \---> (build TCB enter ESTABLISHED
                                          state)
                                   /---- COOKIE-ACK
                                  /
    (Cancel T1-init timer, <-----/
     Enter ESTABLISHED state)
    {app sends 1st user data; strm 0}
     DATA [TSN=initial TSN_A
         Strm=0,Seq=1 & user data]--\
     (Start T3-rtx timer)            \
                                      \->
                                  /----- SACK [TSN Ack=init
                                 /              TSN_A,Block=0]
   (Cancel T3-rtx timer) <------/
                                          ...
                                          {app sends 2 messages;strm 0}
                                    /---- DATA
                                   /        [TSN=init TSN_Z
                               <--/          Strm=0,Seq=1 & user data 1]
   SACK [TSN Ack=init TSN_Z,     /    ---- DATA
            Block=0]     --------\  /        [TSN=init TSN_Z +1,
                                  \/         Strm=0,Seq=2 & user data 2]
                           <------/\
                                    \
                                     \------>

                        Figure 4: INITiation Example

Top      Up      ToC       Page 64 
   ---------
   New text: (Section 7.2.1)
   ---------


    Endpoint A                                          Endpoint Z
    {app sets association with Z}
    (build TCB)
    INIT [I-Tag=Tag_A
          & other info]  ------\
    (Start T1-init timer)       \
    (Enter COOKIE-WAIT state)    \---> (compose temp TCB and Cookie_Z)
                                    /-- INIT ACK [Veri Tag=Tag_A,
                                   /             I-Tag=Tag_Z,
    (Cancel T1-init timer) <------/              Cookie_Z, & other info]
                                         (destroy temp TCB)
    COOKIE ECHO [Cookie_Z] ------\
    (Start T1-init timer)         \
    (Enter COOKIE-ECHOED state)    \---> (build TCB enter ESTABLISHED
                                          state)
                                   /---- COOKIE-ACK
                                  /
    (Cancel T1-init timer, <-----/
     Enter ESTABLISHED state)
    {app sends 1st user data; strm 0}
    DATA [TSN=initial TSN_A
        Strm=0,Seq=0 & user data]--\
    (Start T3-rtx timer)            \
                                     \->
                                   /----- SACK [TSN Ack=init
                                  /           TSN_A,Block=0]
    (Cancel T3-rtx timer) <------/
                                          ...
                                         {app sends 2 messages;strm 0}
                                   /---- DATA
                                  /        [TSN=init TSN_Z
                              <--/          Strm=0,Seq=0 & user data 1]
    SACK [TSN Ack=init TSN_Z,      /---- DATA
          Block=0]     --------\  /        [TSN=init TSN_Z +1,
                                \/          Strm=0,Seq=1 & user data 2]
                         <------/\
                                  \
                                   \------>

                       Figure 4: INITiation Example

Top      Up      ToC       Page 65 
   ---------
   Old text: (Section 5.2.4.1)
   ---------

   Endpoint A                                          Endpoint Z
   <------------ Association is established---------------------->
   Tag=Tag_A                                             Tag=Tag_Z
   <------------------------------------------------------------->
   {A crashes and restarts}
   {app sets up a association with Z}
   (build TCB)
   INIT [I-Tag=Tag_A'
         & other info]  --------\
   (Start T1-init timer)         \
   (Enter COOKIE-WAIT state)      \---> (find a existing TCB
                                         compose temp TCB and Cookie_Z
                                         with Tie-Tags to previous
                                         association)
                                   /--- INIT ACK [Veri Tag=Tag_A',
                                  /               I-Tag=Tag_Z',
   (Cancel T1-init timer) <------/                Cookie_Z[TieTags=
                                                  Tag_A,Tag_Z
                                                   & other info]
                                        (destroy temp TCB,leave original
                                         in place)
   COOKIE ECHO [Veri=Tag_Z',
                Cookie_Z
                Tie=Tag_A,
                Tag_Z]----------\
   (Start T1-init timer)         \
   (Enter COOKIE-ECHOED state)    \---> (Find existing association,
                                         Tie-Tags match old tags,
                                         Tags do not match i.e.,
                                         case X X M M above,
                                         Announce Restart to ULP
                                         and reset association).
                                  /---- COOKIE-ACK
   (Cancel T1-init timer, <------/
    Enter ESTABLISHED state)
   {app sends 1st user data; strm 0}
   DATA [TSN=initial TSN_A
       Strm=0,Seq=1 & user data]--\
   (Start T3-rtx timer)            \
                                    \->
                                 /--- SACK [TSN Ack=init TSN_A,Block=0]
   (Cancel T3-rtx timer) <------/

                     Figure 5: A Restart Example

Top      Up      ToC       Page 66 
   ---------
   New text: (Section 5.2.4.1)
   ---------

   Endpoint A                                          Endpoint Z
   <-------------- Association is established---------------------->
   Tag=Tag_A                                             Tag=Tag_Z
   <--------------------------------------------------------------->
   {A crashes and restarts}
   {app sets up a association with Z}
   (build TCB)
   INIT [I-Tag=Tag_A'
         & other info]  --------\
   (Start T1-init timer)         \
   (Enter COOKIE-WAIT state)      \---> (find a existing TCB
                                         compose temp TCB and Cookie_Z
                                         with Tie-Tags to previous
                                         association)
                                   /--- INIT ACK [Veri Tag=Tag_A',
                                  /               I-Tag=Tag_Z',
   (Cancel T1-init timer) <------/                Cookie_Z[TieTags=
                                                  Tag_A,Tag_Z
                                                   & other info]
                                        (destroy temp TCB,leave original
                                         in place)
   COOKIE ECHO [Veri=Tag_Z',
                Cookie_Z
                Tie=Tag_A,
                Tag_Z]----------\
   (Start T1-init timer)         \
   (Enter COOKIE-ECHOED state)    \---> (Find existing association,
                                         Tie-Tags match old tags,
                                         Tags do not match i.e.,
                                         case X X M M above,
                                         Announce Restart to ULP
                                         and reset association).
                                  /---- COOKIE-ACK
   (Cancel T1-init timer, <------/
    Enter ESTABLISHED state)
   {app sends 1st user data; strm 0}
   DATA [TSN=initial TSN_A
       Strm=0,Seq=0 & user data]--\
   (Start T3-rtx timer)            \
                                    \->
                                 /--- SACK [TSN Ack=init TSN_A,Block=0]
   (Cancel T3-rtx timer) <------/

                     Figure 5: A Restart Example

Top      Up      ToC       Page 67 
2.31.3.  Solution description

   Figure 4 and 5 were changed so that the SSN starts with 0 instead of
   1.

2.32.  Unrecognized Parameters

2.32.1.  Description of the Problem

   The RFC does not state clearly in Section 3.3.3.1 whether one or
   multiple unrecognized parameters are included in the 'Unrecognized
   Parameter' parameter.

2.32.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.3.3)
   ---------
         Variable Parameters                  Status     Type Value
         -------------------------------------------------------------
         State Cookie                        Mandatory   7
         IPv4 Address (Note 1)               Optional    5
         IPv6 Address (Note 1)               Optional    6
         Unrecognized Parameters             Optional    8
         Reserved for ECN Capable (Note 2)   Optional    32768 (0x8000)
         Host Name Address (Note 3)          Optional    11

   ---------
   New text: (Section 3.3.3)
   ---------
         Variable Parameters                  Status     Type Value
         -------------------------------------------------------------
         State Cookie                        Mandatory   7
         IPv4 Address (Note 1)               Optional    5
         IPv6 Address (Note 1)               Optional    6
         Unrecognized Parameter              Optional    8
         Reserved for ECN Capable (Note 2)   Optional    32768 (0x8000)
         Host Name Address (Note 3)          Optional    11


   ---------
   Old text: (Section 3.3.3.1)
   ---------
      Unrecognized Parameters:

         Parameter Type Value: 8

         Parameter Length:  Variable Size.

Top      Up      ToC       Page 68 
         Parameter Value:
            This parameter is returned to the originator of the INIT
            chunk when the INIT contains an unrecognized parameter
            which has a value that indicates that it should be reported
            to the sender.  This parameter value field will contain
            unrecognized parameters copied from the INIT chunk complete
            with Parameter Type, Length and Value fields.

   ---------
   New text: (Section 3.3.3.1)
   ---------
      Unrecognized Parameter:

         Parameter Type Value: 8

         Parameter Length:  Variable Size.

         Parameter Value:

            This parameter is returned to the originator of the INIT
            chunk when the INIT contains an unrecognized parameter
            that has a value that indicates that it should be reported
            to the sender.  This parameter value field will contain the
            unrecognized parameter copied from the INIT chunk complete
            with Parameter Type, Length, and Value fields.

2.32.3.  Solution Description

   The new text states clearly that only one unrecognized parameter is
   reported per parameter.

2.33.  Handling of Unrecognized Parameters

2.33.1.  Description of the Problem

   It is not stated clearly in RFC 2960 [5] how unrecognized parameters
   should be handled.  The problem comes up when an INIT contains an
   unrecognized parameter with highest bits 00.  It was not clear
   whether an INIT-ACK should be sent.

2.33.2.  Text Changes to the Document

   Some of the changes given here already include changes suggested in
   Section 2.27 of this document.

Top      Up      ToC       Page 69 
   ---------
   Old text: (Section 3.2.1)
   ---------

   00 - Stop processing this SCTP packet and discard it, do not process
        any further chunks within it.

   01 - Stop processing this SCTP packet and discard it, do not process
        any further chunks within it, and report the unrecognized
        parameter in an 'Unrecognized Parameter Type' (in either an
        ERROR or in the INIT ACK).

   10 - Skip this parameter and continue processing.

   11 - Skip this parameter and continue processing but report the
        unrecognized parameter in an 'Unrecognized Parameter Type' (in
        either an ERROR or in the INIT ACK).

   ---------
   New text: (Section 3.2.1)
   ---------

   00 - Stop processing this parameter; do not process
        any further parameters within this chunk.

   01 - Stop processing this parameter, do not process
        any further parameters within this chunk, and report the
        unrecognized parameter in an 'Unrecognized Parameter Type', as
        described in 3.2.2.

   10 - Skip this parameter and continue processing.

   11 - Skip this parameter and continue processing but report the
        unrecognized parameter in an 'Unrecognized Parameter Type', as
        described in 3.2.2.


   ---------
   New text: (Note: no old text; clarification added in section 3.2)
   ---------

   3.2.2.  Reporting of Unrecognized Parameters

   If the receiver of an INIT chunk detects unrecognized parameters and
   has to report them according to Section 3.2.1, it MUST put the
   'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in
   response to the INIT-chunk.  Note that if the receiver of the INIT
   chunk is NOT going to establish an association (e.g., due to lack of

Top      Up      ToC       Page 70 
   resources), an 'Unrecognized Parameter' would NOT be included with
   any ABORT being sent to the sender of the INIT.

   If the receiver of an INIT-ACK chunk detects unrecognized parameters
   and has to report them according to Section 3.2.1, it SHOULD bundle
   the ERROR chunk containing the 'Unrecognized Parameter' error cause
   with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk.
   If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk
   with the ERROR chunk, the ERROR chunk MAY be sent separately but not
   before the COOKIE-ACK has been received.

   Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
   first chunk.

2.33.3.  Solution Description

   The procedure of handling unrecognized parameters has been described
   clearly.

2.34.  Tie Tags

2.34.1.  Description of the Problem

   RFC 2960 requires that Tie-Tags be included in the COOKIE.  The
   cookie may not be encrypted.  An attacker could discover the value of
   the Verification Tags by analyzing cookies received after sending an
   INIT.

2.34.2.  Text Changes to the Document

   ---------
   Old text: (Section 1.4)
   ---------
      o  Tie-Tags: Verification Tags from a previous association.  These
         Tags are used within a State Cookie so that the newly
         restarting association can be linked to the original
         association within the endpoint that did not restart.

   ---------
   New text: (Section 1.4)
   ---------

      o  Tie-Tags: Two 32-bit random numbers that together make a 64-
         bit nonce.  These Tags are used within a State Cookie and TCB
         so that a newly restarting association can be linked to the
         original association within the endpoint that did not restart
         and yet not reveal the true Verification Tags of an existing
         association.

Top      Up      ToC       Page 71 
   ---------
   Old text: (Section 5.2.1)
   ---------

      For an endpoint that is in the COOKIE-ECHOED state it MUST
      populate its Tie-Tags with the Tag information of itself and
      its peer (see Section 5.2.2 for a description of the Tie-Tags).

   ---------
   New text: (Section 5.2.1)
   ---------
      For an endpoint that is in the COOKIE-ECHOED state it MUST
      populate its Tie-Tags within both the association TCB and
      inside the State Cookie (see section 5.2.2 for a description
      of the Tie-Tags).


   ---------
   Old text: (Section 5.2.2)
   ---------
      Unless otherwise stated, upon reception of an unexpected INIT for
      this association, the endpoint shall generate an INIT ACK with a
      State Cookie.  In the outbound INIT ACK the endpoint MUST copy its
      current Verification Tag and peer's Verification Tag into a
      reserved place within the state cookie.  We shall refer to these
      locations as the Peer's-Tie-Tag and the Local-Tie-Tag.  The
      outbound SCTP packet containing this INIT ACK MUST carry a
      Verification Tag value equal to the Initiation Tag found in the
      unexpected INIT.  And the INIT ACK MUST contain a new Initiation
      Tag (randomly generated see Section 5.3.1).  Other parameters
      for the endpoint SHOULD be copied from the existing parameters
      of the association (e.g., number of outbound streams) into the
      INIT ACK and cookie.

   ---------
   New text: (Section 5.2.2)
   ---------

      Unless otherwise stated, upon receipt of an unexpected INIT for
      this association, the endpoint MUST generate an INIT ACK with a
      State Cookie.  In the outbound INIT ACK, the endpoint MUST copy
      its current Tie-Tags to a reserved place within the State Cookie
      and the association's TCB.  We shall refer to these locations
      inside the cookie as the Peer's-Tie-Tag and the Local-Tie-Tag.  We
      will refer to the copy within an association's TCB as the Local
      Tag and Peer's Tag.  The outbound SCTP packet containing this INIT
      ACK MUST carry a Verification Tag value equal to the Initiation
      Tag found in the unexpected INIT.  And the INIT ACK MUST contain a

Top      Up      ToC       Page 72 
      new Initiation Tag (randomly generated; see Section 5.3.1).  Other
      parameters for the endpoint SHOULD be copied from the existing
      parameters of the association (e.g., number of outbound streams)
      into the INIT ACK and cookie.

2.34.3.  Solution Description

   The solution to this problem is not to use the real Verification Tags
   within the State Cookie as tie-tags.  Instead, two 32-bit random
   numbers are created to form one 64-bit nonce and stored both in the
   State Cookie and the existing association TCB.  This prevents
   exposing the Verification Tags inadvertently.

2.35.  Port Number Verification in the COOKIE-ECHO

2.35.1.  Description of the Problem

   The State Cookie sent by a listening SCTP endpoint may not contain
   the original port numbers or the local Verification Tag.  It is then
   possible that the endpoint, on receipt of the COOKIE-ECHO, will not
   be able to verify that these values match the original values found
   in the INIT and INIT-ACK that began the association setup.

2.35.2.  Text Changes to the Document

   ---------
   Old text: (Section 5.1.5)
   ---------
      3) Compare the creation timestamp in the State Cookie to the
         current local time.  If the elapsed time is longer than the
         lifespan carried in the State Cookie, then the packet,
         including the COOKIE ECHO and any attached DATA chunks,
         SHOULD be discarded and the endpoint MUST transmit an ERROR
         chunk with a "Stale Cookie" error cause to the peer endpoint,

      4) If the State Cookie is valid, create an association to the
         sender of the COOKIE ECHO chunk with the information in the
         TCB data carried in the COOKIE ECHO, and enter the
         ESTABLISHED state,

      5) Send a COOKIE ACK chunk to the peer acknowledging reception
         of the COOKIE ECHO.  The COOKIE ACK MAY be bundled with an
         outbound DATA chunk or SACK chunk; however, the COOKIE ACK
         MUST be the first chunk in the SCTP packet.

      6) Immediately acknowledge any DATA chunk bundled with the COOKIE
         ECHO with a SACK (subsequent DATA chunk acknowledgement should
         follow the rules defined in Section 6.2).  As mentioned in step

Top      Up      ToC       Page 73 
         5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
         MUST appear first in the SCTP packet.

   ---------
   New text: (Section 5.1.5)
   ---------

      3) Compare the port numbers and the Verification Tag contained
         within the COOKIE ECHO chunk to the actual port numbers and the
         Verification Tag within the SCTP common header of the received
         packet.  If these values do not match, the packet MUST be
         silently discarded.

      4) Compare the creation timestamp in the State Cookie to the
         current local time.  If the elapsed time is longer than the
         lifespan carried in the State Cookie, then the packet,
         including the COOKIE ECHO and any attached DATA chunks,
         SHOULD be discarded, and the endpoint MUST transmit an
         ERROR chunk with a "Stale Cookie" error cause to the peer
         endpoint.

      5) If the State Cookie is valid, create an association to the
         sender of the COOKIE ECHO chunk with the information in the
         TCB data carried in the COOKIE ECHO and enter the
         ESTABLISHED state.

      6) Send a COOKIE ACK chunk to the peer acknowledging receipt of
         the COOKIE ECHO.  The COOKIE ACK MAY be bundled with an
         outbound DATA chunk or SACK chunk; however, the COOKIE ACK
         MUST be the first chunk in the SCTP packet.

      7) Immediately acknowledge any DATA chunk bundled with the COOKIE
         ECHO with a SACK (subsequent DATA chunk acknowledgement should
         follow the rules defined in Section 6.2).  As mentioned in step
         5, if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
         MUST appear first in the SCTP packet.

2.35.3.  Solution Description

   By including both port numbers and the local Verification Tag within
   the State Cookie and verifying these during COOKIE-ECHO processing,
   this issue is resolved.

Top      Up      ToC       Page 74 
2.36.  Path Initialization

2.36.1.  Description of the Problem

   When an association enters the ESTABLISHED state, the endpoint has no
   verification that all of the addresses presented by the peer do in
   fact belong to the peer.  This could cause various forms of denial of
   service attacks.

2.36.2.  Text Changes to the Document

   ---------
   Old text: None
   ---------

   ---------
   New text: (Section 5.4)
   ---------
   5.4.  Path Verification

   During association establishment, the two peers exchange a list of
   addresses.  In the predominant case, these lists accurately represent
   the addresses owned by each peer.  However, it is possible that a
   misbehaving peer may supply addresses that it does not own.  To
   prevent this, the following rules are applied to all addresses of the
   new association:

   1) Any address passed to the sender of the INIT by its upper layer is
      automatically considered to be CONFIRMED.

   2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is
      the one that the INIT-ACK was sent to.

   3) All other addresses not covered by rules 1 and 2 are considered
      UNCONFIRMED and are subject to probing for verification.

   To probe an address for verification, an endpoint will send
   HEARTBEATs including a 64-bit random nonce and a path indicator (to
   identify the address that the HEARTBEAT is sent to) within the
   HEARTBEAT parameter.

   Upon receipt of the HEARTBEAT-ACK, a verification is made that the
   nonce included in the HEARTBEAT parameter is the one sent to the
   address indicated inside the HEARTBEAT parameter.  When this match
   occurs, the address that the original HEARTBEAT was sent to is now
   considered CONFIRMED and available for normal data transfer.

Top      Up      ToC       Page 75 
   These probing procedures are started when an association moves to the
   ESTABLISHED state and are ended when all paths are confirmed.

   Each RTO a probe may be sent on an active UNCONFIRMED path in an
   attempt to move it to the CONFIRMED state.  If during this probing
   the path becomes inactive, this rate is lowered to the normal
   HEARTBEAT rate.  At the expiration of the RTO timer, the error
   counter of any path that was probed but not CONFIRMED is incremented
   by one and subjected to path failure detection, as defined in section
   8.2.  When probing UNCONFIRMED addresses, however, the association
   overall error count is NOT incremented.

   The number of HEARTBEATS sent at each RTO SHOULD be limited by the
   HB.Max.Burst parameter.  It is an implementation decision as to how
   to distribute HEARTBEATS to the peer's addresses for path
   verification.

   Whenever a path is confirmed, an indication MAY be given to the upper
   layer.

   An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with
   the following exceptions:

   - A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED
     address.

   - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address.

   - A COOKIE-ACK MAY be sent to an UNCONFIRMED address, but it MUST be
     bundled with a HEARTBEAT including a nonce.  An implementation that
     does NOT support bundling MUST NOT send a COOKIE-ACK to an
     UNCONFIRMED address.

   - A COOKE-ECHO MAY be sent to an UNCONFIRMED address, but it MUST be
     bundled with a HEARTBEAT including a nonce, and the packet MUST NOT
     exceed the path MTU.  If the implementation does NOT support
     bundling or if the bundled COOKIE-ECHO plus HEARTBEAT (including
     nonce) would exceed the path MTU, then the implementation MUST NOT
     send a COOKIE-ECHO to an UNCONFIRMED address.

   ---------
   Old text: (Section 14)
   ---------

   14.  Suggested SCTP Protocol Parameter Values

   The following protocol parameters are RECOMMENDED:

Top      Up      ToC       Page 76 
   RTO.Initial              - 3  seconds
   RTO.Min                  - 1  second
   RTO.Max                 -  60 seconds
   RTO.Alpha                - 1/8
   RTO.Beta                 - 1/4
   Valid.Cookie.Life        - 60  seconds
   Association.Max.Retrans  - 10 attempts
   Path.Max.Retrans         - 5  attempts (per destination address)
   Max.Init.Retransmits     - 8  attempts
   HB.interval              - 30 seconds

   ---------
   New text: (Section 14)
   ---------

   14.  Suggested SCTP Protocol Parameter Values

   The following protocol parameters are RECOMMENDED:

   RTO.Initial              - 3 seconds
   RTO.Min                  - 1 second
   RTO.Max                  - 60 seconds
   Max.Burst                - 4
   RTO.Alpha                - 1/8
   RTO.Beta                 - 1/4
   Valid.Cookie.Life        - 60 seconds
   Association.Max.Retrans  - 10 attempts
   Path.Max.Retrans         - 5 attempts (per destination address)
   Max.Init.Retransmits     - 8 attempts
   HB.Interval              - 30 seconds
   HB.Max.Burst             - 1

2.36.3.  Solution Description

   By properly setting up initial path state and accelerated probing via
   HEARTBEAT's, a new association can verify that all addresses
   presented by a peer belong to that peer.

2.37.  ICMP Handling Procedures

2.37.1.  Description of the Problem

   RFC 2960 does not describe how ICMP messages should be processed by
   an SCTP endpoint.

Top      Up      ToC       Page 77 
2.37.2.  Text Changes to the Document

   --------
   Old text: None
   --------

   ---------
   New text
   ---------

   11.5.  Protection of Non-SCTP Capable Hosts.

   To provide a non-SCTP capable host with the same level of protection
   against attacks as for SCTP-capable ones, all SCTP stacks MUST
   implement the ICMP handling described in Appendix C.

   When an SCTP stack receives a packet containing multiple control or
   DATA chunks and the processing of the packet requires the sending of
   multiple chunks in response, the sender of the response chunk(s) MUST
   NOT send more than one packet.  If bundling is supported, multiple
   response chunks that fit into a single packet MAY be bundled together
   into one single response packet.  If bundling is not supported, then
   the sender MUST NOT send more than one response chunk and MUST
   discard all other responses.  Note that this rule does NOT apply to a
   SACK chunk, since a SACK chunk is, in itself, a response to DATA and
   a SACK does not require a response of more DATA.

   An SCTP implementation SHOULD abort the association if it receives a
   SACK acknowledging a TSN that has not been sent.

   An SCTP implementation that receives an INIT that would require a
   large packet in response, due to the inclusion of multiple ERROR
   parameters, MAY (at its discretion) elect to omit some or all of the
   ERROR parameters to reduce the size of the INIT-ACK.  Due to a
   combination of the size of the COOKIE parameter and the number of
   addresses a receiver of an INIT may be indicating to a peer, it is
   always possible that the INIT-ACK will be larger than the original
   INIT.  An SCTP implementation SHOULD attempt to make the INIT-ACK as
   small as possible to reduce the possibility of byte amplification
   attacks.

   ---------
   Old text: None
   ---------

Top      Up      ToC       Page 78 
   ---------
   New text: (Appendix C)
   ---------

   Appendix C ICMP Handling

   Whenever an ICMP message is received by an SCTP endpoint the
   following procedures MUST be followed to ensure proper utilization of
   the information being provided by layer 3.

   ICMP1) An implementation MAY ignore all ICMPv4 messages where the
          type field is not set to "Destination Unreachable".

   ICMP2) An implementation MAY ignore all ICMPv6 messages where the
          type field is not "Destination Unreachable, "Parameter
          Problem" or "Packet Too Big".

   ICMP3) An implementation MAY ignore any ICMPv4 messages where the
          code does not indicate "Protocol Unreachable" or
          "Fragmentation Needed".

   ICMP4) An implementation MAY ignore all ICMPv6 messages of type
          "Parameter Problem" if the code is not "Unrecognized next
          header type encountered".

   ICMP5) An implementation MUST use the payload of the ICMP message (V4
          or V6) to locate the association that sent the message that
          ICMP is responding to.  If the association cannot be found, an
          implementation SHOULD ignore the ICMP message.

   ICMP6) An implementation MUST validate that the Verification Tag
          contained in the ICMP message matches the verification tag of
          the peer.  If the Verification Tag is not 0 and does NOT
          match, discard the ICMP message.  If it is 0 and the ICMP
          message contains enough bytes to verify that the chunk type is
          an INIT chunk and that the initiate tag matches the tag of the
          peer, continue with ICMP7.  If the ICMP message is too short
          or the chunk type or the initiate tag does not match, silently
          discard the packet.

   ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4
          "Fragmentation Needed", an implementation MAY process this
          information as defined for PATH MTU discovery.

   ICMP8) If the ICMP code is a "Unrecognized next header type
          encountered" or a "Protocol Unreachable", an implementation
          MUST treat this message as an abort with the T bit set if it
          does not contain an INIT chunk.  If it does contain an INIT

Top      Up      ToC       Page 79 
          chunk and the association is in COOKIE-WAIT state, handle the
          ICMP message like an ABORT.

   ICMP9) If the ICMPv6 code is "Destination Unreachable", the
          implementation MAY mark the destination into the unreachable
          state or alternatively increment the path error counter.

   Note that these procedures differ from RFC 1122 [1] and from its
   requirements for processing of port-unreachable messages and the
   requirements that an implementation MUST abort associations in
   response to a "protocol unreachable" message.  Port unreachable
   messages are not processed, since an implementation will send an
   ABORT, not a port unreachable.  The stricter handling of the
   "protocol unreachable" message is due to security concerns for hosts
   that do NOT support SCTP.

2.37.3.  Solution Description

   The new appendix now describes proper handling of ICMP messages in
   conjunction with SCTP.

2.38.  Checksum

2.38.1.  Description of the problem

   RFC 3309 [6] changes the SCTP checksum due to weaknesses in the
   original Adler 32 checksum for small messages.  This document, being
   used as a guide for a cut and paste replacement to update RFC 2960,
   thus also needs to incorporate the checksum changes.  The idea is
   that one could apply all changes found in this guide to a copy of RFC
   2960 and have a "new" document that has ALL changes (including RFC
   3309).

2.38.2.  Text Changes to the Document

   ---------
   Old text:
   ---------

   6.8 Adler-32 Checksum Calculation

      When sending an SCTP packet, the endpoint MUST strengthen the data
      integrity of the transmission by including the Adler-32 checksum
      value calculated on the packet, as described below.

      After the packet is constructed (containing the SCTP common header
      and one or more control or DATA chunks), the transmitter shall:

Top      Up      ToC       Page 80 
      1) Fill in the proper Verification Tag in the SCTP common header
         and initialize the checksum field to 0's.

      2) Calculate the Adler-32 checksum of the whole packet, including
         the SCTP common header and all the chunks.  Refer to
         appendix B for details of the Adler-32 algorithm.  And,

      3) Put the resultant value into the checksum field in the common
         header, and leave the rest of the bits unchanged.

      When an SCTP packet is received, the receiver MUST first check the
      Adler-32 checksum:

      1) Store the received Adler-32 checksum value aside,

      2) Replace the 32 bits of the checksum field in the received SCTP
         packet with all '0's and calculate an Adler-32 checksum value
         of the whole received packet.  And,

      3) Verify that the calculated Adler-32 checksum is the same as the
         received Adler-32 checksum.  If not, the receiver MUST treat
         the packet as an invalid SCTP packet.

      The default procedure for handling invalid SCTP packets is to
      silently discard them.

   ---------
   New text:
   ---------

   6.8 CRC-32c Checksum Calculation

      When sending an SCTP packet, the endpoint MUST strengthen the data
      integrity of the transmission by including the CRC32c checksum
      value calculated on the packet, as described below.

      After the packet is constructed (containing the SCTP common header
      and one or more control or DATA chunks), the transmitter MUST

      1) fill in the proper Verification Tag in the SCTP common header
         and initialize the checksum field to '0's,

      2) calculate the CRC32c checksum of the whole packet, including
         the SCTP common header and all the chunks (refer to
         appendix B for details of the CRC32c algorithm); and

      3) put the resultant value into the checksum field in the common
         header, and leave the rest of the bits unchanged.

Top      Up      ToC       Page 81 
      When an SCTP packet is received, the receiver MUST first check the
      CRC32c checksum as follows:

      1) Store the received CRC32c checksum value aside.

      2) Replace the 32 bits of the checksum field in the received SCTP
         packet with all '0's and calculate a CRC32c checksum value of
         the whole received packet.

      3) Verify that the calculated CRC32c checksum is the same as the
         received CRC32c checksum.  If it is not, the receiver MUST
         treat the packet as an invalid SCTP packet.

      The default procedure for handling invalid SCTP packets is to
      silently discard them.

      Any hardware implementation SHOULD be done in a way that is
      verifiable by the software.


   ---------
   Old text:
   ---------

   Appendix B Alder 32 bit checksum calculation

      The Adler-32 checksum calculation given in this appendix is
      copied from [RFC1950].

      Adler-32 is composed of two sums accumulated per byte: s1 is the
      sum of all bytes, s2 is the sum of all s1 values.  Both sums are
      done modulo 65521.  s1 is initialized to 1, s2 to zero.  The
      Adler-32 checksum is stored as s2*65536 + s1 in network byte
      order.

      The following C code computes the Adler-32 checksum of a data
      buffer.  It is written for clarity, not for speed.  The sample
      code is in the ANSI C programming language.  Non C users may
      find it easier to read with these hints:

      &      Bitwise AND operator.
      >>     Bitwise right shift operator.  When applied to an
             unsigned quantity, as here, right shift inserts zero bit(s)
             at the left.
      <<     Bitwise left shift operator.  Left shift inserts zero
             bit(s) at the right.
      ++     "n++" increments the variable n.
      %      modulo operator: a % b is the remainder of a divided by b.

Top      Up      ToC       Page 82 
       #define BASE 65521 /* largest prime smaller than 65536 */
       /*
         Update a running Adler-32 checksum with the bytes buf[0..len-1]
         and return the updated checksum.  The Adler-32 checksum should
         be initialized to 1.

          Usage example:

            unsigned long adler = 1L;

            while (read_buffer(buffer, length) != EOF) {
              adler = update_adler32(adler, buffer, length);
             }
            if (adler != original_adler) error();
         */
         unsigned long update_adler32(unsigned long adler,
            unsigned char *buf, int len)
         {
           unsigned long s1 = adler & 0xffff;
           unsigned long s2 = (adler >> 16) & 0xffff;
           int n;

           for (n = 0; n < len; n++) {
             s1 = (s1 + buf[n]) % BASE;
             s2 = (s2 + s1)     % BASE;
           }
           return (s2 << 16) + s1;
         }

         /* Return the adler32 of the bytes buf[0..len-1] */
         unsigned long adler32(unsigned char *buf, int len)
         {
           return update_adler32(1L, buf, len);
         }

   ---------
   New text:
   ---------

   Appendix B CRC32c Checksum Calculation

      We define a 'reflected value' as one that is the opposite of the
      normal bit order of the machine.  The 32-bit CRC is calculated as
      described for CRC-32c and uses the polynomial code 0x11EDC6F41
      (Castagnoli93) or x^32+x^28+x^27+x^26+x^25
      +x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0.
      The CRC is computed using a procedure similar to ETHERNET CRC
      [ITU32], modified to reflect transport level usage.

Top      Up      ToC       Page 83 
      CRC computation uses polynomial division.  A message
      bit-string M is transformed to a polynomial, M(X), and the CRC
      is calculated from M(X) using polynomial arithmetic [PETERSON 72].

      When CRCs are used at the link layer, the polynomial is derived
      from on-the-wire bit ordering: the first bit 'on the wire' is the
      high-order coefficient.  Since SCTP is a transport-level protocol,
      it cannot know the actual serial-media bit ordering.  Moreover,
      different links in the path between SCTP endpoints may use
      different link-level bit orders.

      A convention must therefore be established for mapping SCTP
      transport messages to polynomials for purposes of CRC computation.
      The bit-ordering for mapping SCTP messages to polynomials is that
      bytes are taken most-significant first; but within each byte, bits
      are taken least-significant first.  The first byte of the message
      provides the eight highest coefficients.  Within each byte,
      the least-significant SCTP bit gives the most significant
      polynomial coefficient within that byte, and the most-significant
      SCTP bit is the least significant polynomial coefficient in that
      byte.  (This bit ordering is sometimes called 'mirrored' or
      'reflected' [WILLIAMS93].)  CRC polynomials are to be transformed
      back into SCTP transport-level byte values, using a consistent
      mapping.

      The SCTP transport-level CRC value should be calculated as
      follows:

         -  CRC input data are assigned to a byte stream, numbered from
            0 to N-1.

         -  The transport-level byte-stream is mapped to a polynomial
            value.  An N-byte PDU with j bytes numbered 0 to N-1 is
            considered as coefficients of a polynomial M(x) of order
            8N-1, with bit 0 of byte j being coefficient x^(8(N-j)-8),
            and bit 7 of byte j being coefficient x^(8(N-j)-1).

         -  The CRC remainder register is initialized with all 1s and
            the CRC is computed with an algorithm that simultaneously
            multiplies by x^32 and divides by the CRC polynomial.

         -  The polynomial is multiplied by x^32 and divided by G(x),
            the generator polynomial, producing a remainder R(x) of
            degree less than or equal to 31.

         -  The coefficients of R(x) are considered a 32-bit sequence.

Top      Up      ToC       Page 84 
         -  The bit sequence is complemented.  The result is the CRC
            polynomial.

         -  The CRC polynomial is mapped back into SCTP transport-level
            bytes.  The coefficient of x^31 gives the value of bit 7 of
            SCTP byte 0, and the coefficient of x^24 gives the value of
            bit 0 of byte 0.  The coefficient of x^7 gives bit 7 of
            byte 3, and the coefficient of x^0 gives bit 0 of byte 3.
            The resulting four-byte transport-level sequence is the
            32-bit SCTP checksum value.

      IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor
      literature on CRCs often follow an alternative formulation, in
      which the register used to hold the remainder of the
      long-division algorithm is initialized to zero rather than
      all-1s, and instead the first 32 bits of the message are
      complemented.  The long-division algorithm used in our
      formulation is specified such that the initial
      multiplication by 2^32 and the long-division are combined into
      one simultaneous operation.  For such algorithms, and for
      messages longer than 64 bits, the two specifications are
      precisely equivalent.  That equivalence is the intent of
      this document.

      Implementors of SCTP are warned that both specifications are to be
      found in the literature, sometimes with no restriction on the
      long-division algorithm.  The choice of formulation in this
      document is to permit non-SCTP usage, where the same CRC
      algorithm may be used to protect messages shorter than 64 bits.

      There may be a computational advantage in validating the
      Association against the Verification Tag, prior to performing a
      checksum, as invalid tags will result in the same action as a bad
      checksum in most cases.  The exceptions for this technique would
      be INIT and some SHUTDOWN-COMPLETE exchanges, as well as a stale
      COOKIE-ECHO.  These special case exchanges must represent small
      packets and will minimize the effect of the checksum calculation.


   ---------
   Old text: (Section 18)
   ---------

   18.  Bibliography

   [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
              Network Path Properties", Proc. SIGCOMM'99, 1999.

Top      Up      ToC       Page 85 
   [FALL96]   Fall, K. and Floyd, S., Simulation-based Comparisons of
              Tahoe, Reno, and SACK TCP, Computer Communications Review,
              V. 26 N. 3, July 1996, pp.  5-21.

   [RFC1750]  Eastlake, D. (ed.), "Randomness Recommendations for
              Security", RFC 1750, December 1994.

   [RFC1950]  Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
              Specification version 3.3", RFC 1950, May 1996.

   [RFC2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
              Hashing for Message Authentication", RFC 2104, March 1997.

   [RFC2196]  Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
              September 1997.

   [RFC2522]  Karn, P. and W. Simpson, "Photuris: Session-Key Management
              Protocol", RFC 2522, March 1999.

   [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
              "TCP Congestion Control with a Misbehaving Receiver",  ACM
              Computer Communication Review, 29(5), October 1999.

   ---------
   New text: (Section 18, including changes from 2.11)
   ---------

   18.  Bibliography

   [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
              Network Path Properties", Proc. SIGCOMM'99, 1999.

   [FALL96]   Fall, K. and Floyd, S., Simulation-based Comparisons of
              Tahoe, Reno, and SACK TCP, Computer Communications Review,
              V. 26 N. 3, July 1996, pp.  5-21.

   [ITU32]         ITU-T Recommendation V.42, "Error-correcting
                   procedures for DCEs using asynchronous-to-synchronous
                   conversion", Section 8.1.1.6.2, October 1996.

   [PETERSON 1972] W. W. Peterson and E.J Weldon, Error Correcting
                   Codes, 2nd Edition, MIT Press, Cambridge,
                   Massachusetts.

   [RFC1750]  Eastlake, D., Ed., "Randomness Recommendations for
              Security", RFC 1750, December 1994.

Top      Up      ToC       Page 86 
   [RFC1858]  Ziemba, G., Reed, D. and Traina P., "Security
              Considerations for IP Fragment Filtering", RFC 1858,
              October 1995.

   [RFC1950]  Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
              Specification version 3.3", RFC 1950, May 1996.

   [RFC2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
              Hashing for Message Authentication", RFC 2104, March 1997.

   [RFC2196]  Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
              September 1997.

   [RFC2522]  Karn, P. and W. Simpson, "Photuris: Session-Key Management
              Protocol", RFC 2522, March 1999.

   [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
              "TCP Congestion Control with a Misbehaving Receiver", ACM
              Computer Communication Review, 29(5), October 1999.

   [WILLIAMS93]    Williams, R., "A PAINLESS GUIDE TO CRC ERROR
                   DETECTION ALGORITHMS" - Internet publication, August
                   1993,
                   http://www.geocities.com/SiliconValley/Pines/
                   8659/crc.htm.

2.38.3.  Solution Description

   This change adds to the implementor's guide the complete set of
   changes that, when combined with RFC 2960 [5], encompasses the
   changes from RFC 3309 [6].

2.39.  Retransmission Policy

2.39.1.  Description of the Problem

   The current retransmission policy (send all retransmissions an
   alternate destination) in the specification has performance issues
   under certain loss conditions with multihomed endpoints.  Instead,
   fast retransmissions should be sent to the same destination, and only
   timeout retransmissions should be sent to an alternate destination
   [4].

Top      Up      ToC       Page 87 
2.39.2.  Text Changes to the Document

   ---------
   Old text: (Section 6.4)
   ---------

   Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
   retransmit a chunk to an active destination transport address that is
   different from the last destination address to which the DATA chunk
   was sent.

   ---------
   New text: (Section 6.4)
   ---------

   Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
   retransmit a chunk that timed out to an active destination transport
   address that is different from the last destination address to which
   the DATA chunk was sent.

   ---------
   Old text: (Section 6.4.1)
   ---------

   When retransmitting data, if the endpoint is multi-homed, it should
   consider each source-destination address pair in its retransmission
   selection policy.  When retransmitting the endpoint should attempt to
   pick the most divergent source-destination pair from the original
   source-destination pair to which the packet was transmitted.

   ---------
   New text: (Section 6.4.1)
   ---------

   When retransmitting data that timed out, if the endpoint is
   multi-homed, it should consider each source-destination address
   pair in its retransmission selection policy.  When retransmitting
   timed out data, the endpoint should attempt to pick the most
   divergent source-destination pair from the original
   source-destination pair to which the packet was transmitted.

2.39.3.  Solution Description

   The above wording changes clarify that only timeout retransmissions
   should be sent to an alternate active destination.


Next RFC Part