tech-invite   World Map     

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

RFC 4460

 
 
 

Stream Control Transmission Protocol (SCTP) Specification Errata and Issues

Part 2 of 4, p. 25 to 57
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 25 
2.10.  Issues with Heartbeating and Failure Detection

2.10.1.  Description of the Problem

   Five basic problems have been discovered with the current heartbeat
   procedures:

   o  The current specification does not specify that you should count a
      failed heartbeat as an error against the overall association.

   o  The current specification is not specific as to when you start
      sending heartbeats and when you should stop.

   o  The current specification is not specific as to when you should
      respond to heartbeats.

Top      Up      ToC       Page 26 
   o  When responding to a Heartbeat, it is unclear what to do if more
      than a single TLV is present.

   o  The jitter applied to a heartbeat was meant to be a small variance
      of the RTO and is currently a wide variance, due to the default
      delay time and incorrect wording within the RFC.

2.10.2.  Text Changes to the Document

   ---------
   Old text: (Section 8.1)
   ---------

   8.1 Endpoint Failure Detection

   An endpoint shall keep a counter on the total number of consecutive
   retransmissions to its peer (including retransmissions to all the
   destination transport addresses of the peer if it is multi-homed).
   If the value of this counter exceeds the limit indicated in the
   protocol parameter 'Association.Max.Retrans', the endpoint shall
   consider the peer endpoint unreachable and shall stop transmitting
   any more data to it (and thus the association enters the CLOSED
   state).  In addition, the endpoint shall report the failure to the
   upper layer, and optionally report back all outstanding user data
   remaining in its outbound queue.  The association is automatically
   closed when the peer endpoint becomes unreachable.

   The counter shall be reset each time a DATA chunk sent to that peer
   endpoint is acknowledged (by the reception of a SACK), or a
   HEARTBEAT-ACK is received from the peer endpoint.

Top      Up      ToC       Page 27 
   ---------
   New text: (Section 8.1)
   ---------

   8.1.  Endpoint Failure Detection

   An endpoint shall keep a counter on the total number of consecutive
   retransmissions to its peer (this includes retransmissions to all the
   destination transport addresses of the peer if it is multi-homed),
   including unacknowledged HEARTBEAT Chunks.  If the value of this
   counter exceeds the limit indicated in the protocol parameter
   'Association.Max.Retrans', the endpoint shall consider the peer
   endpoint unreachable and shall stop transmitting any more data to it
   (and thus the association enters the CLOSED state).  In addition, the
   endpoint MAY report the failure to the upper layer and optionally
   report back all outstanding user data remaining in its outbound
   queue.  The association is automatically closed when the peer
   endpoint becomes unreachable.

   The counter shall be reset each time a DATA chunk sent to that peer
   endpoint is acknowledged (by the reception of a SACK), or a
   HEARTBEAT-ACK is received from the peer endpoint.


   ---------
   Old text: (Section 8.3)
   ---------

   8.3 Path Heartbeat

   By default, an SCTP endpoint shall monitor the reachability of the
   idle destination transport address(es) of its peer by sending a
   HEARTBEAT chunk periodically to the destination transport
   address(es).

   ---------
   New text: (Section 8.3)
   ---------

   8.3 Path Heartbeat

   By default, an SCTP endpoint SHOULD monitor the reachability of the
   idle destination transport address(es) of its peer by sending a
   HEARTBEAT chunk periodically to the destination transport
   address(es).  HEARTBEAT sending MAY begin upon reaching the
   ESTABLISHED state and is discontinued after sending either SHUTDOWN
   or SHUTDOWN-ACK.  A receiver of a HEARTBEAT MUST respond to a
   HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state

Top      Up      ToC       Page 28 
   (INIT sender) or the ESTABLISHED state (INIT receiver), up until
   reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-
   ACK-SENT state (SHUTDOWN receiver).


   ---------
   Old text: (Section 8.3)
   ---------

   The receiver of the HEARTBEAT should immediately respond with a
   HEARTBEAT ACK that contains the Heartbeat Information field copied
   from the received HEARTBEAT chunk.

   ---------
   New text: (Section 8.3)
   ---------

   The receiver of the HEARTBEAT should immediately respond with a
   HEARTBEAT ACK that contains the Heartbeat Information TLV, together
   with any other received TLVs, copied unchanged from the received
   HEARTBEAT chunk.


   ---------
   Old text: (Section 8.3)
   ---------

   On an idle destination address that is allowed to heartbeat, a
   HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that
   destination address plus the protocol parameter 'HB.interval' , with
   jittering of +/- 50%, and exponential back-off of the RTO if the
   previous HEARTBEAT is unanswered.

   ---------
   New text: (Section 8.3)
   ---------

   On an idle destination address that is allowed to heartbeat, it is
   recommended that a HEARTBEAT chunk is sent once per RTO of that
   destination address plus the protocol parameter 'HB.interval', with
   jittering of +/- 50% of the RTO value, and exponential back-off of
   the RTO if the previous HEARTBEAT is unanswered.

2.10.3.  Solution Description

   The above text provides guidance as to how to respond to the five
   issues mentioned in Section 2.10.1.  In particular, the wording
   changes provide guidance as to when to start and stop heartbeating,

