Network Working Group                                         R. Stewart
Internet-Draft                                       Cisco Systems, Inc.
Expires: April 1, August 27, 2003                                          L. Ong
                                                           Ciena Systems
                                                      I. Arias-Rodriguez
                                                   Nokia Research Center
                                                                 K. Poon
                                                Sun Microsysystems, Inc.
                                                              Consultant
                                                               P. Conrad
                                                       Temple University
                                                                 A. Caro
                                                Department of Computer &
                                      Information Sciences
                                                  University of Delaware
                                                               M. Tuexen
                                                              Siemens AG
                                                         October 1, 2002
                                                       February 26, 2003

    Stream Control Transmission Protocol (SCTP) Implementers Implementer's Guide
                  draft-ietf-tsvwg-sctpimpguide-07.txt
                  draft-ietf-tsvwg-sctpimpguide-08.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

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

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

   This Internet-Draft will expire on April 1, August 27, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002). (2003).  All Rights Reserved.

Abstract

   This document contains a compilation of all defects found up until
   the publishing of this document for the Stream Control Transmission
   Protocol (SCTP) RFC2960 [3]. [5].  These defects may be of an editorial or
   technical nature.  This document may be thought of as a companion
   document to be used in the implementation of SCTP to clarify errors
   in the original SCTP document.

   This document updates RFC2960 [3] [5] and text within this document
   supersedes the text found in RFC2960 [3]. [5].

