HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:03:42 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 09 Sep 1996 22:17:00 GMT ETag: "361bb3-dcd7-3234975c" Accept-Ranges: bytes Content-Length: 56535 Connection: close Content-Type: text/plain Draft-ietf-ripv2-protocol-v2-00.txt G. Malkin Obsoletes RFCs 1723, 1388 Bay Networks September 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: 9Mar97 [Page 1] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 2] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 3] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 4] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 5] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 6] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 7] Internet Draft RIP Version 2 September 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 (0x0800) 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: 9Mar97 [Page 8] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 9] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 10] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 11] Internet Draft RIP Version 2 September 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 a destination address 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: 9Mar97 [Page 12] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 13] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 14] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 15] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 16] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 17] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 18] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 19] Internet Draft RIP Version 2 September 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. The recommended default for this switch is RIP-1 compatibility. 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. 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 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 Malkin Expires: 9Mar97 [Page 20] Internet Draft RIP Version 2 September 1996 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: 9Mar97 [Page 21] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 22] Internet Draft RIP Version 2 September 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: 9Mar97 [Page 23]