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 4 of 4, p. 88 to 109
Prev RFC Part

 


prevText      Top      Up      ToC       Page 88 
2.40.  Port Number 0

2.40.1.  Description of the Problem

   The port number 0 has a special semantic in various APIs.  For
   example, in the socket API, if the user specifies 0, the SCTP
   implementation chooses an appropriate port number for the user.
   Therefore, the port number 0 should not be used on the wire.

2.40.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.1)
   ---------

      Source Port Number: 16 bits (unsigned integer)

         This is the SCTP sender's port number.  It can be used by the
         receiver in combination with the source IP address, the SCTP
         destination port, and possibly the destination IP address to
         identify the association to which this packet belongs.

      Destination Port Number: 16 bits (unsigned integer)

         This is the SCTP port number to which this packet is destined.
         The receiving host will use this port number to de-multiplex
         the SCTP packet to the correct receiving endpoint/application.

   ---------
   New text: (Section 3.1)
   ---------

      Source Port Number: 16 bits (unsigned integer)

         This is the SCTP sender's port number.  It can be used by the
         receiver in combination with the source IP address, the SCTP
         destination port and possibly the destination IP address to
         identify the association to which this packet belongs.
         The port number 0 MUST NOT be used.

      Destination Port Number: 16 bits (unsigned integer)

         This is the SCTP port number to which this packet is destined.
         The receiving host will use this port number to de-multiplex
         the SCTP packet to the correct receiving endpoint/application.
         The port number 0 MUST NOT be used.

Top      Up      ToC       Page 89 
2.40.3.  Solution Description

   It is clearly stated that the port number 0 is an invalid value on
   the wire.

2.41.  T Bit

2.41.1.  Description of the Problem

   The description of the T bit as the bit describing whether a TCB has
   been destroyed is misleading.  In addition, the procedure described
   in Section 2.13 is not as precise as needed.

2.41.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.3.7)
   ---------

      T bit:  1 bit
         The T bit is set to 0 if the sender had a TCB that it
         destroyed.  If the sender did not have a TCB it should set
         this bit to 1.

   ---------
   New text: (Section 3.3.7)
   ---------

      T bit:  1 bit
         The T bit is set to 0 if the sender filled in the
         Verification Tag expected by the peer.  If the Verification
         Tag is reflected, the T bit MUST be set to 1.  Reflecting means
         that the sent Verification Tag is the same as the received
         one.


   ---------
   Old text: (Section 3.3.13)
   ---------

      T bit:  1 bit
         The T bit is set to 0 if the sender had a TCB that it
         destroyed.  If the sender did not have a TCB it should set
         this bit to 1.

Top      Up      ToC       Page 90 
   ---------
   New text: (Section 3.3.13)
   ---------

      T bit:  1 bit
         The T bit is set to 0 if the sender filled in the
         Verification Tag expected by the peer.  If the Verification
         Tag is reflected, the T bit MUST be set to 1.  Reflecting means
         that the sent Verification Tag is the same as the received
         one.


   ---------
   Old text: (Section 8.4)
   ---------

       3) If the packet contains an INIT chunk with a Verification Tag
          set to '0', process it as described in Section 5.1.
          Otherwise,

   ---------
   New text: (Section 8.4)
   ---------
       3) If the packet contains an INIT chunk with a Verification Tag
         set to '0', process it as described in Section 5.1.  If, for
         whatever reason, the INIT cannot be processed normally and
         an ABORT has to be sent in response, the Verification Tag of
         the packet containing the ABORT chunk MUST be the Initiate
         tag of the received INIT chunk, and the T-Bit of the ABORT
         chunk has to be set to 0, indicating that the Verification
         Tag is NOT reflected.


   ---------
   Old text: (Section 8.4)
   ---------
      5) If the packet contains a SHUTDOWN ACK chunk, the receiver
         should respond to the sender of the OOTB packet with a
         SHUTDOWN COMPLETE.  When sending the SHUTDOWN COMPLETE, the
         receiver of the OOTB packet must fill in the Verification
         Tag field of the outbound packet with the Verification Tag
         received in the SHUTDOWN ACK and set the T-bit in the Chunk
         Flags to indicate that no TCB was found.  Otherwise,