Table of Contents

   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   6   5
   1.1    Conventions  . . . . . . . . . . . . . . . . . . . . . . .   6   5
   2.     Corrections to RFC2960 . . . . . . . . . . . . . . . . . .   7   6
   2.1    Incorrect error type during chunk processing.  . . . . . .   7   6
   2.1.1  Description of the problem . . . . . . . . . . . . . . . .   7   6
   2.1.2  Text changes to the document . . . . . . . . . . . . . . .   7   6
   2.1.3  Solution description . . . . . . . . . . . . . . . . . . .   7   6
   2.2    Parameter processing issue . . . . . . . . . . . . . . . .   7   6
   2.2.1  Description of the problem . . . . . . . . . . . . . . . .   7   6
   2.2.2  Text changes to the document . . . . . . . . . . . . . . .   8   7
   2.2.3  Solution description . . . . . . . . . . . . . . . . . . .   8   7
   2.3    Padding issues . . . . . . . . . . . . . . . . . . . . . .   8   7
   2.3.1  Description of the problem . . . . . . . . . . . . . . . .   8   7
   2.3.2  Text changes to the document . . . . . . . . . . . . . . .   8   7
   2.3.3  Solution description . . . . . . . . . . . . . . . . . . .  10   9
   2.4    Parameter types across all chunk types . . . . . . . . . .  10   9
   2.4.1  Description of the problem . . . . . . . . . . . . . . . .  10   9
   2.4.2  Text changes to the document . . . . . . . . . . . . . . .  10   9
   2.4.3  Solution description . . . . . . . . . . . . . . . . . . .  11  10
   2.5    Stream parameter clarification . . . . . . . . . . . . . .  12  11
   2.5.1  Description of the problem . . . . . . . . . . . . . . . .  12  11
   2.5.2  Text changes to the document . . . . . . . . . . . . . . .  12  11
   2.5.3  Solution description . . . . . . . . . . . . . . . . . . .  13  11
   2.6    Restarting association security issue  . . . . . . . . . .  13  12
   2.6.1  Description of the problem . . . . . . . . . . . . . . . .  13  12
   2.6.2  Text changes to the document . . . . . . . . . . . . . . .  13  12
   2.6.3  Solution description . . . . . . . . . . . . . . . . . . .  17  16
   2.7    Implicit ability to exceed cwnd by PMTU-1 bytes  . . . . .  17  16
   2.7.1  Description of the problem . . . . . . . . . . . . . . . .  17  16
   2.7.2  Text changes to the document . . . . . . . . . . . . . . .  18  17
   2.7.3  Solution description . . . . . . . . . . . . . . . . . . .  18  17
   2.8    Issues with Fast Retransmit  . . . . . . . . . . . . . . .  18  17
   2.8.1  Description of the problem . . . . . . . . . . . . . . . .  18  17
   2.8.2  Text changes to the document . . . . . . . . . . . . . . .  18  17
   2.8.3  Solution description . . . . . . . . . . . . . . . . . . .  21  20
   2.9    Missing statement about partial_bytes_acked update . . . .  22  21
   2.9.1  Description of the problem . . . . . . . . . . . . . . . .  22  21
   2.9.2  Text changes to the document . . . . . . . . . . . . . . .  22  21
   2.9.3  Solution description . . . . . . . . . . . . . . . . . . .  23  22
   2.10   Issues with Heartbeating and failure detection . . . . . .  23  22
   2.10.1 Description of the problem . . . . . . . . . . . . . . . .  23  22
   2.10.2 Text changes to the document . . . . . . . . . . . . . . .  24  22
   2.10.3 Solution description . . . . . . . . . . . . . . . . . . .  26  25
   2.11   Security interactions with firewalls . . . . . . . . . . .  26  25
   2.11.1 Description of the problem . . . . . . . . . . . . . . . .  26  25
   2.11.2 Text changes to the document . . . . . . . . . . . . . . .  26  25
   2.11.3 Solution description . . . . . . . . . . . . . . . . . . .  28  27
   2.12   Shutdown ambiguity . . . . . . . . . . . . . . . . . . . .  28  27
   2.12.1 Description of the problem . . . . . . . . . . . . . . . .  28  27
   2.12.2 Text changes to the document . . . . . . . . . . . . . . .  29  27
   2.12.3 Solution description . . . . . . . . . . . . . . . . . . .  30  29
   2.13   Inconsistency in ABORT processing  . . . . . . . . . . . .  30  29
   2.13.1 Description of the problem . . . . . . . . . . . . . . . .  30  29
   2.13.2 Text changes to the document . . . . . . . . . . . . . . .  30  29
   2.13.3 Solution description . . . . . . . . . . . . . . . . . . .  31  30
   2.14   Cwnd gated by its full use . . . . . . . . . . . . . . . .  31  30
   2.14.1 Description of the problem . . . . . . . . . . . . . . . .  32  30
   2.14.2 Text changes to the document . . . . . . . . . . . . . . .  32  31
   2.14.3 Solution description . . . . . . . . . . . . . . . . . . .  34  33
   2.15   Window probes in SCTP  . . . . . . . . . . . . . . . . . .  35  33
   2.15.1 Description of the problem . . . . . . . . . . . . . . . .  35  34
   2.15.2 Text changes to the document . . . . . . . . . . . . . . .  35  34
   2.15.3 Solution description . . . . . . . . . . . . . . . . . . .  36  35
   2.16   Fragmentation and Path MTU issues  . . . . . . . . . . . .  37  36
   2.16.1 Description of the problem . . . . . . . . . . . . . . . .  37  36
   2.16.2 Text changes to the document . . . . . . . . . . . . . . .  37  36
   2.16.3 Solution description . . . . . . . . . . . . . . . . . . .  38  37
   2.17   Initial value of the cumulative TSN Ack  . . . . . . . . .  38  37
   2.17.1 Description of the problem . . . . . . . . . . . . . . . .  38  37
   2.17.2 Text changes to the document . . . . . . . . . . . . . . .  39  37
   2.17.3 Solution description . . . . . . . . . . . . . . . . . . .  39  38
   2.18   Handling of address parameters within the INIT or
          INIT-ACK  39 . . . . . . . . . . . . . . . . . . . . . . . . .  38
   2.18.1 Description of the problem . . . . . . . . . . . . . . . .  39  38
   2.18.2 Text changes to the document . . . . . . . . . . . . . . .  39  38
   2.18.3 Solution description . . . . . . . . . . . . . . . . . . .  40  39
   2.19   Handling of stream shortages . . . . . . . . . . . . . . .  40
   2.19.1 Description of the problem . . . . . . . . . . . . . . . .  41  40
   2.19.2 Text changes to the document . . . . . . . . . . . . . . .  41  40
   2.19.3 Solution description . . . . . . . . . . . . . . . . . . .  42  41
   2.20   Indefinite postponement  . . . . . . . . . . . . . . . . .  42  41
   2.20.1 Description of the problem . . . . . . . . . . . . . . . .  42  41
   2.20.2 Text changes to the document . . . . . . . . . . . . . . .  42  41
   2.20.3 Solution description . . . . . . . . . . . . . . . . . . .  43  42
   2.21   User initiated abort of an association . . . . . . . . . .  43  42
   2.21.1 Description of the problem . . . . . . . . . . . . . . . .  44  42
   2.21.2 Text changes to the document . . . . . . . . . . . . . . .  44  43
   2.21.3 Solution description . . . . . . . . . . . . . . . . . . .  49  48
   2.22   Handling of invalid Initiate Tag of INIT-ACK . . . . . . .  49  48
   2.22.1 Description of the problem . . . . . . . . . . . . . . . .  49  48
   2.22.2 Text changes to the document . . . . . . . . . . . . . . .  49  48
   2.22.3 Solution description . . . . . . . . . . . . . . . . . . .  50  49
   2.23   ABORT sending in response to an INIT . . . . . . . . . . .  50  49
   2.23.1 Description of the problem . . . . . . . . . . . . . . . .  51  50
   2.23.2 Text changes to the document . . . . . . . . . . . . . . .  51  50
   2.23.3 Solution description . . . . . . . . . . . . . . . . . . .  51  50
   2.24   Stream Sequence Number (SSN) Initialization  . . . . . . .  51  50
   2.24.1 Description of the problem . . . . . . . . . . . . . . . .  51  50
   2.24.2 Text changes to the document . . . . . . . . . . . . . . .  52  51
   2.24.3 Solution description . . . . . . . . . . . . . . . . . . .  52  51
   2.25   SACK packet format . . . . . . . . . . . . . . . . . . . .  52  51
   2.25.1 Description of the problem . . . . . . . . . . . . . . . .  52  51
   2.25.2 Text changes to the document . . . . . . . . . . . . . . .  53  52
   2.25.3 Solution description . . . . . . . . . . . . . . . . . . .  53  52
   2.26   Protocol Violation Error Cause . . . . . . . . . . . . . .  53  52
   2.26.1 Description of the problem . . . . . . . . . . . . . . . .  53  52
   2.26.2 Text changes to the document . . . . . . . . . . . . . . .  53  52
   2.26.3 Solution description . . . . . . . . . . . . . . . . . . .  55  54
   2.27   Reporting of Unrecognized Parameters . . . . . . . . . . .  55  54
   2.27.1 Description of the problem . . . . . . . . . . . . . . . .  55  54
   2.27.2 Text changes to the document . . . . . . . . . . . . . . .  56  55
   2.27.3 Solution description . . . . . . . . . . . . . . . . . . .  57  56
   2.28   Handling of IP Address Parameters  . . . . . . . . . . . .  57  56
   2.28.1 Description of the problem . . . . . . . . . . . . . . . .  57  56
   2.28.2 Text changes to the document . . . . . . . . . . . . . . .  58  57
   2.28.3 Solution description . . . . . . . . . . . . . . . . . . .  58  57
   2.29   Handling of  COOKIE ECHO chunks when a TCB exists  . . . .  58  57
   2.29.1 Description of the problem . . . . . . . . . . . . . . . .  58  57
   2.29.2 Text changes to the document . . . . . . . . . . . . . . .  59  58
   2.29.3 Solution description . . . . . . . . . . . . . . . . . . .  59  58
   3.     Acknowledgments  . . . . . . . . . . . . . . . . . . . . .  60  59
          References . . . . . . . . . . . . . . . . . . . . . . . .  61  60
          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  61
          Full  60
          Intellectual Property and Copyright Statement . . . . . . . . . . . Statements . . . . . .  63

