RFC 1146
HISTORICAL EXPERIMENTTCP Alternate Checksum Options
J. Zweig, C. Partridge · March 1990 · original status: Experimental · current status: Historic
obsoleted by: RFC 6247
HISTORICAL EXTENSION — never deployed, moved to Historic by RFC 6247. Production TCP uses only the standard Internet checksum. This lab exists to teach checksum design trade-offs, strictly quarantined from the real codec.
This module teaches HISTORICAL behaviour
This document
- RFC 1146 — Alternate Checksum Request option (kind 14, SYN-only negotiation)
- RFC 1146 — Alternate Checksum Data option (kind 15)
- RFC 1146 — 8-bit and 16-bit Fletcher checksum appendices
Where the current rules live
- RFC 9293 §3.1 — the one and only standard TCP checksum (RFC 1071 arithmetic)
TCP Alternate Checksum Options (historical experiment)
New to these ideas? Switch to the beginner level for a from-zero concept primer.
The problem this document answered
The Internet checksum is a one's-complement sum of 16-bit words. Addition is commutative, so reordering whole words leaves it unchanged; it is also blind to compensating errors (+N here, −N there). RFC 1146 offered Fletcher's checksum, whose second accumulator sums the running totals and is therefore position-sensitive, negotiated per connection via two new options.
Historical context
J. Zweig and C. Partridge, March 1990, Experimental. Contemporary with the discovery that the Internet checksum's weaknesses were measurable in the wild (Stone & Partridge's later work found real errors slipping past it). Never deployed; reclassified Historic by RFC 6247 in 2011.
Current practice
Production TCP has exactly one checksum: the RFC 1071 Internet checksum over the pseudo-header, header and payload (RFC 9293 §3.1). Where stronger integrity is needed it comes from elsewhere — Ethernet's CRC-32 on each hop, TLS record authentication end to end, or application-level hashes. SubnetLayer's own codec computes only the standard checksum; the Fletcher code lives behind an explicitly experimental interface and never touches a simulated packet.
Interactive laboratory
🧪 Checksum laboratory — what each algorithm can and cannot catch
| algorithm | original | corrupted | verdict |
|---|---|---|---|
| Internet checksum (standard) | 0xca66 | 0xca66 | ✗ MISSED |
| Fletcher-8 (RFC 1146) | 0xadce | 0x14ce | ✓ detected |
| Fletcher-16 (RFC 1146) | 0xc3df3599 | 0x5d793599 | ✓ detected |
The standard checksum is blind to this corruption: it is a plain sum, and addition doesn't care about order or about two errors that cancel. Fletcher's second accumulator sums the running totals, so position matters — which is exactly the weakness RFC 1146 set out to fix.
Negotiation is a separate matter from calculation: RFC 1146 used option kind 14 (Alternate Checksum Request, SYN-only) to agree an algorithm, and kind 15 to carry the result — because the 16-bit header field can only hold the standard checksum. Both endpoints had to understand both options, and a peer that didn't simply ignored the request and stayed on the standard checksum. That backwards compatibility is also why nobody ever had to adopt it — and nobody did.
Original RFC vs current standard
Number of checksum algorithms
- Original behaviour
- RFC 1146: endpoints may negotiate Fletcher-8, Fletcher-16 or redundant-checksum avoidance in place of the standard checksum.
- Current behaviour
- RFC 9293 §3.1: exactly one algorithm, the RFC 1071 Internet checksum, mandatory and non-negotiable.
- What changed
- The extension was never implemented and is now Historic (RFC 6247).
- Why it changed
- Link-layer CRCs below and application/TLS integrity above already covered the gap; changing every TCP stack for a marginal gain never paid.
📷 In a capture: You will never see option kinds 14 or 15 in a real capture. If you do, you are looking at a research artefact or a fuzzer.
Where the checksum value lives
- Original behaviour
- RFC 1146: the standard 16-bit header field is bypassed and the alternate value rides in the kind-15 option, because a 32-bit Fletcher cannot fit the field.
- Current behaviour
- The 16-bit header field always holds the standard checksum; no option carries checksum data.
- What changed
- The second option became unnecessary along with the first.
- Why it changed
- Same reason — the mechanism was never adopted.
📷 In a capture: The checksum field is at a fixed offset (bytes 16–17 of the TCP header) in every real segment; select it in any packet here to see it.
Common misconceptions
- ✗“TCP can negotiate a stronger checksum today” — it cannot. There is exactly one TCP checksum in RFC 9293; RFC 1146 is Historic and unimplemented.
- ✗“A valid TCP checksum means the data is definitely intact” — it means no error the checksum can see occurred. Word swaps and compensating errors pass cleanly, which is precisely what the lab demonstrates.
- ✗“Fletcher is a cryptographic hash” — it is not; it resists accidental corruption, not deliberate tampering. Anyone can craft data with a chosen Fletcher value.
- ✗“The checksum was left weak by oversight” — it was a deliberate trade for speed on 1981 hardware, and layered defences (link CRCs, TLS) made strengthening it unnecessary later.
- ✗“Historic status means the idea was wrong” — it means the mechanism was never deployed. The analysis behind it was sound and still shapes how people reason about integrity layering.
Glossary terms used here
Knowledge check
1/4 · In the lab, swapping two whole 16-bit words leaves the standard checksum unchanged. Why?
2/4 · Why did RFC 1146 need TWO options rather than one?
3/4 · A 1990 host offering Fletcher-16 connects to a host that has never heard of RFC 1146. What happens?
4/4 · Your TCP checksum validates. What have you actually proven?