draft-ietf-tsvwg-sctpimpguide-12.txt   draft-ietf-tsvwg-sctpimpguide-13.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: April 15, 2005 I. Arias-Rodriguez Expires: August 25, 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
October 15, 2004 February 21, 2005
Stream Control Transmission Protocol (SCTP) Implementer's Guide Stream Control Transmission Protocol (SCTP) Implementer's Guide
draft-ietf-tsvwg-sctpimpguide-12.txt draft-ietf-tsvwg-sctpimpguide-13.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 of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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-Drafts. Internet-Drafts.
skipping to change at page 1, line 42 skipping to change at page 1, line 43
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 April 15, 2005. This Internet-Draft will expire on August 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). 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
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.
This document updates RFC2960 [6] and text within this document This document updates RFC2960 [6] and text within this document
skipping to change at page 3, line 16 skipping to change at page 3, line 16
2.35 Port number verification in the COOKIE-ECHO . . . . . . 69 2.35 Port number verification in the COOKIE-ECHO . . . . . . 69
2.36 Path Initialization . . . . . . . . . . . . . . . . . . 71 2.36 Path Initialization . . . . . . . . . . . . . . . . . . 71
2.37 ICMP handling procedures . . . . . . . . . . . . . . . . 72 2.37 ICMP handling procedures . . . . . . . . . . . . . . . . 72
2.38 Checksum . . . . . . . . . . . . . . . . . . . . . . . . 74 2.38 Checksum . . . . . . . . . . . . . . . . . . . . . . . . 74
2.39 Retransmission Policy . . . . . . . . . . . . . . . . . 81 2.39 Retransmission Policy . . . . . . . . . . . . . . . . . 81
2.40 Port Number 0 . . . . . . . . . . . . . . . . . . . . . 83 2.40 Port Number 0 . . . . . . . . . . . . . . . . . . . . . 83
2.41 T Bit . . . . . . . . . . . . . . . . . . . . . . . . . 84 2.41 T Bit . . . . . . . . . . . . . . . . . . . . . . . . . 84
2.42 Unknown Parameter Handling . . . . . . . . . . . . . . . 89 2.42 Unknown Parameter Handling . . . . . . . . . . . . . . . 89
2.43 Cookie Echo Chunk . . . . . . . . . . . . . . . . . . . 90 2.43 Cookie Echo Chunk . . . . . . . . . . . . . . . . . . . 90
2.44 Partial Chunks . . . . . . . . . . . . . . . . . . . . . 91 2.44 Partial Chunks . . . . . . . . . . . . . . . . . . . . . 91
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 93 2.45 Non-unicast addresses . . . . . . . . . . . . . . . . . 92
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 93 2.46 Processing of ABORT chunks . . . . . . . . . . . . . . . 93
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 94 2.47 Sending of ABORT chunks . . . . . . . . . . . . . . . . 94
Intellectual Property and Copyright Statements . . . . . . . 96 2.48 Handling of Supported Address Types parameter . . . . . 95
2.49 Handling of unexpected parameters . . . . . . . . . . . 96
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 99
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 99
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 100
Intellectual Property and Copyright Statements . . . . . . . 102
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.
This document updates RFC2960 and text within this document, where This document updates RFC2960 and text within this document, where
noted, supersedes the text found in RFC2960 [6]. Each error will be noted, supersedes the text found in RFC2960 [6]. Each error will be
detailed within this document in the form of: detailed within this document in the form of:
o The problem description, o The problem description,
o The text quoted from RFC2960 [6], o The text quoted from RFC2960 [6],
o The replacement text, o The replacement text,
o A description of the solution. o A description of the solution.
Note that when reading this document one must use care to assure that
a field or item is not updated further on within the document. Each
section should be applied in sequence to the original RFC2960 [6]
since this document is a historical record of the sequential changes
that have been found necessary at various inter-op events and through
discussion on the list.
1.1 Conventions 1.1 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
RFC2119 [2]. RFC2119 [2].
2. Corrections to RFC2960 2. Corrections to RFC2960
2.1 Incorrect error type during chunk processing. 2.1 Incorrect error type during chunk processing.
skipping to change at page 18, line 31 skipping to change at page 18, line 31
iii) If the SACK is missing a TSN that was previously iii) If the SACK is missing a TSN that was previously
acknowledged via a Gap Ack Block (e.g., the data receiver acknowledged via a Gap Ack Block (e.g., the data receiver
reneged on the data), then mark the corresponding DATA chunk as reneged on the data), then mark the corresponding DATA chunk as
available for retransmit: Mark it as missing for fast available for retransmit: Mark it as missing for fast
retransmit as described in Section 7.2.4 and if no retransmit retransmit as described in Section 7.2.4 and if no retransmit
timer is running for the destination address to which the DATA timer is running for the destination address to which the DATA
chunk was originally transmitted, then T3-rtx is started for chunk was originally transmitted, then T3-rtx is started for
that destination address. that destination address.
iv) If the Cumulative TSN Ack exceeds the Fast Recovery exit iv) If the Cumulative TSN Ack matches or exceeds the Fast Recovery exit
point (Section 7.2.4), Fast Recovery is exited. point (Section 7.2.4), Fast Recovery is exited.
--------- ---------
Old text: (Section 7.2.4) Old text: (Section 7.2.4)
--------- ---------
Whenever an endpoint receives a SACK that indicates some TSN(s) Whenever an endpoint receives a SACK that indicates some TSN(s)
missing, it SHOULD wait for 3 further miss indications (via missing, it SHOULD wait for 3 further miss indications (via
subsequent SACK's) on the same TSN(s) before taking action with subsequent SACK's) on the same TSN(s) before taking action with
regard to Fast Retransmit. regard to Fast Retransmit.
skipping to change at page 53, line 24 skipping to change at page 53, line 24
--------- ---------
New text: (Note no old text, new error added in section 3.3.10) New text: (Note no old text, new error added in section 3.3.10)
--------- ---------
3.3.10.13 Protocol Violation (13) 3.3.10.13 Protocol Violation (13)
Cause of error Cause of error
-------------- --------------
This error cause MAY be included in ABORT chunks which is sent This error cause MAY be included in ABORT chunks which are sent
because an SCTP endpoint detects a protocol violation of the peer because an SCTP endpoint detects a protocol violation of the peer
which is not covered by the error causes described in 3.3.10.1 to which is not covered by the error causes described in 3.3.10.1 to
3.3.10.12. An implementation MAY provide Additional Information 3.3.10.12. An implementation MAY provide Additional Information
specifying what kind of protocol violation has been detected. specifying what kind of protocol violation has been detected.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable | | Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information / / Additional Information /
\\ \\ \\ \\
skipping to change at page 73, line 21 skipping to change at page 73, line 21
Appendix C ICMP Handling Appendix C ICMP Handling
Whenever an ICMP message is received by an SCTP endpoint the Whenever an ICMP message is received by an SCTP endpoint the
following procedures should be followed to assure proper following procedures should be followed to assure proper
utilization of the information being provided by layer 3. utilization of the information being provided by layer 3.
ICMP1) Ignore all ICMPv4 messages where the type field is ICMP1) Ignore all ICMPv4 messages where the type field is
not set to "Destination Unreachable". not set to "Destination Unreachable".
ICMP2) Ignore all ICMPv6 messages where the type filed is ICMP2) Ignore all ICMPv6 messages where the type field is
not "Destination Unreachable, "Parameter Problem" or not "Destination Unreachable, "Parameter Problem" or
"Packet Too Big". "Packet Too Big".
ICMP3) Ignore any ICMPv4 messages where the code does not ICMP3) Ignore any ICMPv4 messages where the code does not
indicate "Protocol Unreachable" or "Fragmentation Needed". indicate "Protocol Unreachable" or "Fragmentation Needed".
ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if
the code is not "Unrecognized next header type encountered". the code is not "Unrecognized next header type encountered".
ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the
skipping to change at page 93, line 5 skipping to change at page 92, line 24
--------- ---------
Partial chunks MUST NOT be placed in an SCTP packet. A partial Partial chunks MUST NOT be placed in an SCTP packet. A partial
chunk is a chunk which is not completely contained in the SCTP chunk is a chunk which is not completely contained in the SCTP
packet, i.e. the SCTP packet is too short to contain all the bytes packet, i.e. the SCTP packet is too short to contain all the bytes
of the chunk as indicated by the chunk length. of the chunk as indicated by the chunk length.
2.44.3 Solution description 2.44.3 Solution description
The new text adds a definition of 'partial chunks'. 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 RFC2960 [6] forces the OOTB handling to discard all
non-unicast addresses. This MUST, leaves future use of any-cast
addresses in question. With the addition of the add-ip feature SCTP
should be able to easily handle any-cast INIT's that can be followed,
after association setup, with a delete of the any-cast 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 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, a
reciever 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 is 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 RFC2960 [6] 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 if 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 RFC2960 [6] requires that an ABORT chunk is 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 discarding 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 containg the INIT chunk or listed addresses
within the INIT chunk indicate that more address types are supported
than 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 only supporting either IPv4
or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-ACK chunk
from its peer it MUST use all of the addresses belonging to the
supported address family. The other addresses MAY be ignored. The
endpoint SHOULD NOT respond with any kind of error indication.
IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported Address
Types' parameter only either IPv4 or IPv6 but uses the other family
for sending the packet containing the INIT chunk or lists also addresses
of the other family in the INIT chunk, then the address family which 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
RFC2960 [6] 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 an optional parameter in either the INIT or
INIT-ACK chunk but received in the chunk for which it is not an
optional parameter. For exmaple, the 'Supported Address Types'
parameter would be an unexpected paramter 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
which 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
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
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.
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 Heinz Prantner, Jan Rovins, Renee Revis, Steven Furniss, Manoj
Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Glaude, Jon Solanki, Mike Turner, Jonathan Lee, Peter Butler, Laurent Glaude, Jon
Berger, Jon Grim, Dan Harrison, Sabina Torrente, Tomas Orti Martin, Berger, Jon Grim, Dan Harrison, Sabina Torrente, Tomas Orti Martin,
Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben Robinson, Jeff Waskow, Robby Benedyk, Steve Dimig, Joe Keller, Ben Robinson,
David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, Melissa David Lehmann, John Hebert, Sanjay Rao, Kausar Hassan, Melissa
Campbell, Sujith Radhakrishnan, Andreas Jungmaier, Mitch Miers, Fred Campbell, Sujith Radhakrishnan, Andreas Jungmaier, Mitch Miers, Fred
Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Sverre Slotte, Wang Hasle, Oliver Mayor, Cliff Thomas, Jonathan Wood, Sverre Slotte, Wang
Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep Mahajan, RCMonee, Ken Xiaopeng, John Townsend, Harsh Bhondwe, Sandeep Mahajan, RCMonee, Ken
FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep Balani, Biren Patel, FUJITA, Yuji SUZUKI, Mutsuya IRIE, Sandeep Balani, Biren Patel,
Qiaobing Xie, Karl Knutson, La Monte Yarroll, Gareth Keily, Ian Qiaobing Xie, Karl Knutson, La Monte Yarroll, Gareth Keily, Ian
Periam, Nathalie Mouellic, Atsushi Fukumoto, David Lehmann, Rob Periam, Nathalie Mouellic, Atsushi Fukumoto, David Lehmann, Rob
Brennan, Thomas Curran, Stan McClellan, Keyur Shah, Janardhan Brennan, Thomas Curran, Stan McClellan, Keyur Shah, Janardhan
Iyengar, Serkan Cil, Bernward Meyknecht and Caitlin Bestler. Iyengar, Serkan Cil, Bernward Meyknecht, Caitlin Bestler, Barry
Zuckerman and Philippe Langlois.
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", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3",
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>.
skipping to change at page 94, line 17 skipping to change at page 100, line 18
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
EMail: rrs@cisco.com Email: rrs@cisco.com
Ivan Arias-Rodriguez Ivan Arias-Rodriguez
Nokia Research Center Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
EMail: ivan.arias-rodriguez@nokia.com Email: ivan.arias-rodriguez@nokia.com
Kacheong Poon Kacheong Poon
Sun Microsystems, Inc. Sun Microsystems, Inc.
3571 N. First St. 3571 N. First St.
San Jose, CA 95134 San Jose, CA 95134
USA USA
EMail: kacheong.poon@sun.com Email: kacheong.poon@sun.com
Armando L. Caro Jr. Armando L. Caro Jr.
University of Delaware University of Delaware
Department of Computer & Information Sciences Department of Computer & Information Sciences
103 Smith Hall 103 Smith Hall
Newark, DE 19716 Newark, DE 19716
USA USA
EMail: me @ armandocaro . net Email: me @ armandocaro . net
URI: http://www.armandocaro.net URI: http://www.armandocaro.net
Michael Tuexen Michael Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
EMail: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 96, line 41 skipping to change at page 102, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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