1. Introduction

   This document contains a compilation of all defects found up until
   the publishing of this document for the Stream Control Transmission
   Protocol (SCTP) RFC2960 [3]. [5].  These defects may be of an editorial or
   technical nature.  This document may be thought of as a companion
   document to be used in the implementation of SCTP to clarify errors
   in the original SCTP document.

   This document updates RFC2960 and text within this document, where
   noted, supersedes the text found in RFC2960 [3]. [5].  Each error will be
   detailed within this document in the form of:

   o  The problem description,

   o  The text quoted from RFC2960 [3], [5],

   o  The replacement text,

   o  A description of the solution.

1.1 Conventions

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

2. Corrections to RFC2960

2.1 Incorrect error type during chunk processing.

2.1.1 Description of the problem

   A typo was discovered in RFC2960 [3] [5] that incorrectly specifies an
   action to be taken when processing chunks of unknown identity.

2.1.2 Text changes to the document

   ---------
   Old text: (Section 3.2)
   ---------

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

   ---------
   New text: (Section 3.2)
   ---------

   01 - Stop processing this SCTP packet and discard it, do not process
        any further chunks within it, and report the unrecognized
        chunk in an 'Unrecognized Chunk Type'.

2.1.3 Solution description

   The receiver of an unrecognized Chunk should not send a 'parameter'
   error but instead the appropriate chunk error as described above.

2.2 Parameter processing issue

2.2.1 Description of the problem

   A typographical error was introduced through an improper cut and
   paste in the use of the upper two bits to describe proper handling of
   unknown parameters.

2.2.2 Text changes to the 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).

   ---------
   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' (in
        either an ERROR or in the INIT ACK).

2.2.3 Solution description

   It was always the intent to stop processing at the level one was at
   in an unknown chunk or parameter with the upper bit set to 0.  Thus
   if you are processing a chunk, you should drop the packet.  If you
   are processing a parameter, you should drop the chunk.

2.3 Padding issues

2.3.1 Description of the problem

   A problem was found in that when a Chunk terminated in a TLV
   parameter.  If this last TLV was not on a 32 bit boundary (as
   required), there was confusion as to if the last padding was included
   in the chunk length.

2.3.2 Text changes to the document

   ---------
   Old text: (Section 3.2)
   ---------
   Chunk Length: 16 bits (unsigned integer)

      This value represents the size of the chunk in bytes including the
      Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
      Therefore, if the Chunk Value field is zero-length, the Length
      field will be set to 4.  The Chunk Length field does not count any
      padding.

   Chunk Value: variable length

      The Chunk Value field contains the actual information to be
      transferred in the chunk.  The usage and format of this field is
      dependent on the Chunk Type.

   The total length of a chunk (including Type, Length and Value fields)
   MUST be a multiple of 4 bytes.  If the length of the chunk is not a
   multiple of 4 bytes, the sender MUST pad the chunk with all zero
   bytes and this padding is not included in the chunk length field.
   The sender should never pad with more than 3 bytes.  The receiver
   MUST ignore the padding bytes.

   ---------
   New text: (Section 3.2)
   ---------

   Chunk Length: 16 bits (unsigned integer)

      This value represents the size of the chunk in bytes including the
      Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
      Therefore, if the Chunk Value field is zero-length, the Length
      field will be set to 4. The Chunk Length field does not count any
      chunk padding.

      Chunks (including Type, Length and Value fields) are padded out by
      the sender with all zero bytes to be a multiple of 4 bytes long.
      This padding MUST NOT be more than 3 bytes in total. The Chunk
      Length value does not include terminating padding of the Chunk.
      However, it does include padding of any variable length parameter
      except the last parameter in the Chunk. The receiver MUST ignore
      the padding.

      Note: A robust implementation should accept the Chunk whether
      or not the final padding has been included in the Chunk Length.

   Chunk Value: variable length

      The Chunk Value field contains the actual information to be
      transferred in the chunk. The usage and format of this field is
      dependent on the Chunk Type.

2.3.3 Solution description

   The above text makes clear that the padding of the last parameter is
   not included in the Chunk Length field.  It also clarifies that the
   padding of parameters that are not the last one must be counted in
   the Chunk Length field.

2.4 Parameter types across all chunk types