Top      Up      ToC       Page 91 
   ---------
   New text: (Section 8.4)
   ---------

      5) If the packet contains a SHUTDOWN ACK chunk, the receiver
         should respond to the sender of the OOTB packet with a
         SHUTDOWN COMPLETE.  When sending the SHUTDOWN COMPLETE, the
         receiver of the OOTB packet must fill in the Verification
         Tag field of the outbound packet with the Verification Tag
         received in the SHUTDOWN ACK and set the T-bit in the
         Chunk Flags to indicate that the Verification Tag is
         reflected.  Otherwise,


   ---------
   Old text: (Section 8.4)
   ---------

      8) The receiver should respond to the sender of the OOTB packet
         with an ABORT.  When sending the ABORT, the receiver of the
         OOTB packet MUST fill in the Verification Tag field of the
         outbound packet with the value found in the Verification
         Tag field of the OOTB packet and set the T-bit in the Chunk
         Flags to indicate that no TCB was found.  After sending this
         ABORT, the receiver of the OOTB packet shall discard the
         OOTB packet and take no further action.

   ---------
   New text: (Section 8.4)
   ---------

      8) The receiver should respond to the sender of the OOTB packet
         with an ABORT.  When sending the ABORT, the receiver of the
         OOTB packet MUST fill in the Verification Tag field of the
         outbound packet with the value found in the Verification Tag
         field of the OOTB packet and set the T-bit in the Chunk Flags
         to indicate that the Verification Tag is reflected.  After
         sending this ABORT, the receiver of the OOTB packet shall
         discard the OOTB packet and take no further action.


   ---------
   Old text: (Section 8.5.1)
   ---------

      B) Rules for packet carrying ABORT:

Top      Up      ToC       Page 92 
         -  The endpoint shall always fill in the Verification Tag
            field of the outbound packet with the destination
            endpoint's tag value if it is known.

         -  If the ABORT is sent in response to an OOTB packet, the
            endpoint MUST follow the procedure described in
            Section 8.4.

         -  The receiver MUST accept the packet if the Verification
            Tag matches either its own tag, OR the tag of its peer.
            Otherwise, the receiver MUST silently discard the packet
            and take no further action.

   ---------
   New text: (Section 8.5.1)
   ---------

     B) Rules for packet carrying ABORT:

         -  The endpoint MUST always fill in the Verification Tag
            field of the outbound packet with the destination
            endpoint's tag value, if it is known.

         -  If the ABORT is sent in response to an OOTB packet, the
            endpoint MUST follow the procedure described in
            Section 8.4.

         -  The receiver of an ABORT MUST accept the packet
            if the Verification Tag field of the packet matches its
            own tag and the T bit is not set
            OR
            if it is set to its peer's tag and the T bit is set in
            the Chunk Flags.
            Otherwise, the receiver MUST silently discard the packet
            and take no further action.


   ---------
   Old text: (Section 8.5.1)
   ---------

      C) Rules for packet carrying SHUTDOWN COMPLETE:

         -  When sending a SHUTDOWN COMPLETE, if the receiver of the
            SHUTDOWN ACK has a TCB then the destination endpoint's
            tag MUST be used.  Only where no TCB exists should the
            sender use the Verification Tag from the SHUTDOWN ACK.

