RFC 1145

RFC 1145: TCP Alternate Checksum Options 🎀

okay bestie, let's get into this one 💅 it's RFC 1145, titled "TCP Alternate Checksum Options," and it's giving February 1990 vibes 🦋. Written by J. Zweig (UIUC) and C. Partridge (BBN). It's an experimental memo, so it's not recommended for production use 🙈. It doesn't obsolete or update anything, so it's standing on its own ✨

Distribution is unlimited, so share it with your whole group chat 🫶

---

Status of This Memo ✨

okay so this memo suggests a pair of TCP options that let you use alternate data checksum algorithms in the TCP header 🧚 the use of these options is experimental, and it's not recommended for production use 🙈 distribution of this memo is unlimited 💖

Introduction 🌸

some folks in the networking community were curious about using checksum algorithms with different error detection and correction properties than the standard TCP checksum 👀 this option gives you a way to negotiate an alternate checksum when the connection is being set up, and also a way to carry extra checksum info for algorithms whose checksums are longer than 16 bits 💜

Definition of the Options 🎀

the TCP Alternate Checksum Request Option can be sent in a SYN segment to say "hey, I'm ready to both generate and receive checksums using an alternate algorithm" 💅 during communication, the alternate checksum takes the place of the regular TCP checksum in the checksum field of the TCP header 🦋

if the alternate checksum needs more than 2 octets, the checksum can either get moved into a TCP Alternate Checksum Data Option (with the checksum field of the TCP header sent as 0), or the data can be split between the header field and the option ✨ alternate checksums are computed over the same data as the regular TCP checksum (see the TCP Alternate Checksum Data Option discussion below) 🫶

TCP Alternate Checksum Request Option 🌈

the format of the TCP Alternate Checksum Request Option is:

          +----------+----------+----------+
          |  Kind=14 | Length=3 |  chksum  |
          +----------+----------+----------+

here chksum is a number that identifies which checksum type to use 🧚

this option is not copied into each fragment, so it only shows up in the first fragment 🙈

the currently defined values of chksum are:

            0  -- TCP checksum
            1  -- 8-bit  Fletcher's algorithm (see Appendix I)
            2  -- 16-bit Fletcher's algorithm (see Appendix II)

heads up, the 8-bit Fletcher algorithm gives you a 16-bit checksum, and the 16-bit algorithm gives you a 32-bit checksum 🔥

alternate checksum negotiation goes like this 💖

• a SYN segment used to originate a connection may contain the Alternate Checksum Request Option, which specifies the alternate checksum calculation algorithm to be used for the connection 🦋 the acknowledging SYN-ACK segment may also carry the option 💅
• if both SYN segments carry the Alternate Checksum Request option, and both specify the same algorithm, that algorithm must be used for the remainder of the connection ✨ otherwise, the standard TCP checksum algorithm must be used for the entire connection 💀 so for example, if one TCP specifies type 1 checksums and the other specifies type 2, they'll use type 0 (the regular TCP checksum) 😭 in practice, one TCP will typically be responding to the other's SYN, and thus either accepting or rejecting the proposed alternate checksum algorithm 🫶
• any segment with the SYN bit set must always use the standard TCP checksum algorithm 👑 this means the SYN segment will always be understood by the receiving TCP 💜 the alternate checksum must not be used until the first non-SYN segment 🙈 also, because RST segments may be received or sent without complete state information, any segment with the RST bit set must use the standard TCP checksum 🌸
• the option may not be sent in any segment that does not have the SYN bit set 🚫✨
• an implementation of TCP that doesn't support the option should silently ignore it (as RFC 1122 requires) 💅 ignoring the option forces any TCP trying to use an alternate checksum to fall back to the standard TCP checksum algorithm, which keeps everything interoperable 🫶

TCP Alternate Checksum Data Option 🧚

the format of the TCP Alternate Checksum Data Option is:

           +---------+---------+---------+     +---------+
           | Kind=15 |Length=N |  data   | ... |  data   |
           +---------+---------+---------+     +---------+

this field is only used when the negotiated alternate checksum is longer than 16 bits 🔥 those checksums won't fit in the checksum field of the TCP header, so at least part of them must be put in an option 💖 whether the checksum gets split between the header field and the option, or the whole thing goes in the option, is decided on a checksum-by-checksum basis 🦋

the length of this option depends on which alternate checksum algorithm is chosen for the connection ✨

