draft-ietf-tsvwg-2960bis-03.txt   draft-ietf-tsvwg-2960bis-04.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Editor Internet-Draft Editor
Expires: June 15, 2007 December 12, 2006 Intended status: Standards Track April 5, 2007
Expires: October 7, 2007
Stream Control Transmission Protocol Stream Control Transmission Protocol
draft-ietf-tsvwg-2960bis-03.txt draft-ietf-tsvwg-2960bis-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance 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
skipping to change at page 1, line 33 skipping to change at page 1, line 34
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 June 15, 2007. This Internet-Draft will expire on October 7, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes the Stream Control Transmission Protocol This document obsoletes RFC2960 [RFC2960] and describes the Stream
(SCTP). SCTP is designed to transport PSTN signaling messages over Control Transmission Protocol (SCTP). SCTP is designed to transport
IP networks, but is capable of broader applications. PSTN signaling messages over IP networks, but is capable of broader
applications.
SCTP is a reliable transport protocol operating on top of a SCTP is a reliable transport protocol operating on top of a
connectionless packet network such as IP. It offers the following connectionless packet network such as IP. It offers the following
services to its users: services to its users:
-- acknowledged error-free non-duplicated transfer of user data, -- acknowledged error-free non-duplicated transfer of user data,
-- data fragmentation to conform to discovered path MTU size, -- data fragmentation to conform to discovered path MTU size,
-- sequenced delivery of user messages within multiple streams, with -- sequenced delivery of user messages within multiple streams, with
an option for order-of-arrival delivery of individual user an option for order-of-arrival delivery of individual user
messages, messages,
skipping to change at page 4, line 45 skipping to change at page 4, line 45
11.2.1. Countering Insider Attacks . . . . . . . . . . . . . 124 11.2.1. Countering Insider Attacks . . . . . . . . . . . . . 124
11.2.2. Protecting against Data Corruption in the Network . . 124 11.2.2. Protecting against Data Corruption in the Network . . 124
11.2.3. Protecting Confidentiality . . . . . . . . . . . . . 125 11.2.3. Protecting Confidentiality . . . . . . . . . . . . . 125
11.2.4. Protecting against Blind Denial of Service Attacks . 125 11.2.4. Protecting against Blind Denial of Service Attacks . 125
11.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 126 11.2.4.1. Flooding . . . . . . . . . . . . . . . . . . . . 126
11.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 127 11.2.4.2. Blind Masquerade . . . . . . . . . . . . . . . . 127
11.2.4.3. Improper Monopolization of Services . . . . . . 128 11.2.4.3. Improper Monopolization of Services . . . . . . 128
11.3. Protection against Fraud and Repudiation . . . . . . . . 128 11.3. Protection against Fraud and Repudiation . . . . . . . . 128
11.4. SCTP Interactions with Firewalls . . . . . . . . . . . . 129 11.4. SCTP Interactions with Firewalls . . . . . . . . . . . . 129
11.5. Protection of Non-SCTP Capable Hosts. . . . . . . . . . . 129 11.5. Protection of Non-SCTP Capable Hosts. . . . . . . . . . . 129
12. Network Managment Considerations . . . . . . . . . . . . . . 130 12. Network Management Considerations . . . . . . . . . . . . . . 130
13. Recommended Transmission Control Block (TCB) Parameters . . . 130 13. Recommended Transmission Control Block (TCB) Parameters . . . 130
13.1. Parameters necessary for the SCTP instance . . . . . . . 130 13.1. Parameters necessary for the SCTP instance . . . . . . . 130
13.2. Parameters necessary per association (i.e. the TCB) . . . 130 13.2. Parameters necessary per association (i.e. the TCB) . . . 130
13.3. Per Transport Address Data . . . . . . . . . . . . . . . 132 13.3. Per Transport Address Data . . . . . . . . . . . . . . . 132
13.4. General Parameters Needed . . . . . . . . . . . . . . . . 133 13.4. General Parameters Needed . . . . . . . . . . . . . . . . 133
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 134 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 134
14.1. IETF-defined Chunk Extension . . . . . . . . . . . . . . 134 14.1. IETF-defined Chunk Extension . . . . . . . . . . . . . . 134
14.2. IETF-defined Chunk Parameter Extension . . . . . . . . . 134 14.2. IETF-defined Chunk Parameter Extension . . . . . . . . . 134
14.3. IETF-defined Additional Error Causes . . . . . . . . . . 135 14.3. IETF-defined Additional Error Causes . . . . . . . . . . 135
14.4. Payload Protocol Identifiers . . . . . . . . . . . . . . 135 14.4. Payload Protocol Identifiers . . . . . . . . . . . . . . 135
skipping to change at page 16, line 14 skipping to change at page 16, line 14
arithmetic. arithmetic.
1.7. Changes from RFC2960 1.7. Changes from RFC2960
SCTP was originally defined in [RFC2960] which this document SCTP was originally defined in [RFC2960] which this document
obsoletes. Readers interested in the details of the various changes obsoletes. Readers interested in the details of the various changes
that this document incorporates are asked to consult [RFC4460]. that this document incorporates are asked to consult [RFC4460].
2. Conventions 2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
they appear in this document, are to be interpreted as described in document are to be interpreted as described in RFC2119 [RFC2119].
[RFC2119].
3. SCTP packet Format 3. SCTP packet Format
An SCTP packet is composed of a common header and chunks. A chunk An SCTP packet is composed of a common header and chunks. A chunk
contains either control information or user data. contains either control information or user data.
The SCTP packet format is shown below: The SCTP packet format is shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 29, line 25 skipping to change at page 29, line 25
| IPv6 Address | | IPv6 Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address: 128 bit (unsigned integer) IPv6 Address: 128 bit (unsigned integer)
Contains an IPv6 address of the sending endpoint. It is binary Contains an IPv6 address of the sending endpoint. It is binary
encoded. encoded.
Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC2373]. Note: A sender MUST NOT use an IPv4-mapped IPv6 address [RFC4291].
but should instead use an IPv4 Address Parameter for an IPv4 but should instead use an IPv4 Address Parameter for an IPv4
address. address.
Combined with the Source Port Number in the SCTP common header, Combined with the Source Port Number in the SCTP common header,
the value passed in an IPv4 or IPv6 Address parameter indicates a the value passed in an IPv4 or IPv6 Address parameter indicates a
transport address the sender of the INIT will support for the transport address the sender of the INIT will support for the
association being initiated. That is, during the lifetime of this association being initiated. That is, during the lifetime of this
association, this IP address can appear in the source address association, this IP address can appear in the source address
field of an IP datagram sent from the sender of the INIT, and can field of an IP datagram sent from the sender of the INIT, and can
be used as a destination address of an IP datagram sent from the be used as a destination address of an IP datagram sent from the
skipping to change at page 53, line 39 skipping to change at page 53, line 39
The state diagram in the figures below illustrates state changes, The state diagram in the figures below illustrates state changes,
together with the causing events and resulting actions. Note that together with the causing events and resulting actions. Note that
some of the error conditions are not shown in the state diagram. some of the error conditions are not shown in the state diagram.
Full description of all special cases should be found in the text. Full description of all special cases should be found in the text.
Note: Chunk names are given in all capital letters, while parameter Note: Chunk names are given in all capital letters, while parameter
names have the first letter capitalized, e.g., COOKIE ECHO chunk type names have the first letter capitalized, e.g., COOKIE ECHO chunk type
vs. State Cookie parameter. If more than one event/message can occur vs. State Cookie parameter. If more than one event/message can occur
which causes a state transition it is labeled (A), (B) etc. which causes a state transition it is labeled (A), (B) etc.
----- -------- (frm any state) ----- -------- (from any state)
/ \ / rcv ABORT [ABORT] / \ / rcv ABORT [ABORT]
rcv INIT | | | ---------- or ---------- rcv INIT | | | ---------- or ----------
--------------- | v v delete TCB snd ABORT --------------- | v v delete TCB snd ABORT
generate Cookie \ +---------+ delete TCB generate Cookie \ +---------+ delete TCB
snd INIT ACK ---| CLOSED | snd INIT ACK ---| CLOSED |
+---------+ +---------+
/ \ [ASSOCIATE] / \ [ASSOCIATE]
/ \ --------------- / \ ---------------
| | create TCB | | create TCB
| | snd INIT | | snd INIT
skipping to change at page 64, line 44 skipping to change at page 64, line 44
/---- DATA /---- DATA
/ [TSN=init TSN_Z / [TSN=init TSN_Z
<--/ Strm=0,Seq=0 & user data 1] <--/ Strm=0,Seq=0 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1, Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=1 & user data 2] \/ Strm=0,Seq=1 & user data 2]
<------/\ <------/\
\ \
\------> \------>
Figure 4: INITiation Example Figure 4: INITIATION Example
If the T1-init timer expires at "A" after the INIT or COOKIE ECHO If the T1-init timer expires at "A" after the INIT or COOKIE ECHO
chunks are sent, the same INIT or COOKIE ECHO chunk with the same chunks are sent, the same INIT or COOKIE ECHO chunk with the same
Initiate Tag (i.e., Tag_A) or State Cookie shall be retransmitted and Initiate Tag (i.e., Tag_A) or State Cookie shall be retransmitted and
the timer restarted. This shall be repeated Max.Init.Retransmits the timer restarted. This shall be repeated Max.Init.Retransmits
times before "A" considers "Z" unreachable and reports the failure to times before "A" considers "Z" unreachable and reports the failure to
its upper layer (and thus the association enters the CLOSED state). its upper layer (and thus the association enters the CLOSED state).
When retransmitting the INIT, the endpoint MUST follow the rules When retransmitting the INIT, the endpoint MUST follow the rules
skipping to change at page 89, line 23 skipping to change at page 89, line 23
Endpoint A Endpoint Z Endpoint A Endpoint Z
{App sends 3 messages; strm 0} {App sends 3 messages; strm 0}
DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed) DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)
(Start T3-rtx timer) (Start T3-rtx timer)
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack) immediately send ack)
/----- SACK [TSN Ack=6,Block=1, /----- SACK [TSN Ack=6,Block=1,
/ Strt=2,End=2] / Start=2,End=2]
<-----/ <-----/
(remove 6 from out-queue, (remove 6 from out-queue,
and mark 7 as "1" missing report) and mark 7 as "1" missing report)
Figure 9 - Reporting a Gap using SACK Figure 9 - Reporting a Gap using SACK
The maximum number of Gap Ack Blocks that can be reported within a The maximum number of Gap Ack Blocks that can be reported within a
single SACK chunk is limited by the current path MTU. When a single single SACK chunk is limited by the current path MTU. When a single
SACK can not cover all the Gap Ack Blocks needed to be reported due SACK can not cover all the Gap Ack Blocks needed to be reported due
to the MTU limitation, the endpoint MUST send only one SACK, to the MTU limitation, the endpoint MUST send only one SACK,
skipping to change at page 111, line 20 skipping to change at page 111, line 20
the local endpoint. the local endpoint.
IMPLEMENTATION NOTE: If this optional attribute is supported by an IMPLEMENTATION NOTE: If this optional attribute is supported by an
implementation, it will be the responsibility of the implementation implementation, it will be the responsibility of the implementation
to enforce that the IP source address field of any SCTP packets sent to enforce that the IP source address field of any SCTP packets sent
out by this endpoint contains one of the IP addresses indicated in out by this endpoint contains one of the IP addresses indicated in
the local eligible address list. the local eligible address list.
B) Associate B) Associate
Format: ASSOCIATE(local SCTP instance name, destination transport addr, Format: ASSOCIATE(local SCTP instance name,
outbound stream count) destination transport addr, outbound stream count)
-> association id [,destination transport addr list] [,outbound stream -> association id [,destination transport addr list]
count] [,outbound stream count]
This primitive allows the upper layer to initiate an association to a This primitive allows the upper layer to initiate an association to a
specific peer endpoint. specific peer endpoint.
The peer endpoint shall be specified by one of the transport The peer endpoint shall be specified by one of the transport
addresses which defines the endpoint (see Section 1.4). If the local addresses which defines the endpoint (see Section 1.4). If the local
SCTP instance has not been initialized, the ASSOCIATE is considered SCTP instance has not been initialized, the ASSOCIATE is considered
an error. an error.
An association id, which is a local handle to the SCTP association, An association id, which is a local handle to the SCTP association,
skipping to change at page 113, line 22 skipping to change at page 113, line 22
o Upper Layer Abort Reason - Reason of the abort to be passed to the o Upper Layer Abort Reason - Reason of the abort to be passed to the
peer. peer.
None. None.
E) Send E) Send
Format: SEND(association id, buffer address, byte count [,context] Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address] [,stream id] [,life time] [,destination transport address]
[,unorder flag] [,no-bundle flag] [,payload protocol-id] ) [,unordered flag] [,no-bundle flag] [,payload protocol-id] )
-> result -> result
This is the main method to send user data via SCTP. This is the main method to send user data via SCTP.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o buffer address - the location where the user message to be o buffer address - the location where the user message to be
transmitted is stored; transmitted is stored;
skipping to change at page 114, line 20 skipping to change at page 114, line 20
implementation simplicity, once a TSN number has been assigned the implementation simplicity, once a TSN number has been assigned the
sender should consider the send of this DATA chunk as committed, sender should consider the send of this DATA chunk as committed,
overriding any lifetime option attached to the DATA chunk. overriding any lifetime option attached to the DATA chunk.
o destination transport address - specified as one of the o destination transport address - specified as one of the
destination transport addresses of the peer endpoint to which this destination transport addresses of the peer endpoint to which this
packet should be sent. Whenever possible, SCTP should use this packet should be sent. Whenever possible, SCTP should use this
destination transport address for sending the packets, instead of destination transport address for sending the packets, instead of
the current primary path. the current primary path.
o unorder flag - this flag, if present, indicates that the user o unordered flag - this flag, if present, indicates that the user
would like the data delivered in an unordered fashion to the peer would like the data delivered in an unordered fashion to the peer
(i.e., the U flag is set to 1 on all DATA chunks carrying this (i.e., the U flag is set to 1 on all DATA chunks carrying this
message). message).
o no-bundle flag - instructs SCTP not to bundle this user data with o no-bundle flag - instructs SCTP not to bundle this user data with
other outbound DATA chunks. SCTP MAY still bundle even when this other outbound DATA chunks. SCTP MAY still bundle even when this
flag is present, when faced with network congestion. flag is present, when faced with network congestion.
o payload protocol-id - A 32 bit unsigned integer that is to be o payload protocol-id - A 32 bit unsigned integer that is to be
passed to the peer indicating the type of payload protocol data passed to the peer indicating the type of payload protocol data
skipping to change at page 117, line 4 skipping to change at page 117, line 4
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
Optional attributes: Optional attributes:
None. None.
I) Change Heartbeat I) Change Heartbeat
Format: CHANGEHEARTBEAT(association id, destination transport address, Format: CHANGE HEARTBEAT(association id,
new state [,interval]) destination transport address, new state [,interval])
-> result -> result
Instructs the local endpoint to enable or disable heartbeat on the Instructs the local endpoint to enable or disable heartbeat on the
specified destination transport address. specified destination transport address.
The result of attempting this operation shall be returned. The result of attempting this operation shall be returned.
Note: Even when enabled, heartbeat will not take place if the Note: Even when enabled, heartbeat will not take place if the
destination transport address is not idle. destination transport address is not idle.
skipping to change at page 118, line 9 skipping to change at page 118, line 9
chunk to the destination address is successful. chunk to the destination address is successful.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o destination transport address - the transport address of the o destination transport address - the transport address of the
association on which a heartbeat should be issued. association on which a heartbeat should be issued.
K) Get SRTT Report K) Get SRTT Report
Format: GETSRTTREPORT(association id, destination transport address) Format: GETSRTTREPORT(association id,
destination transport address)
-> srtt result -> srtt result
Instructs the local SCTP to report the current SRTT measurement on Instructs the local SCTP to report the current SRTT measurement on
the specified destination transport address of the given association. the specified destination transport address of the given association.
The returned result can be an integer containing the most recent SRTT The returned result can be an integer containing the most recent SRTT
in milliseconds. in milliseconds.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
skipping to change at page 118, line 45 skipping to change at page 119, line 4
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o destination transport address - the transport address of the o destination transport address - the transport address of the
association on which the failure detection threshold is to be set. association on which the failure detection threshold is to be set.
o failure threshold - the new value of 'Path.Max.Retrans' for the o failure threshold - the new value of 'Path.Max.Retrans' for the
destination address. destination address.
M) Set Protocol Parameters M) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id,
Format: SETPROTOCOLPARAMETERS(association id, [,destination transport [,destination transport address,]
address,] protocol parameter list) protocol parameter list)
-> result -> result
This primitive allows the local SCTP to customize the protocol This primitive allows the local SCTP to customize the protocol
parameters. parameters.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association o association id - local handle to the SCTP association
o protocol parameter list - The specific names and values of the o protocol parameter list - The specific names and values of the
protocol parameters (e.g., Association.Max.Retrans [see Section 15 protocol parameters (e.g., Association.Max.Retrans [see Section 15
) that the SCTP user wishes to customize. ) that the SCTP user wishes to customize.
skipping to change at page 119, line 22 skipping to change at page 119, line 27
protocol parameters (e.g., Association.Max.Retrans [see Section 15 protocol parameters (e.g., Association.Max.Retrans [see Section 15
) that the SCTP user wishes to customize. ) that the SCTP user wishes to customize.
Optional attributes: Optional attributes:
o destination transport address - some of the protocol parameters o destination transport address - some of the protocol parameters
may be set on a per destination transport address basis. may be set on a per destination transport address basis.
N) Receive unsent message N) Receive unsent message
Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer size Format: RECEIVE_UNSENT(data retrieval id, buffer address,
[,stream id] [, stream sequence number] [,partial flag] buffer size [,stream id] [, stream sequence number]
[,payload protocol-id]) [,partial flag] [,payload protocol-id])
o data retrieval id - The identification passed to the ULP in the o data retrieval id - The identification passed to the ULP in the
failure notification. failure notification.
o buffer address - the memory location indicated by the ULP to store o buffer address - the memory location indicated by the ULP to store
the received message. the received message.
o buffer size - the maximum size of data to be received, in bytes. o buffer size - the maximum size of data to be received, in bytes.
Optional attributes: Optional attributes:
skipping to change at page 120, line 11 skipping to change at page 120, line 18
accompany this receive. When this flag is set to 0, it indicates accompany this receive. When this flag is set to 0, it indicates
that no more deliveries will be received for this stream sequence that no more deliveries will be received for this stream sequence
number. number.
o payload protocol-id - The 32 bit unsigned integer that was sent to o payload protocol-id - The 32 bit unsigned integer that was sent to
be sent to the peer indicating the type of payload protocol of the be sent to the peer indicating the type of payload protocol of the
received data. received data.
o Receive unacknowledged message o Receive unacknowledged message
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size, Format: RECEIVE_UNACKED(data retrieval id, buffer address,
[,stream id] [, stream sequence number] [,partial flag] buffer size, [,stream id] [, stream sequence number]
[,payload protocol-id]) [,partial flag] [,payload protocol-id])
o data retrieval id - The identification passed to the ULP in the o data retrieval id - The identification passed to the ULP in the
failure notification. failure notification.
o buffer address - the memory location indicated by the ULP to store o buffer address - the memory location indicated by the ULP to store
the received message. the received message.
o buffer size - the maximum size of data to be received, in bytes. o buffer size - the maximum size of data to be received, in bytes.
Optional attributes: Optional attributes:
skipping to change at page 130, line 9 skipping to change at page 130, line 9
large packet in response, due to the inclusion of multiple ERROR large packet in response, due to the inclusion of multiple ERROR
parameters, MAY (at its discretion) elect to omit some or all of the parameters, MAY (at its discretion) elect to omit some or all of the
ERROR parameters to reduce the size of the INIT-ACK. Due to a ERROR parameters to reduce the size of the INIT-ACK. Due to a
combination of the size of the COOKIE parameter and the number of combination of the size of the COOKIE parameter and the number of
addresses a receiver of an INIT may be indicating to a peer, it is addresses a receiver of an INIT may be indicating to a peer, it is
always possible that the INIT-ACK will be larger than the original always possible that the INIT-ACK will be larger than the original
INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as
small as possible to reduce the possibility of byte amplification small as possible to reduce the possibility of byte amplification
attacks. attacks.
12. Network Managment Considerations 12. Network Management Considerations
A MIB for SCTP is defined in [RFC3873]. A MIB for SCTP is defined in [RFC3873].
13. Recommended Transmission Control Block (TCB) Parameters 13. Recommended Transmission Control Block (TCB) Parameters
This section details a recommended set of parameters that should be This section details a recommended set of parameters that should be
contained within the TCB for an implementation. This section is for contained within the TCB for an implementation. This section is for
illustrative purposes and should not be deemed as requirements on an illustrative purposes and should not be deemed as requirements on an
implementation or as an exhaustive list of all parameters inside an implementation or as an exhaustive list of all parameters inside an
SCTP TCB. Each implementation may need its own additional parameters SCTP TCB. Each implementation may need its own additional parameters
skipping to change at page 133, line 35 skipping to change at page 133, line 35
: ALLOW-HB, NO-HEARTBEAT, etc. : ALLOW-HB, NO-HEARTBEAT, etc.
PMTU : The current known path MTU. PMTU : The current known path MTU.
Per : A timer used by each destination. Per : A timer used by each destination.
Destination : Destination :
Timer : Timer :
RTO-Pending : A flag used to track if one of the DATA chunks sent to RTO-Pending : A flag used to track if one of the DATA chunks sent to
this address is currently being used to compute a this address is currently being used to compute a
RTT. If this flag is 0, the next DATA chunk sent to this RTT. If this flag is 0, the next DATA chunk sent to
destination should be used to compute a RTT and this this destination should be used to compute a RTT and
flag should be set. Every time the RTT calculation this flag should be set. Every time the RTT
completes (i.e. the DATA chunk is SACK'd) clear this calculation completes (i.e. the DATA chunk is SACK'd)
flag. clear this flag.
last-time : The time this destination was last sent to. This can be last-time : The time this destination was last sent to. This can be
used : used to determine if a HEARTBEAT is needed. used : used to determine if a HEARTBEAT is needed.
13.4. General Parameters Needed 13.4. General Parameters Needed
Out Queue : A queue of outbound DATA chunks. Out Queue : A queue of outbound DATA chunks.
In Queue : A queue of inbound DATA chunks. In Queue : A queue of inbound DATA chunks.
skipping to change at page 136, line 51 skipping to change at page 136, line 51
Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney, Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney,
Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon
Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme, Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme,
Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg
Sidebottom, Brian Wyld, La Monte Yarroll, and many others for their Sidebottom, Brian Wyld, La Monte Yarroll, and many others for their
invaluable comments. invaluable comments.
then add the authors of the SCTP implementors guide, I. Arias- then add the authors of the SCTP implementors guide, I. Arias-
Rodriguez, K. Poon, A. Caro, M. Tuexen, Rodriguez, K. Poon, A. Caro, M. Tuexen,
Add to these the efforts of all the subsequent seven SCTP inter- Add to these the efforts of all the subsequent seven SCTP
operability tests and those who commented on the RFC4460 as shown in interoperability tests and those who commented on the RFC4460 as
its acknowledgments: shown in its acknowledgments:
Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng, Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng,
Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina
Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte, Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte,
Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC
Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel, Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel,
Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan, Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan,
Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann, Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann,
Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth
Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John
skipping to change at page 147, line 26 skipping to change at page 147, line 26
[ITU32] "ITU-T Recommendation V.42, "Error-correcting procedures [ITU32] "ITU-T Recommendation V.42, "Error-correcting procedures
for DCEs using asynchronous-to-synchronous conversion".", for DCEs using asynchronous-to-synchronous conversion".",
ITU-T section 8.1.1.6.2. ITU-T section 8.1.1.6.2.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP",
RFC 813, July 1982.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990. November 1990.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, August 1996.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999. Control", RFC 2581, April 1999.
[RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission [RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission
Protocol (SCTP) Management Information Base (MIB)", Protocol (SCTP) Management Information Base (MIB)",
RFC 3873, September 2004. RFC 3873, September 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
skipping to change at page 148, line 46 skipping to change at page 148, line 36
17.2. Informative References 17.2. Informative References
[FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of [FALL96] Fall, K. and S. Floyd, "Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP", SIGCOMM'99 V. 26 N. 3 pp 5-21, Tahoe, Reno, and SACK TCP", SIGCOMM'99 V. 26 N. 3 pp 5-21,
July 1996. July 1996.
[SAVAGE99] [SAVAGE99]
Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
"TCP Congestion Control with a Misbehaving Receiver", ACM "TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Commuinications Review 29(5), October 1999. Computer Communications Review 29(5), October 1999.
[ALLMAN99] [ALLMAN99]
Allman, M. and V. Paxson, "On Estimating End-to-End Allman, M. and V. Paxson, "On Estimating End-to-End
Network Path Properties", SIGCOMM'99 , 1999. Network Path Properties", SIGCOMM'99 , 1999.
[WILLIAMS93] [WILLIAMS93]
Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION
ALGORITHMS" - Internet publication http:// ALGORITHMS" - Internet publication http://
www.geocities.com/SiliconValley/Pines/8659/crc.htm.", www.geocities.com/SiliconValley/Pines/8659/crc.htm.",
August 1993. August 1993.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP",
Specification version 3.3", RFC 1950, May 1996. RFC 813, July 1982.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196,
September 1997. September 1997.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999. Protocol", RFC 2522, March 1999.
skipping to change at page 150, line 7 skipping to change at page 150, line 7
Editor Editor
4875 Forest Drive 4875 Forest Drive
Suite 200 Suite 200
Columbia, SC 29206 Columbia, SC 29206
US US
Email: rrs@cisco.com Email: rrs@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 31 change blocks. 
60 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/