draft-ietf-tsvwg-sctpcsum-05.txt   draft-ietf-tsvwg-sctpcsum-06.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Category: Internet Draft Cisco Systems Category: Internet Draft Cisco Systems
J. Stone J. Stone
Stanford Stanford
D. Otis D. Otis
SANlight SANlight
April 3, 2002 April 23, 2002
Stream Control Transmission Protocol (SCTP) Checksum Change Stream Control Transmission Protocol (SCTP) Checksum Change
draft-ietf-tsvwg-sctpcsum-05.txt draft-ietf-tsvwg-sctpcsum-06.txt
Status of this Memo Status of this Memo
This document is an internet-draft and is in full conformance with all This document is an internet-draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. Internet- may also distribute working documents as Internet-Drafts. Internet-
Drafts are draft documents valid for a maximum of six months and may be Drafts are draft documents valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress." 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.
Abstract Abstract
Stream Control Tranmission Protocol [RFC2960] (SCTP) currently uses an Stream Control Transmission Protocol [RFC2960] (SCTP) currently uses an
Adler-32 checksum. For small packets Adler-32 provides weak detection Adler-32 checksum. For small packets Adler-32 provides weak detection
of errors. This document changes that checksum and updates SCTP to of errors. This document changes that checksum and updates SCTP to
use a 32 bit CRC checksum. use a 32 bit CRC checksum.
Table of Contents Table of Contents
1 Introduction ................................................1 1 Introduction ................................................1
2 Checksum Procedures .........................................2 2 Checksum Procedures .........................................2
3 Security Considerations......................................5 3 Security Considerations......................................6
4 IANA Considerations..........................................5 4 IANA Considerations..........................................6
5 Acknowledgments .............................................5 5 Acknowledgments .............................................6
6 Authors' Addresses ..........................................6 6 Authors' Addresses ..........................................6
7 References ..................................................6 7 References ..................................................7
8 Appendix ....................................................7 8 Appendix ....................................................8
1 Introduction 1 Introduction
A fundamental weakness has been detected in SCTP's current Adler-32 A fundamental weakness has been detected in SCTP's current Adler-32
checksum algorithm [STONE]. One requirement of an effective checksum is checksum algorithm [STONE]. One requirement of an effective checksum is
that it evenly and smoothly spreads its input packets over the available that it evenly and smoothly spreads its input packets over the available
check bits. check bits.
From an email from Jonathan Stone, who analyzed the Adler-32 as part From an email from Jonathan Stone, who analyzed the Adler-32 as part
Internet draft SCTP Checksum Change April 2002
of his doctoral thesis: of his doctoral thesis:
"Briefly, the problem is that, for very short packets, Adler32 is "Briefly, the problem is that, for very short packets, Adler32 is
guaranteed to give poor coverage of the available bits. Don't take my guaranteed to give poor coverage of the available bits. Don't take my
word for it, ask Mark Adler. :-). word for it, ask Mark Adler. :-).
Adler-32 uses two 16-bit counters, s1 and s2. s1 is the sum of the Adler-32 uses two 16-bit counters, s1 and s2. s1 is the sum of the
input, taken as 8-bit bytes. s2 is a running sum of each value of s1. input, taken as 8-bit bytes. s2 is a running sum of each value of s1.
Both s1 and s2 are computed mod-65521 (the largest prime less than 2^16). Both s1 and s2 are computed mod-65521 (the largest prime less than 2^16).
Consider a packet of 128 bytes. The *most* that each byte can be is 255. Consider a packet of 128 bytes. The *most* that each byte can be is 255.
skipping to change at page 2, line 60 skipping to change at page 3, line 4
1.1 Conventions 1.1 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,SHOULD
NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in
this document, are to be interpreted as described in [RFC2119]. this document, are to be interpreted as described in [RFC2119].
2 Checksum Procedures 2 Checksum Procedures
The procedures described in section 2.1 of this document MUST be The procedures described in section 2.1 of this document MUST be
followed, replacing the current checksum defined in [RFC2960]. followed, replacing the current checksum defined in [RFC2960].
Furthermore any references within [RFC2960] to Adler-32 MUST be treated
Internet draft SCTP Checksum Change April 2002
Furthermore any references within [RFC2960] to Adler-32 MUST be treated
as a reference to CRC-32c. Section 2.1 of this document describes the as a reference to CRC-32c. Section 2.1 of this document describes the
new calculation and verification procedures that MUST be followed. new calculation and verification procedures that MUST be followed.
2.1 Checksum Calculation 2.1 Checksum Calculation
When sending an SCTP packet, the endpoint MUST include in the checksum When sending an SCTP packet, the endpoint MUST strengthen the data
field the CRC-32c value calculated on the packet, as described below. integrity of the transmission by including the CRC-32c checksum
value calculated on the packet, as described below.
After the packet is constructed (containing the SCTP common header and After the packet is constructed (containing the SCTP common header
one or more control or DATA chunks), the transmitter MUST do the and one or more control or DATA chunks), the transmitter shall:
following:
1) Fill in the proper Verification Tag in the SCTP common header and 1) Fill in the proper Verification Tag in the SCTP common header and
initialize the Checksum field to 0's. initialize the Checksum field to 0's.
2) Calculate the CRC-32c of the whole packet, including the SCTP common 2) Calculate the CRC-32c of the whole packet, including the SCTP common
header and all the chunks. header and all the chunks.
3) Put the resultant value into the Checksum field in the common header, 3) Put the resultant value into the Checksum field in the common header,
and leave the rest of the bits unchanged. and leave the rest of the bits unchanged.
When an SCTP packet is received, the receiver MUST first perform the When an SCTP packet is received, the receiver MUST first check the
following: CRC-32c checksum:
1) Store the received CRC-32c value, 1) Store the received CRC-32c value,
2) Replace the 32 bits of the Checksum field in the received SCTP packet 2) Replace the 32 bits of the Checksum field in the received SCTP packet
with all '0's and calculate a CRC-32c value of the whole received with all '0's and calculate a CRC-32c value of the whole received
packet. And, packet. And,
3) Verify that the calculated CRC-32c value is the same as the received 3) Verify that the calculated CRC-32c value is the same as the received
CRC-32c value. If not, the receiver MUST treat the packet as an CRC-32c value. If not, the receiver MUST treat the packet as an
invalid SCTP packet. invalid SCTP packet.
The default procedure for handling invalid SCTP packets is to silently The default procedure for handling invalid SCTP packets is to silently
discard them. discard them.
Any implementation using hardware assists for checksum computation
MUST make the final CRC value available to the software portion of
the stack. Such implementations SHOULD also make the buffer size
used by the hardware unit available to software.
NOTE: this requirement explicitly forbids hardware-acceleration
implementations which provide only a one-bit indication, ``checksum
valid'' or ``checksum invalid'. This requirement is to permit
software to audit the hardware assist: to re-compute the SCTP
checksum over the identical input seen by the outboard hardware
accelerator, and make a comparison of the software-computed and
hardware-assisted values.
This requirement is motivated by experience with a variety of TCP/IP
checksum assists. Bugs in outboard checksum-assist implementations
(which may occur only under certain edge conditions) but which did
not provide the additional information specified here, leave
protocol implementors with little choice but to completely disable
the checksum assist.
An implementation using hardware assist is encouraged to follow the
exact procedure specified above. Whatever implementation strategy
an implementation chooses, it MUST arrange to provide both the
initial value of the checksum field, and the value computed for the
SCTP checksum, to the software stack.
IMPLEMENTATION NOTE: One recommended implementation strategy is:
* save the contents of the checksum field;
* zero out the checksum field;
* compute the checksum;
* the checksum implementation then provides both the
checksum computed over the zeroed-out field, and the initial
value of that zeroed-out field to software.
This strategy is believed to be robust against errors in an
outboard acceleration unit, and against communication errors (or
memory-addressing errors) between an outboard CRC acceleration
unit and the software stack. It also provides a clean path for
retrofitting hardware checksum acceleration into a previously
`software-only' SCTP stack.
We define a 'reflected value' as one that is the opposite of the We define a 'reflected value' as one that is the opposite of the
normal bit order of the machine. The 32 bit CRC is normal bit order of the machine. The 32 bit CRC is
calculated as described for CRC-32c and uses the polynomial code calculated as described for CRC-32c and uses the polynomial code
0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25 0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25
+x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. +x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0.
The CRC is computed using a procedure similar to ETHERNET CRC [ITU32], The CRC is computed using a procedure similar to ETHERNET CRC [ITU32],
modified to reflect transport level usage. modified to reflect transport level usage.
CRC computation uses polynomial division. A message bit-string M CRC computation uses polynomial division. A message bit-string M
is transformed to a polynomial, M(X), and the CRC is calculated is transformed to a polynomial, M(X), and the CRC is calculated
from M(X) using polynomial arithmetic [Peterson 72]. from M(X) using polynomial arithmetic [Peterson 72].
When CRCs are used at the link layer, the polynomial is derived from When CRCs are used at the link layer, the polynomial is derived from
on-the-wire bit ordering: the first bit `on the wire' is on-the-wire bit ordering: the first bit `on the wire' is
the high-order coefficient. Since SCTP is a transport-level protocol, the high-order coefficient. Since SCTP is a transport-level protocol,
it cannot know the actual serial-media bit ordering. Moreover, it cannot know the actual serial-media bit ordering. Moreover,
different links in the path between SCTP endpoints may use different links in the path between SCTP endpoints may use
different link-level bit orders) different link-level bit orders)
Internet draft SCTP Checksum Change April 2002
A convention must therefore be established for mapping SCTP transport A convention must therefore be established for mapping SCTP transport
messages to polynomials for purposes of CRC computation. messages to polynomials for purposes of CRC computation.
The bit-ordering for mapping SCTP messages to polynomials is The bit-ordering for mapping SCTP messages to polynomials is
that bytes are taken most-significant first; but within each byte, that bytes are taken most-significant first; but within each byte,
bits are taken least-significant first. The first byte of the bits are taken least-significant first. The first byte of the
message provides the eight highest coefficients. message provides the eight highest coefficients.
Within each byte, the least-significant SCTP bit gives the Within each byte, the least-significant SCTP bit gives the
most significant polynomial coefficient within that byte, and most significant polynomial coefficient within that byte, and
the most-significant SCTP bit is the most significant polynomial the most-significant SCTP bit is the most significant polynomial
coefficient in that byte. (This bit ordering is sometimes coefficient in that byte. (This bit ordering is sometimes
skipping to change at page 5, line 4 skipping to change at page 5, line 47
algorithm is initialized to zero rather than all-1s, and instead the algorithm is initialized to zero rather than all-1s, and instead the
first 32 bits of the message are complemented. The long-division first 32 bits of the message are complemented. The long-division
algorithm used in our formulation is specified such that the the algorithm used in our formulation is specified such that the the
initial multiplication by 2^32 and the long-division, into one initial multiplication by 2^32 and the long-division, into one
simultaneous operation. For such algorithms, and for messages longer simultaneous operation. For such algorithms, and for messages longer
than 64 bits, the two specifications are precisely equivalent. That than 64 bits, the two specifications are precisely equivalent. That
equivalence is the intent of this document. Implementors of SCTP are equivalence is the intent of this document. Implementors of SCTP are
warned that both specifications are to be found in the literature, warned that both specifications are to be found in the literature,
sometimes with no restriction on the long-division algorithm. sometimes with no restriction on the long-division algorithm.
The choice of formulation in this document is to permit non-SCTP The choice of formulation in this document is to permit non-SCTP
Internet draft SCTP Checksum Change April 2002
usage, where the same CRC algorithm may be used to protect messages usage, where the same CRC algorithm may be used to protect messages
shorter than 64 bits. shorter than 64 bits.
If SCTP could follow link level CRC use, the CRC would be computed If SCTP could follow link level CRC use, the CRC would be computed
over the link-level bit-stream. The first bit on the link over the link-level bit-stream. The first bit on the link
mapping to the highest-order coefficient, and so on down to the mapping to the highest-order coefficient, and so on down to the
last link-level bit as the lowest-order coefficient. The CRC value last link-level bit as the lowest-order coefficient. The CRC value
would be transmitted immediately after the input message as a link-level would be transmitted immediately after the input message as a link-level
`trailer'. The resulting link-level bit-stream would be `trailer'. The resulting link-level bit-stream would be
(M(X)x) * x^32) + (M(X)*x^32))/ G(x), which is divisible by G(X). (M(X)x) * x^32) + (M(X)*x^32))/ G(x), which is divisible by G(X).
skipping to change at page 5, line 49 skipping to change at page 6, line 36
4 IANA Considerations 4 IANA Considerations
There are no IANA considerations required in this document. There are no IANA considerations required in this document.
5 Acknowledgments 5 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 on the checksum issue: provided comments and input on the checksum issue:
Mark Adler, Ran Atkinson, Stephen Bailey, David Black, Scott Mark Adler, Ran Atkinson, Stephen Bailey, David Black, Brian
Bradner, Mikael Degermark, Laurent Glaude, Klaus Gradischnig, Alf Bidulock, Scott Bradner, Mikael Degermark, Laurent Glaude, Klaus
Heidermark, Jacob Heitz, Gareth Kiely, David Lehmann, Allision Gradischnig, Alf Heidermark, Jacob Heitz, Gareth Kiely, David
Mankin, Lyndon Ong, Craig Partridge, Vern Paxson, Kacheong Poon, Lehmann, Allision Mankin, Lyndon Ong, Craig Partridge, Vern Paxson,
Michael Ramalho, David Reed, Ian Rytina, Hanns Juergen Schwarzbauer, Kacheong Poon, Michael Ramalho, David Reed, Ian Rytina, Hanns
Chip Sharp, Bill Sommerfeld, Michael Tuexen, Jim Williams, Jim Wendt, Juergen Schwarzbauer, Chip Sharp, Bill Sommerfeld, Michael Tuexen,
Michael Welzl, Jonathan Wood, Lloyd Wood, Qiaobing Xie, La Monte Jim Williams, Jim Wendt, Michael Welzl, Jonathan Wood, Lloyd Wood,
Yarroll. Qiaobing Xie, La Monte Yarroll.
Special thanks to Dafna Scheinwald, Julian Satran Pat Thaler, Matt Special thanks to Dafna Scheinwald, Julian Satran Pat Thaler, Matt
Wakeley, and Vince Cavanna, for selection criteria of polynomials and Wakeley, and Vince Cavanna, for selection criteria of polynomials and
examination of CRC polynomials, particularly CRC-32c [Castagnoli93]. examination of CRC polynomials, particularly CRC-32c [Castagnoli93].
Internet draft SCTP Checksum Change April 2002
Special thanks to Mr. Ross Williams and his document [Williams93]. Special thanks to Mr. Ross Williams and his document [Williams93].
This non-formal perspective on software aspects of CRCs furthered This non-formal perspective on software aspects of CRCs furthered
understanding of authors previously unfamiliar with CRC computation. understanding of authors previously unfamiliar with CRC computation.
More formal treatments of [Blahut 94] or [Peterson 72], was More formal treatments of [Blahut 94] or [Peterson 72], was
also essential. also essential.
6 Authors' Addresses 6 Authors' Addresses
Randall R. Stewart Randall R. Stewart
24 Burning Bush Trail. 24 Burning Bush Trail.
skipping to change at page 7, line 5 skipping to change at page 7, line 46
3", BCP 9, RFC 2026, October 1996. 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.
[RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp,
H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang,
and, V. Paxson, "Stream Control Transmission Protocol," RFC and, V. Paxson, "Stream Control Transmission Protocol," RFC
2960, October 2000. 2960, October 2000.
Internet draft SCTP Checksum Change April 2002
[ITU32] ITU-T Recommendation V.42, "Error-correcting [ITU32] ITU-T Recommendation V.42, "Error-correcting
procedures for DCEs using asynchronous-to-synchronous procedures for DCEs using asynchronous-to-synchronous
conversion", section 8.1.1.6.2, October 1996. conversion", section 8.1.1.6.2, October 1996.
7.1 Informative References 7.1 Informative References
[STONE] Stone, J., "Checksums in the Internet", Doctoral [STONE] Stone, J., "Checksums in the Internet", Doctoral
dissertation - August 2001 dissertation - August 2001
[Williams93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION [Williams93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION
skipping to change at page 8, line 4 skipping to change at page 8, line 46
This appendix is for information only and is NOT part of the This appendix is for information only and is NOT part of the
standard. standard.
The anticipated deployment of SCTP ranges over several orders of The anticipated deployment of SCTP ranges over several orders of
magnitude of link speed: from cellular-power telephony devices at magnitude of link speed: from cellular-power telephony devices at
tens of kilobits, to local links at tens of gigabits. Implementors tens of kilobits, to local links at tens of gigabits. Implementors
of SCTP should consider their link speed and choose, from the wide of SCTP should consider their link speed and choose, from the wide
range of CRC implementations, one which matches their own design range of CRC implementations, one which matches their own design
point for size, cost, and throughput. Many techniques for computing point for size, cost, and throughput. Many techniques for computing
Internet draft SCTP Checksum Change April 2002
CRCs are known. This Appendix surveys just a few, to give a feel for CRCs are known. This Appendix surveys just a few, to give a feel for
the range of techniques available. the range of techniques available.
CRCs are derived from early work by Prange in the 1950s [Prange 57]. CRCs are derived from early work by Prange in the 1950s [Prange 57].
The theory underlying CRCs and choice of generator polynomial can be The theory underlying CRCs and choice of generator polynomial can be
introduced by either via the theory of Galois fields [Blahut 94] introduced by either via the theory of Galois fields [Blahut 94]
or as ideals of an algebra over cyclic codes [cite Peterson 72]. or as ideals of an algebra over cyclic codes [cite Peterson 72].
One of the simplest techniques is direct bit-serial hardware One of the simplest techniques is direct bit-serial hardware
implementations, using the generator polynomial as the taps of a implementations, using the generator polynomial as the taps of a
skipping to change at page 9, line 5 skipping to change at page 9, line 47
total size. total size.
Implementors should keep in mind the bit ordering described in Implementors should keep in mind the bit ordering described in
Section 2: the ordering of bits within bytes for computing CRCs in Section 2: the ordering of bits within bytes for computing CRCs in
SCTP is the least significant bit of each byte is the SCTP is the least significant bit of each byte is the
most-significant polynomial coefficient(and vice-versa). This most-significant polynomial coefficient(and vice-versa). This
`reflected' SCTP CRC bit ordering matches on-the-wire bit order for `reflected' SCTP CRC bit ordering matches on-the-wire bit order for
Ethernet and other serial media, but is the reverse of traditional Ethernet and other serial media, but is the reverse of traditional
Internet bit ordering. Internet bit ordering.
Internet draft SCTP Checksum Change April 2002
One technique to accommodate this bit-reversal can be explained as One technique to accommodate this bit-reversal can be explained as
follows: sketch out a hardware implementation assuming the bits are follows: sketch out a hardware implementation assuming the bits are
in CRC bit order; then perform a left-to-right inversion (mirror in CRC bit order; then perform a left-to-right inversion (mirror
image) on the entire algorithm. (We defer for a moment the issue of image) on the entire algorithm. (We defer for a moment the issue of
byte order within words.) Then compute that "mirror image" in byte order within words.) Then compute that "mirror image" in
software. The CRC from the ``mirror image'' algorithm will be the software. The CRC from the ``mirror image'' algorithm will be the
bit-reversal of a correct hardware implementation. When the bit-reversal of a correct hardware implementation. When the
link-level media sends each byte, the byte is sent in the reverse of link-level media sends each byte, the byte is sent in the reverse of
the host CPU bit-order. Serialization of each byte of the the host CPU bit-order. Serialization of each byte of the
``reflected'' CRC value re-reverses the bit order, so in the end, ``reflected'' CRC value re-reverses the bit order, so in the end,
skipping to change at page 10, line 4 skipping to change at page 10, line 47
0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL,
0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL,
0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L,
0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL,
0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L,
0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L,
0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL,
0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL,
0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L,
0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L,
Internet draft SCTP Checksum Change April 2002
0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL,
0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L,
0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL,
0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL,
0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L,
0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L,
0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L,
0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L,
0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L,
0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L,
skipping to change at page 11, line 5 skipping to change at page 11, line 48
0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL,
0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L,
0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L,
0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL,
0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L,
0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL,
0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL,
0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L,
}; };
Internet draft SCTP Checksum Change April 2002
#endif #endif
/* Example of table build routine */ /* Example of table build routine */
#include <stdio.h> #include <stdio.h>
#include <stdlib.h> #include <stdlib.h>
#define OUTPUT_FILE "crc32cr.h" #define OUTPUT_FILE "crc32cr.h"
#define CRC32C_POLY 0x1EDC6F41L #define CRC32C_POLY 0x1EDC6F41L
FILE *tf; FILE *tf;
skipping to change at page 12, line 4 skipping to change at page 12, line 47
main () main ()
{ {
int i; int i;
printf ("\nGenerating CRC-32c table file <%s>\n", OUTPUT_FILE); printf ("\nGenerating CRC-32c table file <%s>\n", OUTPUT_FILE);
if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){ if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){
printf ("Unable to open %s\n", OUTPUT_FILE); printf ("Unable to open %s\n", OUTPUT_FILE);
exit (1); exit (1);
} }
Internet draft SCTP Checksum Change April 2002
fprintf (tf, "#ifndef __crc32cr_table_h__\n"); fprintf (tf, "#ifndef __crc32cr_table_h__\n");
fprintf (tf, "#define __crc32cr_table_h__\n\n"); fprintf (tf, "#define __crc32cr_table_h__\n\n");
fprintf (tf, "#define CRC32C_POLY 0x%08lX\n", CRC32C_POLY); fprintf (tf, "#define CRC32C_POLY 0x%08lX\n", CRC32C_POLY);
fprintf (tf, "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n"); fprintf (tf, "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf (tf, "\nunsigned long crc_c[256] =\n{\n"); fprintf (tf, "\nunsigned long crc_c[256] =\n{\n");
for (i = 0; i < 256; i++){ for (i = 0; i < 256; i++){
fprintf (tf, "0x%08lXL, ", build_crc_table (i)); fprintf (tf, "0x%08lXL, ", build_crc_table (i));
if ((i & 3) == 3) if ((i & 3) == 3)
fprintf (tf, "\n"); fprintf (tf, "\n");
} }
skipping to change at page 13, line 4 skipping to change at page 13, line 44
* Note that a 32-bit bit-reversal is identical to four inplace * Note that a 32-bit bit-reversal is identical to four inplace
* 8-bit reversals followed by an end-for-end byteswap. * 8-bit reversals followed by an end-for-end byteswap.
* In other words, the bytes of each bit are in the right order, * In other words, the bytes of each bit are in the right order,
* but the bytes have been byteswapped. So we now do an explicit * but the bytes have been byteswapped. So we now do an explicit
* byteswap. On a little-endian machine, this byteswap and * byteswap. On a little-endian machine, this byteswap and
* the final ntohl cancel out and could be elided. * the final ntohl cancel out and could be elided.
*/ */
byte0 = result & 0xff; byte0 = result & 0xff;
byte1 = (result>>8) & 0xff; byte1 = (result>>8) & 0xff;
byte2 = (result>>16) & 0xff; byte2 = (result>>16) & 0xff;
Internet draft SCTP Checksum Change April 2002
byte3 = (result>>24) & 0xff; byte3 = (result>>24) & 0xff;
crc32 = ((byte0 << 24) | crc32 = ((byte0 << 24) |
(byte1 << 16) | (byte1 << 16) |
(byte2 << 8) | (byte2 << 8) |
byte3); byte3);
return ( crc32 ); return ( crc32 );
} }
int int
skipping to change at page 14, line 4 skipping to change at page 14, line 47
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into Standards process must be followed, or as required to translate it into
languages other than English. languages other than English.
Internet draft SCTP Checksum Change April 2002
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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