Top      Up      ToC       Page 29 
   how to respond to a heartbeat with extra parameters, and it clarifies
   the error counting procedures for the association.

2.11.  Security interactions with firewalls

2.11.1.  Description of the Problem

   When dealing with firewalls, it is advantageous for the firewall to
   be able to properly determine the initial startup sequence of a
   reliable transport protocol.  With this in mind, the following text
   is to be added to SCTP's security section.

2.11.2.  Text Changes to the Document

   ---------
   New text: (no old text, new section added)
   ---------

   11.4 SCTP Interactions with Firewalls

   It is helpful for some firewalls if they can inspect
   just the first fragment of a fragmented SCTP packet and unambiguously
   determine whether it corresponds to an INIT chunk (for further
   information, please refer to RFC1858).  Accordingly, we
   stress the requirements, stated in 3.1, that (1) an INIT chunk MUST
   NOT be bundled with any other chunk in a packet, and (2) a packet
   containing an INIT chunk MUST have a zero Verification Tag.
   Furthermore, we require that the receiver of an INIT chunk MUST
   enforce these rules by silently discarding an arriving packet with an
   INIT chunk that is bundled with other chunks.

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

   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.

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

Top      Up      ToC       Page 30 
   [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)
   ---------

   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.

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

   [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.

Top      Up      ToC       Page 31 
   [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.

2.11.3.  Solution Description

   The above text, which adds a new subsection to the Security
   Considerations section of RFC 2960 [5] makes clear that, to make
   easier the interaction with firewalls, an INIT chunk must not be
   bundled in any case with any other chunk that will silently discard
   the packets that do not follow this rule (this rule is enforced by
   the packet receiver).

2.12.  Shutdown Ambiguity

2.12.1.  Description of the Problem

   Currently, there is an ambiguity between the statements in Sections
   6.2 and 9.2.  Section 6.2 allows the sending of a SHUTDOWN chunk in
   place of a SACK when the sender is in the process of shutting down,
   while section 9.2 requires that both a SHUTDOWN chunk and a SACK
   chunk be sent.

   Along with this ambiguity there is a problem wherein an errant
   SHUTDOWN receiver may fail to stop accepting user data.

2.12.2.  Text Changes to the Document

   ---------
   Old text: (Section 9.2)
   ---------

   If there are still outstanding DATA chunks left, the SHUTDOWN
   receiver shall continue to follow normal data transmission procedures
   defined in Section 6 until all outstanding DATA chunks are
   acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
   from its SCTP user.

   While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
   respond to each received packet containing one or more DATA chunk(s)
   with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer.  If
   it has no more outstanding DATA chunks, the SHUTDOWN receiver shall
   send a SHUTDOWN ACK and start a T2-shutdown timer of its own,
   entering the SHUTDOWN-ACK-SENT state.  If the timer expires, the
   endpoint must re-send the SHUTDOWN ACK.

Top      Up      ToC       Page 32 
   ---------
   New text: (Section 9.2)
   ---------

   If there are still outstanding DATA chunks left, the SHUTDOWN
   receiver MUST continue to follow normal data transmission procedures
   defined in Section 6, until all outstanding DATA chunks are
   acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data
   from its SCTP user.

   While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately
   respond to each received packet containing one or more DATA chunks
   with a SHUTDOWN chunk and restart the T2-shutdown timer.  If a
   SHUTDOWN chunk by itself cannot acknowledge all of the received DATA
   chunks (i.e., there are TSNs that can be acknowledged that are larger
   than the cumulative TSN, and thus gaps exist in the TSN sequence), or
   if duplicate TSNs have been received, then a SACK chunk MUST also be
   sent.

   The sender of the SHUTDOWN MAY also start an overall guard timer
   'T5-shutdown-guard' to bound the overall time for shutdown sequence.
   At the expiration of this timer, the sender SHOULD abort the
   association by sending an ABORT chunk.  If the 'T5-shutdown-guard'
   timer is used, it SHOULD be set to the recommended value of 5 times
   'RTO.Max'.

   If the receiver of the SHUTDOWN has no more outstanding DATA chunks,
   the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a
   T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state.
   If the timer expires, the endpoint must re-send the SHUTDOWN ACK.

2.12.3.  Solution Description

   The above text clarifies the use of a SACK in conjunction with a
   SHUTDOWN chunk.  It also adds a guard timer to the SCTP shutdown
   sequence to protect against errant receivers of SHUTDOWN chunks.

2.13.  Inconsistency in ABORT Processing

2.13.1.  Description of the Problem

   It was noted that the wording in Section 8.5.1 did not give proper
   directions in the use of the 'T bit' with the Verification Tags.

Top      Up      ToC       Page 33 
2.13.2.  Text changes to the document

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

   B) Rules for packet carrying ABORT:

      -  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 a ABORT MUST accept the packet if the
         Verification Tag field of the packet matches its own tag 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.

2.13.3.  Solution Description

   The above text change clarifies that the T bit must be set before an
   implementation looks for the peer's tag.

Top      Up      ToC       Page 34 
2.14.  Cwnd Gated by Its Full Use

2.14.1.  Description of the Problem

   A problem was found with the current specification of the growth and
   decay of cwnd.  The cwnd should only be increased if it is being
   fully utilized, and after periods of underutilization, the cwnd
   should be decreased.  In some sections, the current wording is weak
   and is not clearly defined.  Also, the current specification
   unnecessarily introduces the need for special case code to ensure
   cwnd degradation.  Plus, the cwnd should not be increased during Fast
   Recovery, since a full cwnd during Fast Recovery does not qualify the
   cwnd as being fully utilized.  Additionally, multiple loss scenarios
   in a single window may cause the cwnd to grow more rapidly as the
   number of losses in a window increases [3].

2.14.2.  Text Changes to the Document

   ---------
   Old text: (Section 6.1)
   ---------

   D) Then, the sender can send out as many new DATA chunks as Rule A
      and Rule B above allow.

   ---------
   New text: (Section 6.1)
   ---------

   D) When the time comes for the sender to transmit new DATA chunks,
      the protocol parameter Max.Burst SHOULD be used to limit the
      number of packets sent.  The limit MAY be applied by adjusting
      cwnd as follows:

      if((flightsize + Max.Burst*MTU) < cwnd)
         cwnd = flightsize + Max.Burst*MTU

      Or it MAY be applied by strictly limiting the number of packets
      emitted by the output routine.

   E) Then, the sender can send out as many new DATA chunks as Rule A
      and Rule B allow.

