Skip to content

Ripv1 Header Format For Essay

RIP, Routing Information Protocol


Description:

RIP version 1 (RIPv1).

This 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).

This version 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.


MAC headerIP headerUDP headerRIP headerData :::

RIPv1 header:

RIPv2 header:

Command. 8 bits.

ValueDescriptionReferences
1Request. A request for the responding system to send all or part of its routing table. 
2Response. A message containing all or part of the sender's routing table. This message may be sent in response to a request, or it may be an unsolicited routing update generated by the sender. 
3Trace on.Obsolete. 
4Trace off.Obsolete. 
5SUN reserved. 
6Triggered request.RFC 1582
7Triggered response.RFC 1582
8Triggered acknowledgement.RFC 1582
9Update Request.RFC 2091
10Update Response.RFC 2091
11Update Acknowledge.RFC 2091

Version. 8 bits.
The RIP protocol version.

RIPv1 entry table. Variable length.
An array of RIPv1 entries. Each RIPv1 entry contains the following structure:

RIPv2 entry table. Variable length.
An array of RIPv2 entries. Each RIPv2 entry contains the following structure:

Address family. 16 bits.

Route tag. 16 bits.
Cleared to 0 for RIPv1. For RIPv2, this is an attribute assigned to a route which must be preserved and readvertised with a route. The intended use of this tag is to provide a method of separating routes for networks within the RIP routing domain from routes which may have been imported from an EGP or another IGP.

IPv4 address. 32 bits.

Subnet mask. 32 bits.
Cleared to 0 for RIPv1. For RIPv2, this is the subnet mask that can be applied to the IPv4 address to resolve the network portion of the address. If the field is cleared to 0, no subnet mask is specified.

Next hop. 32 bits.
Cleared to 0 for RIPv1. For RIPv2, this is the IP where packets for this entry should be forwarded to.

Metric. 32 bits.
Contains a value from 1 to 15 which specifies the current metric for the destination. A value of 16 indicates that the destination is not reachable.


Glossary:

Circuit Manager.
A circuit manager provides an interface between the connectionless and connection oriented network layers. The circuit manager takes datagrams from the connectionless network layer protocols and as necessary opens a virtual circuit to the next hop router.

Demand RIP.
Has an upper limit of 255 fragments in an update. This sets an upper limit on the sizes of routing and service advertising databases which can be propagated.

Triggered RIP.
Routing updates are only transmitted for the following conditions:

  • A request for a routing update has been received.
  • The routing database is modified by new information from another interface.
  • The circuit manager indicates that a destination has changed from an unreachable to a reachable state.
  • When a unit is first powered on to ensure that at least one update is sent. This can be thought of as a transition from unreachable to reachable. It MAY contain no routes or services, and is used to flush routes or services from the peer's database.

Fragmentation is not allowed in an update.

Triggered updates.


RFCs:

[RFC 1058] Routing Information Protocol.

  • STD: 34.
  • Defines RIP version 1.

[RFC 1581] Protocol Analysis for Extensions to RIP to Support Demand Circuits.

[RFC 1582] Extensions to RIP to Support Demand Circuits.

  • Category: Standards Track.

[RFC 1721] RIP Version 2 Protocol Analysis.

  • Category: Informational.
  • Obsoletes:
    RFC 1387.

[RFC 1722] RIP Version 2 Protocol Applicability Statement.

[RFC 1723] RIP Version 2 Carrying Additional Information.

[RFC 1724] RIP Version 2 MIB Extension.

  • Category: Standards Track.
  • Defines SNMP MIB iso.org.dod.internet.mgmt.mib-2.rip-2 (1.3.6.1.2.1.23).
  • Obsoletes:
    RFC 1389.

[RFC 1812] Requirements for IP Version 4 Routers.

[RFC 1923] RIPv1 Applicability Statement for Historic Status.

[RFC 2082] RIP-2 MD5 Authentication.

  • Category: Standards Track.

[RFC 2091] Triggered Extensions to RIP to Support Demand Circuits.

  • Category: Standards Track.

[RFC 2092] Protocol Analysis for Triggered RIP.

[RFC 2453] RIP Version 2.


Publications:


Obsolete RFCs:

[RFC 1387] RIP Version 2 Protocol Analysis.

[RFC 1388] RIP Version 2 Carrying Additional Information.

[RFC 1389] RIP Version 2 MIB Extension.



Welcome to the heart of networking: the routing protocols. We begin our series of looks at these protocols with one of the originals, and the most simple: RIP, the Routing Information Protocol.

RIP, like all routing protocols, is designed to disseminate network information pertinent to routers. At the most basic level, routers need to know what networks are reachable and how far away they are. RIP does this, and it’s still widely used today. In fact, we received feedback regarding last week’s Routing Overview from a reader who happily uses RIP at the ISP he works for.

