Summary

  • A branch worker may be unable to submit an order even when the links are up, if RIP is the only route source and the path exceeds 15 hops.
  • After a failure, stale routes may keep sending traffic the wrong way. RFC 1058 used 16 to bound that count, not to promise instant service recovery.

A route can be too long to exist

Imagine a branch employee submitting an order before a deadline. The link lights are on, but if RIP is the only route source and the destination lies beyond its metric ceiling, the gateway has no usable route to announce. The order cannot leave the branch. Now imagine a different failure: one gateway withdraws a destination while its neighbor keeps pointing back toward it, so packets may continue along the wrong path during recovery. These are explanatory scenarios, not reported 1988 incidents; RFC 1058 describes the mechanism, not a named outage.

RIP’s 1988 specification gave that problem a deliberately small stopping point. In RFC 1058, a route metric from 1 through 15 was usable; 16 represented unreachable. Sixteen was therefore not a literal measurement of an infinitely distant network. It was the protocol’s chosen boundary between a route it could advertise and one it had to withdraw.

That boundary imposed a practical bargain. A protocol that calls 16 “infinity” cannot express a valid path whose metric would exceed 15. Hedrick’s memo says the design was aimed at networks of moderate size and records the designers’ view that RIP was unlikely to be practical above a diameter of 15. A small bound also meant a stale route had fewer increments to travel before the protocol could stop counting it.

The number was not the cure

RFC 1058 does not present the low ceiling as a complete solution. It describes count-to-infinity as a convergence failure and discusses split horizon, poisoned reverse and triggered updates as additional safeguards. Even those controls had limits: triggered updates could arrive too late to prevent a remnant bad route from circulating, so counting to infinity remained possible.

The metric made the failure bounded in one sense, not harmless. While gateways were counting, they could still direct packets along a false path. A route can be finitely wrong for long enough to disrupt a service. “Sixteen” answers when the control plane stops treating that route as usable; it does not prove that every packet took a working path before then.

Later documents preserve the distinction. RFC 2453, the RIP Version 2 specification, retained 16 as infinity while describing the protocol’s limits and loop behavior. RFC 1812 records RIP among historical routing protocols, a reminder that a well-documented mechanism is not a universal routing design.

A modest network was part of the design

It is tempting to read 16 as an arbitrary old constant. The memo gives a more revealing explanation: infinity should be no larger than necessary, because every extra step can prolong counting after a failure, but not so small that ordinary paths become unrepresentable. The choice trades network diameter against recovery time when bad information survives.

That makes the limit an operating assumption, not just a packet-field detail. A network operator choosing RIP also accepted a topology envelope. If the network grew past it, no timer adjustment could make a route of metric 16 become valid under the protocol’s meaning. The system had reached its representational edge.

The lesson extends beyond RIP. A bounded value can contain the time or space over which a failure spreads, but only by declaring some otherwise conceivable states out of bounds. Designers should ask who bears that cost: the protocol’s convergence behavior, the operator who must redesign, or users whose paths cannot be represented. In 1988, RIP made that choice unusually legible. Sixteen was where its map stopped claiming to know the way.

Primary documents: RFC 1058; RFC 2453; RFC 1812.