2.4.1 Description of the problem

   A problem was noted when multiple errors are needed to be sent
   regarding unknown or unrecognized parameters.  Since often times the
   error type does not hold the chunk type field, it may become
   difficult to tell which error was associated with which chunk.

2.4.2 Text changes to the document

   ---------
   Old text: (Section 3.2.1)
   ---------

   The actual SCTP parameters are defined in the specific SCTP chunk
   sections.  The rules for IETF-defined parameter extensions are
   defined in Section 13.2.

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

   The actual SCTP parameters are defined in the specific SCTP chunk
   sections. The rules for IETF-defined parameter extensions are
   defined in Section 13.2. Note that a parameter type MUST be unique
   across all chunks. For example, the parameter type '5' is used to
   represent an IPv4 address (see section 3.3.2). The value '5' then is
   reserved across all chunks to represent an IPv4 address and MUST NOT
   be reused with a different meaning in any other chunk.

   ---------
   Old text: (Section 13.2)
   ---------

   13.2 IETF-defined Chunk Parameter Extension

   The assignment of new chunk parameter type codes is done through an
   IETF Consensus action as defined in [RFC2434].  Documentation of the
   chunk parameter MUST contain the following information:

   a) Name of the parameter type.

   b) Detailed description of the structure of the parameter field.
      This structure MUST conform to the general type-length-value
      format described in Section 3.2.1.

   c) Detailed definition of each component of the parameter type.

   d) Detailed description of the intended use of this parameter type,
      and an indication of whether and under what circumstances multiple
      instances of this parameter type may be found within the same
      chunk.

   ---------
   New text: (Section 13.2)
   ---------

   13.2 IETF-defined Chunk Parameter Extension

   The assignment of new chunk parameter type codes is done through an
   IETF Consensus action as defined in [RFC2434]. Documentation of the
   chunk parameter MUST contain the following information:

   a) Name of the parameter type.

   b) Detailed description of the structure of the parameter field. This
      structure MUST conform to the general type-length-value format
      described in Section 3.2.1.

   c) Detailed definition of each component of the parameter type.

   d) Detailed description of the intended use of this parameter type,
      and an indication of whether and under what circumstances multiple
      instances of this parameter type may be found within the same
      chunk.

   e) Each parameter type MUST be unique across all chunks.

2.4.3 Solution description

   By having all parameters unique across all chunk assignments (the
   current assignment policy) no ambiguity exists as to what a parameter
   means based on context.  The trade off for this is a smaller
   parameter space i.e.  65,536 parameters versus 65,536 * Number-of-
   chunks.
   Number-of-chunks.

2.5 Stream parameter clarification

2.5.1 Description of the problem

   A problem was found where the specification is unclear on the
   legality of an endpoint asking for more stream resources than were
   allowed in the MIS value of the INIT.  In particular the value in the
   INIT ACK requested in its OS value was larger than the MIS value
   received in the INIT chunk.  This behavior is illegal yet it was
   unspecified in RFC2960 [3] [5]

2.5.2 Text changes to the document

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

   Number of Outbound Streams (OS):  16 bits (unsigned integer)

      Defines the number of outbound streams the sender of this INIT ACK
      chunk wishes to create in this association.  The value of 0 MUST
      NOT be used.

      Note: A receiver of an INIT ACK  with the OS value set to 0 SHOULD
      destroy the association discarding its TCB.

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

   Number of Outbound Streams (OS): 16 bits (unsigned integer)

      Defines the number of outbound streams the sender of this INIT ACK
      chunk wishes to create in this association. The value of 0 MUST
      NOT be used and the value MUST NOT be greater than the MIS value
      sent in the INIT chunk.

      Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
      destroy the association discarding its TCB.

2.5.3 Solution description

   The change in wording, above, changes it so that a responder to an
   INIT chunk does not specify more streams in its OS value than was
   represented to it in the MIS value i.e.  its maximum.

2.6 Restarting association security issue

2.6.1 Description of the problem

   A security problem was found when a restart occurs.  It is possible
   for an intruder to send an INIT to an endpoint of an existing
   association.  In the INIT the intruder would list one or more of the
   current addresses of an association and its own.  The normal restart
   procedures would then occur and the intruder would have hi-jacked an
   association.

