draft-ietf-tsvwg-sctpcsum-04.txt		draft-ietf-tsvwg-sctpcsum-05.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
	March 22, 2002		April 3, 2002
	SCTP Checksum Change		Stream Control Transmission Protocol (SCTP) Checksum Change
	draft-ietf-tsvwg-sctpcsum-04.txt		draft-ietf-tsvwg-sctpcsum-05.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
	SCTP [RFC2960] currently uses an Adler-32 checksum. For small packets		Stream Control Tranmission Protocol [RFC2960] (SCTP) currently uses an
	Adler-32 provides weak detection of errors. This document changes that		Adler-32 checksum. For small packets Adler-32 provides weak detection
	checksum and updates SCTP to use a 32 bit CRC checksum.		of errors. This document changes that checksum and updates SCTP to
			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......................................6		3 Security Considerations......................................5
	4 IANA Considerations..........................................6		4 IANA Considerations..........................................5
	5 Acknowledgments .............................................6		5 Acknowledgments .............................................5
	6 Authors' Addresses ..........................................6		6 Authors' Addresses ..........................................6
	7 References ..................................................7		7 References ..................................................6
	8 Appendix ....................................................8		8 Appendix ....................................................7
	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 3, line 4		skipping to change at page 3, line 4
	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		Furthermore any references within [RFC2960] to Adler-32 MUST be treated
			Internet draft SCTP Checksum Change April 2002
	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 include in the checksum
	field the CRC-32c value calculated on the packet, as described below.		field the CRC-32c 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 and
	one or more control or DATA chunks), the transmitter MUST do the		one or more control or DATA chunks), the transmitter MUST do the
	skipping to change at page 4, line 4		skipping to change at page 4, line 4
	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 4, line 36		skipping to change at page 4, line 39
	- the CRC remainder register is initialized with all 1s		- the CRC remainder register is initialized with all 1s
	and the CRC is computed with an algorithm that		and the CRC is computed with an algorithm that
	simultaneously multiplies by x^32 and divides by the CRC		simultaneously multiplies by x^32 and divides by the CRC
	polynomial.		polynomial.
	- the polynomial is multiplied by x^32 and divided by G(x),		- the polynomial is multiplied by x^32 and divided by G(x),
	the generator polynomial, producing a remainder R(x) of degree		the generator polynomial, producing a remainder R(x) of degree
	less than or equal to 31.		less than or equal to 31.
	- the coefficients of R(x) are considered a 32 bit sequence.		- the coefficients of R(x) are considered a 32 bit sequence.
	- the bit sequence is complemented. The resulting is the CRC		- the bit sequence is complemented. The resulting is the CRC
	polynomial.		polynomial.
	- The CRC polynomial is mapped back into SCTP transport-level		- The CRC polynomial is mapped back into SCTP transport-level
	bytes. Coefficient of x^31 gives the value of bit 0 of		bytes. Coefficient of x^31 gives the value of bit 0 of
	SCTP byte 0, the coefficient of x^24 gives the value of		SCTP byte 0, the coefficient of x^24 gives the value of
	bit 7 of byte 0. the coefficient of x^7 gives bit 0 of		bit 7 of byte 0. The coefficient of x^7 gives bit 0 of
	bit 0 and the coefficient of x^0 0 gives bit 7 of byte 3.		byte 3 and the coefficient of x^0 gives bit 7 of byte 3.
	The resulting four-byte transport-level sequence is the		The resulting four-byte transport-level sequence is the
	32-bit SCTP checksum value.		32-bit SCTP checksum value.
	IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor		IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor
	literature on CRCs often follow an alternative formulation, in which		literature on CRCs often follow an alternative formulation, in which
	the register used to hold the remainder of the long-division		the register used to hold the remainder of the long-division
	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
	usage, where the same CRC algorithm may be used to protect messages
	shorter than 64 bits.
	When an SCTP packet is transmitted, the sender MUST perform this
	checksum procedure, using the preceding CRC computation:
	1) Fill in the proper Verification Tag in the SCTP common header and
	initialize the Checksum field to 0's.
	2) Calculate the CRC-32c of the whole packet, including the SCTP common		Internet draft SCTP Checksum Change April 2002
	header and all the chunks.
	3) Put the resultant 32-bit SCTP checksum value into the Checksum field
	in the common header, and leave the rest of the bits unchanged.
	When an SCTP packet is received, the receiver MUST first perform the
	following:
	1) Store the received CRC-32c value,
	2) Replace the 32 bits of the Checksum field in the received SCTP packet
	with all '0's and calculate the SCTP CRC-32c checksum value of
	the whole received packet. And,
	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
	invalid SCTP packet.
	The default procedure for handling invalid SCTP packets is to silently		usage, where the same CRC algorithm may be used to protect messages
	discard them.		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).
	There would thus be a constant CRC remainder for `good' packets.		There would thus be a constant CRC remainder for `good' packets.
	However, given that implementations of RFC2960 have already		However, given that implementations of RFC2960 have already
	skipping to change at page 6, line 33		skipping to change at page 6, line 5
	Mankin, Lyndon Ong, Craig Partridge, Vern Paxson, Kacheong Poon,		Mankin, Lyndon Ong, Craig Partridge, Vern Paxson, Kacheong Poon,
	Michael Ramalho, David Reed, Ian Rytina, Hanns Juergen Schwarzbauer,		Michael Ramalho, David Reed, Ian Rytina, Hanns Juergen Schwarzbauer,
	Chip Sharp, Bill Sommerfeld, Michael Tuexen, Jim Williams, Jim Wendt,		Chip Sharp, Bill Sommerfeld, Michael Tuexen, Jim Williams, Jim Wendt,
	Michael Welzl, Jonathan Wood, Lloyd Wood, Qiaobing Xie, La Monte		Michael Welzl, Jonathan Wood, Lloyd Wood, Qiaobing Xie, La Monte
	Yarroll.		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 31		skipping to change at page 7, line 5
	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 31		skipping to change at page 8, line 4
	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 32		skipping to change at page 9, line 5
	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 32		skipping to change at page 10, line 4
	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 33		skipping to change at page 11, line 5
	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 32		skipping to change at page 12, line 4
	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 32		skipping to change at page 13, line 4
	* 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 32		skipping to change at page 14, line 4
	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/