Routing Information Protocol (RIP)

The Routing Information Protocol (RIP) was one of the most commonly used interior gateway protocol (IGP) routing protocols on internal networks (and to a lesser extent, networks connected to the Internet), which helps routers dynamically adapt to changes of network connections by communicating information about which networks each router can reach and how far away those networks are. The Routing Information Protocol, or RIP, as it is more commonly called, is one of the most enduring of all routing protocols. RIP is also one of the more easily confused protocols because a variety of RIP-like routing protocols proliferated, some of which even used the same name! RIP and the myriad RIP-like protocols were based on the same set of algorithms that use distance vectors to mathematically compare routes to identify the best path to any given destination address. The most popular of the TCP/IP interior routing protocols is the Routing Information Protocol (RIP). The simplicity of the name matches the simplicity of the protocol—RIP is one of the easiest to configure and least resource-demanding of all the routing protocols. Its popularity is due both to this simplicity and its long history. In fact, support for RIP has been built into operating systems for as long as TCP/IP itself has existed. These algorithms emerged from academic research that dates back to 1957.

Today's open standard version of RIP, sometimes referred to as IP RIP, is formally defined in two documents: Request For Comments (RFC) 1058 and Internet Standard (STD) 56. As IP-based networks became both more numerous and greater in size, it became apparent to the Internet Engineering Task Force (IETF) that RIP needed to be updated. Consequently, the IETF released RFC 1388 in January 1993, which was then superceded in November 1994 by RFC 1723, which describes RIP 2 (the second version of RIP). These RFCs described an extension of RIP's capabilities but did not attempt to obsolete the previous version of RIP. RIP 2 enabled RIP messages to carry more information, which permitted the use of a simple authentication mechanism to secure table updates. More importantly, RIP 2 supported subnet masks, a critical feature that was not available in RIP.

In this section I describe the characteristics and operation of the TCP/IP Routing Information Protocol (RIP). There are three versions of RIP: RIP versions 1 and 2 for IP version 4 and RIPng (next generation) for IP version 6. The basic operation of the protocol is mostly the same for all three versions, but there are also some notable differences between them, especially in terms of the format of messages sent.

For this reason, I have divided my description of RIP into two subsections. In the first, I describe the fundamental attributes of RIP and its operation in general terms for all three versions. In the second, I take a closer look at each version, showing the message format used for each and discussing version-specific features as well.

RIP is a dynamic, distance vector routing protocol based around the Berkely BSD application routed and was developed for smaller IP based networks. RIP uses UDP port 520 for route updates. RIP calculates the best route based on hop count. Like all distance vector routing protocols, RIP takes some time to converge. While RIP requires less CPU power and RAM than some other routing protocols, RIP does have some limitations:

Metric: Hop Count
Since RIP calculates the best route to a destination based solely on how many hops it is to the destination network, RIP tends to be inefficient in network using more than one LAN protocol, such as Fast Ethernet and serial or Token Ring. This is because RIP prefers paths with the shortest hop count. The path with the shortest hop count might be over the slowest link in the network.

Hop Count Limit
RIP cannot handle more than 15 hops. Anything more than 15 hops away is considered unreachable by RIP. This fact is used by RIP to prevent routing loops.

Classful Routing Only
RIP is a classful routing protocol. RIP cannot handle classless routing. RIP v1 advertises all networks it knows as classful networks, so it is impossible to subnet a network properly via VLSM if you are running RIP v1, which
However, it must be pointed out that RIP is the only routing protocol that all routing devices and software support, so in a mixed equipment environment, RIP may be your only option for dynamic routing. This is changing with the widespread use of OSPF.

---

Description:

Protocol suite: TCP/IP.
Type: Application layer, interior gateway protocol, distance vector.
Multicast addresses: 224.0.0.9.
Port: 520 (UDP).
MIME subtype:
SNMP MIBs: iso.org.dod.internet.mgmt.mib-2.rip-2 (1.3.6.1.2.1.23).
Working groups: rip, Routing Information Protocol.
Links:

RIP version 1 (RIPv1) is a simple distance vector protocol. It has been enhanced with various techniques, including Split Horizon and Poison Reverse in order to enable it to perform better in somewhat complicated networks.

The longest path cannot exceed 15 hops.
RIP uses static metrics to compare routes.
The maximum datagram size is 512 bytes not including the IP or UDP headers.

RIP version 2 (RIPv2) added several new features.

External route tags.
Subnet masks.
Next hop router addresses.
Authentication.
Multicast support.
RFC 2453, section 3.2:

The protocol is limited to networks whose longest path is 15 hops. The designers believe that the basic protocol design is inappropriate for larger networks. Note that this statement of the limit assumes that a cost of 1 is used for each network. This is the way RIP is normally configured. If the system administrator chooses to use larger costs, the upper bound of 15 can easily become a problem.

The protocol depends upon "counting to infinity" to resolve certain unusual situations. If the system of networks has several hundred networks, and a routing loop was formed involving all of them, the resolution of the loop would require either much time (if the frequency of routing updates were limited) or bandwidth (if updates were sent whenever changes were detected). Such a loop would consume a large amount of network bandwidth before the loop was corrected. We believe that in realistic cases, this will not be a problem except on slow lines. Even then, the problem will be fairly unusual, since various precautions are taken that should prevent these problems in most cases.

This protocol uses fixed "metrics" to compare alternative routes. It is not appropriate for situations where routes need to be chosen based on real-time parameters such a measured delay, reliability, or load. The obvious extensions to allow metrics of this type are likely to introduce instabilities of a sort that the protocol is not designed to handle.