Top      Up      ToC       Page 35 
   ---------
   Old text: (Section 7.2.1)
   ---------

   o  When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
      use the slow start algorithm to increase cwnd (assuming the
      current congestion window is being fully utilized).  If an
      incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be
      increased by at most the lesser of 1) the total size of the
      previously outstanding DATA chunk(s) acknowledged, and 2) the
      destination's path MTU.  This protects against the ACK-Splitting
      attack outlined in [SAVAGE99].

   ---------
   New text: (Section 7.2.1)
   ---------

   o  When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST
      use the slow start algorithm to increase cwnd only if the current
      congestion window is being fully utilized, an incoming SACK
      advances the Cumulative TSN Ack Point, and the data sender is not
      in Fast Recovery.  Only when these three conditions are met can
      the cwnd be increased; otherwise, the cwnd MUST not be increased.
      If these conditions are met, then cwnd MUST be increased by, at
      most, the lesser of 1) the total size of the previously
      outstanding DATA chunk(s) acknowledged, and 2) the destination's
      path MTU.  This upper bound protects against the ACK-Splitting
      attack outlined in [SAVAGE99].


   ---------
   Old 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
   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

Top      Up      ToC       Page 36 
   ---------
   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

2.14.3.  Solution Description

   The above changes strengthen the rules and make it much more apparent
   as to the need to block cwnd growth when the full cwnd is not being
   utilized.  The changes also apply cwnd degradation without
   introducing the need for complex special case code.

2.15.  Window Probes in SCTP

2.15.1.  Description of the Problem

   When a receiver clamps its rwnd to 0 to flow control the peer, the
   specification implies that one must continue to accept data from the
   remote peer.  This is incorrect and needs clarification.

2.15.2.  Text Changes to the Document

   ---------
   Old text: (Section 6.2)
   ---------

   The SCTP endpoint MUST always acknowledge the receipt of each valid
   DATA chunk.

Top      Up      ToC       Page 37 
   ---------
   New text: (Section 6.2)
   ---------

   The SCTP endpoint MUST always acknowledge the reception of each valid
   DATA chunk when the DATA chunk received is inside its receive window.

   When the receiver's advertised window is 0, the receiver MUST drop
   any new incoming DATA chunk with a TSN larger than the largest TSN
   received so far.  If the new incoming DATA chunk holds a TSN value
   less than the largest TSN received so far, then the receiver SHOULD
   drop the largest TSN held for reordering and accept the new incoming
   DATA chunk.  In either case, if such a DATA chunk is dropped, the
   receiver MUST immediately send back a SACK with the current receive
   window showing only DATA chunks received and accepted so far.  The
   dropped DATA chunk(s) MUST NOT be included in the SACK, as they were
   not accepted.  The receiver MUST also have an algorithm for
   advertising its receive window to avoid receiver silly window
   syndrome (SWS), as described in RFC 813.  The algorithm can be
   similar to the one described in Section 4.2.3.3 of RFC 1122.


   ---------
   Old text: (Section 6.1)
   ---------

   A) At any given time, the data sender MUST NOT transmit new data to
      any destination transport address if its peer's rwnd indicates
      that the peer has no buffer space (i.e., rwnd is 0, see Section
      6.2.1).  However, regardless of the value of rwnd (including if it
      is 0), the data sender can always have one DATA chunk in flight to
      the receiver if allowed by cwnd (see rule B below).  This rule
      allows the sender to probe for a change in rwnd that the sender
      missed due to the SACK having been lost in transit from the data
      receiver to the data sender.

