RIP, Routing Information Protocol

Description Glossary RFCs Publications Obsolete RFCs

Description:

Protocol suite: TCP/IP.
Protocol 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).

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 maximum datagram size is 512 bytes not including the IP or UDP headers.

RIP version 2 (RIPv2).

This version added several new features.

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 header IP header UDP header RIP header Data :::

RIPv1 header:

0001020304050607 0809101112131415 1617181920212223 2425262728293031
Command Version 0
RIPv1 entry table :::

RIPv2 header:

0001020304050607 0809101112131415 1617181920212223 2425262728293031
Command Version 0
RIPv2 entry table :::

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
7 Triggered response. RFC 1582
8 Triggered acknowledgement. RFC 1582
9 Update Request. RFC 2091
10 Update 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:

0001020304050607 0809101112131415 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Address family0
IPv4 address
0
0
Metric

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

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Address family Route tag
IPv4 address
Subnet mask
Next hop
Metric

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:

Fragmentation is not allowed in an update.

Triggered updates.


RFCs:

[RFC 1058] Routing Information Protocol.

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

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

[RFC 1721] RIP Version 2 Protocol Analysis.

[RFC 1722] RIP Version 2 Protocol Applicability Statement.

[RFC 1723] RIP Version 2 Carrying Additional Information.

[RFC 1724] RIP Version 2 MIB Extension.

[RFC 1812] Requirements for IP Version 4 Routers.

[RFC 1923] RIPv1 Applicability Statement for Historic Status.

[RFC 2082] RIP-2 MD5 Authentication.

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

[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.


Description Glossary RFCs Publications Obsolete RFCs