2.6.2 Text changes to the 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.

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

   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.11 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 cause added in section 3.3.10)
   ---------

   3.3.10.11 Restart of an association with new addresses (11)

    Cause of error
    --------------
    Restart of an association with new addresses: An INIT was received
    on an existing association. But the INIT added addresses to the
    association that were previously NOT part of the association. The
    New addresses are listed in the error code. This ERROR is normally
    sent as part of an ABORT refusing the INIT (see section 5.2).

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Cause Code=11         |      Cause Length=Variable    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                       New Address TLVs                        /
      \\                                                               \\
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   ---------
   Old text: (Section 5.2.1)
   ---------

   Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an
   endpoint MUST respond with an INIT ACK using the same parameters it
   sent in its original INIT chunk (including its Initiation Tag,
   unchanged).  These original parameters are combined with those from
   the newly received INIT chunk.  The endpoint shall also generate a
   State Cookie with the INIT ACK.  The endpoint uses the parameters
   sent in its INIT to calculate the State Cookie.

   ---------
   New text: (Section 5.2.1)
   ---------

   Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST
   respond with an INIT ACK using the same parameters it sent in its
   original INIT chunk (including its Initiation Tag, unchanged). When
   responding the endpoint MUST send the INIT ACK back to the same
   address that the original INIT (sent by this endpoint) was sent to.

   Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST
   respond with an INIT ACK using the same parameters it sent in its
   original INIT chunk (including its Initiation Tag, unchanged)
   provided that no NEW address have been added to the forming
   association. If the INIT message indicates that a new address(es)
   have been added to the association, then the entire INIT MUST be
   discarded and NO changes should be made to the existing association.
   An ABORT MUST be sent in response that SHOULD include the error
   'Restart of an association with new addresses'. The error SHOULD list
   the addresses that were added to the restarting association.

   When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with
   an INIT ACK the original parameters are combined with those from the
   newly received INIT chunk. The endpoint shall also generate a State
   Cookie with the INIT ACK. The endpoint uses the parameters sent in
   its INIT to calculate the State Cookie.

   ---------
   Old text: (Section 5.2.2)
   ---------
   5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
         COOKIE-WAIT and SHUTDOWN-ACK-SENT

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

   After sending out the INIT ACK, the endpoint shall take no further
   actions, i.e., the existing association, including its current state,
   and the corresponding TCB MUST NOT be changed.

   Note: Only when a TCB exists and the association is not in a COOKIE-
   WAIT state are the Tie-Tags populated.  For a normal association INIT
   (i.e. the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be
   set to 0 (indicating that no previous TCB existed).  The INIT ACK and
   State Cookie are populated as specified in section 5.2.1.

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

   5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
         COOKIE-WAIT and SHUTDOWN-ACK-SENT

   Unless otherwise stated, upon reception of an unexpected INIT for
   this association, the endpoint shall generate an INIT ACK with a
   State Cookie. Before responding the endpoint MUST check to see if the
   unexpected INIT adds new addresses to the association. If new
   addresses are added to the association, the endpoint MUST respond
   with an ABORT copying the 'Initiation Tag' of the unexpected INIT
   into the 'Verification Tag' of the outbound packet carrying the ABORT.
   In the ABORT response the cause of error SHOULD be set to 'restart
   of an association with new addresses'. The error SHOULD list the
   addresses that were added to the restarting association.

   If no new addresses are added, when responding to the INIT in the
   outbound INIT ACK the endpoint MUST copy its current Verification Tag
   and peer's Verification Tag into a reserved place within the state
   cookie. We shall refer to these locations as the Peer's-Tie-Tag and
   the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK
   MUST carry a Verification Tag value equal to the Initiation Tag found
   in the unexpected INIT. And the INIT ACK MUST contain a new
   Initiation Tag (randomly generated see Section 5.3.1). Other
   parameters for the endpoint SHOULD be copied from the existing
   parameters of the association (e.g. number of outbound streams) into
   the INIT ACK and cookie.

   After sending out the INIT ACK or ABORT, the endpoint shall take no
   further actions, i.e., the existing association, including its
   current state, and the corresponding TCB MUST NOT be changed.

   Note: Only when a TCB exists and the association is not in a COOKIE-
   WAIT, COOKIE-ECHOED or SHUTDOWN-ACK-SENT state are the Tie-Tags
   populated with a value other than 0. For a normal association INIT
   (i.e. the endpoint is in the CLOSED state), the Tie-Tags MUST be set
   to 0 (indicating that no previous TCB existed).

2.6.3 Solution description

   A new error code is being added and specific instructions to send
   back an ABORT to a new association in a restart case or collision
   case, where new addresses have been added.  The error code can be
   used by a legitimate restart to inform the endpoint that it has made
   a software error in adding a new address.  The endpoint then can
   choose to wait until the OOTB ABORT tears down the old association,
   or restart without the new address.

   Also the Note at the end of section 5.2.2 explaining the use of the
   Tie-Tags was modified to properly explain the states in which the
   Tie-Tags should be set to a value different than 0.

2.7 Implicit ability to exceed cwnd by PMTU-1 bytes

2.7.1 Description of the problem

   Some implementations were having difficulty growing their cwnd.  This
   was due to an improper enforcement of the congestion control rules.
   The rules, as written, provided for a slop over of the cwnd value.
   Without this slop over the sender would appear to NOT be using its
   full cwnd value and thus never increase it.

2.7.2 Text changes to the document

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

   B) At any given time, the sender MUST NOT transmit new data to a
      given transport address if it has cwnd or more bytes of data
      outstanding to that transport address.

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

   B) At any given time, the sender MUST NOT transmit new data to a
      given transport address if it has cwnd or more bytes of data
      outstanding to that transport address. The sender may exceed cwnd
      by up to (PMTU-1) bytes on a new transmission if the cwnd is not
      currently exceeded.

2.7.3 Solution description

   The text changes make clear the ability to go over the cwnd value by
   no more than (PMTU-1) bytes.

2.8 Issues with Fast Retransmit

2.8.1 Description of the problem

   A problem was

   Several problems were found in the current specification of fast
   retransmit.
   In particular in a high bandwidth * delay network.  The current wording did not require GAP ACK blocks to be
   sent, even though they are essential to the workings of SCTP's
   congestion control.  Also the  The specification left unclear how to handle the
   fast retransmit cycle, having the implementation to wait on the cwnd
   to retransmit a TSN that was marked for fast retransmit.  Also no  No limit
   was placed on how many times a TSN could be fast retransmitted.  Fast
   Recovery was not specified, causing the congestion window to be
   reduced drastically when there are multiple losses in a single RTT.

