Routing Information Protocol
RFC 1058

RFC 1058              Routing Information Protocol             June 1988

      - by the regular routing update.  Every 30 seconds, a
        response containing the whole routing table is sent to
        every neighboring gateway.  (See section 3.3.)

      - by triggered updates.  Whenever the metric for a route is
        changed, an update is triggered.  (The update may be
        delayed; see below.)

   Before describing the way a message is generated for each directly-
   connected network, we will comment on how the destinations are chosen
   for the latter two cases.  Normally, when a response is to be sent to
   all destinations (that is, either the regular update or a triggered
   update is being prepared), a response is sent to the host at the
   opposite end of each connected point-to-point link, and a response is
   broadcast on all connected networks that support broadcasting.  Thus,
   one response is prepared for each directly-connected network and sent
   to the corresponding (destination or broadcast) address.  In most
   cases, this reaches all neighboring gateways.  However, there are
   some cases where this may not be good enough.  This may involve a
   network that does not support broadcast (e.g., the ARPANET), or a
   situation involving dumb gateways.  In such cases, it may be
   necessary to specify an actual list of neighboring hosts and
   gateways, 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.

   Triggered updates require special handling for two reasons.  First,
   experience shows that triggered updates can cause excessive loads on
   networks with limited capacity or with many gateways on them.  Thus
   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 time 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, and the timer is then set to another random value between 1
   and 5 seconds.  Triggered updates may 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 that have changed need to be
   included.  Thus 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, or all routes, at the discretion
   of the implementor; however, when full routing updates require
   multiple packets, sending all routes 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 below).

Hedrick                                                        [Page 29]
RFC 1058              Routing Information Protocol             June 1988

   If, after split horizon processing, a changed route will appear
   identical on a network as it did previously, the route need not be
   sent; if, as a result, no routes need be sent, the update may be
   omitted on that network.  (If a route had only a metric change, or
   uses a new gateway that is on the same network as the old gateway,
   the route will be sent to the network of the old gateway with a
   metric of infinity both before and after the change.)  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 rest of the mechanisms about to be described must all apply to
   triggered updates.

   Here is how a response datagram is generated for a particular
   directly-connected network:

   The IP source address must be the sending host's address on that
   network.  This is important because the source address is put into
   routing tables in other hosts.  If an incorrect source address is
   used, other hosts may be unable to route datagrams.  Sometimes
   gateways are set up with multiple IP addresses on a single physical
   interface.  Normally, this means that several logical IP networks are
   being carried over one physical medium.  In such cases, a separate
   update message must be sent for each address, with that address as
   the IP source address.

   Set the version number to the current version of RIP.  (The version
   described in this document is 1.)  Set the command to response.  Set
   the bytes labeled "must be zero" to zero.  Now start filling in
   entries.

   To fill in the entries, go down all the routes in the internal
   routing table.  Recall that the maximum datagram size is 512 bytes.
   When there is no more space in the datagram, send the current message
   and start a new one.  If a triggered update is being generated, only
   entries whose route change flags are set need be included.

   See the description in Section 3.2 for a discussion of problems
   raised by subnet and host routes.  Routes to subnets will be
   meaningless outside the network, and must be omitted if the
   destination is not on the same subnetted network; they should be

Hedrick                                                        [Page 30]
RFC 1058              Routing Information Protocol             June 1988

   replaced with a single route to the network of which the subnets are
   a part.  Similarly, routes to hosts must be eliminated if they are
   subsumed by a network route, as described in the discussion in
   Section 3.2.

   If the route passes these tests, then the destination and metric are
   put into the entry in the output datagram.  Routes must be included
   in the datagram even if their metrics are infinite.  If the gateway
   for the route is on the network for which the datagram is being
   prepared, the metric in the entry is set to 16, or the entire entry
   is omitted.  Omitting the entry is simple split horizon.  Including
   an entry with metric 16 is split horizon with poisoned reverse.  See
   Section 2.2 for a more complete discussion of these alternatives.

3.6. Compatibility

   The protocol described in this document is intended to interoperate
   with routed and other existing implementations of RIP.  However, a
   different viewpoint is adopted about when to increment the metric
   than was used in most previous implementations.  Using the previous
   perspective, the internal routing table has a metric of 0 for all
   directly-connected networks.  The cost (which is always 1) is added
   to the metric when the route is sent in an update message.  By
   contrast, in this document directly-connected networks appear in the
   internal routing table with metrics equal to their costs; the metrics
   are not necessarily 1.  In this document, the cost is added to the
   metrics when routes are received in update messages.  Metrics from
   the routing table are sent in update messages without change (unless
   modified by split horizon).

   These two viewpoints result in identical update messages being sent.
   Metrics in the routing table differ by a constant one in the two
   descriptions.  Thus, there is no difference in effect.  The change
   was made because the new description makes it easier to handle
   situations where different metrics are used on directly-attached
   networks.

   Implementations that only support network costs of one need not
   change to match the new style of presentation.  However, they must
   follow the description given in this document in all other ways.

4. Control functions

   This section describes administrative controls.  These are not part
   of the protocol per se.  However, experience with existing networks
   suggests that they are important.  Because they are not a necessary
   part of the protocol, they are considered optional.  However, we
   strongly recommend that at least some of them be included in every

Hedrick                                                        [Page 31]
RFC 1058              Routing Information Protocol             June 1988

   implementation.

   These controls are intended primarily to allow RIP to be connected to
   networks whose routing may be unstable or subject to errors.  Here
   are some examples:

   It is sometimes desirable to limit the hosts and gateways from which
   information will be accepted.  On occasion, hosts have been
   misconfigured in such a way that they begin sending inappropriate
   information.

   A number of sites limit the set of networks that they allow in update
   messages.  Organization A may have a connection to organization B
   that they use for direct communication.  For security or performance
   reasons A may not be willing to give other organizations access to
   that connection.  In such cases, A should not include B's networks in
   updates that A sends to third parties.

   Here are some typical controls.  Note, however, that the RIP protocol
   does not require these or any other controls.

      - a neighbor list - the network administrator should be able
        to define a list of neighbors for each host.  A host would
        accept response messages only from hosts on its list of
        neighbors.

      - allowing or disallowing specific destinations - the network
        administrator should be able to specify a list of
        destination addresses to allow or disallow.  The list would
        be associated with a particular interface in the incoming
        or outgoing direction.  Only allowed networks would be
        mentioned in response messages going out or processed in
        response messages coming in.  If a list of allowed
        addresses is specified, all other addresses are disallowed.
        If a list of disallowed addresses is specified, all other
        addresses are allowed.

REFERENCES and BIBLIOGRAPHY

   [1] Bellman, R. E., "Dynamic Programming", Princeton University
       Press, Princeton, N.J., 1957.

   [2] Bertsekas, D. P., and Gallaher, R. G., "Data Networks",
       Prentice-Hall, Englewood Cliffs, N.J., 1987.

   [3] Braden, R., and Postel, J., "Requirements for Internet Gateways",
       USC/Information Sciences Institute, RFC-1009, June 1987.

Hedrick                                                        [Page 32]
RFC 1058              Routing Information Protocol             June 1988

   [4] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M.,
       "Pup: An Internetwork Architecture", IEEE Transactions on
       Communications, April 1980.

   [5] Clark, D. D., "Fault Isolation and Recovery," MIT-LCS, RFC-816,
       July 1982.

   [6] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks",
       Princeton University Press, Princeton, N.J., 1962.

   [7] Xerox Corp., "Internet Transport Protocols", Xerox System
       Integration Standard XSIS 028112, December 1981.

Hedrick                                                        [Page 33]