home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_q_t
/
draft-ietf-ripv2-protocol-v2-01.txt
< prev
next >
Wrap
Text File
|
1996-10-23
|
57KB
|
1,286 lines
Draft-ietf-ripv2-protocol-v2-01.txt G. Malkin
Obsoletes RFCs 1723, 1388 Bay Networks
October 1996
RIP Version 2
Carrying Additional Information
Abstract
This document specifies an extension of the Routing Information
Protocol (RIP), as defined in [1,2], to expand the amount of useful
information carried in RIP messages and to add a measure of security.
A companion document will define the SNMP MIB objects for RIP-2 [3].
An additional document will define cryptographic security
improvements for RIP-2 [10].
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
It is intended that this document will be submitted to the IESG for
consideration as a standards document. Distribution of this document
is unlimited.
Acknowledgements
I would like to thank the IETF RIP Working Group for their help in
improving the RIP-2 protocol.
Malkin Expires: 22Apr97 [Page 1]
Internet Draft RIP Version 2 October 1996
Table of Contents
1. Justification . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Limitations of the Protocol . . . . . . . . . . . . . . . . 4
3.3 Protocol Specification . . . . . . . . . . . . . . . . . . . 5
3.4 Message Format . . . . . . . . . . . . . . . . . . . . . . . 6
3.5 Addressing Considerations . . . . . . . . . . . . . . . . . 8
3.6 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.7 Input Processing . . . . . . . . . . . . . . . . . . . . . . 11
3.8 Output Processing . . . . . . . . . . . . . . . . . . . . . 15
3.9 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 16
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 17
4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 19
4.6 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1 Compatibility Switch . . . . . . . . . . . . . . . . . . . . 20
5.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 20
5.3 Larger Infinity . . . . . . . . . . . . . . . . . . . . . . 21
5.4 Addressless Links . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
Appendicies . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Malkin Expires: 22Apr97 [Page 2]
Internet Draft RIP Version 2 October 1996
1. Justification
With the advent of OSPF and IS-IS, there are those who believe that
RIP is obsolete. While it is true that the newer IGP routing
protocols are far superior to RIP, RIP does have some advantages.
Primarily, in a small network, RIP has very little overhead in terms
of bandwidth used and configuration and management time. RIP is also
very easy to implement, especially in relation to the newer IGPs.
Additionally, there are many, many more RIP implementations in the
field than OSPF and IS-IS combined. It is likely to remain that way
for some years yet.
Given that RIP will be useful in many environments for some period of
time, it is reasonable to increase RIP's usefulness. This is
especially true since the gain is far greater than the expense of the
change.
2. Current RIP
The current RIP-1 message contains the minimal amount of information
necessary for routers to route messages through a network. It also
contains a large amount of unused space, owing to its origins.
The current RIP-1 protocol does not consider autonomous systems and
IGP/EGP interactions, subnetting, and authentication since
implementations of these postdate RIP-1. The lack of subnet masks is
a particularly serious problem for routers since they need a subnet
mask to know how to determine a route. If a RIP-1 route is a network
route (all non-network bits 0), the subnet mask equals the network
mask. However, if some of the non-network bits are set, the router
cannot determine the subnet mask. Worse still, the router cannot
determine if the RIP-1 route is a subnet route or a host route.
Currently, some routers simply choose the subnet mask of the
interface over which the route was learned and determine the route
type from that.
3. Basic Protocol
Much of the material in this section has been taken from [1].
3.1 Introduction
RIP is a routing protocol based on the Bellman-Ford (or distance
vector) algorithm. This algorithm has been used for routing
computations in computer networks since the early days of the
Malkin Expires: 22Apr97 [Page 3]
Internet Draft RIP Version 2 October 1996
ARPANET. The particular packet formats and protocol described here
are based on the program "routed," which is included with the
Berkeley distribution of Unix.
In an international network, such as the Internet, it is very
unlikely that a single routing protocol will used for the entire
network. Rather, the network will be organized as a collection of
Autonomous Systems (AS), each of which will, in general, be
administered by a single entity. Each AS will have its own routing
technology, which may differ among AS's. The routing protocol used
within an AS is referred to as an Interior Gateway Protocol (IGP). A
separate protocol, called an Exterior Gateway Protocol (EGP), is used
to transfer routing information among the AS's. RIP was designed to
work as an IGP in moderate-size AS's. It is not intended for use in
more complex environments. For information on the context into which
RIP-1 is expected to fit, see Braden and Postel [6].
RIP uses one of a class of routing algorithms known as Distance
Vector algorithms. The earliest description of this class of
algorithms known to the author is in Ford and Fulkerson [8]. Because
of this, they are sometimes known as Ford-Fulkerson algorithms. The
term Bellman-Ford is also used, and derives from the fact that the
formulation is based on Bellman's equation [4]. The presentation in
this document is closely based on [5]. This document contains a
protocol specification. For an introduction to the mathematics of
routing algorithms, see [1]. The basic algorithms used by this
protocol were used in computer routing as early as 1969 in the
ARPANET. However, the specific ancestry of this protocol is within
the Xerox network protocols. The PUP protocols [7] used the Gateway
Information Protocol to exchange routing information. A somewhat
updated version of this protocol was adopted for the Xerox Network
Systems (XNS) architecture, with the name Routing Information
Protocol [9]. Berkeley's routed is largely the same as the Routing
Information Protocol, with XNS addresses replaced by a more general
address format capable of handling IPv4 and other types of address,
and with routing updates limited to one every 30 seconds. Because of
this similarity, the term Routing Information Protocol (or just RIP)
is used to refer to both the XNS protocol and the protocol used by
routed.
An introduction to the theory and math behind Distance Vector
protocols is provided in [1]. It has not been incorporated in this
document for the sake of brevity.
3.2 Limitations of the Protocol
This protocol does not solve every possible routing problem. As
mentioned above, it is primary intended for use as an IGP in networks
Malkin Expires: 22Apr97 [Page 4]
Internet Draft RIP Version 2 October 1996
of moderate size. In addition, the following specific limitations
are be mentioned:
- The protocol is limited to networks whose longest path (the
network's diameter) 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 (see section 2.2 in [1]). 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.
3.3 Protocol Specification
RIP is intended to allow routers to exchange information for
computing routes through an IPv4-based network. Any router that uses
RIP is assumed to have interfaces to one or more networks, otherwise
it isn't really a router. These are referred to as its directly-
connected networks. The protocol relies on access to certain
information about each of these networks, the most important of which
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 this
protocol; however, given the maximum path limit of 15, a value of 1
is usually used. Implementations should allow the system
administrator to set the metric of each network. In addition to the
metric, each network will have an IPv4 destination address and subnet
mask associated with it. These are to be set by the system
administrator in a manner not specified in this protocol.
Malkin Expires: 22Apr97 [Page 5]
Internet Draft RIP Version 2 October 1996
Each router that implements RIP is assumed to have a routing table.
This table has one entry for every destination that is reachable
throughout the system operating RIP. Each entry contains at least
the following information:
- The IPv4 address of the destination.
- A metric, which represents the total cost of getting a datagram
from the router to that destination. This metric is the sum of the
costs associated with the networks that would be traversed to get
to the destination.
- The IPv4 address of the next router along the path to the
destination (i.e., the next hop). If the destination is on one of
the directly-connected networks, this item is not needed.
- A flag to indicate that information about the route has changed
recently. This will be referred to as the "route change flag."
- Various timers associated with the route. See section 3.6 for more
details on timers.
The entries for the directly-connected networks are set up by the
router using information gathered by means not specified in this
protocol. The metric for a directly-connected network is set to the
cost of that network. As mentioned, 1 is the usual cost. In that
case, the RIP metric reduces to a simple hop-count. More complex
metrics may be used when it is desirable to show preference for some
networks over others (e.g., to indicate of differences in bandwidth
or reliability).
Implementors may also choose to allow the system administrator to
enter additional routes. These would most likely be routes to hosts
or networks outside the scope of the routing system. They are
referred to as "static routes." Entries for destinations other than
these initial ones are added and updated by the algorithms described
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 cases
where multiple IGPs are in use, there must be at least one router
which can leak routing information between the protocols.
3.4 Message Format
RIP is a UDP-based protocol. Each router that uses RIP has a routing
process that sends and receives datagrams on UDP port number 520, the
RIP-1/RIP-2 port. All communications intended for another routers's
Malkin Expires: 22Apr97 [Page 6]
Internet Draft RIP Version 2 October 1996
RIP process are sent to the RIP port. All routing update messages
are sent from the RIP port. Unsolicited routing update messages have
both the source and destination port equal to the RIP port. Update
messages sent in response to a request are sent to the port from
which the request came. Specific queries may be sent from ports
other than the RIP port, but they must be directed to the RIP port on
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) ~
| |
+---------------+---------------+---------------+---------------+
There may be between 1 and 25 (inclusive) RIP entries. A RIP-1 entry
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, fields
contain binary integers, in network byte order, with the most-
significant octet first (big-endian). Each tick mark represents one
bit.
Every message contains a RIP header which consists of a command and a
version number. This section of the document describes version 1 of
the protocol; section 4 describes the version 2 extensions. The
command field is used to specify the purpose of this message. The
commands implemented in version 1 and 2 are:
Malkin Expires: 22Apr97 [Page 7]
Internet Draft RIP Version 2 October 1996
1 - request A request for the responding system to send all or
part of its routing table.
2 - response 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.
For each of these message types, in version 1, the remainder of the
datagram contains a list of Route Entries (RTEs). Each RTE in this
list contains an Address Family Identifier (AFI), destination IPv4
address, and the cost to reach that destination (metric).
The AFI is the type of address. For RIP-1, only AF_INET (2) is
generally supported.
The metric field contains a value between 1 and 15 (inclusive) which
specifies the current metric for the destination; or the value 16
(infinity), which indicates that the destination is not reachable.
3.5 Addressing Considerations
Distance vector routing can be used to describe routes to individual
hosts or to networks. The RIP protocol allows either of these
possibilities. The destinations appearing in request and response
messages can be networks, hosts, or a special code used to indicate a
default address. In general, the kinds of routes actually used will
depend upon the routing strategy used for the particular network.
Many networks are set up so that routing information for individual
hosts is not needed. If every node on a given network or subnet is
accessible through the same gateways, then there is no reason to
mention individual hosts in the routing tables. However, networks
that include point-to-point lines sometimes require gateways to keep
track of routes to certain nodes. Whether this feature is required
depends upon the addressing and routing approach used in the system.
Thus, some implementations may choose not to support host routes. If
host routes are not supported, they are to be dropped when they are
received in response messages (see section 3.7.2).
The RIP-1 packet format does not distinguish among various types of
address. Fields that are labeled "address" can contain any of the
following:
host address
subnet number
network number
zero (default route)
Malkin Expires: 22Apr97 [Page 8]
Internet Draft RIP Version 2 October 1996
Entities which use RIP-1 are assumed to use the most specific
information available when routing a datagram. That is, when routing
a datagram, its destination address must first be checked against the
list of node addresses. Then it must be checked to see whether it
matches any known subnet or network number. Finally, if none of
these match, the default route is used.
When a node evaluates information that it receives via RIP-1, its
interpretation of an address depends upon whether it knows the subnet
mask that applies to the net. If so, then it is possible to
determine the meaning of the address. For example, consider net
128.6. It has a subnet mask of 255.255.255.0. Thus 128.6.0.0 is a
network number, 128.6.4.0 is a subnet number, and 128.6.4.1 is a node
address. However, if the node does not know the subnet mask,
evaluation of an address may be ambiguous. If there is a non-zero
node part, there is no clear way to determine whether the address
represents a subnet number or a node address. As a subnet number
would be useless without the subnet mask, addresses are assumed to
represent nodes in this situation. In order to avoid this sort of
ambiguity, when using version 1, nodes must not send subnet routes to
nodes that cannot be expected to know the appropriate subnet mask.
Normally hosts only know the subnet masks for directly-connected
networks. Therefore, unless special provisions have been made,
routes to a subnet must not be sent outside the network of which the
subnet is a part. RIP-2 (see section 4) eliminates the subnet/host
ambiguity by including the subnet mask in the routing entry.
This filtering is carried out by the routers at the "border" of the
subnetted network. These are routers which connect that network with
some other network. Within the subnetted network, each subnet is
treated as an individual network. Routing entries for each subnet
are circulated by RIP. However, border routers send only a single
entry for the network as a whole to nodes in other networks. This
means that a border router will send different information to
different neighbors. For neighbors connected to the subnetted
network, it generates a list of all subnets to which it is directly
connected, using the subnet number. For neighbors connected to other
networks, it makes a single entry for the network as a whole, showing
the metric associated with that network. This metric would normally
be the smallest metric for the subnets to which the gateway is
attached.
Similarly, border routers must not mention host routes for nodes
within one of the directly-connected networks in messages to other
networks. Those routes will be subsumed by the single entry for the
network as a whole.
The special address 0.0.0.0 is used to describe a default route. A
Malkin Expires: 22Apr97 [Page 9]
Internet Draft RIP Version 2 October 1996
default route is used when it is not convenient to list every
possible network in the RIP updates, and when one or more closely-
connected gateways in the system are prepared to handle traffic to
the networks that are not listed explicitly. These gateways should
create RIP entries for the address 0.0.0.0, just as if it were a
network to which they are connected. The decision as to how gateways
create entries for 0.0.0.0 is left to the implementor. Most
commonly, the system administrator will be provided with a way to
specify which gateways should create entries for 0.0.0.0; however,
other mechanisms are possible. For example, an implementor might
decide that any gateway which speaks BGP should be declared to be a
default gateway. It may be useful to allow the network administrator
to choose the metric to be used in these entries. If there is more
than one default gateway, this will make it possible to express a
preference for one over the other. The entries for 0.0.0.0 are
handled by RIP in exactly the same manner as if there were an actual
network with this address. System administrators should take care to
make sure that routes to 0.0.0.0 do not propagate further than is
intended. Generally, each autonomous system has its own preferred
default gateway. Thus, routes involving 0.0.0.0 should generally not
leave the boundary of an autonomous system. The mechanisms for
enforcing this are not specified in this document.
3.6 Timers
This section describes all events that are triggered by timers.
Every 30 seconds, the RIP process is awakened to send an unsolicited
Response message containing the complete routing table (see section
3.9 on Split Horizon) to every neighboring router. When there are
many routers on a single network, there is a tendency for them to
synchronize with each other such that they all issue updates at the
same time. This can happen whenever the 30 second timer is affected
by the processing load on the system. It is undesirable for the
update messages to become synchronized, since it can lead to
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 not
affected by system load or the time required to service the
previous update timer.
- The 30-second timer is offset by a small random time (+/- 0 to 5
seconds) each time it is set.
There are two timers associated with each route, a "timeout" and a
"garbage-collection" time. Upon expiration of the timeout, the route
is no longer valid; however, it is retained in the routing table for
Malkin Expires: 22Apr97 [Page 10]
Internet Draft RIP Version 2 October 1996
a short time so that neighbors can be notified that the route has
been dropped. Upon expiration of the garbage-collection timer, the
route is finally removed from the routing table.
The timeout is initialized when a route is established, and any time
an update message is received for the route. If 180 seconds elapse
from the last time the timeout was initialized, the route is
considered to have expired, and the deletion process described below
begins for that route.
Deletions can occur for one of two reasons: the timeout expires, or
the metric is set to 16 because of an update received from the
current router (see section 3.7.2 for a discussion of processing
updates from other routers). In either case, the following events
happen:
- The garbage-collection timer is set for 120 seconds.
- The metric for the route is set to 16 (infinity). This causes the
route to be removed from service.
- The route change flag is set to indicate that this entry has been
changed.
- The output process is signalled to trigger a response.
Until the garbage-collection timer expires, the route is included in
all updates sent by this router. When the garbage-collection timer
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 that
is about to be deleted. In this case the garbage-collection timer
must be cleared.
Triggered updates also use a small timer; however, this is best
described in section 3.9.1.
3.7 Input Processing
This section will describe the handling of datagrams received on the
RIP port. Processing will depend upon the value in the command
field.
3.7.1 Request Messages
A Request is used to ask for a response containing all or part of a
routers's routing table. Normally, Requests are sent as broadcasts
Malkin Expires: 22Apr97 [Page 11]
Internet Draft RIP Version 2 October 1996
(multicasts for RIP-2), from the RIP port, by routers which have just
come up and are seeking to fill in their routing tables as quickly as
possible. However, there may be situations (e.g., router monitoring)
where the routing table of only a single router is needed. In this
case, the Request should be sent directly to that router from a UDP
port other than the RIP port. If such a Request is received, the
router responds directly to the requestor's address and port.
The Request is processed entry by entry. If there are no entries, no
response is given. There is one special case. If there is exactly
one entry in the request, and it has an address family identifier of
zero and a metric of infinity (i.e., 16), then this is a request to
send the entire routing table. In that case, a call is made to the
output process to send the routing table to the requesting
address/port. Except for this special case, processing is quite
simple. Examine the list of RTEs in the Request one by one. For
each entry, look up the destination in the router's routing database
and, if there is a route, put that route's metric in the metric field
of the RTE. If there is no explicit route to the specified
destination, put infinity in the metric field. Once all the entries
have been filled in, change the command from Request to Response and
send the datagram back to the requestor.
Note that there is a difference in metric handling for specific and
whole-table requests. If the request is for a complete routing
table, normal output processing is done, including Split Horizon (see
section 3.9 on Split Horizon). If the request is for specific
entries, they are looked up in the routing table and the information
is returned as is; no Split Horizon processing is done. The reason
for this distinction is the expectation that these requests are
likely to be used for different purposes. When a router first comes
up, it multicasts a Request on every connected network asking for a
complete routing table. It is assumed that these complete routing
tables are to be used to update the requestor's routing table. For
this reason, Split Horizon must be done. It is further assumed that
a Request for specific networks is made only by diagnostic software,
and is not used for routing. In this case, the requester would want
to know the exact contents of the routing table and would not want
any information hidden or modified.
3.7.2 Response Messages
A Response can be received for one of several different reasons:
- response to a specific query
- regular update (unsolicited response)
- triggered update caused by a route change
Malkin Expires: 22Apr97 [Page 12]
Internet Draft RIP Version 2 October 1996
Processing is the same no matter why the Response was generated.
Because processing of a Response may update the router's routing
table, the Response must be checked carefully for validity. The
Response must be ignored if it is not from the RIP port. The
datagram's IPv4 source address should be checked to see whether the
datagram is from a valid neighbor; the source of the datagram must be
on a directly-connected network. It is also worth checking to see
whether the response is from one of the router's own addresses.
Interfaces on broadcast networks may receive copies of their own
broadcasts immediately. If a router processes its own output as new
input, confusion is likely so such datagrams must be ignored.
Once the datagram as a whole has been validated, process the RTEs in
the Response one by one. Again, start by doing validation.
Incorrect metrics and other format errors usually indicate
misbehaving neighbors and should probably be brought to the
administrator's attention. For example, if the metric is greater
than infinity, ignore the entry but log the event. The basic
validation tests are:
- is the destination address valid (e.g., unicast; not net 0 or 127)
- is the metric valid (i.e., between 1 and 16, inclusive)
If any check fails, ignore that entry and proceed to the next.
Again, logging the error is probably a good idea.
Once the entry has been validated, update the metric by adding the
cost of the network on which the message arrived. If the result is
greater than infinity, use infinity. That is,
metric = MIN (metric + cost, infinity)
Now, check to see whether there is already an explicit route for the
destination address. If there is no such route, add this route to
the routing table, unless the metric is infinity (there is no point
in adding a route which is unusable). Adding a route to the routing
table consists of:
- Setting the destination address to the destination address in the
RTE
- Setting the metric to the newly calculated metric (as described
above)
- Set the next hop address to be the address of the router from which
the datagram came
Malkin Expires: 22Apr97 [Page 13]
Internet Draft RIP Version 2 October 1996
- Initialize the timeout for the route. If the garbage-collection
timer is running for this route, stop it (see section 3.6 for a
discussion of the timers)
- Set the route change flag
- Signal the output process to trigger an update (see section 3.8.1)
If there is an existing route, compare the next hop address to the
address of the router from which the datagram came. If this datagram
is from the same router as the existing route, reinitialize the
timeout. Next, compare the metrics. If the datagram is from the
same router as the existing route, and the new metric is different
than the old one; or, if the new metric is lower than the old one; do
the following actions:
- Adopt the route from the datagram (i.e., put the new metric in and
adjust the next hop address, if necessary).
- Set the route change flag and signal the output process to trigger
an update
- If the new metric is infinity, start the deletion process
(described above); otherwise, re-initialize the timeout
If the new metric is infinity, the deletion process begins for the
route, which is no longer used for routing packets. Note that the
deletion process is started only when the metric is first set to
infinity. If the metric was already infinity, then a new deletion
process is not started.
If the new metric is the same as the old one, it is simplest to do
nothing further (beyond re-initializing the timeout, as specified
above); but, there is a heuristic which could be applied. Normally,
it is senseless to replace a route if the new route has the same
metric as the existing route; this would cause the route to bounce
back and forth, which would generate an intolerable number of
triggered updates. However, if the existing route is showing signs
of timing out, it may be better to switch to an equally-good
alternative route immediately, rather than waiting for the timeout to
happen. Therefore, if the new metric is the same as the old one,
examine the timeout for the existing route. If it is at least
halfway to the expiration point, switch to the new route. This
heuristic is optional, but highly recommended.
Any entry that fails these tests is ignored, as it is no better than
the current route.
Malkin Expires: 22Apr97 [Page 14]
Internet Draft RIP Version 2 October 1996
3.8 Output Processing
This section describes the processing used to create response
messages that contain all or part of the routing table. This
processing may be triggered in any of the following ways:
- By input processing, when a Request is received (this Response is
unicast to the requestor; see section 3.7.1)
- By the regular routing update (broadcast every 30 seconds) router.
- By triggered updates (broadcast when a route changes)
When a Response is to be sent to all neighbors (i.e., a regular or
triggered update), a Response message is directed to the router at
the far end of each connected point-to-point link, and is broadcast
(multicast for RIP-2) on all connected networks which support
broadcasting. Thus, one Response is prepared for each directly-
connected network, and sent to the appropriate address (direct or
broadcast). In most cases, this reaches all neighboring routers.
However, there are some cases where this may not be good enough.
This may involve a network that is not a broadcast network (e.g., the
ARPANET), or a situation involving dumb routers. In such cases, it
may be necessary to specify an actual list of neighboring routers and
send a datagram to each one explicitly. It is left to the
implementor to determine whether such a mechanism is needed, and to
define how the list is specified.
3.8.1 Triggered Updates
Triggered updates require special handling for two reasons. First,
experience shows that triggered updates can cause excessive load on
networks with limited capacity or networks with many routers on them.
Therefore, the protocol requires that implementors include provisions
to limit the frequency of triggered updates. After a triggered
update is sent, a timer should be set for a random interval between 1
and 5 seconds. If other changes that would trigger updates occur
before the timer expires, a single update is triggered when the timer
expires. The timer is then reset to another random value between 1
and 5 seconds. A triggered update should be suppressed if a regular
update is due by the time the triggered update would be sent.
Second, triggered updates do not need to include the entire routing
table. In principle, only those routes which have changed need to be
included. Therefore, messages generated as part of a triggered
update must include at least those routes that have their route
change flag set. They may include additional routes, at the
discretion of the implementor; however, sending complete routing
Malkin Expires: 22Apr97 [Page 15]
Internet Draft RIP Version 2 October 1996
updates is strongly discouraged. When a triggered update is
processed, messages should be generated for every directly-connected
network. Split Horizon processing is done when generating triggered
updates as well as normal updates (see section 3.9). If, after Split
Horizon processing for a given network, a changed route will appear
unchanged on that network (e.g., it appears with an infinite metric),
the route need not be sent. If no routes need be sent on that
network, the update may be omitted. Once all of the triggered
updates have been generated, the route change flags should be
cleared.
If input processing is allowed while output is being generated,
appropriate interlocking must be done. The route change flags should
not be changed as a result of processing input while a triggered
update message is being generated.
The only difference between a triggered update and other update
messages is the possible omission of routes that have not changed.
The remaining mechanisms, described in the next section, must be
applied to all updates.
3.8.2 Generating Response Messages
This section describes how a Response message is generated for a
particular directly-connected network:
Set the version number to either 1 or 2. The mechanism for deciding
which version to send is implementation specific; however, if this is
the Response to a Request, the Response version should match the
Request version. Set the command to Response. Set the bytes labeled
"must be zero" to zero. Start filling in RTEs. Recall that there is
a limit of 25 RTEs to a Response; if there are more, send the current
Response and start a new one. There is no defined limit to the
number of datagrams which make up a Response.
To fill in the RTEs, examine each route in the routing table. If a
triggered update is being generated, only entries whose route change
flags are set need be included. If, after Split Horizon processing,
the route should not be included, skip it. If the route is to be
included, then the destination address and metric are put into the
RTE. Routes must be included in the datagram even if their metrics
are infinite.
3.9 Split Horizon
Split Horizon is a algorithm for avoiding problems caused by
including routes in updates sent to the gateway from which they were
learned. The basic split horizon algorithm omits routes learned from
Malkin Expires: 22Apr97 [Page 16]
Internet Draft RIP Version 2 October 1996
one neighbor in updates sent to that neighbor. In the case of a
broadcast network, all routes learned from any neighbor on that
network are omitted from updates sent on that network.
Split Horizon with Poisoned Reverse (more simply, Poison Reverse)
does include such routes in updates, but sets their metrics to
infinity. In effect, advertising the fact that these routes are not
reachable. This is the preferred method of operation; however,
implementations should provide a per-interface control allowing no
horizoning, split horizoning, and poisoned reverse to be selected.
For a theoretical discussion of Split Horizon and Poison Reverse, and
why they are needed, see section 2.1.1 of [1].
4. Protocol Extensions
This section does not change the RIP protocol per se. Rather, it
provides extensions to the message format which allows routers to
share important additional information.
The first four octets of a RIP message contain the RIP header (as
defined in section 3.4). The same header format is used for RIP-1
and RIP-2. The remainder of the message is composed of 1 - 25
(inclusive) 20-octet route entries (RTEs). The RIP-2 RTE format is:
0 1 2 3 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) | Route Tag (2) |
+-------------------------------+-------------------------------+
| IP Address (4) |
+---------------------------------------------------------------+
| Subnet Mask (4) |
+---------------------------------------------------------------+
| Next Hop (4) |
+---------------------------------------------------------------+
| Metric (4) |
+---------------------------------------------------------------+
The Address Family Identifier, IP Address, and Metric all have the
meanings defined in section 3.4. The Version field will specify
version number 2 for RIP messages which use authentication or carry
information in any of the newly defined fields.
4.1 Authentication
Since authentication is a per message function, and since there is
Malkin Expires: 22Apr97 [Page 17]
Internet Draft RIP Version 2 October 1996
only one 2-octet field available in the message header, and since any
reasonable authentication scheme will require more than two octets,
the authentication scheme for RIP version 2 will use the space of an
entire RIP entry. If the Address Family Identifier of the first (and
only the first) entry in the message is 0xFFFF, then the remainder of
the entry contains the authentication. This means that there can be,
at most, 24 RIP entries in the remainder of the message. If
authentication is not in use, then no entries in the message should
have an Address Family Identifier of 0xFFFF. A RIP message which
contains an authentication entry would begin with the following
format:
0 1 2 3 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) | unused |
+---------------+---------------+-------------------------------+
| 0xFFFF | Authentication Type (2) |
+-------------------------------+-------------------------------+
~ Authentication (16) ~
+---------------------------------------------------------------+
Currently, the only Authentication Type is simple password and it
is type 2. The remaining 16 octets contain the plain text password. If
the password is under 16 octets, it must be left-justified and
padded to the right with nulls (0x00).
4.2 Route Tag
The Route Tag (RT) field is an attribute assigned to a route which
must be preserved and readvertised with a route. The intended use
of the Route Tag is to provide a method of separating "internal"
RIP routes (routes for networks within the RIP routing domain)
from "external" RIP routes, which may have been imported from an
EGP or another IGP.
Routers supporting protocols other than RIP should be configurable
to allow the Route Tag to be configured for routes imported from
different sources. For example, routes imported from EGP or BGP
should be able to have their Route Tag either set to an arbitrary
value, or at least to the number of the Autonomous System from
which the routes were learned.
Other uses of the Route Tag are valid, as long as all routers in
the RIP domain use it consistently. This allows for the
possibility of a BGP-RIP protocol interactions document, which
would describe methods for synchronizing routing in a transit
network.
Malkin Expires: 22Apr97 [Page 18]
Internet Draft RIP Version 2 October 1996
4.3 Subnet mask
The Subnet Mask field contains the subnet mask which is applied to
the IP address to yield the non-host portion of the address. If this
field is zero, then no subnet mask has been included for this entry.
On an interface where a RIP-1 router may hear and operate on the
information in a RIP-2 routing entry the following rules apply:
1) information internal to one network must never be advertised into
another network,
2) information about a more specific subnet may not be advertised
where RIP-1 routers would consider it a host route, and
3) supernet routes (routes with a netmask less specific than
the "natural" network mask) must not be advertised where they
could be misinterpreted by RIP-1 routers.
4.4 Next Hop
The immediate next hop IP address to which packets to the destination
specified by this route entry should be forwarded. Specifying a
value of 0.0.0.0 in this field indicates that routing should be via
the originator of the RIP advertisement. An address specified as
a next hop must, per force, be directly reachable on the logical
subnet over which the advertisement is made.
The purpose of the Next Hop field is to eliminate packets being routed
through extra hops in the system. It is particularly useful when RIP
is not being run on all of the routers on a network. A simple example
is given in Appendix A. Note that Next Hop is an "advisory" field. That
is, if the provided information is ignored, a possibly sub-optimal,
but absolutely valid, route may be taken. If the received Next Hop
is not directly reachable, it should be treated as 0.0.0.0.
4.5 Multicasting
In order to reduce unnecessary load on those hosts which are not
listening to RIP-2 messages, an IP multicast address will be used for
periodic broadcasts. The IP multicast address is 224.0.0.9. Note that
IGMP is not needed since these are inter-router messages which are not
forwarded.
In order to maintain backwards compatibility, the use of the
multicast address will be configurable, as described in section 4.1. If
multicasting is used, it should be used on all interfaces which support
it.
Malkin Expires: 22Apr97 [Page 19]
Internet Draft RIP Version 2 October 1996
4.5 Queries
If a RIP-2 router receives a RIP-1 Request, it should respond with a
RIP-1 Response. If the router is configured to send only RIP-2
messages, it should not respond to a RIP-1 Request.
5. Compatibility
RFC 1058 showed considerable forethought in its specification of
the handling of version numbers. It specifies that RIP messages of
version 0 are to be discarded, that RIP messages of version 1 are
to be discarded if any Must Be Zero (MBZ) field is non-zero, and that
RIP messages of any version greater than 1 should not be discarded
simply because an MBZ field contains a value other than zero. This
means that the new version of RIP is totally backwards compatible
with existing RIP implementations which adhere to this part of the
specification.
5.1 Compatibility Switch
A compatibility switch is necessary for two reasons. First, there
are implementations of RIP-1 in the field which do not follow RFC
1058 as described above. Second, the use of multicasting would
prevent RIP-1 systems from receiving RIP-2 updates (which may
be a desired feature in some cases). This switch should be configurable
on a per-interface basis.
The switch has four settings: RIP-1, in which only RIP-1 messages are
sent; RIP-1 compatibility, in which RIP-2 messages are broadcast;
RIP-2, in which RIP-2 messages are multicast; and "none", which
disables the sending of RIP messages. It is recommended that the
default setting be either RIP-1 or RIP-2, but not RIP-1 compatibility.
This is because of the potential problems which can occur on some
topologies. RIP-1 compatibility should only be used when all of the
consequences of its use are well understood by the network administrator.
For completeness, routers should also implement a receive control
switch which would determine whether to accept, RIP-1 only, RIP-2
only, both, or none. It should also be configurable on a
per-interface basis. It is recommended that the default be compatible
with the default chosen for sending updates.
5.2 Authentication
The following algorithm should be used to authenticate a RIP message. If
the router is not configured to authenticate RIP-2 messages, then RIP-1
and unauthenticated RIP-2 messages will be accepted; authenticated
Malkin Expires: 22Apr97 [Page 20]
Internet Draft RIP Version 2 October 1996
RIP-2 messages shall be discarded. If the router is configured to
authenticate RIP-2 messages, then RIP-1 messages and RIP-2 messages
which pass authentication testing shall be accepted; unauthenticated
and failed authentication RIP-2 messages shall be discarded. For
maximum security, RIP-1 messages should be ignored when authentication
is in use (see section 4.1).
Since an authentication entry is marked with an Address Family
Identifier of 0xFFFF, a RIP-1 system would ignore this entry since
it would belong to an address family other than IP. It should
be noted, therefore, that use of authentication will not prevent
RIP-1 systems from seeing RIP-2 messages. If desired, this may
be done using multicasting, as described in sections 3.5 and 4.1.
5.3 Larger Infinity
While on the subject of compatibility, there is one item which people
have requested: increasing infinity. The primary reason that this
cannot be done is that it would violate backwards compatibility. A
larger infinity would obviously confuse older versions of rip. At
best, they would ignore the route as they would ignore a metric of
16. There was also a proposal to make the Metric a single octet and reuse
the high three octets, but this would break any implementations which
treat the metric as a 4-octet entity.
5.4 Addressless Links
As in RIP-1, addressless links will not be supported by RIP-2.
6. Security Considerations
The basic RIP protocol is not a secure protocol. To bring RIP-2
in line with more modern routing protocols, an extensible authentication
mechanism has been incorporated into the protocol enhancements. This
mechanism is described in sections 4.1 and 5.2. Security is further
enhanced by the mechanism described in [10].
Malkin Expires: 22Apr97 [Page 21]
Internet Draft RIP Version 2 October 1996
Appendix A
This is a simple example of the use of the next hop field in a rip entry.
----- ----- ----- ----- ----- -----
|IR1| |IR2| |IR3| |XR1| |XR2| |XR3|
--+-- --+-- --+-- --+-- --+-- --+--
| | | | | |
--+-------+-------+---------------+-------+-------+--
<-------------RIP-2------------->
Assume that IR1, IR2, and IR3 are all "internal" routers which are
under one administration (e.g. a campus) which has elected to use
RIP-2 as its IGP. XR1, XR2, and XR3, on the other hand, are under
separate administration (e.g. a regional network, of which the campus
is a member) and are using some other routing protocol (e.g. OSPF).
XR1, XR2, and XR3 exchange routing information among themselves such
that they know that the best routes to networks N1 and N2 are via
XR1, to N3, N4, and N5 are via XR2, and to N6 and N7 are via XR3. By
setting the Next Hop field correctly (to XR2 for N3/N4/N5, to XR3 for
N6/N7), only XR1 need exchange RIP-2 routes with IR1/IR2/IR3 for
routing to occur without additional hops through XR1. Without the
Next Hop (for example, if RIP-1 were used) it would be necessary for
XR2 and XR3 to also participate in the RIP-2 protocol to eliminate
extra hops.
Malkin Expires: 22Apr97 [Page 22]
Internet Draft RIP Version 2 October 1996
References
[1] Hedrick, C., Routing Information Protocol, Request For Comments
(RFC) 1058, Rutgers University, June 1988.
[2] Malkin, G., RIP Version 2 - Carrying Additional Information,
Request for Comments (RFC) 1723, Xylogics, Inc., July 1994.
[3] Malkin, G., and F. Baker, RIP Version 2 MIB Extension, Request
For Comments (RFC) 1389, Xylogics, Inc., Advanced Computer
Communications, January 1993.
[4] Bellman, R. E., "Dynamic Programming", Princeton University
Press, Princeton, N.J., 1957.
[5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks",
Prentice-Hall, Englewood Cliffs, N.J., 1987.
[6] Braden, R., and Postel, J., "Requirements for Internet Gateways",
USC/Information Sciences Institute, RFC-1009, June 1987.
[7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M.,
"Pup: An Internetwork Architecture", IEEE Transactions on
Communications, April 1980.
[8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks",
Princeton University Press, Princeton, N.J., 1962.
[9] Xerox Corp., "Internet Transport Protocols", Xerox System
Integration Standard XSIS 028112, December 1981.
[10] Baker, F., Atkinson, R., "RIP-II MD5 Authentication", draft-
ietf-ripv2-md5-04.txt, September 1996.
Author's Address
Gary Scott Malkin
Bay Networks
53 Third Avenue
Burlington, MA 01803
Phone: (617) 272-8140
EMail: gmalkin@baynetworks.com
Malkin Expires: 22Apr97 [Page 23]