2.8.2 Text changes to the document

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

   Acknowledgments MUST be sent in SACK chunks unless shutdown was
   requested by the ULP in which case an endpoint MAY send an
   acknowledgment in the SHUTDOWN chunk.  A SACK chunk can acknowledge
   the reception of multiple DATA chunks.  See Section 3.3.4 for SACK
   chunk format.  In particular, the SCTP endpoint MUST fill in the
   Cumulative TSN Ack field to indicate the latest sequential TSN (of a
   valid DATA chunk) it has received.  Any received DATA chunks with TSN
   greater than the value in the Cumulative TSN Ack field SHOULD also be
   reported in the Gap Ack Block fields.

   ---------
   New text: (Section 6.2)
   ---------

   Acknowledgments MUST be sent in SACK chunks unless shutdown was
   requested by the ULP in which case an endpoint MAY send an
   acknowledgment in the SHUTDOWN chunk. A SACK chunk can acknowledge
   the reception of multiple DATA chunks. See Section 3.3.4 for SACK
   chunk format. In particular, the SCTP endpoint MUST fill in the
   Cumulative TSN Ack field to indicate the latest sequential TSN (of a
   valid DATA chunk) it has received. Any received DATA chunks with
   TSN greater than the value in the Cumulative TSN Ack field MUST also be are reported
   in the Gap Ack Block fields. The SCTP endpoint MUST report as many
   Gap Ack Blocks that can fit in a single SACK chunk limited by the
   current path MTU.

   ---------
   Old text: (Section 7.2.4)
   ---------

   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.

   When the TSN(s) is reported as missing in the fourth consecutive
   SACK, the data sender shall:

   1) Mark the missing DATA chunk(s) for retransmission,

   2) Adjust the ssthresh and cwnd of the destination address(es) to
      which the missing DATA chunks were last sent, according to the
      formula described in Section 7.2.3.

   3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
      marked for retransmission will fit into a single packet, subject
      to constraint of the path MTU of the destination transport address
      to which the packet is being sent.  Call this value K. Retransmit
      those K DATA chunks in a single packet.

   4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
      outstanding TSN number sent to that address, or the endpoint is
      retransmitting the first outstanding DATA chunk sent to that
      address.

   Note: Before the above adjustments, if the received SACK also
   acknowledges new DATA chunks and advances the Cumulative TSN Ack
   Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
   must be applied first.

   A straightforward implementation of the above keeps a counter for
   each TSN hole reported by a SACK. The counter increments for each
   consecutive SACK reporting the TSN hole.  After reaching 4 and
   starting the fast retransmit procedure, the counter resets to 0.
   Because cwnd in SCTP indirectly bounds the number of outstanding
   TSN's, the effect of TCP fast-recovery is achieved automatically with
   no adjustment to the congestion control window size.

   ---------
   New text: (Section 7.2.4)
   ---------

   When

   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.

   Miss indications SHOULD follow the HTNA (Highest TSN Newly Acknowledged)
   algorithm. For each incoming SACK, miss indications are incremented only
   for missing TSNs prior to the highest TSN newly acknowledged in the
   SACK. A newly acknowledged DATA chunk is one not previously acknowledged
   in a SACK.  If an endpoint is in Fast Recovery and a SACK arrives that
   advances the Cumulative TSN Ack Point, the miss indications are
   incremented for all TSNs reported as missing in the SACK.

   When the fourth consecutive
   SACK, miss indication is recieved for a TSN(s), the
   data sender shall:

   1) Mark the missing DATA chunk(s) with four miss indications for retransmission as described
      below in M1-M3, retransmission.

   2) Adjust If not in Fast Recovery, adjust the ssthresh and cwnd of the
      destination address(es) to which the missing DATA chunks were last
      sent, according to the formula described in Section 7.2.3.

   3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks
      marked for retransmission will fit into a single packet, subject
      to constraint of the path MTU of the destination transport address
      to which the packet is being sent. Call this value K. Retransmit
      those K DATA chunks in a single packet. When a Fast Retransmit is
      being performed the sender SHOULD ignore the value of cwnd and
      SHOULD NOT delay retransmission. retransmission for this single packet.

   4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
      outstanding TSN number sent to that address, or the endpoint is
      retransmitting the first outstanding DATA chunk sent to that
      address.

   5) Mark the DATA chunk(s) as being fast retransmitted and thus
      ineligible for a subsequent fast retransmit. Those TSNs marked
      for retransmission due to the Fast Retransmit algorithm that
      did not fit in the sent datagram carrying K other TSNs are also
      marked as ineligible for a subsequent fast retransmit. However,
      as they are marked for retransmission they will be retransmitted
      later on as soon as cwnd allows.

   6) If not in Fast Recovery, enter Fast Recovery and mark the highest
      outstanding TSN as the Fast Recovery exit point. When a SACK
      acknowledges all TSNs up to and including this exit point, Fast
      Recovery is exited. While in Fast Recovery, the ssthresh and cwnd
      SHOULD NOT change for any destinations.

   Note: Before the above adjustments, if the received SACK also
   acknowledges new DATA chunks and advances the Cumulative TSN Ack
   Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2
   must be applied first.

   A straightforward implementation

