RIP Protocol Specification

This page specifies our version of the RIP protocol. Our protocol is based on RFC2453–please see this document for more details. Note that our specifications override any specifications in the RFC version.

We will discuss the RIP protocol in detail during class within the first week of the assignment’s release. You can also read more about the RIP protocol in Sections 13.1–13.2 of the Dordal textbook or in Section 4.2.2 of the Peterson textbook.

Message format

Our version of RIP uses a slightly modified packet structure. You must adhere to the following packet format for exchanging RIP information:

uint16 command;
uint16 num_entries;
struct {
    uint32 cost;     // Integer value of cost
    uint32 address;  // Byte representation of the IP address
    uint32 mask;     // Byte representation of the subnet mask 
} entries[num_entries];
If you are using C or C++

If you are writing in C or C++, consider using flexible array members to allocate space within your packet data.

The RIP message fields must adhere to the following:

  • command will be 1 for a request of routing information, and 2 for a response
  • num_entries will not exceed 64 (and must be 0 for a request command)

  • cost will not exceed 16. We define infinity to be 16.

  • address and mask are the network address and subnet mask for the IP prefix being advertised, indicating the size of the network. For example, to advertise the prefix 1.2.3.0/24, address should have the value 1.2.3.0 and mask should be 255.255.255.0

As with all network protocols, all fields must be sent on the wire in network byte order.

In the standard version of RIP, packets are typically sent to routers via UDP. In our version, RIP messages are sent directly inside our (virtual) IP packets, using IP protocol 200.

Protocol operation

Terminology: RIP neighbors

As RIP is a distance-vector protocol, routers communicate by sending messages to neighboring RIP routers. In our virtual network, routers always know their RIP neighbors based on the lnx file: neighbors are listed using one or more rip advertise-to directives. For more info on how RIP neighbors are specified, see here.

RIP requests

Once a router comes online, it must send a Request to each of its RIP neighbors. Whenever a router receives a RIP request, it should send a RIP Response containing all routes in its routing table (same as a periodic update).

RIP responses

RIP responses (also called “RIP updates”) are sent in the following cases (notes on each below):

  1. As a response to a RIP request
  2. A periodic update, which is sent by the router every 5 seconds
  3. A triggered update, which is sent whenever the router’s routing table changes

For RIP responses and periodic updates (cases 1 and 2), the update message MUST contain all entries in the router’s routing table.

Triggered updates (case 2) should only be sent with the node’s routing table is updated, and should only include the updated entries, not the entire table.

Split Horizon, Poison Reverse

Your RIP messages MUST use split horizon with poisoned reverse.

What does this mean? Split horizon enforces that a node does not send any new routing information to the router from which they received the information; this prevents route instability and infinite loops. For example, if a node A receives a route to node C from node B, in the RIP response, A does not advertise the route to C through B.

Split horizon with poisoned reverse is a variant wherein a router advertises “unreachability” (i.e. a cost of INFINITY) instead of not responding. In the above example, A would advertise a route to C with a cost of INFINITY, rather than not sending the route back to B.

More information can be found in the RIP RFC.

Route timeouts

A routing entry learned from neighbor router should expire if it has not been refreshed in 12 seconds.

When a route expires, your router should:

  1. Set the route’s cost to infinity (16)
  2. Send a triggered update
  3. Remove the route from the routing table

Overall, once your node expires a route, it should be able to update its table when a new, better route arrives.

RIP and disabled interfaces (up/down)

No changes to RIP functionality are required for disabled interfaces. Some optimizations are possible that can reduce RIP update size or lead to faster convergence, but they are not required. Specifically:

  • Routers MAY stop advertising a route for a local prefix when that interface is disabled (or advertise it with cost 16)
  • Routers MAY send a triggered update when a link is disabled or enabled