this option is not copied into each fragment, so it only appears in the first fragment 🙈

while computing the alternate checksum, the TCP checksum field and the data portion of the TCP Alternate Checksum Data Option are replaced with zeros 🧚

an otherwise acceptable segment that carries this option on a connection using a 16-bit checksum algorithm, or that carries this option with an inappropriate number of data octets for the chosen alternate checksum algorithm, is in error 😭 it must be discarded, an RST segment must be generated, and the connection aborted 💀

note the requirement above that RST and SYN segments must always use the standard TCP checksum 🫶

APPENDIX I: The 8-bit Fletcher Checksum Algorithm 🌈

the 8-bit Fletcher checksum is calculated over a sequence of data octets (call them D[1] through D[N]) using 2 unsigned 1's-complement 8-bit accumulators, A and B, which both start at zero 🧮 you run the following loop, where i goes from 1 to N:

        A := A + D[i]
        B := B + A

it can be shown that at the end of the loop, A holds the 8-bit 1's complement sum of all octets in the datagram, and B holds (N)D[1] + (N-1)D[2] + ... + D[N] ✨

the octets covered by this algorithm should be the same ones the standard TCP checksum calculation covers, with the pseudoheader being D[1] through D[12] and the TCP header beginning at D[13] 💅 for the checksum computation, the checksum field itself must be equal to zero 🙈

at the end of the loop, A goes in the first byte of the TCP checksum and B goes in the second byte 💜

note that, unlike the OSI version of the Fletcher checksum, this checksum does not adjust the check bytes so the receiver's checksum is 0 👀

there are a bunch of much faster algorithms for calculating the two octets of the 8-bit Fletcher checksum 🚀 for more info, see [Sklower89], [Nakassis88] and [Fletcher82] 🦋 any computation that gives the same number the loop above would give can be used to calculate the checksum ✨ one perk of the Fletcher algorithms over the standard TCP checksum is that they can detect transposition of octets or words of any size within a datagram 👑

APPENDIX II: The 16-bit Fletcher Checksum Algorithm 🌈

the 16-bit Fletcher checksum algorithm works exactly like the 8-bit one, except that A, B and the D[i] are 16-bit quantities 🧚 it's necessary (just like with the standard TCP checksum algorithm) to pad a datagram with an odd number of octets using a zero octet 💅

Result A should go in the TCP header checksum field, and Result B should appear in a TCP Alternate Checksum Data option 💖 this option must be present in every TCP header 🫶 the two bytes reserved for B should be set to zero during the calculation of the checksum 🙈

the checksum field of the TCP header shall contain the contents of A at the end of the loop 👑 the TCP Alternate Checksum Data option must be present and must contain the contents of B at the end of the loop 💀

BIBLIOGRAPHY 📚

[BrBoPa89] Braden, R., Borman, D., and C. Partridge, "Computing the Internet Checksum", ACM Computer Communication Review, Vol. 19, No. 2, pp. 86-101, April 1989. [Note that this includes Plummer, W. "IEN-45: TCP Checksum Function Design" (1978) as an appendix.] 💜

[Fletcher82] Fletcher, J., "An Arithmetic Checksum for Serial Transmissions", IEEE Transactions on Communication, Vol. COM-30, No. 1, pp. 247-252, January 1982. 🦋

[Nakassis88] Nakassis, T., "Fletcher's Error Detection Algorithm: How to implement it efficiently and how to avoid the most common pitfalls", ACM Computer Communication Review, Vol. 18, No. 5, pp. 86-94, October 1988. ✨

[Sklower89] Sklower, K., "Improving the Efficiency of the OSI Checksum Calculation", ACM Computer Communication Review, Vol. 19, No. 5, pp. 32-43, October 1989. 🌸

Security Considerations 🔐

security issues are not addressed in this memo 😬 so if you're looking for security guidance here, it's a no-show 💀

Authors' Addresses 📮

Johnny Zweig Digital Computer Lab University of Illinois (UIUC) 1304 West Springfield Avenue CAMPUS MC 258 Urbana, IL 61801

Phone: (217) 333-7937 EMail: zweig@CS.UIUC.EDU

Craig Partridge Bolt Beranek and Newman Inc. 50 Moulton Street Cambridge, MA 02138

Phone: (617) 873-2459 EMail: craig@BBN.COM

that's the whole tea, bestie 🌈👑💅✨