2.8.3 Solution description

   The effect of the above is as follows:

   M1) Each time a new DATA chunk is transmitted set the
       'TSN.Missing.Report' count for that TSN to 0. The
       'TSN.Missing.Report' count will be used to determine missing
       chunks and when to fast retransmit.

   M2) Each time a SACK arrives reporting 'Stray DATA chunk(s)' record
       the highest TSN reported as newly acknowledged, call this
       value 'HighestTSNinSack'. A newly acknowledged DATA chunk is one
       not previously acknowledged in a SACK.

       When the SCTP sender of data receives a SACK chunk that
       acknowledges, for the first time, the receipt of a DATA chunk,
       all the still unacknowledged DATA chunks whose TSN is older than
       that newly acknowledged DATA chunk, are qualified as
       'Stray DATA chunks'.

   M3) Examine all 'Unacknowledged TSN's', if the TSN number of an
       'Unacknowledged TSN' is smaller than the 'HighestTSNinSack'
       value, increment the 'TSN.Missing.Report' count on that chunk if
       it has NOT been fast retransmitted or marked for fast retransmit
       already.

   M4) If any DATA chunk is found to have a 'TSN.Missing.Report' value
       larger than or equal to 4, mark that chunk for retransmission and
       start the fast retransmit procedure (steps 2-5 above).

   M5) If a T3-rtx timer expires, the 'TSN.Missing.Report' of all
       affected TSNs is set to 0.

   Because cwnd in SCTP indirectly bounds the number of outstanding
   TSN's, the effect of TCP fast-recovery is achieved automatically with
   no adjustment to the congestion control window size.

2.8.3 Solution description

   The effect of the above wording changes are wording changes are as follows:

   o  It requires with a MUST the sending of GAP Ack blocks instead of
      the current RFC2960 [3] [5] SHOULD.

   o  It allows a TSN being Fast Retransmitted (FR) to be sent only once
      via FR.

   o  It ends the delay in awaiting for the flight size to drop when a
      TSN is identified ready to FR.

   o  It changes the way chunks are marked during fast retransmit, so
      that only new reports are counted (using M1-M4 above). counted.

   o  It introduces a Fast Recovery period to avoid multiple congestion
      window reductions when there are multiple losses in a single RTT
      (as shown by Caro et al.  [3]).

   These changes will effectively allow SCTP to follow a similar model
   as TCP+SACK in the handling of Fast Retransmit.

2.9 Missing statement about partial_bytes_acked update

2.9.1 Description of the problem

   SCTP uses four control variables to regulate its transmission rate:
   rwnd, cwnd, ssthresh and partial_bytes_acked.  Upon detection of
   packet losses from SACK or when the T3-rtx timer expires on an
   address cwnd and ssthresh should be updated as stated in section
   7.2.3.  However, that section should also clarify that
   partial_bytes_acked must be updated as well, having to be reset to 0.

2.9.2 Text changes to the document

   ---------
   Old text: (Section 7.2.3)
   ---------

   7.2.3 Congestion Control

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

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

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

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

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

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

   7.2.3 Congestion Control

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

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

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

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

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