Top      Up      ToC       Page 38 
   ---------
   New text: (Section 6.1)
   ---------

   A) At any given time, the data sender MUST NOT transmit new data to
      any destination transport address if its peer's rwnd indicates
      that the peer has no buffer space (i.e., rwnd is 0; see Section
      6.2.1).  However, regardless of the value of rwnd (including if it
      is 0), the data sender can always have one DATA chunk in flight to
      the receiver if allowed by cwnd (see rule B, below).  This rule
      allows the sender to probe for a change in rwnd that the sender
      missed due to the SACK's having been lost in transit from the data
      receiver to the data sender.

      When the receiver's advertised window is zero, this probe is
      called a zero window probe.  Note that a zero window probe
      SHOULD only be sent when all outstanding DATA chunks have
      been cumulatively acknowledged and no DATA chunks are in
      flight.  Zero window probing MUST be supported.

      If the sender continues to receive new packets from the receiver
      while doing zero window probing, the unacknowledged window probes
      should not increment the error counter for the association or any
      destination transport address.This is because the receiver MAY
      keep its window closed for an indefinite time.  Refer to
      Section 6.2 on the receiver behavior when it advertises a zero
      window.  The sender SHOULD send the first zero window probe after
      1 RTO when it detects that the receiver has closed its window
      and SHOULD increase the probe interval exponentially afterwards.
      Also note that the cwnd SHOULD be adjusted according to
      Section 7.2.1.  Zero window probing does not affect the
      calculation of cwnd.

      The sender MUST also have an algorithm for sending new DATA chunks
      to avoid silly window syndrome (SWS) as described in RFC 813.  The
      algorithm can be similar to the one described in Section 4.2.3.4
      of RFC 1122.

2.15.3.  Solution Description

   The above allows a receiver to drop new data that arrives and yet
   still requires the receiver to send a SACK showing the conditions
   unchanged (with the possible exception of a new a_rwnd) and the
   dropped chunk as missing.  This will allow the association to
   continue until the rwnd condition clears.

Top      Up      ToC       Page 39 
2.16.  Fragmentation and Path MTU Issues

2.16.1.  Description of the Problem

   The current wording of the Fragmentation and Reassembly forces an
   implementation that supports fragmentation to always fragment.  This
   prohibits an implementation from offering its users an option to
   disable sends that exceed the SCTP fragmentation point.

   The restriction in RFC 2960 [5], Section 6.9, was never meant to
   restrict an implementations API from this behavior.

2.16.2.  Text Changes to the Document

   ---------
   Old text: (Section 6.1)
   ---------

   6.9 Fragmentation and Reassembly

   An endpoint MAY support fragmentation when sending DATA chunks, but
   MUST support reassembly when receiving DATA chunks.  If an endpoint
   supports fragmentation, it MUST fragment a user message if the size
   of the user message to be sent causes the outbound SCTP packet size
   to exceed the current MTU.  If an implementation does not support
   fragmentation of outbound user messages, the endpoint must return an
   error to its upper layer and not attempt to send the user message.

   IMPLEMENTATION NOTE:  In this error case, the Send primitive
   discussed in Section 10.1 would need to return an error to the upper
   layer.

   ---------
   New text: (Section 6.1)
   ---------

   6.9.  Fragmentation and Reassembly

   An endpoint MAY support fragmentation when sending DATA chunks, but
   it MUST support reassembly when receiving DATA chunks.  If an
   endpoint supports fragmentation, it MUST fragment a user message if
   the size of the user message to be sent causes the outbound SCTP
   packet size to exceed the current MTU.  If an implementation does not
   support fragmentation of outbound user messages, the endpoint MUST
   return an error to its upper layer and not attempt to send the user
   message.

Top      Up      ToC       Page 40 
   Note: If an implementation that supports fragmentation makes
   available to its upper layer a mechanism to turn off fragmentation it
   may do so.  However, in so doing, it MUST react just like an
   implementation that does NOT support fragmentation, i.e., it MUST
   reject sends that exceed the current P-MTU.

   IMPLEMENTATION NOTE:  In this error case, the Send primitive
   discussed in Section 10.1 would need to return an error to the upper
   layer.

2.16.3.  Solution Description

   The above wording will allow an implementation to offer the option of
   rejecting sends that exceed the P-MTU size even when the
   implementation supports fragmentation.

2.17.  Initial Value of the Cumulative TSN Ack

2.17.1.  Description of the Problem

   The current description of the SACK chunk within the RFC does not
   clearly state the value that would be put within a SACK when no DATA
   chunk has been received.

2.17.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.3.4)
   ---------

   Cumulative TSN Ack: 32 bits (unsigned integer)

      This parameter contains the TSN of the last DATA chunk received in
      sequence before a gap.

   ---------
   New text: (Section 3.3.4)
   ---------

   Cumulative TSN Ack: 32 bits (unsigned integer)

      This parameter contains the TSN of the last DATA chunk received in
      sequence before a gap.  In the case where no DATA chunk has
      been received, this value is set to the peer's Initial TSN minus
      one.

Top      Up      ToC       Page 41 
2.17.3.  Solution Description

   This change clearly states what the initial value will be for a SACK
   sender.

2.18.  Handling of Address Parameters within the INIT or INIT-ACK

2.18.1.  Description of the Problem

   The current description on handling address parameters contained
   within the INIT and INIT-ACK does not fully describe a requirement
   for their handling.