Top      Up      ToC       Page 93 
         -  The receiver of a SHUTDOWN COMPLETE shall accept the
            packet if the Verification Tag field of the packet matches
            its own tag OR it is set to its peer's tag and the T bit
            is set in the Chunk Flags.  Otherwise, the receiver MUST
            silently discard the packet and take no further action.
            An endpoint MUST ignore the SHUTDOWN COMPLETE if it is
            not in the SHUTDOWN-ACK-SENT state.

   ---------
   New text: (Section 8.5.1)
   ---------

      C) Rules for packet carrying SHUTDOWN COMPLETE:

         -  When sending a SHUTDOWN COMPLETE, if the receiver of the
            SHUTDOWN ACK has a TCB, then the destination endpoint's tag
            MUST be used, and the T-bit MUST NOT be set.  Only where no
            TCB exists should the sender use the Verification Tag from
            the SHUTDOWN ACK, and MUST set the T-bit.

         -  The receiver of a SHUTDOWN COMPLETE shall accept the packet
            if the Verification Tag field of the packet matches its own
            tag and the T bit is not set
            OR
            if it is set to its peer's tag and the T bit is set in the
            Chunk Flags.
            Otherwise, the receiver MUST silently discard the packet
            and take no further action.  An endpoint MUST ignore the
            SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT
            state.

2.41.3.  Solution Description

   The description of the T bit now clearly describes the semantic of
   the bit.  The procedures for receiving the T bit have been clarified.

2.42.  Unknown Parameter Handling

2.42.1.  Description of the Problem

   The description given in Section 2.33 does not state clearly whether
   an INIT-ACK or COOKIE-ECHO is sent.

2.42.2.  Text Changes to the Document

   The changes given here already include changes suggested in Section
   2.2, 2.27, and 2.33 of this document.

Top      Up      ToC       Page 94 
   ---------
   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', 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', as
        described in 3.2.2.

   Please note that in all four cases an INIT-ACK or COOKIE-ECHO
   chunk is sent.  In the 00 or 01 case the processing of the
   parameters after the unknown parameter is canceled, but no
   processing already done is rolled back.

Top      Up      ToC       Page 95 
   ---------
   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 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
      Parameters' 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.42.3.  Solution Description

   The new text clearly states that an INIT-ACK or COOKIE-ECHO has to be
   sent.

2.43.  Cookie Echo Chunk

2.43.1.  Description of the Problem

   The description given in Section 3.3.11 of RFC 2960 [5] is unclear as
   to how the COOKIE-ECHO is composed.

2.43.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.3.11)
   ---------
      Cookie: variable size

         This field must contain the exact cookie received in the State
         Cookie parameter from the previous INIT ACK.

Top      Up      ToC       Page 96 
         An implementation SHOULD make the cookie as small as possible
         to insure interoperability.

   ---------
   New text: (Section 3.3.11)
   ---------
      Cookie: variable size

         This field must contain the exact cookie received in the State
         Cookie parameter from the previous INIT ACK.

         An implementation SHOULD make the cookie as small as possible
         to ensure interoperability.

         Note: A Cookie Echo does NOT contain a State Cookie
         Parameter; instead, the data within the State Cookie's
         Parameter Value becomes the data within the Cookie Echo's
         Chunk Value.  This allows an implementation to change only
         the first two bytes of the State Cookie parameter to become
         a Cookie Echo Chunk.

2.43.3.  Solution Description

   The new text adds a note that helps clarify that a Cookie Echo chunk
   is nothing more than the State Cookie parameter with only two bytes
   modified.

2.44.  Partial Chunks

2.44.1.  Description of the Problem

   Section 6.10 of RFC 2960 [5] uses the notion of 'partial chunks'
   without defining it.

2.44.2.  Text Changes to the Document

   ---------
   Old text: (Section 6.10)
   ---------
   Partial chunks MUST NOT be placed in an SCTP packet.

   ---------
   New text: (Section 6.10)
   ---------
   Partial chunks MUST NOT be placed in an SCTP packet.  A partial
   chunk is a chunk that is not completely contained in the SCTP
   packet; i.e., the SCTP packet is too short to contain all the bytes
   of the chunk as indicated by the chunk length.

