Summary

  • RFC 1146 put an Alternate Checksum Request in TCP option Kind 14. Both SYNs had to carry the exact same algorithm number. A missing option, a disagreement or an old implementation’s silent ignore returned the whole connection to the standard TCP checksum.
  • SYN and RST always remained under the standard checksum. A 32-bit Fletcher result also required Kind 15 on applicable ordinary segments. RFC 4614 later recorded a lack of interest, and RFC 6247 moved the experiment to Historic while marking both option kinds obsolete.

A successful connection could be a failed experiment

One endpoint has been upgraded to understand RFC 1146. It places Kind 14 in its SYN and asks for an alternate checksum. The peer predates the experiment. It reads the TCP option length, skips a kind it does not recognize and proceeds with an ordinary SYN response.

The connection opens. To an application and a basic availability monitor, nothing has gone wrong. Yet the requested checksum was never selected.

That result followed a general compatibility rule. RFC 1122 says an unknown TCP option with a length should be ignored without error. An old stack did not need a special RFC 1146 rejection path. Its normal behavior omitted the matching request.

RFC 1146 treated that omission as a failed bilateral condition, not tacit consent. The upgraded endpoint used the standard checksum for the entire connection. Both sides therefore continued to interpret the same field by the same rule.

Safe fallback protected reachability, but it changed what success meant. “TCP connected” measured the health of the baseline. It did not measure adoption of the optional feature.

The proposal needed an envelope both sides could open

The shared baseline had a precise form. RFC 793 defined TCP’s checksum as the 16-bit one’s complement of the one’s-complement sum over the header, text and pseudoheader. The current RFC 9293 keeps checksum generation and verification mandatory.

Before the first SYN, the endpoints had no shared state about an alternative. Protecting the proposal with the proposed algorithm would create a circular dependency: the receiver would have to trust a method before it could reliably read the message that selected the method.

RFC 1146 therefore carried Kind 14 in a SYN protected by the standard checksum. A receiver first validated the envelope under a common rule. It could then decide whether to understand and answer the request inside.

The old checksum was more than an emergency fallback. It was the bootstrap language that gave a new checksum a chance to acquire bounded authority. The proposed replacement had to ask permission in the rule it sought to replace.

Two identical choices made one connection rule

Alternate Checksum Request had Kind 14 and a length of three octets. Its final octet named the algorithm. Zero meant the standard TCP checksum. One meant an 8-bit Fletcher calculation producing a 16-bit result. Two meant a 16-bit Fletcher calculation producing a 32-bit result.

An endpoint put one value in its SYN. The SYN in the opposite direction also had to contain Kind 14 with exactly the same value. Only that pair selected the alternative.

If one SYN lacked the option, the connection used the standard checksum. If one side asked for algorithm 1 and the other for algorithm 2, the result was also standard. The specification did not define a preference list, choose the smaller common result or permit one direction to change alone.

A previous connection’s result did not confer continuing authority. A local configuration did not speak for the peer. Knowledge that another implementation supported the RFC did not replace evidence in this handshake.

The two SYNs were independent acts by the two owners of the new interpretation. One visible Kind 14 proves an offer. Two matching options prove the agreement defined by the document. Later segments are still needed to prove use.

The same fallback rule imposed an adoption threshold

An operator could upgrade one side without causing an outage. That made experimentation possible across a heterogeneous Internet. It also meant the first deployment generally delivered compatibility rather than feature value.

The benefit appeared only when two upgraded endpoints met, chose the same number and traversed a path that preserved the relevant options. Code, tests and parser complexity could be installed widely while the number of eligible endpoint pairs remained small.

Without activation telemetry, every fallback joined the success count. There was no natural error forcing the owner of the second endpoint to upgrade and no user-visible difference demonstrating what the first upgrade had achieved.

This was not a failure of backward compatibility. The design did exactly what a safe experiment should do when it encountered ignorance. But safety and adoption were different control problems. Reducing the cost of a partial rollout also reduced the pressure and evidence needed to complete it.

The old rule retained the entrance and the exit

Even after both endpoints chose an alternate checksum, SYN and RST segments always used the standard one.

The SYN exception followed from sequence. It carried the proposal before agreement existed. Reading it under a negotiated method would presume its own result.

The RST exception protected a different boundary. A reset can be sent by a host that has no state for the connection it is rejecting. Such a host cannot be expected to reconstruct an alternate algorithm chosen in an earlier exchange it may never have seen.

The standard checksum was therefore the stateless exit as well as the common entrance. The alternate method governed applicable ordinary segments of a known connection, not every segment bearing a TCP header.

That boundary matters in evidence. A standard-checksummed RST does not show that the endpoints fell back. A standard-checksummed SYN is expected even when Kind 14 is present. Segment type, direction and connection phase constrain what a checksum value can establish.

A longer result rented space in ordinary segments

The 16-bit result of algorithm 1 fitted the existing checksum field. Algorithm 2 produced 32 bits. RFC 1146 put part A in the normal field and part B in Alternate Checksum Data, option Kind 15.

Kind 15 was not another vote. It was a recurring representation cost after the endpoints selected the long result. Applicable ordinary segments consumed additional TCP option space, and every correct reader needed the handshake state to join the two parts under the right calculation.

