Primary Domain
Internet Infrastructure
Within the Primary Domain facet, Internet Infrastructure intelligence groups reporting by primary domain so readers can follow a focused area of internet infrastructure, governance, connectivity markets, or digital capital. The page brings together related articles, public evidence, institutions, companies, people, regional exposure, operating dependencies, and market context that may otherwise sit across separate category pages. It explains the domain, the likely actor class, the market or governance context, and the source material readers should use when comparing signals. Operators, analysts, and governance readers can see how the same domain appears across events, profiles, market shifts, public-source evidence, regional dependencies, and longer-cycle infrastructure decisions over time.
History
When a Successful ESRO Result Still Ends in Failure
In ESRO, a performer could finish an operation, send a successful result, and later receive a failure indication even though the invoker had already accepted that result. RFC 2188 made room for both observations to be true. Its most durable lesson is not about a forgotten 1990s…
IETF
When One Bad Route Becomes Everyone Else’s Risk: The Authority Question in BGP DRIP
A router sees one suspect announcement. Minutes later, routes that were never themselves invalid have lost preference because they share an origin, a neighbour or an AS-path pattern. That is the consequential idea inside the first BGP DRIP draft: not simply faster warning, but a…
IETF
The Drop Rate Was Historical. The Control Boundary Still Matters: RFC 7872
RFC 7872 recorded substantial loss for several IPv6 extension-header probes in 2014–15. Its enduring value is not a percentage that can be carried into 2026; it is the disciplined separation between what a probe observed, where a path might have discarded it, who could change…
History
The Backup Route’s Invoice
A second Internet provider promised resilience, but the extra route appeared only after the first path failed. RFC 2260’s enduring insight was that multihoming never removed the bill for reachability; it decided whether that bill would be paid in global routing state, provider…
History
RFC 2187’s Cache Hierarchy Was About Authority, Not Distance
The words *parent* and *sibling* make an Internet cache hierarchy sound like a family tree drawn across the network. RFC 2187 described something less geometric and more operational: a division of authority over what happens after a cache miss. Both kinds of neighbour might…
History
RFC 2277 Put UTF-8 and Language on the Review Form. Understanding Was Still Elsewhere
A protocol specification arrives for review with three reassuring statements: its text is UTF-8, its natural language can be tagged, and its internationalization choices have their own section. In 1998, RFC 2277 made those statements part of the IETF's standards discipline. They…
History
RFC 2186 drew a strict boundary between a fast cache hint and proof
In 1997, ICPv2 addressed a narrow operational problem: a Web cache sometimes had to choose among neighbours before a heavier exchange could justify its own delay. The protocol therefore compressed uncertainty into quick, bounded signals. Its historical interest lies as much in…
History
The Tunnel Was One Hop. Its Routes Were Two: RFC 2185
An IPv6 router could see one neat point-to-point link while the packet underneath crossed an independently routed IPv4 network. RFC 2185 made the resulting obligation unusually clear: one control plane had to deliver the packet to the right encapsulator, and another had to carry…
CASE FILE
The SYN Could Be Actionable Before the Application Had a Receipt: RFC 1644
RFC 1644 asked a server to make an unusually consequential decision at the first packet: if a connection count in a SYN was newer than the value remembered for that client, the request data could be delivered immediately. That accelerated a transport exchange. It did not tell…
IETF
The Registry Split. The Collector Still Has to Prove What It Read: RFC 9736
RFC 9736 removes an ambiguity from the BGP Monitoring Protocol by giving Peer Up information its own TLV registry. That is good protocol stewardship. It is not evidence that a production collector has understood, retained or acted on a Peer Up message correctly.
History
Three Name Servers Were Never the Same as Three Ways to Survive
RFC 2182 gave DNS operators a harder definition of redundancy than the zone file appeared to offer. Several NS records could satisfy an inventory rule while every server still depended on one room, one power supply, one LAN or one route. The 1997 BCP treated resilience as a…
History
Paul Baran’s Survivability Curve Had Conditions
Remove a number of nodes from a network. Two endpoints are still standing. Can they still find a path to one another? That was the hard, bounded question inside Paul Baran’s work at RAND—not whether a communications system could pass through nuclear war untouched, and not whether…
IETF
The Last LIE Was Accepted. The Fabric Had Not Yet Proven Itself: RFC 9719
RFC 9719 gives operators a standard way to inspect and control RIFT through YANG. Its most tempting boolean, however, answers a deliberately narrow question. The operational advantage comes from refusing to mistake that answer for the health of the fabric.
History
The mailbox had been deleted. One client could still read it: RFC 2180
In 1997, IMAP documented an awkward but useful truth: two clients could be attached to the same mailbox and temporarily inhabit different operational realities. Interoperability did not require every server to erase that difference in the same way. It required clients to survive…
History
The Route Arrived Before Permission to Forward: RFC 2174
RFC 2174 described a switch fabric in which learning a path was not enough to use it. After a topology change, a MAPOS switch could install a route, identify a new virtual root and mark a candidate broadcast port—then deliberately remain silent. The pause was not indecision. It…
History
The Address Belonged to the Port, Not the Machine: RFC 2171
Unplug a node from one MAPOS switch port and attach it to another. The computer may be unchanged, but the link-layer address is not: the value comes from the new point of attachment. RFC 2171 made that rule central to a scheme that turned point-to-point optical links into a…
Story
The Route Was Absent. The Traffic Still Found It: APNIC 62’s BGP Neighbor Problem
A route-origin filter can leave an operator’s table clean while a downstream neighbor forwards toward the rejected destination. An APNIC 62 presentation made that uncomfortable distinction concrete. The useful response is to preserve separate evidence of received routes, local…
Story
One Revoked Certificate, Three Browser Outcomes at APNIC 62
The certificate was on the revocation list. That was not the end of the story. Geoff Huston's APNIC 62 demonstration put the same adverse record in front of three browser policies and obtained different results—a useful warning about the distance between publishing a security…
History
The Record Was There. RWhois Could Not Find It: RFC 2167
A 1997 directory design exposed an uncomfortable difference between storing a record and putting it where a query can discover it. RWhois could refer a reader toward the responsible area; neither the referral nor an answer certified the underlying claim.
History
A Fast Bus Was Not an Ethernet: RFC 2143’s Missing Peer
The attraction was obvious in 1997: put nearby workstations on a fast SCSI cable and carry IP between them. The hard part was not fitting an IPv4 datagram into a command. It was making a peripheral bus accept an unsolicited message from another host—and finding a neighbor when…