Top      Up      ToC       Page 97 
2.44.3.  Solution Description

   The new text adds a definition of 'partial chunks'.

2.45.  Non-unicast Addresses

2.45.1.  Description of the Problem

   Section 8.4 of RFC 2960 [5] forces the OOTB handling to discard all
   non-unicast addresses.  This leaves future use of anycast addresses
   in question.  With the addition of the add-ip feature, SCTP should be
   able to easily handle anycast INIT s that can be followed, after
   association setup, with a delete of the anycast address from the
   association.

2.45.2.  Text Changes to the Document

   ---------
   Old text: (Section 8.4)
   ---------
   8.4 Handle "Out of the blue" Packets

      An SCTP packet is called an "out of the blue" (OOTB) packet if
      it is correctly formed, i.e., passed the receiver's Adler-32
      check (see Section 6.8), but the receiver is not able to
      identify the association to which this packet belongs.

      The receiver of an OOTB packet MUST do the following:

      1) If the OOTB packet is to or from a non-unicast address,
         silently discard the packet.  Otherwise,


   ---------
   New text: (Section 8.4)
   ---------

   8.4.  Handle "Out of the Blue" Packets

      An SCTP packet is called an "out of the blue" (OOTB) packet if
      it is correctly formed (i.e., passed the receiver's CRC32c
      check; see Section 6.8), but the receiver is not able to identify
      the association to which this packet belongs.

      The receiver of an OOTB packet MUST do the following:

      1) If the OOTB packet is to or from a non-unicast address, a
         receiver SHOULD silently discard the packet.  Otherwise,

Top      Up      ToC       Page 98 
2.45.3.  Solution Description

   The loosening of the wording to a SHOULD will now allow future use of
   anycast addresses.  Note that no changes are made to Section
   11.2.4.1, since responding to broadcast addresses could lead to
   flooding attacks and implementors should pay careful attention to
   these words.

2.46.  Processing of ABORT Chunks

2.46.1.  Description of the Problem

   Section 3.3.7 of RFC 2960 [5] requires an SCTP endpoint to silently
   discard ABORT chunks received for associations that do not exist.  It
   is not clear what this means in the COOKIE-WAIT state, for example.
   Therefore, it was not clear whether an ABORT sent in response to an
   INIT should be processed or silently discarded.

2.46.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.3.7)
   ---------

      If an endpoint receives an ABORT with a format error or for an
      association that doesn't exist, it MUST silently discard it.

   ---------
   New text: (Section 3.3.7)
   ---------

      If an endpoint receives an ABORT with a format error or no
      TCB is found, it MUST silently discard it.

2.46.3.  Solution Description

   It is now clearly stated that an ABORT chunk should be processed
   whenever a TCB is found.

Top      Up      ToC       Page 99 
2.47.  Sending of ABORT Chunks

2.47.1.  Description of the Problem

   Section 5.1 of RFC 2960 [5] requires that an ABORT chunk be sent in
   response to an INIT chunk when there is no listening end point.  To
   make port scanning harder, someone might not want these ABORTs to be
   received by the sender of the INIT chunks.  Currently, the only way
   to enforce this is by using a firewall that discards the packets
   containing the INIT chunks or the packets containing the ABORT
   chunks.  It is desirable that the same can be done without a middle
   box.

2.47.2.  Text Changes to the Document

   ---------
   Old text: (Section 5.1)
   ---------

      If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk
      but decides not to establish the new association due to missing
      mandatory parameters in the received INIT or INIT ACK, invalid
      parameter values, or lack of local resources, it MUST respond with
      an ABORT chunk.

   ---------
   New text: (Section 5.1)
   ---------

      If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk
      but decides not to establish the new association due to missing
      mandatory parameters in the received INIT or INIT ACK, invalid
      parameter values, or lack of local resources, it SHOULD respond
      with an ABORT chunk.

