0 to N-1.
- The transport-level byte-stream is mapped to a polynomial
value. An N-byte PDU with j bytes numbered 0 to N-1 is
considered as coefficients of a polynomial M(x) of order
8N-1, with bit 0 of byte j being coefficient x^(8(N-j)-8),
and bit 7 of byte j being coefficient x^(8(N-j)-1).
- The CRC remainder register is initialized with all 1s and
the CRC is computed with an algorithm that simultaneously
multiplies by x^32 and divides by the CRC polynomial.
- The polynomial is multiplied by x^32 and divided by G(x),
the generator polynomial, producing a remainder R(x) of
degree less than or equal to 31.
- The coefficients of R(x) are considered a 32-bit sequence.
- The bit sequence is complemented. The result is the CRC
polynomial.
- The CRC polynomial is mapped back into SCTP transport-level
bytes. The coefficient of x^31 gives the value of bit 7 of
SCTP byte 0, and the coefficient of x^24 gives the value of
bit 0 of byte 0. The coefficient of x^7 gives bit 7 of
byte 3, and the coefficient of x^0 gives bit 0 of byte 3.
The resulting four-byte transport-level sequence is the
32-bit SCTP checksum value.
IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor
literature on CRCs often follow an alternative formulation, in
which the register used to hold the remainder of the
long-division algorithm is initialized to zero rather than
all-1s, and instead the first 32 bits of the message are
complemented. The long-division algorithm used in our
formulation is specified such that the initial
multiplication by 2^32 and the long-division are combined into
one simultaneous operation. For such algorithms, and for
messages longer than 64 bits, the two specifications are
precisely equivalent. That equivalence is the intent of
this document.
Implementors of SCTP are warned that both specifications are to be
found in the literature, sometimes with no restriction on the
long-division algorithm. The choice of formulation in this
document is to permit non-SCTP usage, where the same CRC
algorithm may be used to protect messages shorter than 64 bits.
There may be a computational advantage in validating the
Association against the Verification Tag, prior to performing a
checksum, as invalid tags will result in the same action as a bad
checksum in most cases. The exceptions for this technique would
be INIT and some SHUTDOWN-COMPLETE exchanges, as well as a stale
COOKIE-ECHO. These special case exchanges must represent small
packets and will minimize the effect of the checksum calculation.
---------
Old text: (Section 18)
---------
18. Bibliography
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM’99, 1999.
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
---------
New text: (Section 18, including changes from 2.11)
---------
18. Bibliography
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM’99, 1999.
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[ITU32] ITU-T Recommendation V.42, "Error-correcting
procedures for DCEs using asynchronous-to-synchronous
conversion", Section 8.1.1.6.2, October 1996.
[PETERSON 1972] W. W. Peterson and E.J Weldon, Error Correcting
Codes, 2nd Edition, MIT Press, Cambridge,
Massachusetts.
[RFC1750] Eastlake, D., Ed., "Randomness Recommendations for
Security", RFC 1750, December 1994.
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
[WILLIAMS93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR
DETECTION ALGORITHMS" - Internet publication, August
1993,
http://www.geocities.com/SiliconValley/Pines/
8659/crc.htm.
2.38.3. Solution Description
This change adds to the implementor’s guide the complete set of
changes that, when combined with RFC 2960 [5], encompasses the
changes from RFC 3309 [6].
2.39. Retransmission Policy
2.39.1. Description of the Problem
The current retransmission policy (send all retransmissions an
alternate destination) in the specification has performance issues
under certain loss conditions with multihomed endpoints. Instead,
fast retransmissions should be sent to the same destination, and only
timeout retransmissions should be sent to an alternate destination
[4].
2.39.2. Text Changes to the Document
---------
Old text: (Section 6.4)
---------
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
retransmit a chunk to an active destination transport address that is
different from the last destination address to which the DATA chunk
was sent.
---------
New text: (Section 6.4)
---------
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
retransmit a chunk that timed out to an active destination transport
address that is different from the last destination address to which
the DATA chunk was sent.
---------
Old text: (Section 6.4.1)
---------
When retransmitting data, if the endpoint is multi-homed, it should
consider each source-destination address pair in its retransmission
selection policy. When retransmitting the endpoint should attempt to
pick the most divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
---------
New text: (Section 6.4.1)
---------
When retransmitting data that timed out, if the endpoint is
multi-homed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
2.39.3. Solution Description
The above wording changes clarify that only timeout retransmissions
should be sent to an alternate active destination.
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