3.36.  Inconsistent Handling of ICMPv4 and ICMPv6 Messages

3.36.1.  Description of the Problem

   Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6
   messages.  The handling of ICMP messages indicating that the port
   number is unreachable, as described in the enumerated procedures, is
   not consistent with the description given in [RFC4960] after the
   procedures.  Furthermore, the text explicitly describes the handling
   of ICMPv6 packets indicating reachability problems but does not do
   the same for the corresponding ICMPv4 packets.

3.36.2.  Text Changes to the Document

   ---------
   Old text: (Appendix C)
   ---------

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

   ---------
   New text: (Appendix C)
   ---------

   ICMP3) An implementation SHOULD ignore any ICMP messages where the
          code indicates "Port Unreachable".

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Appendix C)
   ---------

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

   ---------
   New text: (Appendix C)
   ---------

   ICMP9) If the ICMP type is "Destination Unreachable", the
          implementation MAY move the destination to the unreachable
          state or, alternatively, increment the path error counter.

   This text has been modified by multiple errata.  It is further
   updated in Section 3.37.

3.36.3.  Solution Description

   The text has been changed to describe the intended handling of ICMP
   messages indicating that the port number is unreachable by replacing
   the third rule.  Also, the limitation to ICMPv6 in the ninth rule has
   been removed.

3.37.  Handling of Soft Errors

3.37.1.  Description of the Problem

   [RFC1122] defines the handling of soft errors and hard errors for
   TCP.  Appendix C of [RFC4960] only deals with hard errors.

3.37.2.  Text Changes to the Document

   ---------
   Old text: (Appendix C)
   ---------

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

   ---------
   New text: (Appendix C)
   ---------

   ICMP9) If the ICMP type is "Destination Unreachable", the
          implementation MAY move the destination to the unreachable
          state or, alternatively, increment the path error counter.
          SCTP MAY provide information to the upper layer indicating
          the reception of ICMP messages when reporting a network status
          change.

   This text has been modified by multiple errata.  It includes
   modifications from Section 3.36.  It is in final form and is not
   further updated in this document.

3.37.3.  Solution Description

   Text has been added allowing SCTP to notify the application in the
   case of soft errors.

3.38.  Honoring cwnd

3.38.1.  Description of the Problem

   When using the slow start algorithm, SCTP increases the congestion
   window only when it is being fully utilized.  Since SCTP uses DATA
   chunks and does not use the congestion window to fragment user
   messages, this requires that some overbooking of the congestion
   window be allowed.

3.38.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 + (PMTU - 1) or more bytes
      of data outstanding to that transport address.  If data is
      available, the sender SHOULD exceed cwnd by up to (PMTU - 1) bytes
      on a new data transmission if the flightsize does not currently
      reach cwnd.  The breach of cwnd MUST constitute one packet only.

   This text is in final form and is not further updated in this
   document.

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

   o  Whenever cwnd is greater than zero, the endpoint is allowed to
      have cwnd bytes of data outstanding on that transport address.

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

   o  Whenever cwnd is greater than zero, the endpoint is allowed to
      have cwnd bytes of data outstanding on that transport address.  A
      limited overbooking as described in Section 6.1 B) SHOULD be
      supported.

   This text is in final form and is not further updated in this
   document.

3.38.3.  Solution Description

   Text was added to clarify how the cwnd limit should be handled.

3.39.  Zero Window Probing

3.39.1.  Description of the Problem

   The text in Section 6.1 of [RFC4960] that describes zero window
   probing does not clearly address the case where the window is not
   zero but is too small for the next DATA chunk to be transmitted.
   Even in this case, zero window probing has to be performed to avoid
   deadlocks.

3.39.2.  Text Changes to the Document

   ---------
   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's having been lost in transit from the data
      receiver to the data sender.

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

   ---------
   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 smaller than the
      size of the next DATA chunk; see Section 6.2.1).  However,
      regardless of the value of rwnd (including if it is 0), the data
      sender can always have one DATA chunk in flight to the receiver
      if allowed by cwnd (see rule B, below).  This rule allows the
      sender to probe for a change in rwnd that the sender missed
      due to the SACK's having been lost in transit from the data
      receiver to the data sender.

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

   This text is in final form and is not further updated in this
   document.