2.47.3.  Solution Description

   The requirement of sending ABORT chunks is relaxed such that an
   implementation can decide not to send ABORT chunks.

2.48.  Handling of Supported Address Types Parameter

2.48.1.  Description of the Problem

   The sender of the INIT chunk can include a 'Supported Address Types'
   parameter to indicate which address families are supported.  It is
   unclear how an INIT chunk should be processed where the source
   address of the packet containing the INIT chunk or listed addresses

Top      Up      ToC       Page 100 
   within the INIT chunk indicate that more address types are supported
   than those listed in the 'Supported Address Types' parameter.

2.48.2.  Text Changes to the Document

   The changes given here already include changes suggested in Section
   2.28 of this 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.

      IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported
      Address Types' parameter either IPv4 or IPv6, but uses the other
      family for sending the packet containing the INIT chunk, or if it
      also lists addresses of the other family in the INIT chunk, then
      the address family that is not listed in the 'Supported Address
      Types' parameter SHOULD also be considered as supported by the
      receiver of the INIT chunk.  The receiver of the INIT chunk SHOULD
      NOT respond with any kind of error indication.

2.48.3.  Solution Description

   It is now clearly described how these Supported Address Types
   parameters with incorrect data should be handled.

Top      Up      ToC       Page 101 
2.49.  Handling of Unexpected Parameters

2.49.1.  Description of the Problem

   RFC 2960 [5] clearly describes how unknown parameters in the INIT and
   INIT-ACK chunk should be processed.  But it is not described how
   unexpected parameters should be processed.  A parameter is unexpected
   if it is known and is an optional parameter in either the INIT or
   INIT-ACK chunk but is received in the chunk for which it is not an
   optional parameter.  For example, the 'Supported Address Types'
   parameter would be an unexpected parameter if contained in an INIT-
   ACK chunk.

2.49.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.3.2)
   ---------

      Note 4: This parameter, when present, specifies all the address
      types the sending endpoint can support.  The absence of this
      parameter indicates that the sending endpoint can support any
      address type.

   ---------
   New text: (Section 3.3.2)
   ---------

      Note 4: This parameter, when present, specifies all the address
      types the sending endpoint can support.  The absence of this
      parameter indicates that the sending endpoint can support any
      address type.

      IMPLEMENTATION NOTE: If an INIT chunk is received with known
      parameters that are not optional parameters of the INIT chunk
      then the receiver SHOULD process the INIT chunk and send back
      an INIT-ACK.  The receiver of the INIT chunk MAY bundle an ERROR
      chunk with the COOKIE-ACK chunk later.  However, restrictive
      implementations MAY send back an ABORT chunk in response to
      the INIT chunk.

Top      Up      ToC       Page 102 
   ---------
   Old text: (Section 3.3.3)
   ---------

      IMPLEMENTATION NOTE: An implementation MUST be prepared to receive
      a INIT ACK that is quite large (more than 1500 bytes) due to the
      variable size of the state cookie AND the variable address list.
      For example if a responder to the INIT has 1000 IPv4 addresses
      it wishes to send, it would need at least 8,000 bytes to encode
      this in the INIT ACK.

   ---------
   New text: (Section 3.3.3)
   ---------

      IMPLEMENTATION NOTE: An implementation MUST be prepared to receive
      a INIT ACK that is quite large (more than 1500 bytes) due to the
      variable size of the state cookie AND the variable address list.
      For example, if a responder to the INIT has 1000 IPv4 addresses
      it wishes to send, it would need at least 8,000 bytes to encode
      this in the INIT ACK.

      IMPLEMENTATION NOTE: If an INIT-ACK chunk is received with known
      parameters that are not optional parameters of the INIT-ACK
      chunk, then the receiver SHOULD process the INIT-ACK chunk and
      send back a COOKIE-ECHO.  The receiver of the INIT-ACK chunk
      MAY bundle an ERROR chunk with the COOKIE-ECHO chunk.  However,
      restrictive implementations MAY send back an ABORT chunk in
      response to the INIT-ACK chunk.