Many people have nasty things to say about RIP. They say it converges slowly, it doesn’t scale, it’s insecure because authentication is only plain text, and it suffers from split-horizon issues. This is all true, but it’s still very useful. We hope this article will shed some light on these issues, and help you understand one of the most widely used interior gateway protocols (IGPs) out there.

RIP comes in two flavors: version one and version two. RIPv1 is very limiting because it doesn’t support CIDR addressing. This means it is classfull only, and you can’t slice up, for example, a /24 space into smaller units. RIPv1 also uses broadcast to send its information, which means that hosts can’t ignore RIP advertisements. Remember that each time a broadcast is sent, every host in the broadcast domain will receive an interrupt, and it must process the packet to determine if it’s something it cares about. RIPv2 uses multicast, which will be covered in a future installment of Networking 101. For now, just trust that hosts can ignore multicast without having to process the packet.

Remember, we said that RIP is a distance-vector protocol. The distance part is referring to the hop count in RIP, and the vector is the destination. Other distance-vector protocols may use other criteria for the vector, like an AS path in BGP. Both RIP flavors send their information every 30 seconds to UDP port 520. But what do they send? If you assumed “their routing information” you are correct. It can send specific information about networks it can reach, and also advertise itself as the default gateway (by sending 0.0.0.0 with a metric of 1).

The RIPv2 packet contains headers, just like any other protocol. Note that RIP is above UDP, so it is essentially an application-layer protocol. Every RIP packet contains a command, a version number, and a routing domain. Then up to 25 routes will follow in the same packet.

The Command
A RIP command is either a request or a response. When hosts, either a Unix box running gated or a router, first boot, they need to obtain routing information somehow. The “request” is just that, a request broadcast to ask for a routing table. The “response” is a normal RIP message, which will be in response to a request, or simply broadcast every 30 seconds.

The Version Number
The version number is either one or two.

The Routing Domain
A routing domain in RIP is an identifier used to specify the routing instance. More than one set of RIP instances can exist on the same network by specifying that a message be only intended for only people in a specific domain.

The Rest of the Packet
Then the real RIP information starts. This contains up to 25 routes, which entail the following information:

  • Network Address: to identify the start of the network.
  • Netmask: to say how large the network is.
  • Next-hop IP Address: i.e. the router that can get you there.
  • Metric: how many hops away this network is.

An important characteristic of RIP is that it will tell you about networks it heard from other people. You may hear these types of routing protocols called “routing by rumor.” The way this works is that the metric field is incremented before a router broadcasts a RIP packet. If router A tells you that it can get you to router B in two hops, then you know router A can talk directly to B, because it’s only one hop away. Ergo, router A has a link in the same broadcast domain as router B, but you do not.

When the metric, or hop count, reaches 16 you’re in trouble. The number 16 means infinity in RIP. Infinity being equal to 16 is a mechanism used to stop the problem of “count to infinity.” This happens because of the “routing by rumor” design. This can get tricky, but bear with this three-router example:

Router A knows that it can get to router C in two hops, via B. The picture in your mind should involve a straight line with B in the middle, and A and C on the ends. Now, since B has a direct connection to C, it will know when C goes down. But before B gets a change to tell A about C being down, A chimes in with a RIP update, which will include “I can get to C in two hops!” Router B will of course believe A, which means it thinks that A can get to C. Of course, A cannot, since its path was through B. But B doesn’t know this, because the only information in RIP is the next-hop address, which is A. Finally, when B sends his next update, he will include the route to C, which is now 3 hops. A believes B, because after all, B was the only way to C. This happens a few more times, and we’re at 16. The route is dropped instead of this continuing forever.

How is this problem solved? Not with a distance-vector protocol. When we “tell our neighbors about the world” without providing detailed information about each network, count to infinity is possible. Link-state protocols provide an entire view of the network to all routers, and avoid this issue. "Split-horizon" is another method that will help obviate this bug, but it is flawed as well.

Split-horizon means we would keep track of the interface an update came in on, and pay attention to updates from other routers that could conflict. This helps, but similar situations to the one above can still exist, when more routers are involved. That example gets really complex, but if you’re interested in RIP, feel free to invent a scenario in which count-to-infinity could happen, even with split-horizon capabilities.

The final “issue” with RIP is that it converges slowly. This is true, mostly because of the 30-second wait between updates, but in smaller organizations it doesn’t matter. RIPv2 is implemented on nearly all hardware, even those cheap “home routers” that you buy to NAT a broadband connection. Even if you don’t use RIP exclusively as an IGP, it’s still useful to know about because hosts can use it as well, as an alternative (or supplicant) to manually configuring a default gateway. Finally, if you’re small enough to be using all static routes, RIPv2 is sure to help make your life easier.