As per Relevance of the word triggered, we have this rfc below:
Network Working Group G.
Request for Comments: 2453 Bay
Obsoletes: 1723, 1388 November 1998
STD: 56
Category: Standards
RIP Version 2
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document specifies an extension of the Routing
Protocol (RIP), as defined in [1], to expand the amount of
information carried in RIP messages and to add a measure of security
A companion document will define the SNMP MIB objects for RIP-2 [2].
An additional document will define cryptographic
improvements for RIP-2 [3].
I would like to thank the IETF RIP Working Group for their help
improving the RIP-2 protocol. Much of the text for the
discussions about distance vector protocols and some of
descriptions of the operation of RIP were taken from "
Information Protocol" by C. Hedrick [1]. Some of the final editing
the document was done by Scott Bradner
Malkin Standards Track [Page 1]
RFC 2453 RIP Version 2 November 1998
Table of
1. Justification . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Limitations of the Protocol . . . . . . . . . . . . . . . . 5
3.3. Organization of this document . . . . . . . . . . . . . . . 6
3.4 Distance Vector Algorithms . . . . . . . . . . . . . . . . . 6
3.4.1 Dealing with changes in topology . . . . . . . . . . . . 12
3.4.2 Preventing instability . . . . . . . . . . . . . . . . . 13
3.4.3 Split horizon . . . . . . . . . . . . . . . . . . . . . . 15
3.4.4 Triggered updates . . . . . . . . . . . . . . . . . . . . 17
3.5 Protocol Specification . . . . . . . . . . . . . . . . . . 18
3.6 Message Format . . . . . . . . . . . . . . . . . . . . . . . 20
3.7 Addressing Considerations . . . . . . . . . . . . . . . . . 22
3.8 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.9 Input Processing . . . . . . . . . . . . . . . . . . . . . . 25
3.9.1 Request Messages . . . . . . . . . . . . . . . . . . . . 25
3.9.2 Response Messages . . . . . . . . . . . . . . . . . . . . 26
3.10 Output Processing . . . . . . . . . . . . . . . . . . . . . 28
3.10.1 Triggered Updates . . . . . . . . . . . . . . . . . . . . 29
3.10.2 Generating Response Messages. . . . . . . . . . . . . . . 30
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 31
4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1 Compatibility Switch . . . . . . . . . . . . . . . . . . . . 34
5.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Larger Infinity . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Addressless Links . . . . . . . . . . . . . . . . . . . . . 35
6. Interaction between version 1 and version 2 . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 39
Malkin Standards Track [Page 2]
RFC 2453 RIP Version 2 November 1998
1.
With the advent of OSPF and IS-IS, there are those who believe
RIP is obsolete. While it is true that the newer IGP
protocols are far superior to RIP, RIP does have some advantages
Primarily, in a small network, RIP has very little overhead in
of bandwidth used and configuration and management time. RIP is
very easy to implement, especially in relation to the newer IGPs
Additionally, there are many, many more RIP implementations in
field than OSPF and IS-IS combined. It is likely to remain that
for some years yet
Given that RIP will be useful in many environments for some period
time, it is reasonable to increase RIP's usefulness. This
especially true since the gain is far greater than the expense of
change
2. Current
The current RIP-1 message contains the minimal amount of
necessary for routers to route messages through a network. It
contains a large amount of unused space, owing to its origins
The current RIP-1 protocol does not consider autonomous systems
IGP/EGP interactions, subnetting [11], and authentication
implementations of these postdate RIP-1. The lack of subnet masks
a particularly serious problem for routers since they need a
mask to know how to determine a route. If a RIP-1 route is a
route (all non-network bits 0), the subnet mask equals the
mask. However, if some of the non-network bits are set, the
cannot determine the subnet mask. Worse still, the router
determine if the RIP-1 route is a subnet route or a host route
Currently, some routers simply choose the subnet mask of
interface over which the route was learned and determine the
type from that
3. Basic
3.1
RIP is a routing protocol based on the Bellman-Ford (or
vector) algorithm. This algorithm has been used for
computations in computer networks since the early days of
ARPANET. The particular packet formats and protocol described
are based on the program "routed," which is included with
Berkeley distribution of Unix
Malkin Standards Track [Page 3]
RFC 2453 RIP Version 2 November 1998
In an international network, such as the Internet, it is
unlikely that a single routing protocol will used for the
network. Rather, the network will be organized as a collection
Autonomous Systems (AS), each of which will, in general,
administered by a single entity. Each AS will have its own
technology, which may differ among AS's. The routing protocol
within an AS is referred to as an Interior Gateway Protocol (IGP).
separate protocol, called an Exterior Gateway Protocol (EGP), is
to transfer routing information among the AS's. RIP was designed
work as an IGP in moderate-size AS's. It is not intended for use
more complex environments. For information on the context into
RIP-1 is expected to fit, see Braden and Postel [6].
RIP uses one of a class of routing algorithms known as
Vector algorithms. The earliest description of this class
algorithms known to the author is in Ford and Fulkerson [8].
of this, they are sometimes known as Ford-Fulkerson algorithms.
term Bellman-Ford is also used, and derives from the fact that
formulation is based on Bellman's equation [4]. The presentation
this document is closely based on [5]. This document contains
protocol specification. For an introduction to the mathematics
routing algorithms, see [1]. The basic algorithms used by
protocol were used in computer routing as early as 1969 in
ARPANET. However, the specific ancestry of this protocol is
the Xerox network protocols. The PUP protocols [7] used the
Information Protocol to exchange routing information. A
updated version of this protocol was adopted for the Xerox
Systems (XNS) architecture, with the name Routing
Protocol [9]. Berkeley's routed is largely the same as the
Information Protocol, with XNS addresses replaced by a more
address format capable of handling IPv4 and other types of address
and with routing updates limited to one every 30 seconds. Because
this similarity, the term Routing Information Protocol (or just RIP
is used to refer to both the XNS protocol and the protocol used
routed
RIP is intended for use within the IP-based Internet. The
is organized into a number of networks connected by special
gateways known as routers. The networks may be either point-to-
links or more complex networks such as Ethernet or token ring.
and routers are presented with IP datagrams addressed to some host
Routing is the method by which the host or router decides where
send the datagram. It may be able to send the datagram directly
the destination, if that destination is on one of the networks
are directly connected to the host or router. However,
interesting case is when the destination is not directly reachable
Malkin Standards Track [Page 4]
RFC 2453 RIP Version 2 November 1998
In this case, the host or router attempts to send the datagram to
router that is nearer the destination. The goal of a
protocol is very simple: It is to supply the information that
needed to do routing
3.2 Limitations of the
This protocol does not solve every possible routing problem.
mentioned above, it is primary intended for use as an IGP in
of moderate size. In addition, the following specific
are be mentioned
- The protocol is limited to networks whose longest path (
network's diameter) is 15 hops. The designers believe that
basic protocol design is inappropriate for larger networks.
that this statement of the limit assumes that a cost of 1 is
for each network. This is the way RIP is normally configured.
the system administrator chooses to use larger costs, the
bound of 15 can easily become a problem
- The protocol depends upon "counting to infinity" to resolve
unusual situations. (This will be explained in the next section.)
If the system of networks has several hundred networks, and
routing loop was formed involving all of them, the resolution
the loop would require either much time (if the frequency
routing updates were limited) or bandwidth (if updates were
whenever changes were detected). Such a loop would consume a
amount of network bandwidth before the loop was corrected.
believe that in realistic cases, this will not be a problem
on slow lines. Even then, the problem will be fairly unusual
since various precautions are taken that should prevent
problems in most cases
- This protocol uses fixed "metrics" to compare alternative routes
It is not appropriate for situations where routes need to be
based on real-time parameters such a measured delay, reliability
or load. The obvious extensions to allow metrics of this type
likely to introduce instabilities of a sort that the protocol
not designed to handle
Malkin Standards Track [Page 5]
RFC 2453 RIP Version 2 November 1998
3.3. Organization of this
The main body of this document is organized into two parts,
occupy the next two sections
A conceptual development and justification of distance
algorithms in general
The actual protocol description
Each of these two sections can largely stand on its own. Section 3.4
attempts to give an informal presentation of the
underpinnings of the algorithm. Note that the presentation follows
"spiral" method. An initial, fairly simple algorithm is described
Then refinements are added to it in successive sections. Section 3.5
is the actual protocol description. Except where specific
are made to section 3.4, it should be possible to implement
entirely from the specifications given in section 3.5.
3.4 Distance Vector
Routing is the task of finding a path from a sender to a
destination. In the IP "Internet model" this reduces primarily to
matter of finding a series of routers between the source
destination networks. As long as a message or datagram remains on
single network or subnet, any forwarding problems are
responsibility of technology that is specific to the network.
example, Ethernet and the ARPANET each define a way in which
sender can talk to any specified destination within that one network
IP routing comes in primarily when messages must go from a sender
one network to a destination on a different one. In that case,
message must pass through one or more routers connecting
networks. If the networks are not adjacent, the message may
through several intervening networks, and the routers
them. Once the message gets to a router that is on the same
as the destination, that network's own technology is used to get
the destination
Throughout this section, the term "network" is used generically
cover a single broadcast network (e.g., an Ethernet), a point
point line, or the ARPANET. The critical point is that a network
treated as a single entity by IP. Either no forwarding decision
necessary (as with a point to point line), or that forwarding is
in a manner that is transparent to IP, allowing IP to treat
entire network as a single fully-connected system (as with
Ethernet or the ARPANET). Note that the term "network" is used in
somewhat different way in discussions of IP addressing. We are
the term "network" here to refer to subnets in cases where
Malkin Standards Track [Page 6]
RFC 2453 RIP Version 2 November 1998
addressing is in use
A number of different approaches for finding routes between
are possible. One useful way of categorizing these approaches is
the basis of the type of information the routers need to exchange
order to be able to find routes. Distance vector algorithms
based on the exchange of only a small amount of information.
entity (router or host) that participates in the routing protocol
assumed to keep information about all of the destinations within
system. Generally, information about all entities connected to
network is summarized by a single entry, which describes the route
all destinations on that network. This summarization is
because as far as IP is concerned, routing within a network
invisible. Each entry in this routing database includes the
router to which datagrams destined for the entity should be sent.
addition, it includes a "metric" measuring the total distance to
entity. Distance is a somewhat generalized concept, which may
the time delay in getting messages to the entity, the dollar cost
sending messages to it, etc. Distance vector algorithms get
name from the fact that it is possible to compute optimal routes
the only information exchanged is the list of these distances
Furthermore, information is only exchanged among entities that
adjacent, that is, entities that share a common network
Although routing is most commonly based on information
networks, it is sometimes necessary to keep track of the routes
individual hosts. The RIP protocol makes no formal
between networks and hosts. It simply describes exchange
information about destinations, which may be either networks
hosts. (Note however, that it is possible for an implementor
choose not to support host routes. See section 3.2.) In fact,
mathematical developments are most conveniently thought of in
of routes from one host or router to another. When discussing
algorithm in abstract terms, it is best to think of a routing
for a network as an abbreviation for routing entries for all of
entities connected to that network. This sort of abbreviation
sense only because we think of networks as having no
structure that is visible at the IP level. Thus, we will
assign the same distance to every entity in a given network
We said above that each entity keeps a routing database with
entry for every possible destination in the system. An
implementation is likely to need to keep the following
about each destination
Malkin Standards Track [Page 7]
RFC 2453 RIP Version 2 November 1998
- address: in IP implementations of these algorithms, this will
the IP address of the host or network
- router: the first router along the route to the destination
- interface: the physical network which must be used to reach
first router
- metric: a number, indicating the distance to the destination
- timer: the amount of time since the entry was last updated
In addition, various flags and other internal information
probably be included. This database is initialized with
description of the entities that are directly connected to
system. It is updated according to information received in
from neighboring routers
The most important information exchanged by the hosts and routers
carried in update messages. Each entity that participates in
routing scheme sends update messages that describe the
database as it currently exists in that entity. It is possible
maintain optimal routes for the entire system by using
information obtained from neighboring entities. The algorithm
for that will be described in the next section
As we mentioned above, the purpose of routing is to find a way to
datagrams to their ultimate destinations. Distance vector
are based on a table in each router listing the best route to
destination in the system. Of course, in order to define which
is best, we have to have some way of measuring goodness. This
referred to as the "metric".
In simple networks, it is common to use a metric that simply
how many routers a message must go through. In more
networks, a metric is chosen to represent the total amount of
that the message suffers, the cost of sending it, or some
quantity which may be minimized. The main requirement is that
must be possible to represent the metric as a sum of "costs"
individual hops
Formally, if it is possible to get from entity i to entity j
(i.e., without passing through another router between), then a cost
d(i,j), is associated with the hop between i and j. In the
case where all entities on a given network are considered to be
same, d(i,j) is the same for all destinations on a given network,
represents the cost of using that network. To get the metric of
complete route, one just adds up the costs of the individual
Malkin Standards Track [Page 8]
RFC 2453 RIP Version 2 November 1998
that make up the route. For the purposes of this memo, we
that the costs are positive integers
Let D(i,j) represent the metric of the best route from entity i
entity j. It should be defined for every pair of entities. d(i,j
represents the costs of the individual steps. Formally, let d(i,j
represent the cost of going directly from entity i to entity j.
is infinite if i and j are not immediate neighbors. (Note that d(i,i
is infinite. That is, we don't consider there to be a
connection from a node to itself.) Since costs are additive, it
easy to show that the best metric must be described
D(i,i) = 0, all
D(i,j) = min [d(i,k) + D(k,j)],
and that the best routes start by going from i to those neighbors
for which d(i,k) + D(k,j) has the minimum value. (These things
be shown by induction on the number of steps in the routes.)
that we can limit the second equation to k's that are
neighbors of i. For the others, d(i,k) is infinite, so the
involving them can never be the minimum
It turns out that one can compute the metric by a simple
based on this. Entity i gets its neighbors k to send it
estimates of their distances to the destination j. When i gets
estimates from k, it adds d(i,k) to each of the numbers. This
simply the cost of traversing the network between i and k. Now
then i compares the values from all of its neighbors and picks
smallest
A proof is given in [2] that this algorithm will converge to
correct estimates of D(i,j) in finite time in the absence of
changes. The authors make very few assumptions about the order
which the entities send each other their information, or when the
is recomputed. Basically, entities just can't stop sending
or recomputing metrics, and the networks can't delay
forever. (Crash of a routing entity is a topology change.) Also
their proof does not make any assumptions about the initial
of D(i,j), except that they must be non-negative. The fact
these fairly weak assumptions are good enough is important.
we don't have to make assumptions about when updates are sent, it
safe to run the algorithm asynchronously. That is, each entity
send updates according to its own clock. Updates can be dropped
the network, as long as they don't all get dropped. Because we don'
have to make assumptions about the starting condition, the
can handle changes. When the system changes, the routing
starts moving to a new equilibrium, using the old one as its
point. It is important that the algorithm will converge in
Malkin Standards Track [Page 9]
RFC 2453 RIP Version 2 November 1998
time no matter what the starting point. Otherwise certain kinds
changes might lead to non-convergent behavior
The statement of the algorithm given above (and the proof)
that each entity keeps copies of the estimates that come from each
its neighbors, and now and then does a min over all of the neighbors
In fact real implementations don't necessarily do that. They
remember the best metric seen so far, and the identity of
neighbor that sent it. They replace this information whenever
see a better (smaller) metric. This allows them to compute
minimum incrementally, without having to store data from all of
neighbors
There is one other difference between the algorithm as described
texts and those used in real protocols such as RIP: the
above would have each entity include an entry for itself, showing
distance of zero. In fact this is not generally done. Recall
all entities on a network are normally summarized by a single
for the network. Consider the situation of a host or router G
is connected to network A. C represents the cost of using network
(usually a metric of one). (Recall that we are assuming that
internal structure of a network is not visible to IP, and thus
cost of going between any two entities on it is the same.)
principle, G should get a message from every other entity H
network A, showing a cost of 0 to get from that entity to itself.
would then compute C + 0 as the distance to H. Rather than having
look at all of these identical messages, it simply starts out
making an entry for network A in its table, and assigning it a
of C. This entry for network A should be thought of as
the entries for all other entities on network A. The only entity
A that can't be summarized by that common entry is G itself,
the cost of going from G to G is 0, not C. But since we never
those 0 entries, we can safely get along with just the single
for network A. Note one other implication of this strategy:
we don't need to use the 0 entries for anything, hosts that do
function as routers don't need to send any update messages.
hosts that don't function as routers (i.e., hosts that are
to only one network) can have no useful information to
other than their own entry D(i,i) = 0. As they have only the
interface, it is easy to see that a route to any other
through them will simply go in that interface and then come
back out it. Thus the cost of such a route will be greater than
best cost by at least C. Since we don't need the 0 entries, non
routers need not participate in the routing protocol at all
Let us summarize what a host or router G does. For each
in the system, G will keep a current estimate of the metric for
destination (i.e., the total cost of getting to it) and the
Malkin Standards Track [Page 10]
RFC 2453 RIP Version 2 November 1998
of the neighboring router on whose data that metric is based. If
destination is on a network that is directly connected to G, then
simply uses an entry that shows the cost of using the network,
the fact that no router is needed to get to the destination. It
easy to show that once the computation has converged to the
metrics, the neighbor that is recorded by this technique is in
the first router on the path to the destination. (If there
several equally good paths, it is the first router on one of them.)
This combination of destination, metric, and router is
referred to as a route to the destination with that metric,
that router
4.ne The method so far only has a way to lower the metric, as
existing metric is kept until a smaller one shows up. It is
that the initial estimate might be too low. Thus, there must be
way to increase the metric. It turns out to be sufficient to use
following rule: suppose the current route to a destination has
D and uses router G. If a new set of information arrived from
source other than G, only update the route if the new metric
better than D. But if a new set of information arrives from
itself, always update D to the new value. It is easy to show
with this rule, the incremental update process produces the
routes as a calculation that remembers the latest information
all the neighbors and does an explicit minimum. (Note that
discussion so far assumes that the network configuration is static
It does not allow for the possibility that a system might fail.)
To summarize, here is the basic distance vector algorithm as it
been developed so far. (Note that this is not a statement of the
protocol. There are several refinements still to be added.)
following procedure is carried out by every entity that
in the routing protocol. This must include all of the routers in
system. Hosts that are not routers may participate as well
- Keep a table with an entry for every possible destination in
system. The entry contains the distance D to the destination,
the first router G on the route to that network. Conceptually
there should be an entry for the entity itself, with metric 0,
this is not actually included
- Periodically, send a routing update to every neighbor. The
is a set of messages that contain all of the information from
routing table. It contains an entry for each destination, with
distance shown to that destination
- When a routing update arrives from a neighbor G', add the
associated with the network that is shared with G'. (This
be the network over which the update arrived.) Call the
Malkin Standards Track [Page 11]
RFC 2453 RIP Version 2 November 1998
distance D'. Compare the resulting distances with the
routing table entries. If the new distance D' for N is
than the existing value D, adopt the new route. That is,
the table entry for N to have metric D' and router G'. If G'
the router from which the existing route came, i.e., G' = G,
use the new metric even if it is larger than the old one
3.4.1 Dealing with changes in
The discussion above assumes that the topology of the network
fixed. In practice, routers and lines often fail and come back up
To handle this possibility, we need to modify the algorithm slightly
The theoretical version of the algorithm involved a minimum over
immediate neighbors. If the topology changes, the set of
changes. Therefore, the next time the calculation is done,
change will be reflected. However, as mentioned above,
implementations use an incremental version of the minimization.
the best route to any given destination is remembered. If the
involved in that route should crash, or the network connection to
break, the calculation might never reflect the change. The
as shown so far depends upon a router notifying its neighbors if
metrics change. If the router crashes, then it has no way
notifying neighbors of a change
In order to handle problems of this kind, distance vector
must make some provision for timing out routes. The details
upon the specific protocol. As an example, in RIP every router
participates in routing sends an update message to all its
once every 30 seconds. Suppose the current route for network N
router G. If we don't hear from G for 180 seconds, we can
that either the router has crashed or the network connecting us to
has become unusable. Thus, we mark the route as invalid. When
hear from another neighbor that has a valid route to N, the
route will replace the invalid one. Note that we wait for 180
seconds before timing out a route even though we expect to hear
each neighbor every 30 seconds. Unfortunately, messages
occasionally lost by networks. Thus, it is probably not a good
to invalidate a route based on a single missed message
As we will see below, it is useful to have a way to notify
that there currently isn't a valid route to some network. RIP,
with several other protocols of this class, does this through
normal update message, by marking that network as unreachable.
specific metric value is chosen to indicate an
destination; that metric value is larger than the largest
metric that we expect to see. In the existing implementation of RIP
16 is used. This value is normally referred to as "infinity",
Malkin Standards Track [Page 12]
RFC 2453 RIP Version 2 November 1998
it is larger than the largest valid metric. 16 may look like
surprisingly small number. It is chosen to be this small for
that we will see shortly. In most implementations, the
convention is used internally to flag a route as invalid
3.4.2 Preventing
The algorithm as presented up to this point will always allow a
or router to calculate a correct routing table. However, that
still not quite enough to make it useful in practice. The
referred to above only show that the routing tables will converge
the correct values in finite time. They do not guarantee that
time will be small enough to be useful, nor do they say what
happen to the metrics for networks that become inaccessible
It is easy enough to extend the mathematics to handle routes
inaccessible. The convention suggested above will do that.
choose a large metric value to represent "infinity". This value
be large enough that no real metric would ever get that large.
the purposes of this example, we will use the value 16. Suppose
network becomes inaccessible. All of the immediately
routers time out and set the metric for that network to 16.
purposes of analysis, we can assume that all the neighboring
have gotten a new piece of hardware that connects them directly
the vanished network, with a cost of 16. Since that is the
connection to the vanished network, all the other routers in
system will converge to new routes that go through one of
routers. It is easy to see that once convergence has happened,
the routers will have metrics of at least 16 for the
network. Routers one hop away from the original neighbors would
up with metrics of at least 17; routers two hops away would end
with at least 18, etc. As these metrics are larger than the
metric value, they are all set to 16. It is obvious that the
will now converge to a metric of 16 for the vanished network at
routers
Unfortunately, the question of how long convergence will take is
amenable to quite so simple an answer. Before going any further,
will be useful to look at an example (taken from [2]). Note
what we are about to show will not happen with a
implementation of RIP. We are trying to show why certain
are needed. In the following example the letters correspond
routers, and the lines to networks
Malkin Standards Track [Page 13]
RFC 2453 RIP Version 2 November 1998
A-----
\ / \
\ / |
C / all networks have cost 1,
| / for the direct link from C to D,
|/ has cost 10
|<=== target
Each router will have a table showing a route to each network
However, for purposes of this illustration, we show only the
from each router to the network marked at the bottom of the diagram
D: directly connected, metric 1
B: route via D, metric 2
C: route via B, metric 3
A: route via B, metric 3
Now suppose that the link from B to D fails. The routes should
adjust to use the link from C to D. Unfortunately, it will take
while for this to this to happen. The routing changes start when
notices that the route to D is no longer usable. For simplicity,
chart below assumes that all routers send updates at the same time
The chart shows the metric for the target network, as it appears
the routing table at each router
time ------>
D: dir, 1 dir, 1 dir, 1 dir, 1 ... dir, 1 dir, 1
B: unreach C, 4 C, 5 C, 6 C, 11 C, 12
C: B, 3 A, 4 A, 5 A, 6 A, 11 D, 11
A: B, 3 C, 4 C, 5 C, 6 C, 11 C, 12
dir = directly
unreach =
Here's the problem: B is able to get rid of its failed route using
timeout mechanism, but vestiges of that route persist in the
for a long time. Initially, A and C still think they can get to
via B. So, they keep sending updates listing metrics of 3. In
next iteration, B will then claim that it can get to D via either
or C. Of course, it can't. The routes being claimed by A and C
now gone, but they have no way of knowing that yet. And even
they discover that their routes via B have gone away, they each
there is a route available via the other. Eventually the
converges, as all the mathematics claims it must. But it can
some time to do so. The worst case is when a network
Malkin Standards Track [Page 14]
RFC 2453 RIP Version 2 November 1998
completely inaccessible from some part of the system. In that case
the metrics may increase slowly in a pattern like the one above
they finally reach infinity. For this reason, the problem is
"counting to infinity".
You should now see why "infinity" is chosen to be as small
possible. If a network becomes completely inaccessible, we
counting to infinity to be stopped as soon as possible.
must be large enough that no real route is that big. But
shouldn't be any bigger than required. Thus the choice of
is a tradeoff between network size and speed of convergence in
counting to infinity happens. The designers of RIP believed that
protocol was unlikely to be practical for networks with a
larger than 15.
There are several things that can be done to prevent problems
this. The ones used by RIP are called "split horizon with
reverse", and "triggered updates".
3.4.3 Split
Note that some of the problem above is caused by the fact that A
C are engaged in a pattern of mutual deception. Each claims to
able to get to D via the other. This can be prevented by being a
more careful about where information is sent. In particular, it
never useful to claim reachability for a destination network to
neighbor(s) from which the route was learned. "Split horizon" is
scheme for avoiding problems caused by including routes in
sent to the router from which they were learned. The "simple
horizon" scheme omits routes learned from one neighbor in
sent to that neighbor. "Split horizon with poisoned reverse
includes such routes in updates, but sets their metrics to infinity
If A thinks it can get to D via C, its messages to C should
that D is unreachable. If the route through C is real, then C
has a direct connection to D, or a connection through some
router. C's route can't possibly go back to A, since that forms
loop. By telling C that D is unreachable, A simply guards
the possibility that C might get confused and believe that there is
route through A. This is obvious for a point to point line.
consider the possibility that A and C are connected by a
network such as an Ethernet, and there are other routers on
network. If A has a route through C, it should indicate that D
unreachable when talking to any other router on that network.
other routers on the network can get to C themselves. They
never need to get to C via A. If A's best route is really through C
no other router on that network needs to know that A can reach D
This is fortunate, because it means that the same update message
Malkin Standards Track [Page 15]
RFC 2453 RIP Version 2 November 1998
is used for C can be used for all other routers on the same network
Thus, update messages can be sent by broadcast
In general, split horizon with poisoned reverse is safer than
split horizon. If two routers have routes pointing at each other
advertising reverse routes with a metric of 16 will break the
immediately. If the reverse routes are simply not advertised,
erroneous routes will have to be eliminated by waiting for a timeout
However, poisoned reverse does have a disadvantage: it increases
size of the routing messages. Consider the case of a campus
connecting a number of different buildings. In each building,
is a router connecting the backbone to a local network.
what routing updates those routers should broadcast on the
network. All that the rest of the network really needs to know
each router is what local networks it is connected to. Using
split horizon, only those routes would appear in update messages
by the router to the backbone network. If split horizon
poisoned reverse is used, the router must mention all routes that
learns from the backbone, with metrics of 16. If the system
large, this can result in a large update message, almost all of
entries indicate unreachable networks
In a static sense, advertising reverse routes with a metric of 16
provides no additional information. If there are many routers on
broadcast network, these extra entries can use significant bandwidth
The reason they are there is to improve dynamic behavior.
topology changes, mentioning routes that should not go through
router as well as those that should can speed up convergence
However, in some situations, network managers may prefer to
somewhat slower convergence in order to minimize routing overhead
Thus implementors may at their option implement simple split
rather than split horizon with poisoned reverse, or they may
a configuration option that allows the network manager to
which behavior to use. It is also permissible to implement
schemes that advertise some reverse routes with a metric of 16
omit others. An example of such a scheme would be to use a metric
16 for reverse routes for a certain period of time after
changes involving them, and thereafter omitting them from updates
The router requirements RFC [11] specifies that all implementation
RIP must use split horizon and should also use split horizon
poisoned reverse, although there may be a knob to disable
reverse
Malkin Standards Track [Page 16]
RFC 2453 RIP Version 2 November 1998
3.4.4 Triggered
Split horizon with poisoned reverse will prevent any routing
that involve only two routers. However, it is still possible to
up with patterns in which three routers are engaged in
deception. For example, A may believe it has a route through B,
through C, and C through A. Split horizon cannot stop such a loop
This loop will only be resolved when the metric reaches infinity
the network involved is then declared unreachable. Triggered
are an attempt to speed up this convergence. To get
updates, we simply add a rule that whenever a router changes
metric for a route, it is required to send update messages
immediately, even if it is not yet time for one of the regular
message. (The timing details will differ from protocol to protocol
Some distance vector protocols, including RIP, specify a small
delay, in order to avoid having triggered updates generate
network traffic.) Note how this combines with the rules
computing new metrics. Suppose a router's route to destination
goes through router G. If an update arrives from G itself,
receiving router is required to believe the new information,
the new metric is higher or lower than the old one. If the result
a change in metric, then the receiving router will send
updates to all the hosts and routers directly connected to it.
in turn may each send updates to their neighbors. The result is
cascade of triggered updates. It is easy to show which routers
hosts are involved in the cascade. Suppose a router G times out
route to destination N. G will send triggered updates to all of
neighbors. However, the only neighbors who will believe the
information are those whose routes for N go through G. The
routers and hosts will see this as information about a new route
is worse than the one they are already using, and ignore it.
neighbors whose routes go through G will update their metrics
send triggered updates to all of their neighbors. Again, only
neighbors whose routes go through them will pay attention. Thus,
triggered updates will propagate backwards along all paths leading
router G, updating the metrics to infinity. This propagation
stop as soon as it reaches a portion of the network whose route
destination N takes some other path
If the system could be made to sit still while the cascade
triggered updates happens, it would be possible to prove
counting to infinity will never happen. Bad routes would always
removed immediately, and so no routing loops could form
Unfortunately, things are not so nice. While the triggered
are being sent, regular updates may be happening at the same time
Routers that haven't received the triggered update yet will still
sending out information based on the route that no longer exists.
Malkin Standards Track [Page 17]
RFC 2453 RIP Version 2 November 1998
is possible that after the triggered update has gone through
router, it might receive a normal update from one of these
that hasn't yet gotten the word. This could reestablish an
remnant of the faulty route. If triggered updates happen
enough, this is very unlikely. However, counting to infinity
still possible
The router requirements RFC [11] specifies that all implementation
RIP must implement triggered update for deleted routes and
implement triggered updates for new routes or change of routes.
implementations must also limit the rate which of triggered
may be trandmitted. (see section 3.10.1)
3.5 Protocol
RIP is intended to allow routers to exchange information
computing routes through an IPv4-based network. Any router that
RIP is assumed to have interfaces to one or more networks,
it isn't really a router. These are referred to as its directly
connected networks. The protocol relies on access to
information about each of these networks, the most important of
is its metric. The RIP metric of a network is an integer between 1
and 15, inclusive. It is set in some manner not specified in
protocol; however, given the maximum path limit of 15, a value of 1
is usually used. Implementations should allow the
administrator to set the metric of each network. In addition to
metric, each network will have an IPv4 destination address and
mask associated with it. These are to be set by the
administrator in a manner not specified in this protocol
Any host that uses RIP is assumed to have interfaces to one or
networks. These are referred to as its "directly-
networks". The protocol relies on access to certain
about each of these networks. The most important is its metric
"cost". The metric of a network is an integer between 1 and 15
inclusive. It is set in some manner not specified in this protocol
Most existing implementations always use a metric of 1.
implementations should allow the system administrator to set the
of each network. In addition to the cost, each network will have
IPv4 network number and a subnet mask associated with it. These
to be set by the system administrator in a manner not specified
this protocol
Note that the rules specified in section 3.7 assume that there is
single subnet mask applying to each IPv4 network, and that only
subnet masks for directly-connected networks are known. There may
systems that use different subnet masks for different subnets
a single network. There may also be instances where it is
Malkin Standards Track [Page 18]
RFC 2453 RIP Version 2 November 1998
for a system to know the subnets masks of distant networks. Network
wide distribution of routing information which contains
subnet masks is permitted if all routers in the network are
the extensions presented in this document. However, if all routers
the network are not running these extensions distribution of
information containing different subnet masks must be limited
avoid interoperability problems. See sections 3.7 and 4.3 for
rules governing subnet distribution
Each router that implements RIP is assumed to have a routing table
This table has one entry for every destination that is
throughout the system operating RIP. Each entry contains at
the following information
- The IPv4 address of the destination
- A metric, which represents the total cost of getting a
from the router to that destination. This metric is the sum of
costs associated with the networks that would be traversed to
to the destination
- The IPv4 address of the next router along the path to
destination (i.e., the next hop). If the destination is on one
the directly-connected networks, this item is not needed
- A flag to indicate that information about the route has
recently. This will be referred to as the "route change flag."
- Various timers associated with the route. See section 3.6 for
details on timers
The entries for the directly-connected networks are set up by
router using information gathered by means not specified in
protocol. The metric for a directly-connected network is set to
cost of that network. As mentioned, 1 is the usual cost. In
case, the RIP metric reduces to a simple hop-count. More
metrics may be used when it is desirable to show preference for
networks over others (e.g., to indicate of differences in
or reliability).
To support the extensions detailed in this document, each entry
additionally contain a subnet mask. The subnet mask allows the
(along with the IPv4 address of the destination) to identify
different subnets within a single network as well as the
masks of distant networks
Malkin Standards Track [Page 19]
RFC 2453 RIP Version 2 November 1998
Implementors may also choose to allow the system administrator
enter additional routes. These would most likely be routes to
or networks outside the scope of the routing system. They
referred to as "static routes." Entries for destinations other
these initial ones are added and updated by the algorithms
in the following sections
In order for the protocol to provide complete information on routing
every router in the AS must participate in the protocol. In
where multiple IGPs are in use, there must be at least one
which can leak routing information between the protocols
3.6 Message
RIP is a UDP-based protocol. Each router that uses RIP has a
process that sends and receives datagrams on UDP port number 520,
RIP-1/RIP-2 port. All communications intended for another routers'
RIP process are sent to the RIP port. All routing update
are sent from the RIP port. Unsolicited routing update messages
both the source and destination port equal to the RIP port.
messages sent in response to a request are sent to the port
which the request came. Specific queries may be sent from
other than the RIP port, but they must be directed to the RIP port
the target machine
The RIP packet format is
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
| |
~ RIP Entry (20) ~
| |
+---------------+---------------+---------------+---------------+
Malkin Standards Track [Page 20]
RFC 2453 RIP Version 2 November 1998
There may be between 1 and 25 (inclusive) RIP entries. A RIP-1
has the following format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IPv4 address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+
Field sizes are given in octets. Unless otherwise specified,
contain binary integers, in network byte order, with the most
significant octet first (big-endian). Each tick mark represents
bit
Every message contains a RIP header which consists of a command and
version number. This section of the document describes version 1
the protocol; section 4 describes the version 2 extensions.
command field is used to specify the purpose of this message.
commands implemented in version 1 and 2 are
1 - request A request for the responding system to send all
part of its routing table
2 - response A message containing all or part of the sender'
routing table. This message may be sent in
to a request, or it may be an unsolicited
update generated by the sender
For each of these message types, in version 1, the remainder of
datagram contains a list of Route Entries (RTEs). Each RTE in
list contains an Address Family Identifier (AFI), destination IPv
address, and the cost to reach that destination (metric).
The AFI is the type of address. For RIP-1, only AF_INET (2)
generally supported
The metric field contains a value between 1 and 15 (inclusive)
specifies the current metric for the destination; or the value 16
(infinity), which indicates that the destination is not reachable
Malkin Standards Track [Page 21]
RFC 2453 RIP Version 2 November 1998
3.7 Addressing
Distance vector routing can be used to describe routes to
hosts or to networks. The RIP protocol allows either of
possibilities. The destinations appearing in request and
messages can be networks, hosts, or a special code used to indicate
default address. In general, the kinds of routes actually used
depend upon the routing strategy used for the particular network
Many networks are set up so that routing information for
hosts is not needed. If every node on a given network or subnet
accessible through the same routers, then there is no reason
mention individual hosts in the routing tables. However,
that include point-to-point lines sometimes require routers to
track of routes to certain nodes. Whether this feature is
depends upon the addressing and routing approach used in the system
Thus, some implementations may choose not to support host routes.
host routes are not supported, they are to be dropped when they
received in response messages (see section 3.7.2).
The RIP-1 packet format does not distinguish among various types
address. Fields that are labeled "address" can contain any of
following
host address subnet number network number zero (default route
Entities which use RIP-1 are assumed to use the most
information available when routing a datagram. That is, when
a datagram, its destination address must first be checked against
list of node addresses. Then it must be checked to see whether
matches any known subnet or network number. Finally, if none
these match, the default route is used
When a node evaluates information that it receives via RIP-1,
interpretation of an address depends upon whether it knows the
mask that applies to the net. If so, then it is possible
determine the meaning of the address. For example, consider
128.6. It has a subnet mask of 255.255.255.0. Thus 128.6.0.0 is
network number, 128.6.4.0 is a subnet number, and 128.6.4.1 is a
address. However, if the node does not know the subnet mask
evaluation of an address may be ambiguous. If there is a non-
node part, there is no clear way to determine whether the
represents a subnet number or a node address. As a subnet
would be useless without the subnet mask, addresses are assumed
represent nodes in this situation. In order to avoid this sort
ambiguity, when using version 1, nodes must not send subnet routes
nodes that cannot be expected to know the appropriate subnet mask
Normally hosts only know the subnet masks for directly-
networks. Therefore, unless special provisions have been made
Malkin Standards Track [Page 22]
RFC 2453 RIP Version 2 November 1998
routes to a subnet must not be sent outside the network of which
subnet is a part. RIP-2 (see section 4) eliminates the subnet/
ambiguity by including the subnet mask in the routing entry
This "subnet filtering" is carried out by the routers at the "border
of the subnetted network. These are routers which connect
network with some other network. Within the subnetted network,
subnet is treated as an individual network. Routing entries for
subnet are circulated by RIP. However, border routers send only
single entry for the network as a whole to nodes in other networks
This means that a border router will send different information
different neighbors. For neighbors connected to the
network, it generates a list of all subnets to which it is
connected, using the subnet number. For neighbors connected to
networks, it makes a single entry for the network as a whole,
the metric associated with that network. This metric would
be the smallest metric for the subnets to which the router
attached
Similarly, border routers must not mention host routes for
within one of the directly-connected networks in messages to
networks. Those routes will be subsumed by the single entry for
network as a whole
The router requirements RFC [11] specifies that all implementation
RIP should support host routes but if they do not then they
ignore any received host routes
The special address 0.0.0.0 is used to describe a default route.
default route is used when it is not convenient to list
possible network in the RIP updates, and when one or more closely
connected routers in the system are prepared to handle traffic to
networks that are not listed explicitly. These routers should
RIP entries for the address 0.0.0.0, just as if it were a network
which they are connected. The decision as to how routers
entries for 0.0.0.0 is left to the implementor. Most commonly,
system administrator will be provided with a way to specify
routers should create entries for 0.0.0.0; however, other
are possible. For example, an implementor might decide that
router which speaks BGP should be declared to be a default router
It may be useful to allow the network administrator to choose
metric to be used in these entries. If there is more than
default router, this will make it possible to express a
for one over the other. The entries for 0.0.0.0 are handled by
in exactly the same manner as if there were an actual network
this address. System administrators should take care to make
that routes to 0.0.0.0 do not propagate further than is intended
Generally, each autonomous system has its own preferred
Malkin Standards Track [Page 23]
RFC 2453 RIP Version 2 November 1998
router. Thus, routes involving 0.0.0.0 should generally not
the boundary of an autonomous system. The mechanisms for
this are not specified in this document
3.8
This section describes all events that are triggered by timers
Every 30 seconds, the RIP process is awakened to send an
Response message containing the complete routing table (see
3.9 on Split Horizon) to every neighboring router. When there
many routers on a single network, there is a tendency for them
synchronize with each other such that they all issue updates at
same time. This can happen whenever the 30 second timer is
by the processing load on the system. It is undesirable for
update messages to become synchronized, since it can lead
unnecessary collisions on broadcast networks. Therefore
implementations are required to take one of two precautions
- The 30-second updates are triggered by a clock whose rate is
affected by system load or the time required to service
previous update timer
- The 30-second timer is offset by a small random time (+/- 0 to 5
seconds) each time it is set. (Implementors may wish to
even larger variation in the light of recent research results [10])
There are two timers associated with each route, a "timeout" and
"garbage-collection" time. Upon expiration of the timeout, the
is no longer valid; however, it is retained in the routing table
a short time so that neighbors can be notified that the route
been dropped. Upon expiration of the garbage-collection timer,
route is finally removed from the routing table
The timeout is initialized when a route is established, and any
an update message is received for the route. If 180 seconds
from the last time the timeout was initialized, the route
considered to have expired, and the deletion process described
begins for that route
Deletions can occur for one of two reasons: the timeout expires,
the metric is set to 16 because of an update received from
current router (see section 3.7.2 for a discussion of
updates from other routers). In either case, the following
happen
Malkin Standards Track [Page 24]
RFC 2453 RIP Version 2 November 1998
- The garbage-collection timer is set for 120 seconds
- The metric for the route is set to 16 (infinity). This causes
route to be removed from service
- The route change flag is set to indicate that this entry has
changed
- The output process is signalled to trigger a response
Until the garbage-collection timer expires, the route is included
all updates sent by this router. When the garbage-collection
expires, the route is deleted from the routing table
Should a new route to this network be established while the garbage
collection timer is running, the new route will replace the one
is about to be deleted. In this case the garbage-collection
must be cleared
Triggered updates also use a small timer; however, this is
described in section 3.9.1.
3.9 Input
This section will describe the handling of datagrams received on
RIP port. Processing will depend upon the value in the
field
See sections 4.6 and 5.1 for details on handling version numbers
3.9.1 Request
A Request is used to ask for a response containing all or part of
router's routing table. Normally, Requests are sent as
(multicasts for RIP-2), from the RIP port, by routers which have
come up and are seeking to fill in their routing tables as quickly
possible. However, there may be situations (e.g., router monitoring
where the routing table of only a single router is needed. In
case, the Request should be sent directly to that router from a
port other than the RIP port. If such a Request is received,
router responds directly to the requestor's address and port
The Request is processed entry by entry. If there are no entries,
response is given. There is one special case. If there is
one entry in the request, and it has an address family identifier
zero and a metric of infinity (i.e., 16), then this is a request
send the entire routing table. In that case, a call is made to
output process to send the routing table to the
Malkin Standards Track [Page 25]
RFC 2453 RIP Version 2 November 1998
address/port. Except for this special case, processing is
simple. Examine the list of RTEs in the Request one by one.
each entry, look up the destination in the router's routing
and, if there is a route, put that route's metric in the metric
of the RTE. If there is no explicit route to the
destination, put infinity in the metric field. Once all the
have been filled in, change the command from Request to Response
send the datagram back to the requestor
Note that there is a difference in metric handling for specific
whole-table requests. If the request is for a complete
table, normal output processing is done, including Split Horizon (
section 3.9 on Split Horizon). If the request is for
entries, they are looked up in the routing table and the
is returned as is; no Split Horizon processing is done. The
for this distinction is the expectation that these requests
likely to be used for different purposes. When a router first
up, it multicasts a Request on every connected network asking for
complete routing table. It is assumed that these complete
tables are to be used to update the requestor's routing table.
this reason, Split Horizon must be done. It is further assumed
a Request for specific networks is made only by diagnostic software
and is not used for routing. In this case, the requester would
to know the exact contents of the routing table and would not
any information hidden or modified
3.9.2 Response
A Response can be received for one of several different reasons
- response to a specific
- regular update (unsolicited response
- triggered update caused by a route
Processing is the same no matter why the Response was generated
Because processing of a Response may update the router's
table, the Response must be checked carefully for validity.
Response must be ignored if it is not from the RIP port.
datagram's IPv4 source address should be checked to see whether
datagram is from a valid neighbor; the source of the datagram must
on a directly-connected network. It is also worth checking to
whether the response is from one of the router's own addresses
Interfaces on broadcast networks may receive copies of their
broadcasts/multicasts immediately. If a router processes its
output as new input, confusion is likely so such datagrams must
ignored
Malkin Standards Track [Page 26]
RFC 2453 RIP Version 2 November 1998
Once the datagram</