3.39.3.  Solution Description

   The terminology is used in a cleaner way.

3.40.  Updating References regarding ECN

3.40.1.  Description of the Problem

   For Explicit Congestion Notification (ECN), [RFC4960] refers only to
   [RFC3168], which has been updated by [RFC8311].  This needs to be
   reflected in the text when referring to ECN.

3.40.2.  Text Changes to the Document

   ---------
   Old text: (Appendix A)
   ---------

   ECN [RFC3168] describes a proposed extension to IP that details a
   method to become aware of congestion outside of datagram loss.

   ---------
   New text: (Appendix A)
   ---------

   ECN as specified in [RFC3168] (updated by [RFC8311]) describes an
   extension to IP that details a method for becoming aware of
   congestion outside of datagram loss.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Appendix A)
   ---------

   In general, [RFC3168] should be followed with the following
   exceptions.

   ---------
   New text: (Appendix A)
   ---------

   In general, [RFC3168] (updated by [RFC8311]) SHOULD be followed, with
   the following exceptions.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Appendix A)
   ---------

   [RFC3168] details negotiation of ECN during the SYN and SYN-ACK
   stages of a TCP connection.

   ---------
   New text: (Appendix A)
   ---------

   [RFC3168] (updated by [RFC8311]) details the negotiation of ECN
   during the SYN and SYN-ACK stages of a TCP connection.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Appendix A)
   ---------

   [RFC3168] details a specific bit for a receiver to send back in its
   TCP acknowledgements to notify the sender of the Congestion
   Experienced (CE) bit having arrived from the network.

   ---------
   New text: (Appendix A)
   ---------

   [RFC3168] (updated by [RFC8311]) details a specific bit for a
   receiver to send back in its TCP acknowledgements to notify the
   sender of the Congestion Experienced (CE) bit that the CE bit has
   arrived from the network.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Appendix A)
   ---------

   [RFC3168] details a specific bit for a sender to send in the header
   of its next outbound TCP segment to indicate to its peer that it has
   reduced its congestion window.

   ---------
   New text: (Appendix A)
   ---------

   [RFC3168] (updated by [RFC8311]) details a specific bit for a sender
   to send in the header of its next outbound TCP segment to indicate to
   its peer that it has reduced its congestion window.

   This text is in final form and is not further updated in this
   document.

3.40.3.  Solution Description

   References to [RFC8311] have been added.  Some wordsmithing was also
   done while making those updates.

3.41.  Host Name Address Parameter Deprecated

3.41.1.  Description of the Problem

   [RFC4960] defines three types of address parameters to be used with
   INIT and INIT ACK chunks:

   1.  IPv4 Address parameters.

   2.  IPv6 Address parameters.

   3.  Host Name Address parameters.

   The first two parameter types are supported by the SCTP kernel
   implementations of FreeBSD, Linux, and Solaris, but the third is not.
   In addition, the first two were successfully tested in all nine
   interoperability tests for SCTP, but the third has never been
   successfully tested.  Therefore, the Host Name Address parameter
   should be deprecated.