2.18.2.  Text Changes to the Document

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

   C) If there are only IPv4/IPv6 addresses present in the received INIT
      or INIT ACK chunk, the receiver shall derive and record all the
      transport address(es) from the received chunk AND the source IP
      address that sent the INIT or INIT ACK.  The transport address(es)
      are derived by the combination of SCTP source port (from the
      common header) and the IP address parameter(s) carried in the INIT
      or INIT ACK chunk and the source IP address of the IP datagram.
      The receiver should use only these transport addresses as
      destination transport addresses when sending subsequent packets to
      its peer.

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

   C) If there are only IPv4/IPv6 addresses present in the received INIT
      or INIT ACK chunk, the receiver MUST derive and record all the
      transport addresses from the received chunk AND the source IP
      address that sent the INIT or INIT ACK.  The transport addresses
      are derived by the combination of SCTP source port (from the
      common header) and the IP address parameter(s) carried in the INIT
      or INIT ACK chunk and the source IP address of the IP datagram.
      The receiver should use only these transport addresses as
      destination transport addresses when sending subsequent packets to
      its peer.

Top      Up      ToC       Page 42 
   D) An INIT or INIT ACK chunk MUST be treated as belonging
      to an already established association (or one in the
      process of being established) if the use of any of the
      valid address parameters contained within the chunk
      would identify an existing TCB.

2.18.3.  Solution description

   This new text clearly specifies to an implementor the need to look
   within the INIT or INIT ACK.  Any implementation that does not do
   this may (for example) not be able to recognize an INIT chunk coming
   from an already established association that adds new addresses (see
   Section 2.6) or an incoming INIT ACK chunk sent from a source address
   different from the destination address used to send the INIT chunk.

2.19.  Handling of Stream Shortages

2.19.1.  Description of the Problem

   The current wording in the RFC places the choice of sending an ABORT
   upon the SCTP stack when a stream shortage occurs.  This decision
   should really be made by the upper layer, not the SCTP stack.

2.19.2.  Text Changes to the Document

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

   5.1.1 Handle Stream Parameters

   In the INIT and INIT ACK chunks, the sender of the chunk shall
   indicate the number of outbound streams (OS) it wishes to have in
   the association, as well as the maximum inbound streams (MIS) it
   will accept from the other endpoint.

   After receiving the stream configuration information from the other
   side, each endpoint shall perform the following check:  If the peer's
   MIS is less than the endpoint's OS, meaning that the peer is
   incapable of supporting all the outbound streams the endpoint wants
   to configure, the endpoint MUST either use MIS outbound streams, or
   abort the association and report to its upper layer the resources
   shortage at its peer.

Top      Up      ToC       Page 43 
   ---------
   New text: (Section 5.1.2)
   ---------

   5.1.1.  Handle Stream Parameters

   In the INIT and INIT ACK chunks, the sender of the chunk MUST
   indicate the number of outbound streams (OS) it wishes to have in
   the association, as well as the maximum inbound streams (MIS) it will
   accept from the other endpoint.

   After receiving the stream configuration information from the other
   side, each endpoint MUST perform the following check:  If the peer's
   MIS is less than the endpoint's OS, meaning that the peer is
   incapable of supporting all the outbound streams the endpoint wants
   to configure, the endpoint MUST use MIS outbound streams and MAY
   report any shortage to the upper layer.  The upper layer can then
   choose to abort the association if the resource shortage
   is unacceptable.

2.19.3.  Solution Description

   The above changes take the decision to ABORT out of the realm of the
   SCTP stack and place it into the user's hands.

2.20.  Indefinite Postponement

2.20.1.  Description of the Problem

   The current RFC does not provide any guidance on the assignment of
   TSN sequence numbers to outbound messages nor reception of these
   messages.  This could lead to a possible indefinite postponement.

2.20.2.  Text Changes to the Document

   ---------
   Old text: (Section 6.1)
   ---------

   Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
   1 above the beginning TSN of the current send window.

   6.2  Acknowledgement on Reception of DATA Chunks

Top      Up      ToC       Page 44 
   ---------
   New text: (Section 6.1)
   ---------

   Note: The data sender SHOULD NOT use a TSN that is more than 2**31 -
   1 above the beginning TSN of the current send window.

   The algorithm by which an implementation assigns sequential TSNs to
   messages on a particular association MUST ensure that no user
   message that has been accepted by SCTP is indefinitely postponed
   from being assigned a TSN.  Acceptable algorithms for assigning TSNs
   include

   (a) assigning TSNs in round-robin order over all streams with
       pending data; and

   (b) preserving the linear order in which the user messages were
       submitted to the SCTP association.

   When an upper layer requests to read data on an SCTP association,
   the SCTP receiver SHOULD choose the message with the lowest TSN from
   among all deliverable messages.  In SCTP implementations that allow a
   user to request data on a specific stream, this operation SHOULD NOT
   block if data is not available, since this can lead to a deadlock
   under certain conditions.

   6.2.  Acknowledgement on Receipt of DATA Chunks

2.20.3.  Solution Description

   The above wording clarifies how TSNs SHOULD be assigned by the
   sender.

2.21.  User-Initiated Abort of an Association

2.21.1.  Description of the Problem

   It is not possible for an upper layer to abort the association and
   provide the peer with an indication of why the association is
   aborted.

