RIP is the first routing protocol used in the TCP/IP-based network in an intradomain envi- ronment. While the RIP specification was first described in RFC 1058 in 1988 [290], it was available when RIP was packaged with 4.3 Berkeley Software Distribution (BSD) as part of
“routed” daemon software in the early 1980s. The following passage from RFC 1058 is inter- esting to note: “The Routing Information Protocol (RIP) described here is loosely based on the program routed, distributed with the 4.3 Berkeley Software Distribution. However, there are several other implementations of what is supposed to be the same protocol. Unfortunately, these various implementations disagree in various details. The specifications here represent a combination of features taken from various implementations.”
The name RIP can be deceiving since all routing protocols need to exchange “routing information.” RIP should be understood as an instance of a distance vector protocol family, regardless of its name. It was one of the few protocols for which an implementation was available before a specification was officially complete. The original RIP is now referred to as RIP version 1, or RIPv1 in short. It has since evolved to RIPv2, which is standardized in RFC 2453 [442].
RIP remains one of the popular routing protocols for a small network environment. In fact, most DSL/cable modem routers such as the ones from Linksys come bundled with RIP.
Thus, if you want to set up a private layer-3 IP network in your home or small office, you can do so by using multiple routers where you can invoke RIP.
5.3.1 Communication and Message Format
Since distance vector information is obtained from a neighboring router, the communication of routing information is always between two neighboring routers in the case of RIP. Further- more, since RIP is UDP based, there is no guarantee that a routing information message is received by a receiving router. Also, no session is set up; a routing packet is just encapsulated and sent to the neighbor, normally through broadcast. Thus, we can envision a routing packet in the TCP/IP stack as shown in Figure 5.2.
Next we consider the format of a RIPv1 message; this is shown in Figure 5.3. As a commonly accepted convention in IP, the packet format for RIPv1 is shown in 32-bit (4-byte) boundaries. A RIPv1 message has a common header of 4 bytes, followed by a 20- byte message for each route for which the message is communicating, up to a maximum of 25 routes/addresses. Thus, the maximum size of a RIP message (including IP/UDP headers)
F I G U R E 5.2 RIP message structure, with IP and UDP header.
F I G U R E 5.3 RIPv1 packet format.
is20+8+4+25×20=532 bytes while the minimum is20+8+4+20=52 bytes. It is important to note that the message size does not limit the size of the network in terms of the number of routers; rather it is in terms of the number of addressable networks or routes.
Consider again the three-router network shown in Figure 5.1 along with the routing table in Table 5.1. We can see that there are seven different addressable networks while there are three routers; thus, the routing table needs to have entries for all seven addressable networks, not in terms of routers.
It is important to note that the message size does not limit the size of the addressing net- works to 25 networks (certainly not to routers); if an IP network has more than 25 address- able networks, say 40 of them, a neighbor can send distance vector information for 25 ad- dressable networks in one message and the rest of the 15 addressable networks in another message.
Let us now look at the various fields. A common practice in many protocols is to have some spaces left out for future enhancement of the protocol; often, these spaces are marked with Must Be Zero. As can be seen, there are many places where this occurs in the RIPv1 message format; soon, we will see how some of them are utilized in the RIPv2 message for- mat. Thus, a RIPv1 message has the following five fields: command, version, address family identifier, IP address, and metric. They are described below with command being discussed last:
• Version (1 byte): This field indicates the RIP protocol version. This is set to 1 for RIPv1. If this field happens to be zero, the message is to be ignored.
• Address family identifier (2 bytes): This field identifies the address family. This is set to 2 for the IP address family. Originally, the intent was to provide RIP for other address fam-
ilies, although in practice this RIP packet format has not been used for any other address family. There is a special use case when this field is set to zero; see command field be- low.
• IP address (4 bytes): This is the destination network, identified by a subnet or a host.
• Metric (4 bytes): This is based on hop count; it is a number between 1 and 16 where 16 means unreachable or infinity.
• Command (1 byte): This field is used for different command sets in a RIPv1 message. While there were five different commands originally defined, only two are used: request and re- sponse; the others are obsolete. The request command can be used by a router to request a neighboring router for distance vector information. If the entire routing table is desired, a request message (referred to as “request-full”) is sent where the address family identifier is set to 0 and the metric to infinity; the response, however, follows a split horizon (see Section 3.3.3). However, if responses are sought for a set of address blocks (referred to as “request-partial”), the request flag is set, the address family identifier is set to IP, and the addresses are listed; the responding router sends a response to all addresses listed;
no split horizon is done in this case. This is with the understanding that such a special request is not a normal request. It may be noted that the periodic distance vector update message is also sent with command set to response mode. Since there is no identification field in a RIPv1 message (unlike, say, a DNS message format), a receiving router has no direct way to determine whether the response was a periodic response or a response to its
“request-full” or “request-partial.”
Due to the availability of the request message type, RIP can do information pull, instead of completely relying on information push.
5.3.2 General Operation
The following are the primary operational considerations in regard to the RIP protocol:
• General packet handling: if any of the must-be-zero fields have nonzero values anywhere or if the version field is zero, the packet is discarded.
• Initialization: when a router is activated and it determines that all the interfaces are alive, and it broadcasts a request message that goes to all interfaces in the “request-full” mode.
The neighboring routers handle responses following the split horizon rule. Once the re- sponses are received, the routing table is updated with new routes the router has learned about.
• Normal routing updates: in the default case, this is done approximately every 30 sec (“Autoupdate timer”) where updates are broadcasted with command fields set to the re- sponse mode; as discussed earlier about timer adjustment in Section 3.3.3, a large variation is added to avoid the pendulum effect.
• Normal response received: the routing table is updated by doing the distributed Bellman–
Ford step; only a single best route is stored for each destination.
• Triggered updates: if the metric for an addressable network changes, an update message is generated containing only the affected networks.
• Route expiration: if an addressable network has not been updated for 3 min (“expiration timer”) in the default case, its metric is set to infinity and it is a candidate for deletion.
However, it is kept in the routing table for another 60 sec; this extra time window is re- ferred to as garbage collection or flush timer.
5.3.3 Is RIPv1 Good to Use?
In some sense, RIP has gone through the growing pains of being one of the oldest routing pro- tocols in practice, coupled with the fact that it is a distance vector protocol that has various problems. Some key problems have been addressed through triggered update and avoid- ing the pendulum effect. However, it cannot avoid the looping problem and slow conver- gence.
In addition, RIP inherently imposes a few additional restrictions: the link cost is based only on hop count, a destination cannot be longer than 15 hops (since infinity is defined to be 16), and subnet masking is not provided. The last item deserves further elaboration. If you look at the RIPv1 message format, you will notice that it has a field for the addressable network, but no way to indicate anything specific about this network. This is partly because RIPv1 is an old protocol from the days of IP classful addressing; that is, RIPv1 assumes that an address included follows a Class A, Class B, Class C boundary implicitly. Subnet masking is an issue only for an address block that is not directly connected to a router. We illustrate this by considering the example network shown in Figure 5.1. Suppose that we want to connect subnet address block 172.16.1.0 to router Alpha and subnet 172.16.2.0 to router Charlie. RIPv1, however, implicitly assumes 172.16.0.0 to be a Class B address and thus cannot make the distinction; this means subnet allocation to different routers would not be routable, especially for traffic coming from a network attached to router Bravo.
From an actual operational point of view, RIPv1 is good to use in a small network envi- ronment where links are not likely to fail; this means looping is unlikely to occur. It is also good to use when link cost is not a factor, for example, a simple campus network or a small home network or a simple topology (e.g., hub-and-spoke) where the traffic may be low com- pared to the link speed. If a link or an interface card is likely to fail, RIPv1 faces serious transient issues including possibly creating black hole routes.