2.49.3.  Solution Description

   It is now stated how unexpected parameters should be processed.

2.50.  Payload Protocol Identifier

2.50.1.  Description of the Problem

   The current description of the payload protocol identifier does NOT
   highlight the fact that the field is NOT necessarily in network byte
   order.

Top      Up      ToC       Page 103 
2.50.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.3.1)
   ---------
      Payload Protocol Identifier: 32 bits (unsigned integer)

         This value represents an application (or upper layer) specified
         protocol identifier.  This value is passed to SCTP by its upper
         layer and sent to its peer.  This identifier is not used by
         SCTP but can be used by certain network entities as well as
         the peer application to identify the type of information being
         carried in this DATA chunk.  This field must be sent even in
         fragmented DATA chunks (to make sure it is available for agents
         in the middle of the network).

         The value 0 indicates no application identifier is specified by
         the upper layer for this payload data.

   ---------
   New text: (Section 3.3.1)
   ---------
      Payload Protocol Identifier: 32 bits (unsigned integer)

         This value represents an application (or upper layer) specified
         protocol identifier.  This value is passed to SCTP by its upper
         layer and sent to its peer.  This identifier is not used by
         SCTP but can be used by certain network entities, as well as by
         the peer application, to identify the type of information being
         carried in this DATA chunk.  This field must be sent even in
         fragmented DATA chunks (to make sure it is available for agents
         in the middle of the network).  Note that this field is NOT
         touched by an SCTP implementation, therefore its byte order is
         NOT necessarily Big Endian.  The upper layer is responsible
         for any byte order conversions to this field.

         The value 0 indicates that no application identifier is
         specified by the upper layer for this payload data.

2.50.3.  Solution Description

   It is now explicitly stated that the upper layer is responsible for
   the byte order of this field.

Top      Up      ToC       Page 104 
2.51.  Karn's Algorithm

2.51.1.  Description of the Problem

   The current wording of the use of Karn's algorithm is not descriptive
   enough to ensure that an implementation in a multi-homed association
   does not incorrectly mismeasure the RTT.

2.51.2.  Text Changes to the Document

   ---------
   Old text: (Section 6.3.1)
   ---------

      C5) Karn's algorithm: RTT measurements MUST NOT be made using
          packets that were retransmitted (and thus for which it is
          ambiguous whether the reply was for the first instance of the
          packet or a later instance)
   ---------
   New text: (Section 6.3.1)
   ---------

      C5) Karn's algorithm: RTT measurements MUST NOT be made using
          chunks that were retransmitted (and thus for which it is
          ambiguous whether the reply was for the first instance of
          the chunk or for a later instance)

          IMPLEMENTATION NOTE: RTT measurements should only be
          made using a chunk with TSN r if no chunk
          with TSN less than or equal to r is retransmitted
          since r is first sent.

2.51.3.  Solution Description

   The above clarification adds an implementation note that will provide
   additional guidance in the application of Karn's algorithm.

2.52.  Fast Retransmit Algorithm

2.52.1.  Description of the Problem

   The original SCTP specification is overly conservative in requiring 4
   missing reports before fast retransmitting a segment.  TCP uses 3
   missing reports or 4 acknowledgements indicating that the same
   segment was received.