The error rule was strict. A Kind 15 option with an improper length or in an inappropriate context caused the receiver to discard the segment, send an RST and abort the connection.

Before agreement, ignoring an unfamiliar proposal preserved a common baseline. After agreement, ignoring malformed integrity data would destroy the common interpretation. RFC 1146 placed tolerance and strictness on opposite sides of a clear state boundary.

The cost of the 32-bit choice therefore extended beyond arithmetic. It included header bytes, stateful parsing, packet-analysis context, error handling and tests for a path that might activate only when two rare implementations met.

Registry presence was a memory, not a deployment count

The IANA TCP Parameters registry still lists option Kinds 14 and 15, now marked obsolete. It also preserves the Alternate Checksum Algorithms table: standard, the two Fletcher variants and Redundant Checksum Avoidance.

Those rows prove allocation, defined meaning and current registry status. They let an analyst decode an old capture and prevent the same numbers from being reassigned with incompatible semantics.

They do not prove that current implementations negotiate the feature or that any recent connection has used it. A registry records names and status; it does not observe both SYNs on the wire.

Obsolete does not mean every legacy bit vanished. Registered does not mean recommended or active. Keeping the number is what makes it possible to tell historical residue from a novel unknown option.

Evidence should therefore remain layered. One Kind 14 is an offer. Matching Kind 14 options are an agreement. Correct later values, including Kind 15 where required, support actual use. The registry establishes semantic custody and later status.

Experimental described a deliberately limited claim

RFC 1146 was published in March 1990 as Experimental and explicitly did not recommend the mechanism for production systems. It specified a testable state machine rather than ordering TCP implementations to migrate.

RFC 1071 had documented properties and implementation techniques for the Internet checksum. It supplies useful mathematical and engineering context for the baseline, but its examples are not evidence that RFC 1146 was deployed. Held errata around example implementation code provide an additional reason not to turn a listing into an adoption claim.

In 2006, RFC 4614 surveyed the TCP specification landscape and noted a lack of interest in Alternate Checksum. That is narrower than saying no implementation ever existed or that Fletcher arithmetic failed. It documents the proposal’s reception.

In 2011, RFC 6247 formally moved RFC 1146 to Historic, said the mechanisms had not seen widespread deployment and instructed IANA to mark Kinds 14 and 15 obsolete. Its specific security discussion of spoofing concerned T/TCP, not Alternate Checksum; that rationale cannot be borrowed to dramatize a different retirement.

The supported historical conclusion is modest and sufficient. A bilateral experimental extension did not attract enough interest or deployment to remain a current standards-track direction, so the standards system closed its status while preserving its identifiers.

A checksum field acquired state-dependent meaning

Under the standard rule, a packet analyzer could apply the known checksum formula to the TCP segment. Under algorithm 1, the same 16-bit field carried a Fletcher result. Under algorithm 2, it carried only part A and required Kind 15 for part B.

The bits could not identify their own interpretation. The analyzer needed the two SYNs, their direction, the exact selected number and the segment type. A capture beginning midstream could see a value without the evidence needed to classify it.

A capture that begins after the SYN exchange can expose the value while omitting the evidence that determines its meaning. RFC 1146 defined protocol semantics, but an observer still needed a sufficiently complete record of the connection to apply them.

This expanded the extension’s maintenance surface. Endpoint code was not the only reader of the state transition. Test harnesses and diagnostic tools also needed the handshake context to distinguish the standard, 16-bit Fletcher and split 32-bit forms.

The benefit of a different calculation had to exceed this ecosystem cost. The handshake made consent safe; the data path made that consent durable and therefore expensive.

Safe failure needs its own instrument panel

The essential operational mistake would be to count availability as activation. A healthy standard connection after a Kind 14 offer may prove that fallback worked precisely because adoption did not.

A useful record separates offered, matched, used and fell back. The first is directional. The second requires two exact values. The third needs subsequent verification. The fourth can be inferred only when the handshake evidence is sufficiently complete to rule out a missing capture.

Kind 15 deserves a separate malformed-state path. Its presence makes sense only after algorithm 2 has been selected and only in applicable segments. The specified RST and abort are not generic intolerance of unknown options; they protect a state the endpoints have already agreed to share.

Safe fallback is valuable when it remains observable. When it is merged into a general success metric, it can support a program indefinitely without showing that the program’s objective has ever occurred.

The old language did not defeat the new one

It is tempting to narrate the registry outcome as a contest between an old checksum and a mathematically different replacement. The sources support a more instructive story.

The old language provided common integrity before agreement, a predictable fallback when agreement failed, and a stateless format for SYN and RST. The new language required two matching deployments, ongoing option support for its long result and a measurement system able to distinguish activation from ordinary TCP success.

RFC 1146 made those costs explicit. Later documents recorded a lack of interest and a lack of widespread deployment, then retired the experiment’s current status. They did not need to declare the arithmetic fraudulent for the coordination path to close.

The checksum had to ask in the old language because shared meaning cannot be replaced by a unilateral message. Its safe request kept every old peer reachable. The same courtesy ensured that, unless a second peer answered, the experiment disappeared into the success of the protocol it had hoped to change.

Sources