draft-ietf-tsvwg-sctpimpguide-13.txt   draft-ietf-tsvwg-sctpimpguide-14.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: August 25, 2005 I. Arias-Rodriguez Expires: December 5, 2005 I. Arias-Rodriguez
Nokia Research Center Nokia Research Center
K. Poon K. Poon
Sun Microsystems, Inc. Sun Microsystems, Inc.
A. Caro A. Caro
University of Delaware University of Delaware
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
February 21, 2005 June 3, 2005
Stream Control Transmission Protocol (SCTP) Implementer's Guide Stream Control Transmission Protocol (SCTP) Implementer's Guide
draft-ietf-tsvwg-sctpimpguide-13.txt draft-ietf-tsvwg-sctpimpguide-14.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims
which he or she is aware have been or will be disclosed, and any of of which he or she is aware have been or will be disclosed, and
which he or she become aware will be disclosed, in accordance with any of which he or she becomes aware will be disclosed, in accordance
RFC 3668. with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 25, 2005. This Internet-Draft will expire on December 5, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
the publishing of this document for the Stream Control Transmission the publishing of this document for the Stream Control Transmission
Protocol (SCTP) RFC2960 [6]. These defects may be of an editorial or Protocol (SCTP) RFC2960 [6]. These defects may be of an editorial or
technical nature. This document may be thought of as a companion technical nature. This document may be thought of as a companion
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2. Corrections to RFC2960 . . . . . . . . . . . . . . . . . . . 5 2. Corrections to RFC2960 . . . . . . . . . . . . . . . . . . . 5
2.1 Incorrect error type during chunk processing. . . . . . . 5 2.1 Incorrect error type during chunk processing. . . . . . . 5
2.2 Parameter processing issue . . . . . . . . . . . . . . . . 5 2.2 Parameter processing issue . . . . . . . . . . . . . . . . 5
2.3 Padding issues . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Padding issues . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Parameter types across all chunk types . . . . . . . . . . 8 2.4 Parameter types across all chunk types . . . . . . . . . . 8
2.5 Stream parameter clarification . . . . . . . . . . . . . . 10 2.5 Stream parameter clarification . . . . . . . . . . . . . . 10
2.6 Restarting association security issue . . . . . . . . . . 11 2.6 Restarting association security issue . . . . . . . . . . 11
2.7 Implicit ability to exceed cwnd by PMTU-1 bytes . . . . . 15 2.7 Implicit ability to exceed cwnd by PMTU-1 bytes . . . . . 15
2.8 Issues with Fast Retransmit . . . . . . . . . . . . . . . 16 2.8 Issues with Fast Retransmit . . . . . . . . . . . . . . . 16
2.9 Missing statement about partial_bytes_acked update . . . . 21 2.9 Missing statement about partial_bytes_acked update . . . . 21
2.10 Issues with Heartbeating and failure detection . . . . . 22 2.10 Issues with Heartbeating and failure detection . . . . . 23
2.11 Security interactions with firewalls . . . . . . . . . . 25 2.11 Security interactions with firewalls . . . . . . . . . . 26
2.12 Shutdown ambiguity . . . . . . . . . . . . . . . . . . . 27 2.12 Shutdown ambiguity . . . . . . . . . . . . . . . . . . . 28
2.13 Inconsistency in ABORT processing . . . . . . . . . . . 29 2.13 Inconsistency in ABORT processing . . . . . . . . . . . 30
2.14 Cwnd gated by its full use . . . . . . . . . . . . . . . 30 2.14 Cwnd gated by its full use . . . . . . . . . . . . . . . 31
2.15 Window probes in SCTP . . . . . . . . . . . . . . . . . 33 2.15 Window probes in SCTP . . . . . . . . . . . . . . . . . 34
2.16 Fragmentation and Path MTU issues . . . . . . . . . . . 35 2.16 Fragmentation and Path MTU issues . . . . . . . . . . . 36
2.17 Initial value of the cumulative TSN Ack . . . . . . . . 36 2.17 Initial value of the cumulative TSN Ack . . . . . . . . 38
2.18 Handling of address parameters within the INIT or 2.18 Handling of address parameters within the INIT or
INIT-ACK . . . . . . . . . . . . . . . . . . . . . . . . 37 INIT-ACK . . . . . . . . . . . . . . . . . . . . . . . . 38
2.19 Handling of stream shortages . . . . . . . . . . . . . . 39 2.19 Handling of stream shortages . . . . . . . . . . . . . . 40
2.20 Indefinite postponement . . . . . . . . . . . . . . . . 40 2.20 Indefinite postponement . . . . . . . . . . . . . . . . 42
2.21 User initiated abort of an association . . . . . . . . . 41 2.21 User initiated abort of an association . . . . . . . . . 43
2.22 Handling of invalid Initiate Tag of INIT-ACK . . . . . . 47 2.22 Handling of invalid Initiate Tag of INIT-ACK . . . . . . 48
2.23 ABORT sending in response to an INIT . . . . . . . . . . 48 2.23 ABORT sending in response to an INIT . . . . . . . . . . 50
2.24 Stream Sequence Number (SSN) Initialization . . . . . . 49 2.24 Stream Sequence Number (SSN) Initialization . . . . . . 50
2.25 SACK packet format . . . . . . . . . . . . . . . . . . . 50 2.25 SACK packet format . . . . . . . . . . . . . . . . . . . 51
2.26 Protocol Violation Error Cause . . . . . . . . . . . . . 51 2.26 Protocol Violation Error Cause . . . . . . . . . . . . . 52
2.27 Reporting of Unrecognized Parameters . . . . . . . . . . 53 2.27 Reporting of Unrecognized Parameters . . . . . . . . . . 54
2.28 Handling of IP Address Parameters . . . . . . . . . . . 55 2.28 Handling of IP Address Parameters . . . . . . . . . . . 56
2.29 Handling of COOKIE ECHO chunks when a TCB exists . . . 56 2.29 Handling of COOKIE ECHO chunks when a TCB exists . . . 57
2.30 The Initial Congestion Window Size . . . . . . . . . . . 57 2.30 The Initial Congestion Window Size . . . . . . . . . . . 58
2.31 Stream Sequence Numbers in Figures . . . . . . . . . . . 59 2.31 Stream Sequence Numbers in Figures . . . . . . . . . . . 60
2.32 Unrecognized Parameters . . . . . . . . . . . . . . . . 64 2.32 Unrecognized Parameters . . . . . . . . . . . . . . . . 65
2.33 Handling of unrecognized parameters . . . . . . . . . . 65 2.33 Handling of unrecognized parameters . . . . . . . . . . 66
2.34 Tie Tags . . . . . . . . . . . . . . . . . . . . . . . . 67 2.34 Tie Tags . . . . . . . . . . . . . . . . . . . . . . . . 68
2.35 Port number verification in the COOKIE-ECHO . . . . . . 69 2.35 Port number verification in the COOKIE-ECHO . . . . . . 70
2.36 Path Initialization . . . . . . . . . . . . . . . . . . 71 2.36 Path Initialization . . . . . . . . . . . . . . . . . . 72
2.37 ICMP handling procedures . . . . . . . . . . . . . . . . 72 2.37 ICMP handling procedures . . . . . . . . . . . . . . . . 73
2.38 Checksum . . . . . . . . . . . . . . . . . . . . . . . . 74 2.38 Checksum . . . . . . . . . . . . . . . . . . . . . . . . 75
2.39 Retransmission Policy . . . . . . . . . . . . . . . . . 81 2.39 Retransmission Policy . . . . . . . . . . . . . . . . . 82
2.40 Port Number 0 . . . . . . . . . . . . . . . . . . . . . 83 2.40 Port Number 0 . . . . . . . . . . . . . . . . . . . . . 84
2.41 T Bit . . . . . . . . . . . . . . . . . . . . . . . . . 84 2.41 T Bit . . . . . . . . . . . . . . . . . . . . . . . . . 85
2.42 Unknown Parameter Handling . . . . . . . . . . . . . . . 89 2.42 Unknown Parameter Handling . . . . . . . . . . . . . . . 89
2.43 Cookie Echo Chunk . . . . . . . . . . . . . . . . . . . 90 2.43 Cookie Echo Chunk . . . . . . . . . . . . . . . . . . . 91
2.44 Partial Chunks . . . . . . . . . . . . . . . . . . . . . 91 2.44 Partial Chunks . . . . . . . . . . . . . . . . . . . . . 92
2.45 Non-unicast addresses . . . . . . . . . . . . . . . . . 92 2.45 Non-unicast addresses . . . . . . . . . . . . . . . . . 92
2.46 Processing of ABORT chunks . . . . . . . . . . . . . . . 93 2.46 Processing of ABORT chunks . . . . . . . . . . . . . . . 93
2.47 Sending of ABORT chunks . . . . . . . . . . . . . . . . 94 2.47 Sending of ABORT chunks . . . . . . . . . . . . . . . . 94
2.48 Handling of Supported Address Types parameter . . . . . 95 2.48 Handling of Supported Address Types parameter . . . . . 95
2.49 Handling of unexpected parameters . . . . . . . . . . . 96 2.49 Handling of unexpected parameters . . . . . . . . . . . 96
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 99 2.50 Payload Protocol Identifier . . . . . . . . . . . . . . 98
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 99 2.51 Karns Algorithm . . . . . . . . . . . . . . . . . . . . 99
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 100 2.52 Fast Retransmit algorithm . . . . . . . . . . . . . . . 100
Intellectual Property and Copyright Statements . . . . . . . 102 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 102
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 102
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 103
Intellectual Property and Copyright Statements . . . . . . . 105
1. Introduction 1. Introduction
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
the publishing of this document for the Stream Control Transmission the publishing of this document for the Stream Control Transmission
Protocol (SCTP) RFC2960 [6]. These defects may be of an editorial or Protocol (SCTP) RFC2960 [6]. These defects may be of an editorial or
technical nature. This document may be thought of as a companion technical nature. This document may be thought of as a companion
document to be used in the implementation of SCTP to clarify errors document to be used in the implementation of SCTP to clarify errors
in the original SCTP document. in the original SCTP document.
skipping to change at page 10, line 10 skipping to change at page 10, line 10
instances of this parameter type may be found within the same instances of this parameter type may be found within the same
chunk. chunk.
e) Each parameter type MUST be unique across all chunks. e) Each parameter type MUST be unique across all chunks.
2.4.3 Solution description 2.4.3 Solution description
By having all parameters unique across all chunk assignments (the By having all parameters unique across all chunk assignments (the
current assignment policy) no ambiguity exists as to what a parameter current assignment policy) no ambiguity exists as to what a parameter
means based on context. The trade off for this is a smaller means based on context. The trade off for this is a smaller
parameter space i.e. 65,536 parameters versus 65,536 * parameter space i.e. 65,536 parameters versus 65,536 * Number-of-
Number-of-chunks. chunks.
2.5 Stream parameter clarification 2.5 Stream parameter clarification
2.5.1 Description of the problem 2.5.1 Description of the problem
A problem was found where the specification is unclear on the A problem was found where the specification is unclear on the
legality of an endpoint asking for more stream resources than were 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 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 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 received in the INIT chunk. This behavior is illegal yet it was
skipping to change at page 54, line 5 skipping to change at page 55, line 5
indicate a protocol violation of the peer has been defined. indicate a protocol violation of the peer has been defined.
2.27 Reporting of Unrecognized Parameters 2.27 Reporting of Unrecognized Parameters
2.27.1 Description of the problem 2.27.1 Description of the problem
It is not stated clearly in RFC2960 [6] how unrecognized parameters It is not stated clearly in RFC2960 [6] how unrecognized parameters
should be reported. Unrecognized parameters in an INIT chunk could should be reported. Unrecognized parameters in an INIT chunk could
be reported in the INIT-ACK chunk or in a separate ERROR chunk which 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 can get lost. Unrecognized parameters in an INIT-ACK chunk have to
be reported in an ERROR-chunk. This can be bundled with the be reported in an ERROR-chunk. This can be bundled with the COOKIE-
COOKIE-ERROR chunk or sent separately. If it is sent separately and ERROR chunk or sent separately. If it is sent separately and
received before the COOKIE-ECHO it will be handled as an OOTB packet received before the COOKIE-ECHO it will be handled as an OOTB packet
resulting in sending out an ABORT chunk. Therefore the association resulting in sending out an ABORT chunk. Therefore the association
would not be established. would not be established.
2.27.2 Text changes to the document 2.27.2 Text changes to the document
Some of the changes given here already include changes suggested in Some of the changes given here already include changes suggested in
section Section 2.2 of this document. section Section 2.2 of this document.
--------- ---------
skipping to change at page 75, line 4 skipping to change at page 76, line 7
SCTP common header and all the chunks. Refer to appendix B for SCTP common header and all the chunks. Refer to appendix B for
details of the Adler-32 algorithm. And, details of the Adler-32 algorithm. And,
3) Put the resultant value into the checksum field in the common 3) Put the resultant value into the checksum field in the common
header, and leave the rest of the bits unchanged. header, and leave the rest of the bits unchanged.
When an SCTP packet is received, the receiver MUST first check the When an SCTP packet is received, the receiver MUST first check the
Adler-32 checksum: Adler-32 checksum:
1) Store the received Adler-32 checksum value aside, 1) Store the received Adler-32 checksum value aside,
RFC 2960 Stream Control Transmission Protocol October 2000
2) Replace the 32 bits of the checksum field in the received SCTP 2) Replace the 32 bits of the checksum field in the received SCTP
packet with all '0's and calculate an Adler-32 checksum value of packet with all '0's and calculate an Adler-32 checksum value of
the whole received packet. And, the whole received packet. And,
3) Verify that the calculated Adler-32 checksum is the same as the 3) Verify that the calculated Adler-32 checksum is the same as the
received Adler-32 checksum. If not, the receiver MUST treat the received Adler-32 checksum. If not, the receiver MUST treat the
packet as an invalid SCTP packet. packet as an invalid SCTP packet.
The default procedure for handling invalid SCTP packets is to The default procedure for handling invalid SCTP packets is to
skipping to change at page 76, line 4 skipping to change at page 76, line 46
SCTP common header and all the chunks. Refer to appendix B for SCTP common header and all the chunks. Refer to appendix B for
details of the CRC32c algorithm. And, details of the CRC32c algorithm. And,
3) Put the resultant value into the checksum field in the common 3) Put the resultant value into the checksum field in the common
header, and leave the rest of the bits unchanged. header, and leave the rest of the bits unchanged.
When an SCTP packet is received, the receiver MUST first check the When an SCTP packet is received, the receiver MUST first check the
CRC32c checksum: CRC32c checksum:
1) Store the received CRC32c checksum value aside, 1) Store the received CRC32c checksum value aside,
RFC 2960 Stream Control Transmission Protocol October 2000
2) Replace the 32 bits of the checksum field in the received SCTP 2) Replace the 32 bits of the checksum field in the received SCTP
packet with all '0's and calculate a CRC32c checksum value of packet with all '0's and calculate a CRC32c checksum value of
the whole received packet. And, the whole received packet. And,
3) Verify that the calculated CRC32c checksum is the same as the 3) Verify that the calculated CRC32c checksum is the same as the
received CRC32c checksum. If not, the receiver MUST treat the received CRC32c checksum. If not, the receiver MUST treat the
packet as an invalid SCTP packet. packet as an invalid SCTP packet.
The default procedure for handling invalid SCTP packets is to The default procedure for handling invalid SCTP packets is to
skipping to change at page 77, line 5 skipping to change at page 77, line 32
Adler-32 is composed of two sums accumulated per byte: s1 is the sum Adler-32 is composed of two sums accumulated per byte: s1 is the sum
of all bytes, s2 is the sum of all s1 values. Both sums are done of all bytes, s2 is the sum of all s1 values. Both sums are done
modulo 65521. s1 is initialized to 1, s2 to zero. The Adler-32 modulo 65521. s1 is initialized to 1, s2 to zero. The Adler-32
checksum is stored as s2*65536 + s1 in network byte order. checksum is stored as s2*65536 + s1 in network byte order.
The following C code computes the Adler-32 checksum of a data buffer. The following C code computes the Adler-32 checksum of a data buffer.
It is written for clarity, not for speed. The sample code is in the It is written for clarity, not for speed. The sample code is in the
ANSI C programming language. Non C users may find it easier to read ANSI C programming language. Non C users may find it easier to read
with these hints: with these hints:
RFC 2960 Stream Control Transmission Protocol October 2000
& Bitwise AND operator. & Bitwise AND operator.
>> Bitwise right shift operator. When applied to an >> Bitwise right shift operator. When applied to an
unsigned quantity, as here, right shift inserts zero bit(s) unsigned quantity, as here, right shift inserts zero bit(s)
at the left. at the left.
<< Bitwise left shift operator. Left shift inserts zero << Bitwise left shift operator. Left shift inserts zero
bit(s) at the right. bit(s) at the right.
++ "n++" increments the variable n. ++ "n++" increments the variable n.
% modulo operator: a % b is the remainder of a divided by b. % modulo operator: a % b is the remainder of a divided by b.
#define BASE 65521 /* largest prime smaller than 65536 */ #define BASE 65521 /* largest prime smaller than 65536 */
/* /*
skipping to change at page 85, line 4 skipping to change at page 85, line 15
2.40.3 Solution description 2.40.3 Solution description
It is clearly stated that the port number 0 is an invalid value on It is clearly stated that the port number 0 is an invalid value on
the wire. the wire.
2.41 T Bit 2.41 T Bit
2.41.1 Description of the problem 2.41.1 Description of the problem
The description of the T bit as the bit describing whether a TCB has The description of the T bit as the bit describing whether a TCB has
been destroyed or not is misleading. In additional, the procedure been destroyed or not is misleading. In addition, the procedure
described in Section 2.13 is not as precise as needed. described in Section 2.13 is not as precise as needed.
2.41.2 Text changes to the document 2.41.2 Text changes to the document
--------- ---------
Old text: (Section 3.3.7) Old text: (Section 3.3.7)
--------- ---------
T bit: 1 bit T bit: 1 bit
The T bit is set to 0 if the sender had a TCB that it destroyed. The T bit is set to 0 if the sender had a TCB that it destroyed.
skipping to change at page 88, line 5 skipping to change at page 88, line 12
B) Rules for packet carrying ABORT: B) Rules for packet carrying ABORT:
- The endpoint MUST always fill in the Verification Tag field of - The endpoint MUST always fill in the Verification Tag field of
the outbound packet with the destination endpoint's tag value the outbound packet with the destination endpoint's tag value
if it is known. if it is known.
- If the ABORT is sent in response to an OOTB packet, the - If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4. endpoint MUST follow the procedure described in Section 8.4.
- The receiver of a ABORT MUST accept the packet - The receiver of an ABORT MUST accept the packet
if the Verification Tag field of the packet matches its own tag and if the Verification Tag field of the packet matches its own tag and
the T bit is not set the T bit is not set
OR OR
it is set to its peer's tag and the T bit is set in the Chunk it is set to its peer's tag and the T bit is set in the Chunk
Flags. Flags.
Otherwise, the receiver MUST silently discard the packet Otherwise, the receiver MUST silently discard the packet
and take no further action. and take no further action.
--------- ---------
Old text: (Section 8.5.1) Old text: (Section 8.5.1)
skipping to change at page 88, line 40 skipping to change at page 88, line 47
SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state. SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.
--------- ---------
New text: (Section 8.5.1) New text: (Section 8.5.1)
--------- ---------
C) Rules for packet carrying SHUTDOWN COMPLETE: C) Rules for packet carrying SHUTDOWN COMPLETE:
- When sending a SHUTDOWN COMPLETE, if the receiver of the - When sending a SHUTDOWN COMPLETE, if the receiver of the
SHUTDOWN ACK has a TCB then the destination endpoint's tag MUST SHUTDOWN ACK has a TCB then the destination endpoint's tag MUST
be used. Only where no TCB exists should the sender use the be used and the T-bit MUST NOT be set. Only where no TCB
Verification Tag from the SHUTDOWN ACK. exists should the sender use the Verification Tag from the
SHUTDOWN ACK and MUST set the T-bit.
- The receiver of a SHUTDOWN COMPLETE shall accept the packet - The receiver of a SHUTDOWN COMPLETE shall accept the packet
if the Verification Tag field of the packet matches its own tag and if the Verification Tag field of the packet matches its own tag and
the T bit is not set the T bit is not set
OR OR
it is set to its peer's tag and the T bit is set in the Chunk it is set to its peer's tag and the T bit is set in the Chunk
Flags. Flags.
Otherwise, the receiver MUST silently discard the packet Otherwise, the receiver MUST silently discard the packet
and take no further action. An endpoint MUST ignore the and take no further action. An endpoint MUST ignore the
SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state. SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.
skipping to change at page 93, line 32 skipping to change at page 93, line 32
8.4 Handle "Out of the blue" Packets 8.4 Handle "Out of the blue" Packets
An SCTP packet is called an "out of the blue" (OOTB) packet if it is An SCTP packet is called an "out of the blue" (OOTB) packet if it is
correctly formed, i.e., passed the receiver's Adler-32 check (see correctly formed, i.e., passed the receiver's Adler-32 check (see
Section 6.8), but the receiver is not able to identify the Section 6.8), but the receiver is not able to identify the
association to which this packet belongs. association to which this packet belongs.
The receiver of an OOTB packet MUST do the following: The receiver of an OOTB packet MUST do the following:
1) If the OOTB packet is to or from a non-unicast address, a 1) If the OOTB packet is to or from a non-unicast address, a
reciever SHOULD silently discard the packet. Otherwise, receiver SHOULD silently discard the packet. Otherwise,
2.45.3 Solution description 2.45.3 Solution description
The loosening of the wording to a SHOULD will now allow future use of The loosening of the wording to a SHOULD will now allow future use of
anycast addresses. Note that no changes is made to section 11.2.4.1 anycast addresses. Note that no changes is made to section 11.2.4.1
since responding to broadcast addresses could lead to flooding since responding to broadcast addresses could lead to flooding
attacks and implementors should pay careful attention to these words. attacks and implementors should pay careful attention to these words.
2.46 Processing of ABORT chunks 2.46 Processing of ABORT chunks
skipping to change at page 95, line 34 skipping to change at page 95, line 34
The requirement of sending ABORT chunks is relaxed such that an The requirement of sending ABORT chunks is relaxed such that an
implementation can decide not to send ABORT chunks. implementation can decide not to send ABORT chunks.
2.48 Handling of Supported Address Types parameter 2.48 Handling of Supported Address Types parameter
2.48.1 Description of the problem 2.48.1 Description of the problem
The sender of the INIT chunk can include a 'Supported Address Types' The sender of the INIT chunk can include a 'Supported Address Types'
parameter to indicate which address families are supported. It is parameter to indicate which address families are supported. It is
unclear how an INIT chunk should be processed where the source unclear how an INIT chunk should be processed where the source
address of the packet containg the INIT chunk or listed addresses address of the packet containing the INIT chunk or listed addresses
within the INIT chunk indicate that more address types are supported within the INIT chunk indicate that more address types are supported
than listed in the 'Supported Address Types' parameter. than listed in the 'Supported Address Types' parameter.
2.48.2 Text changes to the document 2.48.2 Text changes to the document
The changes given here already include changes suggested in The changes given here already include changes suggested in
Section 2.28 of this document. Section 2.28 of this document.
--------- ---------
Old text: (Section 5.1.2) Old text: (Section 5.1.2)
skipping to change at page 97, line 4 skipping to change at page 97, line 4
It is now clearly described how these Supported Address Types It is now clearly described how these Supported Address Types
parameters with incorrect data should be handled. parameters with incorrect data should be handled.
2.49 Handling of unexpected parameters 2.49 Handling of unexpected parameters
2.49.1 Description of the problem 2.49.1 Description of the problem
RFC2960 [6] clearly describes how unknown parameters in the INIT and RFC2960 [6] clearly describes how unknown parameters in the INIT and
INIT-ACK chunk should be processed. But it is not described how INIT-ACK chunk should be processed. But it is not described how
unexpected parameters should be processed. A parameter is unexpected unexpected parameters should be processed. A parameter is unexpected
if it is known and an optional parameter in either the INIT or if it is known and an optional parameter in either the INIT or INIT-
INIT-ACK chunk but received in the chunk for which it is not an ACK chunk but received in the chunk for which it is not an optional
optional parameter. For exmaple, the 'Supported Address Types' parameter. For exmaple, the 'Supported Address Types' parameter
parameter would be an unexpected paramter if contained in an INIT-ACK would be an unexpected paramter if contained in an INIT-ACK chunk.
chunk.
2.49.2 Text changes to the document 2.49.2 Text changes to the document
--------- ---------
Old text: (Section 3.3.2) Old text: (Section 3.3.2)
--------- ---------
Note 4: This parameter, when present, specifies all the address types Note 4: This parameter, when present, specifies all the address types
the sending endpoint can support. The absence of this parameter the sending endpoint can support. The absence of this parameter
indicates that the sending endpoint can support any address type. indicates that the sending endpoint can support any address type.
skipping to change at page 99, line 5 skipping to change at page 98, line 18
which are not optional parameters of the INIT-ACK chunk then the receiver which are not optional parameters of the INIT-ACK chunk then the receiver
SHOULD process the INIT-ACK chunk and send back an COOKIE-ECHO. The receiver SHOULD process the INIT-ACK chunk and send back an COOKIE-ECHO. The receiver
of the INIT-ACK chunk MAY bundle an ERROR chunk with the COOKIE-ECHO chunk. of the INIT-ACK chunk MAY bundle an ERROR chunk with the COOKIE-ECHO chunk.
However, restrictive implementations MAY send back an ABORT chunk in However, restrictive implementations MAY send back an ABORT chunk in
response to the INIT-ACK chunk. response to the INIT-ACK chunk.
2.49.3 Solution description 2.49.3 Solution description
It is now stated how unexpected parameters should be processed. It is now stated how unexpected parameters should be processed.
2.50 Payload Protocol Identifier
2.50.1 Description of the problem
The current description of the payload protocol identifier does NOT
highlight the fact that the field is NOT necessarily in network byte
order.
2.50.2 Text changes to the document
---------
Old text: (Section 3.3.1)
---------
Payload Protocol Identifier: 32 bits (unsigned integer)
This value represents an application (or upper layer) specified
protocol identifier. This value is passed to SCTP by its upper
layer and sent to its peer. This identifier is not used by SCTP
but can be used by certain network entities as well as the peer
application to identify the type of information being carried in
this DATA chunk. This field must be sent even in fragmented DATA
chunks (to make sure it is available for agents in the middle of
the network).
The value 0 indicates no application identifier is specified by
the upper layer for this payload data.
---------
New text: (Section 3.3.1)
---------
Payload Protocol Identifier: 32 bits (unsigned integer)
This value represents an application (or upper layer) specified
protocol identifier. This value is passed to SCTP by its upper
layer and sent to its peer. This identifier is not used by SCTP
but can be used by certain network entities as well as the peer
application to identify the type of information being carried in
this DATA chunk. This field must be sent even in fragmented DATA
chunks (to make sure it is available for agents in the middle of
the network). Note that this field is NOT touched by an SCTP
implementation so that its byte order is NOT necessarily Big
Endian. The upper layer is responsible for any byte order
conversions to this field.
The value 0 indicates no application identifier is specified by
the upper layer for this payload data.
2.50.3 Solution description
It is now explicited stated that the upper layer is responsible for
the byte order of this field.
2.51 Karns Algorithm
2.51.1 Description of the problem
The current wording of the use of KARN's algorithm is not descriptive
enough to assure that an implementation in a multi-homed association
does not incorrectly mis-measure the RTT.
2.51.2 Text changes to the document
---------
Old text: (Section 6.3.1)
---------
C5) Karn's algorithm: RTT measurements MUST NOT be made using packets
that were retransmitted (and thus for which it is ambiguous
whether the reply was for the first instance of the packet or a
later instance)
.
---------
New text: (Section 6.3.1)
---------
C5) Karn's algorithm: RTT measurements MUST NOT be made using packets
that were retransmitted (and thus for which it is ambiguous
whether the reply was for the first instance of the packet or a
later instance)
IMPLEMENTATION NOTE: RTT measurements should only be
made using a packet with TSN r if no packet
with TSN less than or equal to r is retransmitted
since r was first sent.
2.51.3 Solution description
The above clearification adds an implementation note that will
provide additional guidance in the application of KARN's algorithm.
2.52 Fast Retransmit algorithm
2.52.1 Description of the problem
The original SCTP specification is overly conservative in requiring 4
missing reports before fast retransmitting a segment. TCP uses 3
missing reports or 4 acknowledgments indicating the same segment was
received.
2.52.2 Text changes to the document
---------
Old text:
---------
7.2.4 Fast Retransmit on Gap Reports
In the absence of data loss, an endpoint performs delayed
acknowledgement. However, whenever an endpoint notices a hole in the
arriving TSN sequence, it SHOULD start sending a SACK back every time
a packet arrives carrying data until the hole is filled.
Whenever an endpoint receives a SACK that indicates some TSN(s)
missing, it SHOULD wait for 3 further miss indications (via
subsequent SACK's) on the same TSN(s) before taking action with
regard to Fast Retransmit.
---------
New text:
---------
7.2.4 Fast Retransmit on Gap Reports
In the absence of data loss, an endpoint performs delayed
acknowledgement. However, whenever an endpoint notices a hole in the
arriving TSN sequence, it SHOULD start sending a SACK back every time
a packet arrives carrying data until the hole is filled.
Whenever an endpoint receives a SACK that indicates some TSN(s)
missing, it SHOULD wait for 2 further miss indications (via
subsequent SACK's for a total of 3 missing reports) on the
same TSN(s) before taking action with regard to Fast Retransmit.
2.52.3 Solution description
The above changes will make SCTP and TCP behave similarly in terms of
how fast they engage the Fast Retansmission algorithm upon receiving
missing reports.
3. Acknowledgments 3. Acknowledgments
The authors would like to thank the following people that have The authors would like to thank the following people that have
provided comments and input for this document: provided comments and input for this document:
Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, Manoj Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng,
Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Glaude, Jon Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina
Berger, Jon Grim, Dan Harrison, Sabina Torrente, Tomas Orti Martin, Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte,
Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben Robinson, Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC
David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, Melissa Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel,
Campbell, Sujith Radhakrishnan, Andreas Jungmaier, Mitch Miers, Fred Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan,
Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Sverre Slotte, Wang Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann,
Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep Mahajan, RCMonee, Ken Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth
FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep Balani, Biren Patel, Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John
Qiaobing Xie, Karl Knutson, La Monte Yarroll, Gareth Keily, Ian Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent
Periam, Nathalie Mouellic, Atsushi Fukumoto, David Lehmann, Rob Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig,
Brennan, Thomas Curran, Stan McClellan, Keyur Shah, Janardhan Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob
Iyengar, Serkan Cil, Bernward Meyknecht, Caitlin Bestler, Barry Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger,
Zuckerman and Philippe Langlois. Robby Benedyk, Stephen Baucke, and Sandeep Balani
A special thanks to Mark Allman, who should actually be a co-author 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 for his work on the max-burst, but managed to wiggle out due to a
technicality. Also we would like to acknowledge Lyndon Ong and Phil technicality. Also we would like to acknowledge Lyndon Ong and Phil
Conrad for their valuable input and many contributions. Conrad for their valuable input and many contributions.
4. References 4. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", [1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Caro, A., Shah, K., Iyengar, J., Amer, P. and R. Stewart, "SCTP [3] Caro, A., Shah, K., Iyengar, J., Amer, P., and R. Stewart, "SCTP
and TCP Variants: Congestion Control Under Multiple Losses", and TCP Variants: Congestion Control Under Multiple Losses",
Technical Report TR2003-04, Computer and Information Sciences Technical Report TR2003-04, Computer and Information Sciences
Department, University of Delaware, February 2003, Department, University of Delaware, February 2003,
<http://www.armandocaro.net/papers>. <http://www.armandocaro.net/papers>.
[4] Caro, A., Amer, P. and R. Stewart, "Retransmission Schemes for [4] Caro, A., Amer, P., and R. Stewart, "Retransmission Schemes for
End-to-end Failover with Transport Layer Multihoming", End-to-end Failover with Transport Layer Multihoming",
GLOBECOM, November 2004., <http://www.armandocaro.net/papers>. GLOBECOM, November 2004., <http://www.armandocaro.net/papers>.
[5] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion Window [5] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion Window
Validation", RFC 2861, June 2000. Validation", RFC 2861, June 2000.
[6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[7] Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission [7] Stone, J., Stewart, R., and D. Otis, "Stream Control
Protocol (SCTP) Checksum Change", RFC 3309, September 2002. Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
4875 Forest Drive 4875 Forest Drive
Suite 200 Suite 200
Columbia, SC 29206 Columbia, SC 29206
USA USA
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/