2.21.2.  Text changes to the document

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

Top      Up      ToC       Page 45 
   ---------
   Old text: (Section 3.3.10)
   ---------

      Cause Code
      Value           Cause Code
      ---------      ----------------
       1              Invalid Stream Identifier
       2              Missing Mandatory Parameter
       3              Stale Cookie Error
       4              Out of Resource
       5              Unresolvable Address
       6              Unrecognized Chunk Type
       7              Invalid Mandatory Parameter
       8              Unrecognized Parameters
       9              No User Data
      10              Cookie Received While Shutting Down

   Cause Length: 16 bits (unsigned integer)

      Set to the size of the parameter in bytes, including the Cause
      Code, Cause Length, and Cause-Specific Information fields

   Cause-specific Information: variable length

      This field carries the details of the error condition.

   Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
   Guidelines for the IETF to define new error cause values are
   discussed in Section 13.3.

Top      Up      ToC       Page 46 
   ---------
   New text: (Section 3.3.10)
   ---------

      Cause Code
      Value           Cause Code
      ---------      ----------------
       1              Invalid Stream Identifier
       2              Missing Mandatory Parameter
       3              Stale Cookie Error
       4              Out of Resource
       5              Unresolvable Address
       6              Unrecognized Chunk Type
       7              Invalid Mandatory Parameter
       8              Unrecognized Parameters
       9              No User Data
      10              Cookie Received While Shutting Down
      11              Restart of an Association with New Addresses
      12              User-Initiated Abort

   Cause Length: 16 bits (unsigned integer)

      Set to the size of the parameter in bytes, including the Cause
      Code, Cause Length, and Cause-Specific Information fields

   Cause-specific Information: variable length

      This field carries the details of the error condition.

   Sections 3.3.10.1 - 3.3.10.12 define error causes for SCTP.
   Guidelines for the IETF to define new error cause values are
   discussed in Section 13.3.

   ---------
   New text: (Note: no old text, new error added in Section 3.3.10)
   ---------

   3.3.10.12.  User-Initiated Abort (12)

    Cause of error
    --------------

    This error cause MAY be included in ABORT chunks that are sent
    because of an upper layer request.  The upper layer can specify
    an Upper Layer Abort Reason that is transported by SCTP
    transparently and MAY be delivered to the upper layer protocol
    at the peer.

Top      Up      ToC       Page 47 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Cause Code=12         |      Cause Length=Variable    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                    Upper Layer Abort Reason                   /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   ---------
   Old text: (Section 9.1)
   ---------

   9.1 Abort of an Association

      When an endpoint decides to abort an existing association, it
      shall send an ABORT chunk to its peer endpoint.  The sender MUST
      fill in the peer's Verification Tag in the outbound packet and
      MUST NOT bundle any DATA chunk with the ABORT.

      An endpoint MUST NOT respond to any received packet that contains
      an ABORT chunk (also see Section 8.4).

      An endpoint receiving an ABORT shall apply the special
      Verification Tag check rules described in Section 8.5.1.

      After checking the Verification Tag, the receiving endpoint shall
      remove the association from its record and shall report the
      termination to its upper layer.

      ---------
      New text: (Section 9.1)
      ---------

      9.1.  Abort of an Association

      When an endpoint decides to abort an existing association, it MUST
      send an ABORT chunk to its peer endpoint.  The sender MUST fill in
      the peer's Verification Tag in the outbound packet and MUST NOT
      bundle any DATA chunk with the ABORT.  If the association is
      aborted on request of the upper layer, a User-Initiated Abort
      error cause (see 3.3.10.12) SHOULD be present in the ABORT chunk.

      An endpoint MUST NOT respond to any received packet that contains
      an ABORT chunk (also see Section 8.4).

      An endpoint receiving an ABORT MUST apply the special Verification
      Tag check rules described in Section 8.5.1.

      After checking the Verification Tag, the receiving endpoint MUST

Top      Up      ToC       Page 48 
      remove the association from its record and SHOULD report the
      termination to its upper layer.  If a User-Initiated Abort error
      cause is present in the ABORT chunk, the Upper Layer Abort Reason
      SHOULD be made available to the upper layer.

   ---------
   Old text: (Section 10.1)
   ---------

      D) Abort

      Format: ABORT(association id [, cause code])
      -> result

      Ungracefully closes an association.  Any locally queued user
      data will be discarded and an ABORT chunk is sent to the peer.
      A success code will be returned on successful abortion of the
      association.  If attempting to abort the association results
      in a failure, an error code shall be returned.

      Mandatory attributes:

      o  association id - local handle to the SCTP association

      Optional attributes:

      o  cause code - reason of the abort to be passed to the peer.


   ---------
   New text: (Section 10.1)
   ---------

      D) Abort

      Format: ABORT(association id [, Upper Layer Abort Reason])
      -> result

      Ungracefully closes an association.  Any locally queued user
      data will be discarded, and an ABORT chunk is sent to the peer.
      A success code will be returned on successful abortion of the
      association.  If attempting to abort the association results
      in a failure, an error code shall be returned.

      Mandatory attributes:

      o  association id - Local handle to the SCTP association.

