History of the Internet

Why IPv4 Checksums Only Its Header

A packet can carry an undamaged payload and still be dangerous to forward if a bit error changes its destination, length or remaining lifetime. IPv4 therefore checks the control surface routers must trust: its header, and only its header.

When IPv4 TTL Stopped Being a Clock

IPv4 gives every datagram a field called Time to Live, measured in seconds. Yet the forwarding rule subtracts at least one even when less than a second has passed. That mismatch turned a nominal lifetime timer into the Internet's practical hop budget.

Formatting Could Disappear. The Message Still Had to Be Readable: RFC 1523

The Formatting Could Disappear. The Message Still Had to Be Readable: RFC 1523

A reader that understood no boldface, centring or indentation could still recover the prose. RFC 1523 made that outcome a property of the format itself: presentation commands were disposable, while their limits, nesting and whitespace rules made the remaining text predictable enough to read.

Why IPv4 Options Carry a Copy Bit

Two fragments of the same IPv4 datagram can legitimately carry different option sets. That is not an accident of implementation. A single bit inside every option type tells a fragmenter whether the option must follow all fragments or remain only with the first.

Link Was Open. Configuration Still Belonged to a Second Negotiator: RFC 1552

The Link Was Open. Configuration Still Belonged to a Second Negotiator: RFC 1552

In one 1993 PPP design, reaching `Opened` could mean the network protocol was ready. In another, the very same state was only permission for a second negotiator to begin. RFC 1552 made that difference explicit—and showed why a state name is never a complete receipt.

Why IPv4 Fragment Offsets Count in Eights

An IPv4 Fragment Offset is not a byte number. Its 13 bits count blocks of eight octets, turning a compact header field into a coordinate that can span the protocol's full datagram size. That economy comes with a precise cost: every fragment that is not last must end on an eight-octet boundary.

When IPv4 Identification Stopped Identifying Every Datagram

IPv4 still carries a 16-bit field called Identification in every header. Yet the current standard says that field has no meaning in an atomic datagram. The apparent contradiction records a deliberate narrowing: an identifier created to reunite fragments no longer has to pretend that it identifies packets which cannot be fragmented.

Attachment Named Its Type. The Local Machine Chose the Command: RFC 1524

The Attachment Named Its Type. The Local Machine Chose the Command: RFC 1524

A multimedia message could say what it carried, but it could not legitimately appoint the program that would open it. RFC 1524 placed that decision in a local `mailcap` policy—a small indirection that made new formats portable across mail readers while exposing exactly where descriptive metadata approached executable authority.

Message Arrived Intact. Its Reading Order Still Had Three Owners: RFC 1556

The Message Arrived Intact. Its Reading Order Still Had Three Owners: RFC 1556

A mixed Hebrew-and-English line could survive every mail relay with its characters unchanged and still arrive as a different sentence on two screens. RFC 1556 named the missing contract: transport had delivered the sequence, but somebody still had to own its order.

Why TCP Options Needed Both an End Marker and a No-Operation

TCP made room for future capabilities inside a header whose total extent still had to be known before payload could begin. Two deliberately small option codes—End of Option List and No-Operation—helped keep that variable space parseable without making every sender lay it out the same way.

Repeater Had to Reply Before It Reset: RFC 1516

The Repeater Had to Reply Before It Reset: RFC 1516

The management reply was designed to leave while the Ethernet repeater was still able to send it. Only then could the disruptive reset begin. RFC 1516 turned that small ordering rule into a durable warning: acknowledgement, action, completion and restored service do not share one timestamp.

Internet Asked Who Would Have to Live With Its Next Protocol: RFC 1550

The Internet Asked Who Would Have to Live With Its Next Protocol: RFC 1550

A utility meter and a wireless link appeared before any packet diagram. In RFC 1550, the search for a successor to IPv4 began by asking future users what the new protocol would have to endure—and by keeping the candidates temporarily out of the room.

Alarm Had to Wait Five Seconds; the Counter Did Not: RFC 1515

The Alarm Had to Wait Five Seconds; the Counter Did Not: RFC 1515

Two bursts of an Ethernet fault could enter the same five-second window. A manager might receive one alarm, poll a normal state a moment later, and still find that the transition counter had advanced twice. In 1993, RFC 1515 made those answers coexist because an alert, a present condition and an occurrence history were never the same piece of evidence.

Standard Had to Work With the Feature Off: RFC 1547

The Standard Had to Work With the Feature Off: RFC 1547

On a metered line, a packet sent only to ask whether the other end is still alive can appear on the bill. RFC 1547 used that small operational conflict to establish a large design rule: if one site needs a feature and another must disable it, the common protocol still has to work.

Table Measured What an Application Could Use, Not the Disk: RFC 1514

The Table Measured What an Application Could Use, Not the Disk: RFC 1514

A host can report a perfectly accurate disk capacity and a smaller, equally accurate amount of usable storage. The disagreement begins only when a manager strips away which layer each number describes. In 1993, RFC 1514 built that distinction into the Host Resources MIB: physical devices, partitions, file systems and application-visible storage pools were related views, not interchangeable names for one thing.

Address Stayed the Same. The Server Did Not Have To: RFC 1546

The Address Stayed the Same. The Server Did Not Have To: RFC 1546

In 1993, one ordinary-looking destination field was asked to do an unusual job: name a service offered by several machines while declining to name any particular machine. RFC 1546 called that experimental service anycasting. Its enduring lesson is less about shortening a path than about refusing to confuse a stable address with a stable actor.

Probe Counted Shortages, Not Missing Frames: RFC 1513

The Probe Counted Shortages, Not Missing Frames: RFC 1513

The counter moved from 41 to 42. How many frames had vanished? RFC 1513 gave the only responsible answer: the number did not say. It recorded one more occasion on which a monitoring probe ran short of resources, not the size of the unseen traffic behind that shortage.

Why TCP Sequence Numbers Return to Zero

In TCP, zero does not always come before a large number. After sequence position 4,294,967,295, the next position is zero. The protocol keeps acknowledgments, windows and retransmission decisions coherent by treating the 32-bit sequence space as a ring and comparing positions with modular arithmetic.

Number That Made TCP Flow Control Move

The Number That Made TCP Flow Control Move

TCP did not put a receiver's memory size into every segment. It put a moving allowance into the header: a count of how many data octets the sender of that segment was then willing to accept, beginning at the acknowledgment frontier. That pairing turned flow control into a continuously renewed boundary in sequence space.

Handle Was the Same. The Credential Could Be Different: RFC 1509

The Handle Was the Same. The Credential Could Be Different: RFC 1509

Two programs present the same pointer-sized value to a security service. One reaches Alice’s credential. The other may reach Bob’s—or nothing at all. No bit in the value has changed. The caller has. RFC 1509 made this possible on purpose, because its handle was never the credential and was never meant to carry authority beyond the local system that resolved it.