Summary

  • On 27 October 1980, ARPANET IMPs repeatedly accepted and flooded updates numbered 8, 40 and 44 because the six-bit LATER comparison made each value newer than another.
  • Eric Rosen’s RFC 789 attributes the likely trigger to a hardware-corrupted retransmission; the resulting high-priority work starved buffers, disrupted link checks and made the network itself a slow channel for the recovery patch.

The network was up at the user’s end—and gone between nodes

The first report was not a neat routing table. Users reached some Terminal Interface Processors, or TIPs, over dial-up lines and received “net trouble” when they tried to reach hosts beyond the local Interface Message Processor. Existing connections broke. Calls to the Network Control Center came from across the country. A TIP could still talk to a person while its IMP had no usable path to another IMP. That distinction became the first clue: the access device was alive, but the network beneath it could not agree on links.

Eric C. Rosen reconstructed the outage in RFC 789, published after the event and based on core dumps taken from several IMPs. The dumps showed buffers crowded with routing updates waiting to be processed. The updates appeared to come from IMP 50. That machine had malfunctioned shortly before the collapse and was already offline. Its neighbor, IMP 29, was also behaving badly and dropping bits. Restarting nearby IMPs did not solve the problem: once reconnected, they received the same updates from their neighbors.

Why 8 could be newer than 44

The routing system needed each IMP to learn the latest delay and line information from the others. Every IMP sent bounded updates to its neighbors; the updates were flooded onward so the network could maintain a shared picture. Each update carried a six-bit sequence number, which advanced modulo 64. A receiver used a half-range rule to decide whether one value was LATER than another. It was compact and normally sufficient because updates were generated at a controlled rate.

The rule was not a general calendar. A value was considered later if it was ahead by up to 32, or if it wrapped past zero by more than 32. That makes 44 later than 40, 40 later than 8, and 8 later than 44. The comparison therefore forms a cycle when those three values coexist.

The core dumps showed precisely that pattern: the same updates, differing only in sequence number, queued as 8, 40, 44, then 8, 40, 44 again. Each could displace another as the newest update and be sent back across the network. The receiver was not choosing randomly; each local decision followed the rule. The loop emerged from applying a bounded comparison to a state the normal generation process was supposed to prevent.

Rosen’s explanation of how that state arose is careful. He thought one update numbered 44 had likely been retransmitted from stored table data after dropped bits changed its sequence field first to 40 and then to 8. The outgoing packet had a checksum, but a retransmission was rebuilt from internal tables; those tables were not continuously checksummed because doing so would consume scarce processor time or memory. The three values looked like one update with a corrupted field. Rosen also acknowledged another possibility: 8 might have been the original, with bits added.

The dumps support the cycle; they do not turn the initiating bit error into certainty.

A routing loop became a resource failure

Routing updates ran at high priority. As the same control information kept circulating, IMP processors and buffers spent most of their capacity handling it. The hardware could not acquire buffers to process HELLO and I-HEARD-YOU messages, which neighboring IMPs used to decide whether a line was healthy. When those checks stopped, software declared lines down. One update loop thus changed the very topology the other IMPs were trying to measure, and users saw a network-wide failure rather than one bad machine.

This distinction matters. In Rosen’s account, the routes were internally consistent with the protocol, and the routing code was not simply calculating a wrong path. A hardware fault created unexpected state; a valid update-handling path then consumed resources without a strong enough stop condition. The article is not evidence of an attack or of modern Internet routing behavior. It is a specific lesson from a deployed network: correctness under normal inputs and a line-rate limit did not guarantee containment when corrupted state was retransmitted and amplified.

The fix had to travel through the damaged network

Operators patched the IMPs to ignore updates from IMP 50, even though IMP 50 itself was already offline. Under normal conditions, the Network Control Center could broadcast such a patch in minutes. During this outage, reaching unmanned IMPs through the network could take three or four hours. The recovery channel depended on the infrastructure it was repairing. The patch succeeded, and Rosen reported no lasting damage beyond the outage.

He proposed a narrow change to the LATER boundary and described future C30 hardware that could detect and correct single-bit errors and detect other bit errors. He also argued for detecting when a high-priority process was consuming too many resources and placing the IMP in a state that could be controlled remotely. These were layered responses: prevent this known comparison cycle, detect a corrupted machine, and make an overwhelmed node recoverable. None promised that every rare fault had been eliminated.

Evidence and sources

Rosen’s account appeared in the January 1981 SIGSOFT Software Engineering Notes and was circulated as RFC 789. It is the primary record for the outage and explicitly labels parts of the hardware explanation as inference. McQuillan, Richer and Rosen’s May 1980 paper documents the routing algorithm’s prior operational tests; those tests covered induced topology changes, heavy traffic and likely loops, but should not be described as having tested this rare combination of stored-data corruption and sequence wrap. The Computer History Museum’s brief anniversary summary repeats the date but calls the values timestamps; RFC 789 identifies them as six-bit sequence numbers, which is the more precise account.

Sources: RFC 789; McQuillan, Richer and Rosen, “The New Routing Algorithm for the ARPANET”; Computer History Museum’s 27 October entry; hosted scan of the 1980 paper at IPCOMPRO; Heng Lu’s Running-Code Primacy, used only as an editorial lens.