Top      Up      ToC       Page 49 
      Optional attributes:

      o  Upper Layer Abort Reason - Reason of the abort to be passed
         to the peer.

      None.

   ---------
   Old text: (Section 10.2)
   ---------

      E) COMMUNICATION LOST notification

      When SCTP loses communication to an endpoint completely (e.g., via
      Heartbeats) or detects that the endpoint has performed an abort
      operation, it shall invoke this notification on the ULP.

      The following shall be passed with the notification:

      o  association id - local handle to the SCTP association

      o status - This indicates what type of event has occurred; The
                 status may indicate a failure OR a normal termination
                 event occurred in response to a shutdown or abort
                 request.

      The following may be passed with the notification:

      o  data retrieval id - an identification used to retrieve
         unsent and unacknowledged data.

      o  last-acked - the TSN last acked by that peer endpoint;

      o  last-sent - the TSN last sent to that peer endpoint;

   ---------
   New text: (Section 10.2)
   ---------

      E) COMMUNICATION LOST notification

      When SCTP loses communication to an endpoint completely (e.g., via
      Heartbeats) or detects that the endpoint has performed an abort
      operation, it shall invoke this notification on the ULP.

      The following shall be passed with the notification:

      o  association id - Local handle to the SCTP association.

Top      Up      ToC       Page 50 
      o  status - This indicates what type of event has occurred; The
                  status may indicate that a failure OR a normal
                  termination event occurred in response to a shutdown
                  or abort request.

      The following may be passed with the notification:

      o  data retrieval id - An identification used to retrieve unsent
         and unacknowledged data.

      o  last-acked - The TSN last acked by that peer endpoint.

      o  last-sent - The TSN last sent to that peer endpoint.

      o  Upper Layer Abort Reason - The abort reason specified in
                                    case of a user-initiated abort.

2.21.3.  Solution Description

   The above allows an upper layer to provide its peer with an
   indication of why the association was aborted.  Therefore, an
   addition error cause was introduced.

2.22.  Handling of Invalid Initiate Tag of INIT-ACK

2.22.1.  Description of the Problem

   RFC 2960 requires that the receiver of an INIT-ACK with the Initiate
   Tag set to zero handles this as an error and sends back an ABORT.
   But the sender of the INIT-ACK normally has no TCB, and thus the
   ABORT is useless.

2.22.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.3.3)
   ---------

      Initiate Tag: 32 bits (unsigned integer)

         The receiver of the INIT ACK records the value of the
         Initiate Tag parameter.  This value MUST be placed into
         the Verification Tag field of every SCTP packet that the
         INIT ACK receiver transmits within this association.

         The Initiate Tag MUST NOT take the value 0.  See Section 5.3.1
         for more on the selection of the Initiate Tag value.

Top      Up      ToC       Page 51 
         If the value of the Initiate Tag in a received INIT ACK chunk
         is found to be 0, the receiver MUST treat it as an error and
         close the association by transmitting an ABORT.

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

      Initiate Tag: 32 bits (unsigned integer)

         The receiver of the INIT ACK records the value of the
         Initiate Tag parameter.  This value MUST be placed into
         the Verification Tag field of every SCTP packet that the
         INIT ACK receiver transmits within this association.

         The Initiate Tag MUST NOT take the value 0.  See Section 5.3.1
         for more on the selection of the Initiate Tag value.

         If the value of the Initiate Tag in a received INIT ACK
         chunk is found to be 0, the receiver MUST destroy the
         association discarding its TCB.  The receiver MAY send an
         ABORT for debugging purpose.

2.22.3.  Solution Description

   The new text does not require that the receiver of the invalid INIT-
   ACK send the ABORT.  This behavior is in tune with the error case of
   invalid stream numbers in the INIT-ACK.  However, sending an ABORT
   for debugging purposes is allowed.

2.23.  Sending an ABORT in Response to an INIT

2.23.1.  Description of the Problem

   Whenever the receiver of an INIT chunk has to send an ABORT chunk in
   response, for whatever reason, it is not stated clearly which
   Verification Tag and value of the T-bit should be used.

2.23.2.  Text Changes to the Document

   ---------
   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,

Top      Up      ToC       Page 52 
   ---------
   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
         a TCB was destroyed.  Otherwise,

2.23.3.  Solution Description

   The new text stated clearly which value of the Verification Tag and
   T-bit have to be used.

2.24.  Stream Sequence Number (SSN) Initialization

2.24.1.  Description of the Problem

   RFC 2960 does not describe the fact that the SSN has to be
   initialized to 0, as required by RFC 2119.

2.24.2.  Text Changes to the Document

   ---------
   Old text: (Section 6.5)
   ---------

      The stream sequence number in all the streams shall start from 0
      when the association is established.  Also, when the stream
      sequence number reaches the value 65535 the next stream sequence
      number shall be set to 0.

   ---------
   New text: (Section 6.5)
   ---------

      The stream sequence number in all the streams MUST start from 0
      when the association is established.  Also, when the stream
      sequence number reaches the value 65535 the next stream sequence
      number MUST be set to 0.

Top      Up      ToC       Page 53 
2.24.3.  Solution Description

   The 'shall' in the text is replaced by a 'MUST' to clearly state the
   required behavior.