3.41.2.  Text Changes to the Document

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

   Note 3: An INIT chunk MUST NOT contain more than one Host Name
   Address parameter.  Moreover, the sender of the INIT MUST NOT combine
   any other address types with the Host Name Address in the INIT.  The
   receiver of INIT MUST ignore any other address types if the Host Name
   Address parameter is present in the received INIT chunk.

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

   Note 3: An INIT chunk MUST NOT contain the Host Name Address
   parameter.  The receiver of an INIT chunk containing a Host Name
   Address parameter MUST send an ABORT and MAY include an "Unresolvable
   Address" error cause.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Section 3.3.2.1)
   ---------

   The sender of INIT uses this parameter to pass its Host Name (in
   place of its IP addresses) to its peer.  The peer is responsible for
   resolving the name.  Using this parameter might make it more likely
   for the association to work across a NAT box.

   ---------
   New text: (Section 3.3.2.1)
   ---------

   The sender of an INIT chunk MUST NOT include this parameter.  The
   usage of the Host Name Address parameter is deprecated.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Section 3.3.2.1)
   ---------

   Address Type: 16 bits (unsigned integer)

      This is filled with the type value of the corresponding address
      TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11).

   ---------
   New text: (Section 3.3.2.1)
   ---------

   Address Type: 16 bits (unsigned integer)

      This is filled with the type value of the corresponding address
      TLV (e.g., IPv4 = 5, IPv6 = 6).  The value indicating the Host
      Name Address parameter (Host name = 11) MUST NOT be used.

   This text is in final form and is not further updated in this
   document.

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

   Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name
   Address parameter.  Moreover, the sender of the INIT ACK MUST NOT
   combine any other address types with the Host Name Address in the
   INIT ACK.  The receiver of the INIT ACK MUST ignore any other address
   types if the Host Name Address parameter is present.

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

   Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address
   parameter.  The receiver of INIT ACK chunks containing a Host Name
   Address parameter MUST send an ABORT and MAY include an "Unresolvable
   Address" error cause.

   This text is in final form and is not further updated in this
   document.

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

   B) If there is a Host Name parameter present in the received INIT or
      INIT ACK chunk, the endpoint shall resolve that host name to a
      list of IP address(es) and derive the transport address(es) of
      this peer by combining the resolved IP address(es) with the SCTP
      source port.

      The endpoint MUST ignore any other IP Address parameters if they
      are also present in the received INIT or INIT ACK chunk.

      The time at which the receiver of an INIT resolves the host name
      has potential security implications to SCTP.  If the receiver of
      an INIT resolves the host name upon the reception of the chunk,
      and the mechanism the receiver uses to resolve the host name
      involves potential long delay (e.g., DNS query), the receiver may
      open itself up to resource attacks for the period of time while it
      is waiting for the name resolution results before it can build the
      State Cookie and release local resources.

      Therefore, in cases where the name translation involves potential
      long delay, the receiver of the INIT MUST postpone the name
      resolution till the reception of the COOKIE ECHO chunk from the
      peer.  In such a case, the receiver of the INIT SHOULD build the
      State Cookie using the received Host Name (instead of destination
      transport addresses) and send the INIT ACK to the source IP
      address from which the INIT was received.

      The receiver of an INIT ACK shall always immediately attempt to
      resolve the name upon the reception of the chunk.

      The receiver of the INIT or INIT ACK MUST NOT send user data
      (piggy-backed or stand-alone) to its peer until the host name is
      successfully resolved.

      If the name resolution is not successful, the endpoint MUST
      immediately send an ABORT with "Unresolvable Address" error cause
      to its peer.  The ABORT shall be sent to the source IP address
      from which the last peer packet was received.

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

   B) If there is a Host Name Address parameter present in the received
      INIT or INIT ACK chunk, the endpoint MUST immediately send an
      ABORT and MAY include an "Unresolvable Address" error cause
      to its peer.  The ABORT SHALL be sent to the source
      IP address from which the last peer packet was received.

   This text is in final form and is not further updated in this
   document.

   ---------
   Old text: (Section 11.2.4.1)
   ---------

   The use of the host name feature in the INIT chunk could be used to
   flood a target DNS server.  A large backlog of DNS queries, resolving
   the host name received in the INIT chunk to IP addresses, could be
   accomplished by sending INITs to multiple hosts in a given domain.
   In addition, an attacker could use the host name feature in an
   indirect attack on a third party by sending large numbers of INITs to
   random hosts containing the host name of the target.  In addition to
   the strain on DNS resources, this could also result in large numbers
   of INIT ACKs being sent to the target.  One method to protect against
   this type of attack is to verify that the IP addresses received from
   DNS include the source IP address of the original INIT.  If the list
   of IP addresses received from DNS does not include the source IP
   address of the INIT, the endpoint MAY silently discard the INIT.
   This last option will not protect against the attack against the DNS.

   ---------
   New text: (Section 11.2.4.1)
   ---------

   Support for the Host Name Address parameter has been removed from the
   protocol.  Endpoints receiving INIT or INIT ACK chunks containing the
   Host Name Address parameter MUST send an ABORT chunk in response and
   MAY include an "Unresolvable Address" error cause.

   This text is in final form and is not further updated in this
   document.