Top      Up      ToC       Page 105 
2.52.2.  Text Changes to the Document

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

   7.2.4 Fast Retransmit on Gap Reports

      In the absence of data loss, an endpoint performs delayed
      acknowledgement.  However, whenever an endpoint notices a hole in
      the arriving TSN sequence, it SHOULD start sending a SACK back
      every time a packet arrives carrying data until the
      hole is filled.

      Whenever an endpoint receives a SACK that indicates some TSN(s)
      missing, it SHOULD wait for 3 further miss indications (via
      subsequent SACK's) on the same TSN(s) before taking action with
      regard to Fast Retransmit.


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

   7.2.4.  Fast Retransmit on Gap Reports

      In the absence of data loss, an endpoint performs delayed
      acknowledgement.  However, whenever an endpoint notices a hole in
      the arriving TSN sequence, it SHOULD start sending a SACK back
      every time a packet arrives carrying data until the
      hole is filled.

      Whenever an endpoint receives a SACK that indicates that some
      TSNs are missing, it SHOULD wait for 2 further miss indications
      (via subsequent SACKs for a total of 3 missing reports) on the
      same TSNs before taking action with regard to Fast Retransmit.

2.52.3.  Solution Description

   The above changes will make SCTP and TCP behave similarly in terms of
   how fast they engage the Fast Retransmission algorithm upon receiving
   missing reports.

3.  Security Considerations

   This document should add no additional security risks to SCTP and in
   fact SHOULD correct some original security flaws within the original
   document once it is incorporated into a RFC 2960 [5] BIS document.

Top      Up      ToC       Page 106 
4.  Acknowledgements

   The authors would like to thank the following people who have
   provided comments and input for this document:

   Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng,
   Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina
   Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte,
   Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC
   Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel,
   Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan,
   Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann,
   Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth
   Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John
   Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent
   Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig,
   Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob
   Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger,
   Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar.

   A special thanks to Mark Allman, who should actually be a co-author
   for his work on the max-burst, but managed to wiggle out due to a
   technicality.  Also, we would like to acknowledge Lyndon Ong and Phil
   Conrad for their valuable input and many contributions.

5.  IANA Considerations

   This document recommends changes for the RFC 2960 [5] BIS document.
   As such, even though it lists new error cause code, this document in
   itself does NOT define those new codes.  Instead, the BIS document
   will make the needed changes to RFC 2960 [5] and thus its IANA
   section will require changes to be made.

6.  Normative References

   [1]  Braden, R., "Requirements for Internet Hosts - Communication
        Layers", STD 3, RFC 1122, October 1989.

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

   [3]  Caro, A., Shah, K., Iyengar, J., Amer, P., and R. Stewart, "SCTP
        and TCP Variants: Congestion Control Under Multiple Losses",
        Technical Report TR2003-04, Computer and Information Sciences
        Department, University of Delaware, February 2003,
        <http://www.armandocaro.net/papers>.

Top      Up      ToC       Page 107 
   [4]  Caro, A., Amer, P., and R. Stewart, "Retransmission Schemes for
        End-to-end Failover with Transport Layer Multihoming", GLOBECOM,
        November 2004., <http://www.armandocaro.net/papers>.

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

   [6]  Stone, J., Stewart, R., and D. Otis, "Stream Control
        Transmission Protocol (SCTP) Checksum Change", RFC 3309,
        September 2002.

Top      Up      ToC       Page 108 
Authors' Addresses

   Randall R. Stewart
   Cisco Systems, Inc.
   4875 Forest Drive
   Suite 200
   Columbia, SC  29206
   USA

   EMail: rrs@cisco.com


   Ivan Arias-Rodriguez
   Nokia Research Center
   PO Box 407
   FIN-00045 Nokia Group
   Finland

   EMail: ivan.arias-rodriguez@nokia.com


   Kacheong Poon
   Sun Microsystems, Inc.
   3571 N. First St.
   San Jose, CA  95134
   USA

   EMail: kacheong.poon@sun.com


   Armando L. Caro Jr.
   BBN Technologies
   10 Moulton St.
   Cambridge, MA 02138

   EMail: acaro@bbn.com
   URI:   http://www.armandocaro.net


   Michael Tuexen
   Muenster Univ. of Applied Sciences
   Stegerwaldstr. 39
   48565 Steinfurt
   Germany

   EMail: tuexen@fh-muenster.de

Top      Up      ToC       Page 109 
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).