2.25.  SACK Packet Format

2.25.1.  Description of the Problem

   It is not clear in RFC 2960 whether a SACK must contain the fields
   Number of Gap Ack Blocks and Number of Duplicate TSNs.

2.25.2.  Text Changes to the Document

   ---------
   Old text: (Section 3.3.4)
   ---------

      The SACK MUST contain the Cumulative TSN Ack and
      Advertised Receiver Window Credit (a_rwnd) parameters.

   ---------
   New text: (Section 3.3.4)
   ---------

      The SACK MUST contain the Cumulative TSN Ack,
      Advertised Receiver Window Credit (a_rwnd), Number
      of Gap Ack Blocks, and Number of Duplicate TSNs fields.

2.25.3.  Solution Description

   The text has been modified.  It is now clear that a SACK always
   contains the fields Number of Gap Ack Blocks and Number of Duplicate
   TSNs.

2.26.  Protocol Violation Error Cause

2.26.1.  Description of the Problem

   There are many situations where an SCTP endpoint may detect that its
   peer violates the protocol.  The result of such detection often
   results in the association being destroyed by the sending of an
   ABORT.  Currently, there are only some error causes that could be
   used to indicate the reason for the abort, but these do not cover all
   cases.

Top      Up      ToC       Page 54 
2.26.2.  Text Changes to the Document

   Some of the changes given here already include changes suggested in
   Section 2.6 and 2.21 of this document.

   ---------
   Old text: (Section 3.3.10)
   ---------

      Cause Code
      Value           Cause Code
      ---------      ----------------
       1              Invalid Stream Identifier
       2              Missing Mandatory Parameter
       3              Stale Cookie Error
       4              Out of Resource
       5              Unresolvable Address
       6              Unrecognized Chunk Type
       7              Invalid Mandatory Parameter
       8              Unrecognized Parameters
       9              No User Data
      10              Cookie Received While Shutting Down

   Cause Length: 16 bits (unsigned integer)

      Set to the size of the parameter in bytes, including the Cause
      Code, Cause Length, and Cause-Specific Information fields

   Cause-specific Information: variable length

      This field carries the details of the error condition.

   Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
   Guidelines for the IETF to define new error cause values are
   discussed in Section 13.3.

Top      Up      ToC       Page 55 
   ---------
   New text: (Section 3.3.10)
   ---------

      Cause Code
      Value           Cause Code
      ---------      ----------------
       1              Invalid Stream Identifier
       2              Missing Mandatory Parameter
       3              Stale Cookie Error
       4              Out of Resource
       5              Unresolvable Address
       6              Unrecognized Chunk Type
       7              Invalid Mandatory Parameter
       8              Unrecognized Parameters
       9              No User Data
      10              Cookie Received While Shutting Down
      11              Restart of an Association with New Addresses
      12              User Initiated Abort
      13              Protocol Violation

   Cause Length: 16 bits (unsigned integer)

      Set to the size of the parameter in bytes, including the Cause
      Code, Cause Length, and Cause-Specific Information fields

   Cause-specific Information: variable length

      This field carries the details of the error condition.

   Sections 3.3.10.1 - 3.3.10.13 define error causes for SCTP.
   Guidelines for the IETF to define new error cause values are
   discussed in Section 13.3.

   ---------
   New text: (Note: no old text; new error added in section 3.3.10)
   ---------

   3.3.10.13.  Protocol Violation (13)

    Cause of error
    --------------

    This error cause MAY be included in ABORT chunks that are sent
    because an SCTP endpoint detects a protocol violation of the peer
    that is not covered by the error causes described in 3.3.10.1 to
    3.3.10.12.  An implementation MAY provide additional information
    specifying what kind of protocol violation has been detected.

Top      Up      ToC       Page 56 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Cause Code=13         |      Cause Length=Variable    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                    Additional Information                     /
      \                                                               \
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.26.3.  Solution Description

   An additional error cause has been defined that can be used by an
   endpoint to indicate a protocol violation of the peer.

2.27.  Reporting of Unrecognized Parameters

2.27.1.  Description of the Problem

   It is not stated clearly in RFC 2960 [5] how unrecognized parameters
   should be reported.  Unrecognized parameters in an INIT chunk could
   be reported in the INIT-ACK chunk or in a separate ERROR chunk, which
   can get lost.  Unrecognized parameters in an INIT-ACK chunk have to
   be reported in an ERROR-chunk.  This can be bundled with the COOKIE-
   ERROR chunk or sent separately.  If it is sent separately and
   received before the COOKIE-ECHO, it will be handled as an OOTB
   packet, resulting in sending out an ABORT chunk.  Therefore, the
   association would not be established.

2.27.2.  Text Changes to the Document

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

   ---------
   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).

Top      Up      ToC       Page 57 
   ---------
   New text: (Section 3.2.1)
   ---------

   00 - Stop processing this SCTP chunk and discard it; do not process
        any further parameters within this chunk.

   01 - Stop processing this SCTP chunk and discard it, 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 resources), then no report would be sent back.

      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.27.3.  Solution Description

   The procedure of reporting unrecognized parameters has been described
   clearly.


Next RFC Part