3.41.3.  Solution Description

   The usage of the Host Name Address parameter has been deprecated.

3.42.  Conflicting Text regarding the 'Supported Address Types'
       Parameter

3.42.1.  Description of the Problem

   Section 5.1.2 of [RFC4960] contains conflicting text regarding the
   receipt of an SCTP packet containing an INIT chunk sent from an
   address for which the corresponding address type is not listed in the
   'Supported Address Types' parameter.  The text states that the
   association MUST be aborted, but it also states that the association
   SHOULD be established and there SHOULD NOT be any error indication.

3.42.2.  Text Changes to the Document

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

   The sender of INIT may include a 'Supported Address Types' parameter
   in the INIT to indicate what types of address are acceptable.  When
   this parameter is present, the receiver of INIT (initiate) MUST
   either use one of the address types indicated in the Supported
   Address Types parameter when responding to the INIT, or abort the
   association with an "Unresolvable Address" error cause if it is
   unwilling or incapable of using any of the address types indicated by
   its peer.

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

   The sender of INIT chunks MAY include a 'Supported Address Types'
   parameter in the INIT to indicate what types of addresses are
   acceptable.

   This text is in final form and is not further updated in this
   document.

3.42.3.  Solution Description

   The conflicting text has been removed.

3.43.  Integration of RFC 6096

3.43.1.  Description of the Problem

   [RFC6096] updates [RFC4960] by adding the "Chunk Flags" registry.
   This should be integrated into the base specification.

3.43.2.  Text Changes to the Document

   ---------
   Old text: (Section 14.1)
   ---------

   14.1.  IETF-Defined Chunk 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) A long and short name for the new chunk type.

      b) A detailed description of the structure of the chunk, which
         MUST conform to the basic structure defined in Section 3.2.

      c) A detailed definition and description of the intended use of
         each field within the chunk, including the chunk flags if any.

      d) A detailed procedural description of the use of the new chunk
         type within the operation of the protocol.

      The last chunk type (255) is reserved for future extension if
      necessary.

   ---------
   New text: (Section 14.1)
   ---------

   14.1.  IETF-Defined Chunk Extension

      The assignment of new chunk type codes is done through an IETF
      Review action, as defined in [RFC8126].  Documentation for a new
      chunk MUST contain the following information:

      a)  A long and short name for the new chunk type.

      b)  A detailed description of the structure of the chunk, which
          MUST conform to the basic structure defined in Section 3.2.

      c)  A detailed definition and description of the intended use of
          each field within the chunk, including the chunk flags
          (if any).  Defined chunk flags will be used as initial entries
          in the chunk flags table for the new chunk type.

      d)  A detailed procedural description of the use of the new chunk
          type within the operation of the protocol.

      The last chunk type (255) is reserved for future extension if
      necessary.

      For each new chunk type, IANA creates a registration table for the
      chunk flags of that type.  The procedure for registering
      particular chunk flags is described in Section 14.2.

   This text has been modified by multiple errata.  It includes
   modifications from Section 3.3.  It is in final form and is not
   further updated in this document.

   ---------
   New text: (Section 14.2)
   ---------

   14.2.  New IETF Chunk Flags Registration

      The assignment of new chunk flags is done through an RFC Required
      action, as defined in [RFC8126].  Documentation for the chunk
      flags MUST contain the following information:

      a)  A name for the new chunk flag.

      b)  A detailed procedural description of the use of the new chunk
          flag within the operation of the protocol.  It MUST be
          considered that implementations not supporting the flag will
          send '0' on transmit and just ignore it on receipt.

      IANA selects a chunk flags value.  This MUST be one of 0x01, 0x02,
      0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within
      the chunk flag values for the specific chunk type.

   This text is in final form and is not further updated in this
   document.

   Please note that Sections 14.2, 14.3, 14.4, and 14.5 as shown in
   [RFC4960] will need to be renumbered when [RFC4960] is updated.

3.43.3.  Solution Description

   [RFC6096] has been integrated, and the reference has been updated to
   [RFC8126].