Distance-vector: a neighbor's word is good enough
RIP (Routing Information Protocol) is the oldest commonly used IGP protocol, first standardized in RFC 1058 (1988), although the principles it's built on were already in use in various implementations long before that. It belongs to the distance-vector category of protocols — unlike OSPF, where every router builds a complete map of the entire topology, a router taking the distance-vector approach remembers only two things about each remote network: direction (which neighbor to go through) and distance (how many "hops" away it is).
A router doesn't see the topology beyond its immediate neighbors at all — it relies on a neighbor honestly telling it "I can reach this network in X hops," and simply adds one more hop to that number. Mathematically, this is a distributed application of the Bellman-Ford algorithm — every router repeatedly updates its estimates based on information from its neighbors, until the entire network settles (converges) into a consistent state.
Metric: hop count, maximum 15
RIP uses the simplest possible metric — hop count, i.e. the number of routers a packet must pass through to reach its destination, regardless of the actual speed or load of the individual links. This simplicity comes at a price: RIP can't distinguish between a slow one-hop link and a fast two-hop link — it will always prefer the smaller hop count, even if that means a slower path in a given case.
An even more significant limitation is the cap of 15 hops. The value 16 is reserved in RIP as the symbol for "infinity" — meaning an unreachable network. This seemingly arbitrary boundary directly limits the maximum size of a network RIP can operate in — any network 16 or more hops away is invisible to RIP, regardless of whether it physically exists.
The count-to-infinity problem, and how RIP handles it
A naive implementation of distance-vector routing suffers from a serious problem: if a network a neighbor previously advertised suddenly disappears, two adjacent routers can end up "lying" to each other — each thinking the other still has a valid path, and gradually increasing their hop counts toward each other all the way to infinity (hence the name count-to-infinity). RIP addresses this with a combination of several mechanisms:
- Split horizon — a router never advertises a network back in the same direction it learned about it from. This prevents the simplest case of two direct neighbors "lying" to each other.
- Split horizon with poison reverse — a stricter variant: instead of a router simply staying silent about a route back toward where it came from, it actively advertises it back with a metric of infinity (16), explicitly saying "this route doesn't exist through me."
- Triggered updates — instead of waiting for the next regular update cycle (every 30 seconds by default), a router immediately broadcasts a change as soon as it detects it, significantly shortening the time needed to spread news of an outage.
- Hold-down timers — after receiving news that a network is unreachable, a router "holds" it in that state for a while and refuses to accept potentially stale, more favorable news about the same network from other neighbors, until the situation stabilizes.
These mechanisms significantly mitigate the problem, but don't fully eliminate it in topologies with more than two paths to the same network — one of the main reasons RIP is practically never used for large or densely interconnected networks today.
RIPv1: the original, classful version (1988)
The first version, defined in RFC 1058, has several significant limitations by today's standards:
- Classful routing — RIPv1 updates never carry a subnet mask at all, just the bare IP network address. The mask is derived solely from the address class (A, B, C) — which rules out using VLSM (Variable Length Subnet Mask) or discontiguous networks within a single class.
- Broadcast updates — updates are sent as a broadcast across the entire local network, burdening even devices that have no interest in RIP whatsoever.
- No authentication — any device on the network can transmit RIPv1 updates, and a router accepts them without verification.
RIPv2: a classless, more secure version (1993 – 1994)
RIPv2 (RFC 1723, later updated by RFC 2453) removes RIPv1's most painful limitations, while deliberately preserving the simplicity and backward compatibility of the packet format:
- Classless routing — updates now carry a subnet mask for every network, adding support for VLSM and CIDR.
- Multicast updates — updates are sent to the multicast address
224.0.0.9instead of a broadcast, so only devices genuinely interested in them process them. - Authentication — added support for a plaintext password as well as cryptographically stronger MD5 authentication of updates.
- Route tags — an optional field for tagging routes that originated from other routing protocols, useful when redistributing routes between different protocols.
RIPng: RIP for the IPv6 world (1997)
The rise of IPv6 created a need to adapt RIP as well — the result is RIPng ("next generation", RFC 2080). It preserves the same basic principle and the 15-hop limit, but is adapted to the new address space:
- Updates are sent over UDP port 521 (instead of the original port 520) to the multicast address FF02::9.
- It natively carries IPv6 prefixes and prefix lengths instead of IPv4 addresses and masks.
- Interestingly, RIPng has no authentication of its own built in — instead it relies entirely on IPsec security at the IPv6 level itself, similar to what we mentioned about OSPFv3.
Comparing the versions
| RIPv1 | RIPv2 | RIPng | |
|---|---|---|---|
| Year / RFC | 1988 · RFC 1058 | 1993/1994 · RFC 2453 | 1997 · RFC 2080 |
| Addressing | IPv4 | IPv4 | IPv6 |
| Routing | Classful | Classless (VLSM/CIDR) | Classless (IPv6 prefixes) |
| Distribution | Broadcast | Multicast 224.0.0.9 | Multicast FF02::9 |
| Authentication | None | Plaintext / MD5 | None (relies on IPsec) |
| Max hops | 15 | 15 | 15 |
Why RIP is barely used in large networks today
The combination of the 15-hop limit, slow convergence (a default 30-second update interval means propagating a change across a larger network can take anywhere from tens of seconds to minutes, even with triggered updates), a crude metric based purely on hop count, and the non-trivial overhead of periodic full-table updates makes RIP unsuitable for medium and large networks. These exact limitations were the direct motivation for the emergence of OSPF and other, more modern IGPs, which build a more precise picture of the network instead of simply counting hops, and converge an order of magnitude faster.
RIPv1 with no authentication at all poses a direct risk — an attacker with access to the local network can simply transmit forged RIP updates and reroute traffic through their own device (similar to other forms of route-poisoning attacks described in our article on cyberattacks). Even in RIPv2, a plain plaintext password is practically worthless — in environments where RIP is still running, at least MD5 authentication is recommended, along with strictly limiting which interfaces the protocol is even enabled on.
Summary
RIP remains a valuable textbook example of pure distance-vector routing — simple to understand and configure, but with limitations (15 hops, a crude metric, slow convergence) that make it unsuitable outside small or educational networks. The evolution from RIPv1 through RIPv2 to RIPng shows a typical pattern in how network protocols mature — adding support for more modern addressing (VLSM, CIDR, IPv6) and security (authentication) without changing the underlying, proven operating principle.