2.9.3 Solution description

   The missing text added solves the doubts about what to do with
   partial_bytes_acked in the situations stated in section 7.2.3, making
   clear that along with ssthresh and cwnd, partial_bytes_acked should
   also be updated, having to be reset to 0.

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 un-specific as to when you start
      sending heartbeats and when you should stop.

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

   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.

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

      ---------
      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 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). 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
      (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, 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% 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, how to
   respond to a heartbeat with extra parameters, and 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 to 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.

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

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

   [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 adding a new subsection to the Security Considerations
   section of RFC2960 [3] [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, being this rule enforced by the packet
   receiver, that will silently discard the packets that do not follow
   this rule.

2.12 Shutdown ambiguity

2.12.1 Description of the problem

   Currently there is an ambiguity between the statements in section 6.2
   and section 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 both a SHUTDOWN chunk and a SACK
   chunk to be sent.

   Along with this ambiguity there is a problem where in 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.

   ---------
   New 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 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 TSN's that can be acknowledged that are larger
   than the cumulative TSN and thus gaps exist in the TSN sequence) or
   if duplicate TSN's have been recieved 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 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.

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.

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 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 of a ABORT 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.

2.13.3 Solution description

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

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 under utilization, 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 MUST first be applied to limit how many
      new DATA chunks may be sent.  The limit is applied by adjusting cwnd
      as follows:

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

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

   ---------
   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 and utilized, an incoming SACK advances
      the Cumulative TSN Ack Point. Point, and the data sender is not in Fast
      Recovery. Only when these two 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 protects against the
      ACK-Splitting attack outlined in [SAVAGE99].

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

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

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

   o  When the association does not transmit data on a given transport address
      within an RTO, the cwnd of the transport address MUST SHOULD be adjusted to
      2*MTU.

   ---------
   Old text: (Section 7.2.2)
   ---------

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

   ---------
   New text: (Section 7.2.2)
   ---------

   o  Same as in the slow start, when the sender does not transmit DATA on
      a given transport address within an RTO, the cwnd of the transport
      address should be adjusted to 2*MTU.

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

   ---------
   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 strengthens the rules and makes it much more
   apparent as to the need to block cwnd growth when the full cwnd is
   not being utilized.  The changes also applies 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 reception of each valid
   DATA chunk.

   ---------
   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
   all new incoming DATA chunk and immediately send back a SACK with
   the current receive window showing only DATA chunks received and
   accepted so far.  The dropped DATA chunk 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.
   Because of receiver SWS avoidance, even when the receiver's internal
   buffer is not full anymore, as long as the advertised window is
   still 0, the receiver MUST still drop all new incoming DATA chunk.

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

   ---------
   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 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 zero window probe SHOULD only be sent
      when all outstanding DATA chunks have been cumulatively acknowledged
      and no DATA chunk(s) are in flight.  Zero window probing MUST
      be supported.

      When a sender is doing zero window probing, it should not time
      out the association if it continues to receive new packets from
      the receiver.  The reason is that 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 algorithm in 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.

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 RFC2960 [3] [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
   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.

   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 peers Initial TSN minus
      one.

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

   D) When searching for a matching TCB upon reception of an INIT
      or INIT-ACK chunk the receiver SHOULD use not only the
      source address of the packet (containing the INIT or
      INIT-ACK) but the receiver SHOULD also use all valid
      address parameters contained within the chunk.

2.18.3 Solution description

   This new text clearly specifies to an implementor the need to look
   within the INIT or INIT-ACK. INIT ACK.  Any implementation that does not do
   this, may for example not be able to establish associations in certain
   circumstances. 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 to 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.

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

   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 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 places it into the users 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 message nor reception of these
   message.  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  Acknowledgment on Reception of DATA Chunks

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

   (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  Acknowledgment on Reception 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 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 Section 2.6 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.

   ---------
   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 which are send
    because of an upper layer request. The upper layer can specify
    an Upper Layer Abort Reason which is transported by SCTP
    transparently and MAY be delivered to the upper layer protocol
    at the peer.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         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 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. If the association is aborted
      on request of the upper layer an 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 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. If an User Initiated Abort error
      cause is present in the ABORT chunk the Upper Layer Abort Reason
      shall 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.

      None.

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

      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

      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;

      o  Upper Layer Abort Reason - the abort reason specified if case of an user
                                    initiated abort.

2.21.3 Solution description

   The above allows an upper layer to provide its peer with an
   indication 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 so 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.

         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 the receiver of the invalid INIT-ACK to
   send the ABORT.  This behavior is in tune with the error case of
   invalid stream numbers in the INIT-ACK.  However it is allowed to
   send an ABORT for debugging purposes.

2.23 ABORT sending 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,

   ---------
   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 can not 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 1 indicating that
         no
         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 have to initialized
   to 0 in he way it is required by RFC2119.

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 shall MUST
      be set to 0.

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 or not.

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 a SCTP endpoints detects that the peer
   violates the protocol.  Therefore the association has to be aborted.
   Currently there are only some error causes which could be used to
   indicate the reason of the abort but these do not cover all cases.

2.26.2 Text changes to the document

   Some of the changes given here already include changes suggested in
   section Section 2.6 and Section 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.

   ---------
   New text: (Section 3.2.10) 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 which are send
    because a SCTP endpoint detects a protocol violation of the peer
    which 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.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Cause Code=13         |      Cause Length=Variable    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                    Additional Information                     /
      \\                                                              \\
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.26.3 Solution description

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

2.27 Reporting of Unrecognized Parameters

2.27.1 Description of the problem

   It is not stated clearly in RFC2960 [3] [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
   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 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).

   ---------
   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 Parameters' error cause
      with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk.
      If the receiver of the INIT-ACK can not 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.

2.28 Handling of IP Address Parameters

2.28.1 Description of the problem

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

2.28.2 Text changes to the document

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

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

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

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

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

2.28.3 Solution description

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

2.29 Handling of  COOKIE ECHO chunks when a TCB exists

2.29.1 Description of the problem

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

2.29.2 Text changes to the document

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

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

2.29.3 Solution description

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

3. Acknowledgments

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

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

   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.

References

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

   [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.cis.udel.edu/~acaro/publications>.

   [4]  Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window
        Validation", RFC 2861, June 2000.

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

Authors' Addresses

   Randall R. Stewart
   Cisco Systems, Inc.
   8725 West Higgins Road
   Suite 300
   Chicago, IL  60631
   USA

   Phone:
   EMail: rrs@cisco.com

   Lyndon Ong
   Ciena Systems
   10480 Ridgeview Ct
   Cupertino, CA  95014
   USA

   Phone:
   EMail: lyong@ciena.com
   Ivan Arias-Rodriguez
   Nokia Research Center
   PO Box 407
   FIN-00045 Nokia Group
   Finland

   Phone:
   EMail: ivan.arias-rodriguez@nokia.com

   Kacheong Poon
   Sun Microsysystems, Inc.
   901 San Antonio Road
   Palo Alto,
   Consultant

   Milpitas, CA  94303
   USA

   Phone:
   EMail: kacheong.poon@sun.com kcpoon@yahoo.com

   Phillip T. Conrad
   Temple University
   CIS Department
   Room 303, Computer Building (038-24)
   1805 N. Broad St.
   Philadelphia, PA  19122
   US

   Phone: +1 215 204 7910
   EMail: conrad@acm.org
   URI:   http://www.cis.temple.edu/~conrad

   Armando L. Caro Jr.
   University of Delaware
   Department of Computer & Information Sciences University of Delaware
   103 Smith Hall
   Newark, DE  19716
   USA

   Phone:
   EMail: acaro@cis.udel.edu
   URI:   http://www.cis.udel.edu/~acaro
   Michael Tuexen
   Siemens AG
   ICN WN CC SE 7
   D-81359 Munich

   Germany

   Phone:
   EMail: Michael.Tuexen@siemens.com tuexen@fh-muenster.de

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2002). (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns. assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.