RFC 4460
Stream Control Transmission Protocol (SCTP) Specification Errata and Issues
2.40. Port Number 0
2.40.1. Description of the Problem
The port number 0 has a special semantic in various APIs. For example, in the socket API, if the user specifies 0, the SCTP implementation chooses an appropriate port number for the user. Therefore, the port number 0 should not be used on the wire.2.40.2. Text Changes to the Document
--------- Old text: (Section 3.1) --------- Source Port Number: 16 bits (unsigned integer) This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port, and possibly the destination IP address to identify the association to which this packet belongs. Destination Port Number: 16 bits (unsigned integer) This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application. --------- New text: (Section 3.1) --------- Source Port Number: 16 bits (unsigned integer) This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port and possibly the destination IP address to identify the association to which this packet belongs. The port number 0 MUST NOT be used. Destination Port Number: 16 bits (unsigned integer) This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application. The port number 0 MUST NOT be used.
2.40.3. Solution Description
It is clearly stated that the port number 0 is an invalid value on the wire.2.41. T Bit
2.41.1. Description of the Problem
The description of the T bit as the bit describing whether a TCB has been destroyed is misleading. In addition, the procedure described in Section 2.13 is not as precise as needed.2.41.2. Text Changes to the Document
--------- Old text: (Section 3.3.7) --------- T bit: 1 bit The T bit is set to 0 if the sender had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1. --------- New text: (Section 3.3.7) --------- T bit: 1 bit The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. If the Verification Tag is reflected, the T bit MUST be set to 1. Reflecting means that the sent Verification Tag is the same as the received one. --------- Old text: (Section 3.3.13) --------- T bit: 1 bit The T bit is set to 0 if the sender had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1.
--------- New text: (Section 3.3.13) --------- T bit: 1 bit The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. If the Verification Tag is reflected, the T bit MUST be set to 1. Reflecting means that the sent Verification Tag is the same as the received one. --------- Old text: (Section 8.4) --------- 3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. Otherwise, --------- New text: (Section 8.4) --------- 3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. If, for whatever reason, the INIT cannot be processed normally and an ABORT has to be sent in response, the Verification Tag of the packet containing the ABORT chunk MUST be the Initiate tag of the received INIT chunk, and the T-Bit of the ABORT chunk has to be set to 0, indicating that the Verification Tag is NOT reflected. --------- Old text: (Section 8.4) --------- 5) If the packet contains a SHUTDOWN ACK chunk, the receiver should respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet must fill in the Verification Tag field of the outbound packet with the Verification Tag received in the SHUTDOWN ACK and set the T-bit in the Chunk Flags to indicate that no TCB was found. Otherwise,
--------- New text: (Section 8.4) --------- 5) If the packet contains a SHUTDOWN ACK chunk, the receiver should respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet must fill in the Verification Tag field of the outbound packet with the Verification Tag received in the SHUTDOWN ACK and set the T-bit in the Chunk Flags to indicate that the Verification Tag is reflected. Otherwise, --------- Old text: (Section 8.4) --------- 8) The receiver should respond to the sender of the OOTB packet with an ABORT. When sending the ABORT, the receiver of the OOTB packet MUST fill in the Verification Tag field of the outbound packet with the value found in the Verification Tag field of the OOTB packet and set the T-bit in the Chunk Flags to indicate that no TCB was found. After sending this ABORT, the receiver of the OOTB packet shall discard the OOTB packet and take no further action. --------- New text: (Section 8.4) --------- 8) The receiver should respond to the sender of the OOTB packet with an ABORT. When sending the ABORT, the receiver of the OOTB packet MUST fill in the Verification Tag field of the outbound packet with the value found in the Verification Tag field of the OOTB packet and set the T-bit in the Chunk Flags to indicate that the Verification Tag is reflected. After sending this ABORT, the receiver of the OOTB packet shall discard the OOTB packet and take no further action. --------- Old text: (Section 8.5.1) --------- B) Rules for packet carrying ABORT:
- The endpoint shall always fill in the Verification Tag
field of the outbound packet with the destination
endpoint's tag value if it is known.
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in
Section 8.4.
- The receiver MUST accept the packet if the Verification
Tag matches either its own tag, OR the tag of its peer.
Otherwise, the receiver MUST silently discard the packet
and take no further action.
---------
New text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
- The endpoint MUST always fill in the Verification Tag
field of the outbound packet with the destination
endpoint's tag value, if it is known.
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in
Section 8.4.
- The receiver of an ABORT MUST accept the packet
if the Verification Tag field of the packet matches its
own tag and the T bit is not set
OR
if it is set to its peer's tag and the T bit is set in
the Chunk Flags.
Otherwise, the receiver MUST silently discard the packet
and take no further action.
---------
Old text: (Section 8.5.1)
---------
C) Rules for packet carrying SHUTDOWN COMPLETE:
- When sending a SHUTDOWN COMPLETE, if the receiver of the
SHUTDOWN ACK has a TCB then the destination endpoint's
tag MUST be used. Only where no TCB exists should the
sender use the Verification Tag from the SHUTDOWN ACK.
- The receiver of a SHUTDOWN COMPLETE shall accept the
packet if the Verification Tag field of the packet matches
its own tag OR it is set to its peer's tag and the T bit
is set in the Chunk Flags. Otherwise, the receiver MUST
silently discard the packet and take no further action.
An endpoint MUST ignore the SHUTDOWN COMPLETE if it is
not in the SHUTDOWN-ACK-SENT state.
---------
New text: (Section 8.5.1)
---------
C) Rules for packet carrying SHUTDOWN COMPLETE:
- When sending a SHUTDOWN COMPLETE, if the receiver of the
SHUTDOWN ACK has a TCB, then the destination endpoint's tag
MUST be used, and the T-bit MUST NOT be set. Only where no
TCB exists should the sender use the Verification Tag from
the SHUTDOWN ACK, and MUST set the T-bit.
- The receiver of a SHUTDOWN COMPLETE shall accept the packet
if the Verification Tag field of the packet matches its own
tag and the T bit is not set
OR
if it is set to its peer's tag and the T bit is set in the
Chunk Flags.
Otherwise, the receiver MUST silently discard the packet
and take no further action. An endpoint MUST ignore the
SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT
state.
2.41.3. Solution Description
The description of the T bit now clearly describes the semantic of
the bit. The procedures for receiving the T bit have been clarified.
2.42. Unknown Parameter Handling
2.42.1. Description of the Problem
The description given in Section 2.33 does not state clearly whether
an INIT-ACK or COOKIE-ECHO is sent.
2.42.2. Text Changes to the Document
The changes given here already include changes suggested in Section
2.2, 2.27, and 2.33 of this document.
--------- Old text: (Section 3.2.1) --------- 00 - Stop processing this SCTP packet and discard it do not process any further chunks within it. 01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK). 10 - Skip this parameter and continue processing. 11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK). --------- New text: (Section 3.2.1) --------- 00 - Stop processing this parameter; do not process any further parameters within this chunk. 01 - Stop processing this parameter, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter', as described in 3.2.2. 10 - Skip this parameter and continue processing. 11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter', as described in 3.2.2. Please note that in all four cases an INIT-ACK or COOKIE-ECHO chunk is sent. In the 00 or 01 case the processing of the parameters after the unknown parameter is canceled, but no processing already done is rolled back.
--------- New text: (Note: no old text; clarification added in Section 3.2) --------- 3.2.2. Reporting of Unrecognized Parameters If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it MUST put the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in response to the INIT-chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g., due to lack of resources), an 'Unrecognized Parameter' would NOT be included with any ABORT being sent to the sender of the INIT. If the receiver of an INIT-ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameters' error cause with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE-ACK has been received. Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the first chunk.2.42.3. Solution Description
The new text clearly states that an INIT-ACK or COOKIE-ECHO has to be sent.2.43. Cookie Echo Chunk
2.43.1. Description of the Problem
The description given in Section 3.3.11 of RFC 2960 [5] is unclear as to how the COOKIE-ECHO is composed.2.43.2. Text Changes to the Document
--------- Old text: (Section 3.3.11) --------- Cookie: variable size This field must contain the exact cookie received in the State Cookie parameter from the previous INIT ACK.
An implementation SHOULD make the cookie as small as possible
to insure interoperability.
---------
New text: (Section 3.3.11)
---------
Cookie: variable size
This field must contain the exact cookie received in the State
Cookie parameter from the previous INIT ACK.
An implementation SHOULD make the cookie as small as possible
to ensure interoperability.
Note: A Cookie Echo does NOT contain a State Cookie
Parameter; instead, the data within the State Cookie's
Parameter Value becomes the data within the Cookie Echo's
Chunk Value. This allows an implementation to change only
the first two bytes of the State Cookie parameter to become
a Cookie Echo Chunk.
2.43.3. Solution Description
The new text adds a note that helps clarify that a Cookie Echo chunk
is nothing more than the State Cookie parameter with only two bytes
modified.
2.44. Partial Chunks
2.44.1. Description of the Problem
Section 6.10 of RFC 2960 [5] uses the notion of 'partial chunks'
without defining it.
2.44.2. Text Changes to the Document
---------
Old text: (Section 6.10)
---------
Partial chunks MUST NOT be placed in an SCTP packet.
---------
New text: (Section 6.10)
---------
Partial chunks MUST NOT be placed in an SCTP packet. A partial
chunk is a chunk that is not completely contained in the SCTP
packet; i.e., the SCTP packet is too short to contain all the bytes
of the chunk as indicated by the chunk length.
2.44.3. Solution Description
The new text adds a definition of 'partial chunks'.2.45. Non-unicast Addresses
2.45.1. Description of the Problem
Section 8.4 of RFC 2960 [5] forces the OOTB handling to discard all non-unicast addresses. This leaves future use of anycast addresses in question. With the addition of the add-ip feature, SCTP should be able to easily handle anycast INIT s that can be followed, after association setup, with a delete of the anycast address from the association.2.45.2. Text Changes to the Document
--------- Old text: (Section 8.4) --------- 8.4 Handle "Out of the blue" Packets An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed, i.e., passed the receiver's Adler-32 check (see Section 6.8), but the receiver is not able to identify the association to which this packet belongs. The receiver of an OOTB packet MUST do the following: 1) If the OOTB packet is to or from a non-unicast address, silently discard the packet. Otherwise, --------- New text: (Section 8.4) --------- 8.4. Handle "Out of the Blue" Packets An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed (i.e., passed the receiver's CRC32c check; see Section 6.8), but the receiver is not able to identify the association to which this packet belongs. The receiver of an OOTB packet MUST do the following: 1) If the OOTB packet is to or from a non-unicast address, a receiver SHOULD silently discard the packet. Otherwise,
2.45.3. Solution Description
The loosening of the wording to a SHOULD will now allow future use of anycast addresses. Note that no changes are made to Section 11.2.4.1, since responding to broadcast addresses could lead to flooding attacks and implementors should pay careful attention to these words.2.46. Processing of ABORT Chunks
2.46.1. Description of the Problem
Section 3.3.7 of RFC 2960 [5] requires an SCTP endpoint to silently discard ABORT chunks received for associations that do not exist. It is not clear what this means in the COOKIE-WAIT state, for example. Therefore, it was not clear whether an ABORT sent in response to an INIT should be processed or silently discarded.2.46.2. Text Changes to the Document
--------- Old text: (Section 3.3.7) --------- If an endpoint receives an ABORT with a format error or for an association that doesn't exist, it MUST silently discard it. --------- New text: (Section 3.3.7) --------- If an endpoint receives an ABORT with a format error or no TCB is found, it MUST silently discard it.2.46.3. Solution Description
It is now clearly stated that an ABORT chunk should be processed whenever a TCB is found.
2.47. Sending of ABORT Chunks
2.47.1. Description of the Problem
Section 5.1 of RFC 2960 [5] requires that an ABORT chunk be sent in response to an INIT chunk when there is no listening end point. To make port scanning harder, someone might not want these ABORTs to be received by the sender of the INIT chunks. Currently, the only way to enforce this is by using a firewall that discards the packets containing the INIT chunks or the packets containing the ABORT chunks. It is desirable that the same can be done without a middle box.2.47.2. Text Changes to the Document
--------- Old text: (Section 5.1) --------- If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it MUST respond with an ABORT chunk. --------- New text: (Section 5.1) --------- If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it SHOULD respond with an ABORT chunk.2.47.3. Solution Description
The requirement of sending ABORT chunks is relaxed such that an implementation can decide not to send ABORT chunks.2.48. Handling of Supported Address Types Parameter
2.48.1. Description of the Problem
The sender of the INIT chunk can include a 'Supported Address Types' parameter to indicate which address families are supported. It is unclear how an INIT chunk should be processed where the source address of the packet containing the INIT chunk or listed addresses
within the INIT chunk indicate that more address types are supported than those listed in the 'Supported Address Types' parameter.2.48.2. Text Changes to the Document
The changes given here already include changes suggested in Section 2.28 of this document. --------- Old text: (Section 5.1.2) --------- IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers. --------- New text: (Section 5.1.2) --------- IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re- initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers. IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT- ACK chunk from its peer, it MUST use all the addresses belonging to the supported address family. The other addresses MAY be ignored. The endpoint SHOULD NOT respond with any kind of error indication. IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported Address Types' parameter either IPv4 or IPv6, but uses the other family for sending the packet containing the INIT chunk, or if it also lists addresses of the other family in the INIT chunk, then the address family that is not listed in the 'Supported Address Types' parameter SHOULD also be considered as supported by the receiver of the INIT chunk. The receiver of the INIT chunk SHOULD NOT respond with any kind of error indication.2.48.3. Solution Description
It is now clearly described how these Supported Address Types parameters with incorrect data should be handled.
2.49. Handling of Unexpected Parameters
2.49.1. Description of the Problem
RFC 2960 [5] clearly describes how unknown parameters in the INIT and INIT-ACK chunk should be processed. But it is not described how unexpected parameters should be processed. A parameter is unexpected if it is known and is an optional parameter in either the INIT or INIT-ACK chunk but is received in the chunk for which it is not an optional parameter. For example, the 'Supported Address Types' parameter would be an unexpected parameter if contained in an INIT- ACK chunk.2.49.2. Text Changes to the Document
--------- Old text: (Section 3.3.2) --------- Note 4: This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type. --------- New text: (Section 3.3.2) --------- Note 4: This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type. IMPLEMENTATION NOTE: If an INIT chunk is received with known parameters that are not optional parameters of the INIT chunk then the receiver SHOULD process the INIT chunk and send back an INIT-ACK. The receiver of the INIT chunk MAY bundle an ERROR chunk with the COOKIE-ACK chunk later. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT chunk.
--------- Old text: (Section 3.3.3) --------- IMPLEMENTATION NOTE: An implementation MUST be prepared to receive a INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the state cookie AND the variable address list. For example if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK. --------- New text: (Section 3.3.3) --------- IMPLEMENTATION NOTE: An implementation MUST be prepared to receive a INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the state cookie AND the variable address list. For example, if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK. IMPLEMENTATION NOTE: If an INIT-ACK chunk is received with known parameters that are not optional parameters of the INIT-ACK chunk, then the receiver SHOULD process the INIT-ACK chunk and send back a COOKIE-ECHO. The receiver of the INIT-ACK chunk MAY bundle an ERROR chunk with the COOKIE-ECHO chunk. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT-ACK chunk.2.49.3. Solution Description
It is now stated how unexpected parameters should be processed.2.50. Payload Protocol Identifier
2.50.1. Description of the Problem
The current description of the payload protocol identifier does NOT highlight the fact that the field is NOT necessarily in network byte order.
2.50.2. Text Changes to the Document
--------- Old text: (Section 3.3.1) --------- Payload Protocol Identifier: 32 bits (unsigned integer) This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities as well as the peer application to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network). The value 0 indicates no application identifier is specified by the upper layer for this payload data. --------- New text: (Section 3.3.1) --------- Payload Protocol Identifier: 32 bits (unsigned integer) This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities, as well as by the peer application, to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network). Note that this field is NOT touched by an SCTP implementation, therefore its byte order is NOT necessarily Big Endian. The upper layer is responsible for any byte order conversions to this field. The value 0 indicates that no application identifier is specified by the upper layer for this payload data.2.50.3. Solution Description
It is now explicitly stated that the upper layer is responsible for the byte order of this field.
2.51. Karn's Algorithm
2.51.1. Description of the Problem
The current wording of the use of Karn's algorithm is not descriptive enough to ensure that an implementation in a multi-homed association does not incorrectly mismeasure the RTT.2.51.2. Text Changes to the Document
--------- Old text: (Section 6.3.1) --------- C5) Karn's algorithm: RTT measurements MUST NOT be made using packets that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the packet or a later instance) --------- New text: (Section 6.3.1) --------- C5) Karn's algorithm: RTT measurements MUST NOT be made using chunks that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the chunk or for a later instance) IMPLEMENTATION NOTE: RTT measurements should only be made using a chunk with TSN r if no chunk with TSN less than or equal to r is retransmitted since r is first sent.2.51.3. Solution Description
The above clarification adds an implementation note that will provide additional guidance in the application of Karn's algorithm.2.52. Fast Retransmit Algorithm
2.52.1. Description of the Problem
The original SCTP specification is overly conservative in requiring 4 missing reports before fast retransmitting a segment. TCP uses 3 missing reports or 4 acknowledgements indicating that the same segment was received.
2.52.2. Text Changes to the Document
--------- Old text: --------- 7.2.4 Fast Retransmit on Gap Reports In the absence of data loss, an endpoint performs delayed acknowledgement. However, whenever an endpoint notices a hole in the arriving TSN sequence, it SHOULD start sending a SACK back every time a packet arrives carrying data until the hole is filled. Whenever an endpoint receives a SACK that indicates some TSN(s) missing, it SHOULD wait for 3 further miss indications (via subsequent SACK's) on the same TSN(s) before taking action with regard to Fast Retransmit. --------- New text: --------- 7.2.4. Fast Retransmit on Gap Reports In the absence of data loss, an endpoint performs delayed acknowledgement. However, whenever an endpoint notices a hole in the arriving TSN sequence, it SHOULD start sending a SACK back every time a packet arrives carrying data until the hole is filled. Whenever an endpoint receives a SACK that indicates that some TSNs are missing, it SHOULD wait for 2 further miss indications (via subsequent SACKs for a total of 3 missing reports) on the same TSNs before taking action with regard to Fast Retransmit.2.52.3. Solution Description
The above changes will make SCTP and TCP behave similarly in terms of how fast they engage the Fast Retransmission algorithm upon receiving missing reports.3. Security Considerations
This document should add no additional security risks to SCTP and in fact SHOULD correct some original security flaws within the original document once it is incorporated into a RFC 2960 [5] BIS document.
4. Acknowledgements
The authors would like to thank the following people who have provided comments and input for this document: Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng, Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte, Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel, Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan, Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann, Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig, Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger, Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar. A special thanks to Mark Allman, who should actually be a co-author for his work on the max-burst, but managed to wiggle out due to a technicality. Also, we would like to acknowledge Lyndon Ong and Phil Conrad for their valuable input and many contributions.5. IANA Considerations
This document recommends changes for the RFC 2960 [5] BIS document. As such, even though it lists new error cause code, this document in itself does NOT define those new codes. Instead, the BIS document will make the needed changes to RFC 2960 [5] and thus its IANA section will require changes to be made.6. Normative References
[1] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Caro, A., Shah, K., Iyengar, J., Amer, P., and R. Stewart, "SCTP and TCP Variants: Congestion Control Under Multiple Losses", Technical Report TR2003-04, Computer and Information Sciences Department, University of Delaware, February 2003, <http://www.armandocaro.net/papers>.
[4] Caro, A., Amer, P., and R. Stewart, "Retransmission Schemes for End-to-end Failover with Transport Layer Multihoming", GLOBECOM, November 2004., <http://www.armandocaro.net/papers>. [5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [6] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
Authors' Addresses
Randall R. Stewart Cisco Systems, Inc. 4875 Forest Drive Suite 200 Columbia, SC 29206 USA EMail: rrs@cisco.com Ivan Arias-Rodriguez Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland EMail: ivan.arias-rodriguez@nokia.com Kacheong Poon Sun Microsystems, Inc. 3571 N. First St. San Jose, CA 95134 USA EMail: kacheong.poon@sun.com Armando L. Caro Jr. BBN Technologies 10 Moulton St. Cambridge, MA 02138 EMail: acaro@bbn.com URI: http://www.armandocaro.net Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany EMail: tuexen@fh-muenster.de
Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).