idnits 2.17.1 draft-ietf-ripv2-protocol-v2-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 18 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 1997) is 9903 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. '1') ** Obsolete normative reference: RFC 1389 (ref. '2') (Obsoleted by RFC 1724) -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1009 (ref. '6') (Obsoleted by RFC 1812) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft-ietf-ripv2-protocol-v2-02.txt G. Malkin 3 Obsoletes RFCs 1723, 1388 Bay Networks 4 March 1997 6 RIP Version 2 7 Carrying Additional Information 9 Abstract 11 This document specifies an extension of the Routing Information 12 Protocol (RIP), as defined in [1], to expand the amount of useful 13 information carried in RIP messages and to add a measure of security. 15 A companion document will define the SNMP MIB objects for RIP-2 [2]. 16 An additional document will define cryptographic security 17 improvements for RIP-2 [3]. 19 Status of this Memo 21 This document is an Internet Draft. Internet Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its Areas, 23 and its Working Groups. Note that other groups may also distribute 24 working documents as Internet Drafts. 26 Internet Drafts are draft documents valid for a maximum of six 27 months. Internet Drafts may be updated, replaced, or obsoleted by 28 other documents at any time. It is not appropriate to use Internet 29 Drafts as reference material or to cite them other than as a "working 30 draft" or "work in progress." 32 Please check the I-D abstract listing contained in each Internet 33 Draft directory to learn the current status of this or any other 34 Internet Draft. 36 It is intended that this document will be submitted to the IESG for 37 consideration as a standards document. Distribution of this document 38 is unlimited. 40 Acknowledgements 42 I would like to thank the IETF RIP Working Group for their help in 43 improving the RIP-2 protocol. 45 Table of Contents 47 1. Justification . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Basic Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 53 3.2 Limitations of the Protocol . . . . . . . . . . . . . . . . 4 54 3.3 Protocol Specification . . . . . . . . . . . . . . . . . . . 5 55 3.4 Message Format . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.5 Addressing Considerations . . . . . . . . . . . . . . . . . 8 57 3.6 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 3.7 Input Processing . . . . . . . . . . . . . . . . . . . . . . 11 59 3.8 Output Processing . . . . . . . . . . . . . . . . . . . . . 15 60 3.9 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 17 62 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 17 63 4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 18 64 4.2 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . 18 65 4.3 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . 19 66 4.4 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 19 67 4.5 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 20 68 4.6 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 20 70 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 20 71 5.1 Compatibility Switch . . . . . . . . . . . . . . . . . . . . 20 72 5.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 21 73 5.3 Larger Infinity . . . . . . . . . . . . . . . . . . . . . . 21 74 5.4 Addressless Links . . . . . . . . . . . . . . . . . . . . . 21 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 78 Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 1. Justification 86 With the advent of OSPF and IS-IS, there are those who believe that 87 RIP is obsolete. While it is true that the newer IGP routing 88 protocols are far superior to RIP, RIP does have some advantages. 89 Primarily, in a small network, RIP has very little overhead in terms 90 of bandwidth used and configuration and management time. RIP is also 91 very easy to implement, especially in relation to the newer IGPs. 93 Additionally, there are many, many more RIP implementations in the 94 field than OSPF and IS-IS combined. It is likely to remain that way 95 for some years yet. 97 Given that RIP will be useful in many environments for some period of 98 time, it is reasonable to increase RIP's usefulness. This is 99 especially true since the gain is far greater than the expense of the 100 change. 102 2. Current RIP 104 The current RIP-1 message contains the minimal amount of information 105 necessary for routers to route messages through a network. It also 106 contains a large amount of unused space, owing to its origins. 108 The current RIP-1 protocol does not consider autonomous systems and 109 IGP/EGP interactions, subnetting, and authentication since 110 implementations of these postdate RIP-1. The lack of subnet masks is 111 a particularly serious problem for routers since they need a subnet 112 mask to know how to determine a route. If a RIP-1 route is a network 113 route (all non-network bits 0), the subnet mask equals the network 114 mask. However, if some of the non-network bits are set, the router 115 cannot determine the subnet mask. Worse still, the router cannot 116 determine if the RIP-1 route is a subnet route or a host route. 117 Currently, some routers simply choose the subnet mask of the 118 interface over which the route was learned and determine the route 119 type from that. 121 3. Basic Protocol 123 Much of the material in this section has been taken from [1]. 125 3.1 Introduction 127 RIP is a routing protocol based on the Bellman-Ford (or distance 128 vector) algorithm. This algorithm has been used for routing 129 computations in computer networks since the early days of the 130 ARPANET. The particular packet formats and protocol described here 131 are based on the program "routed," which is included with the 132 Berkeley distribution of Unix. 134 In an international network, such as the Internet, it is very 135 unlikely that a single routing protocol will used for the entire 136 network. Rather, the network will be organized as a collection of 137 Autonomous Systems (AS), each of which will, in general, be 138 administered by a single entity. Each AS will have its own routing 139 technology, which may differ among AS's. The routing protocol used 140 within an AS is referred to as an Interior Gateway Protocol (IGP). A 141 separate protocol, called an Exterior Gateway Protocol (EGP), is used 142 to transfer routing information among the AS's. RIP was designed to 143 work as an IGP in moderate-size AS's. It is not intended for use in 144 more complex environments. For information on the context into which 145 RIP-1 is expected to fit, see Braden and Postel [6]. 147 RIP uses one of a class of routing algorithms known as Distance 148 Vector algorithms. The earliest description of this class of 149 algorithms known to the author is in Ford and Fulkerson [8]. Because 150 of this, they are sometimes known as Ford-Fulkerson algorithms. The 151 term Bellman-Ford is also used, and derives from the fact that the 152 formulation is based on Bellman's equation [4]. The presentation in 153 this document is closely based on [5]. This document contains a 154 protocol specification. For an introduction to the mathematics of 155 routing algorithms, see [1]. The basic algorithms used by this 156 protocol were used in computer routing as early as 1969 in the 157 ARPANET. However, the specific ancestry of this protocol is within 158 the Xerox network protocols. The PUP protocols [7] used the Gateway 159 Information Protocol to exchange routing information. A somewhat 160 updated version of this protocol was adopted for the Xerox Network 161 Systems (XNS) architecture, with the name Routing Information 162 Protocol [9]. Berkeley's routed is largely the same as the Routing 163 Information Protocol, with XNS addresses replaced by a more general 164 address format capable of handling IPv4 and other types of address, 165 and with routing updates limited to one every 30 seconds. Because of 166 this similarity, the term Routing Information Protocol (or just RIP) 167 is used to refer to both the XNS protocol and the protocol used by 168 routed. 170 An introduction to the theory and math behind Distance Vector 171 protocols is provided in [1]. It has not been incorporated in this 172 document for the sake of brevity. 174 3.2 Limitations of the Protocol 176 This protocol does not solve every possible routing problem. As 177 mentioned above, it is primary intended for use as an IGP in networks 178 of moderate size. In addition, the following specific limitations 179 are be mentioned: 181 - The protocol is limited to networks whose longest path (the 182 network's diameter) is 15 hops. The designers believe that the 183 basic protocol design is inappropriate for larger networks. Note 184 that this statement of the limit assumes that a cost of 1 is used 185 for each network. This is the way RIP is normally configured. If 186 the system administrator chooses to use larger costs, the upper 187 bound of 15 can easily become a problem. 189 - The protocol depends upon "counting to infinity" to resolve certain 190 unusual situations (see section 2.2 in [1]). If the system of 191 networks has several hundred networks, and a routing loop was 192 formed involving all of them, the resolution of the loop would 193 require either much time (if the frequency of routing updates were 194 limited) or bandwidth (if updates were sent whenever changes were 195 detected). Such a loop would consume a large amount of network 196 bandwidth before the loop was corrected. We believe that in 197 realistic cases, this will not be a problem except on slow lines. 198 Even then, the problem will be fairly unusual, since various 199 precautions are taken that should prevent these problems in most 200 cases. 202 - This protocol uses fixed "metrics" to compare alternative routes. 203 It is not appropriate for situations where routes need to be chosen 204 based on real-time parameters such a measured delay, reliability, 205 or load. The obvious extensions to allow metrics of this type are 206 likely to introduce instabilities of a sort that the protocol is 207 not designed to handle. 209 3.3 Protocol Specification 211 RIP is intended to allow routers to exchange information for 212 computing routes through an IPv4-based network. Any router that uses 213 RIP is assumed to have interfaces to one or more networks, otherwise 214 it isn't really a router. These are referred to as its directly- 215 connected networks. The protocol relies on access to certain 216 information about each of these networks, the most important of which 217 is its metric. The RIP metric of a network is an integer between 1 218 and 15, inclusive. It is set in some manner not specified in this 219 protocol; however, given the maximum path limit of 15, a value of 1 220 is usually used. Implementations should allow the system 221 administrator to set the metric of each network. In addition to the 222 metric, each network will have an IPv4 destination address and subnet 223 mask associated with it. These are to be set by the system 224 administrator in a manner not specified in this protocol. 226 Each router that implements RIP is assumed to have a routing table. 227 This table has one entry for every destination that is reachable 228 throughout the system operating RIP. Each entry contains at least 229 the following information: 231 - The IPv4 address of the destination. 233 - A metric, which represents the total cost of getting a datagram 234 from the router to that destination. This metric is the sum of the 235 costs associated with the networks that would be traversed to get 236 to the destination. 238 - The IPv4 address of the next router along the path to the 239 destination (i.e., the next hop). If the destination is on one of 240 the directly-connected networks, this item is not needed. 242 - A flag to indicate that information about the route has changed 243 recently. This will be referred to as the "route change flag." 245 - Various timers associated with the route. See section 3.6 for more 246 details on timers. 248 The entries for the directly-connected networks are set up by the 249 router using information gathered by means not specified in this 250 protocol. The metric for a directly-connected network is set to the 251 cost of that network. As mentioned, 1 is the usual cost. In that 252 case, the RIP metric reduces to a simple hop-count. More complex 253 metrics may be used when it is desirable to show preference for some 254 networks over others (e.g., to indicate of differences in bandwidth 255 or reliability). 257 Implementors may also choose to allow the system administrator to 258 enter additional routes. These would most likely be routes to hosts 259 or networks outside the scope of the routing system. They are 260 referred to as "static routes." Entries for destinations other than 261 these initial ones are added and updated by the algorithms described 262 in the following sections. 264 In order for the protocol to provide complete information on routing, 265 every router in the AS must participate in the protocol. In cases 266 where multiple IGPs are in use, there must be at least one router 267 which can leak routing information between the protocols. 269 3.4 Message Format 271 RIP is a UDP-based protocol. Each router that uses RIP has a routing 272 process that sends and receives datagrams on UDP port number 520, the 273 RIP-1/RIP-2 port. All communications intended for another routers's 274 RIP process are sent to the RIP port. All routing update messages 275 are sent from the RIP port. Unsolicited routing update messages have 276 both the source and destination port equal to the RIP port. Update 277 messages sent in response to a request are sent to the port from 278 which the request came. Specific queries may be sent from ports 279 other than the RIP port, but they must be directed to the RIP port on 280 the target machine. 282 The RIP packet format is: 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | command (1) | version (1) | must be zero (2) | 288 +---------------+---------------+-------------------------------+ 289 | | 290 ~ RIP Entry (20) ~ 291 | | 292 +---------------+---------------+---------------+---------------+ 294 There may be between 1 and 25 (inclusive) RIP entries. A RIP-1 entry 295 has the following format: 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | address family identifier (2) | must be zero (2) | 301 +-------------------------------+-------------------------------+ 302 | IPv4 address (4) | 303 +---------------------------------------------------------------+ 304 | must be zero (4) | 305 +---------------------------------------------------------------+ 306 | must be zero (4) | 307 +---------------------------------------------------------------+ 308 | metric (4) | 309 +---------------------------------------------------------------+ 311 Field sizes are given in octets. Unless otherwise specified, fields 312 contain binary integers, in network byte order, with the most- 313 significant octet first (big-endian). Each tick mark represents one 314 bit. 316 Every message contains a RIP header which consists of a command and a 317 version number. This section of the document describes version 1 of 318 the protocol; section 4 describes the version 2 extensions. The 319 command field is used to specify the purpose of this message. The 320 commands implemented in version 1 and 2 are: 322 1 - request A request for the responding system to send all or 323 part of its routing table. 325 2 - response A message containing all or part of the sender's 326 routing table. This message may be sent in response 327 to a request, or it may be an unsolicited routing 328 update generated by the sender. 330 For each of these message types, in version 1, the remainder of the 331 datagram contains a list of Route Entries (RTEs). Each RTE in this 332 list contains an Address Family Identifier (AFI), destination IPv4 333 address, and the cost to reach that destination (metric). 335 The AFI is the type of address. For RIP-1, only AF_INET (2) is 336 generally supported. 338 The metric field contains a value between 1 and 15 (inclusive) which 339 specifies the current metric for the destination; or the value 16 340 (infinity), which indicates that the destination is not reachable. 342 3.5 Addressing Considerations 344 Distance vector routing can be used to describe routes to individual 345 hosts or to networks. The RIP protocol allows either of these 346 possibilities. The destinations appearing in request and response 347 messages can be networks, hosts, or a special code used to indicate a 348 default address. In general, the kinds of routes actually used will 349 depend upon the routing strategy used for the particular network. 350 Many networks are set up so that routing information for individual 351 hosts is not needed. If every node on a given network or subnet is 352 accessible through the same gateways, then there is no reason to 353 mention individual hosts in the routing tables. However, networks 354 that include point-to-point lines sometimes require gateways to keep 355 track of routes to certain nodes. Whether this feature is required 356 depends upon the addressing and routing approach used in the system. 357 Thus, some implementations may choose not to support host routes. If 358 host routes are not supported, they are to be dropped when they are 359 received in response messages (see section 3.7.2). 361 The RIP-1 packet format does not distinguish among various types of 362 address. Fields that are labeled "address" can contain any of the 363 following: 365 host address 366 subnet number 367 network number 368 zero (default route) 370 Entities which use RIP-1 are assumed to use the most specific 371 information available when routing a datagram. That is, when routing 372 a datagram, its destination address must first be checked against the 373 list of node addresses. Then it must be checked to see whether it 374 matches any known subnet or network number. Finally, if none of 375 these match, the default route is used. 377 When a node evaluates information that it receives via RIP-1, its 378 interpretation of an address depends upon whether it knows the subnet 379 mask that applies to the net. If so, then it is possible to 380 determine the meaning of the address. For example, consider net 381 128.6. It has a subnet mask of 255.255.255.0. Thus 128.6.0.0 is a 382 network number, 128.6.4.0 is a subnet number, and 128.6.4.1 is a node 383 address. However, if the node does not know the subnet mask, 384 evaluation of an address may be ambiguous. If there is a non-zero 385 node part, there is no clear way to determine whether the address 386 represents a subnet number or a node address. As a subnet number 387 would be useless without the subnet mask, addresses are assumed to 388 represent nodes in this situation. In order to avoid this sort of 389 ambiguity, when using version 1, nodes must not send subnet routes to 390 nodes that cannot be expected to know the appropriate subnet mask. 391 Normally hosts only know the subnet masks for directly-connected 392 networks. Therefore, unless special provisions have been made, 393 routes to a subnet must not be sent outside the network of which the 394 subnet is a part. RIP-2 (see section 4) eliminates the subnet/host 395 ambiguity by including the subnet mask in the routing entry. 397 This filtering is carried out by the routers at the "border" of the 398 subnetted network. These are routers which connect that network with 399 some other network. Within the subnetted network, each subnet is 400 treated as an individual network. Routing entries for each subnet 401 are circulated by RIP. However, border routers send only a single 402 entry for the network as a whole to nodes in other networks. This 403 means that a border router will send different information to 404 different neighbors. For neighbors connected to the subnetted 405 network, it generates a list of all subnets to which it is directly 406 connected, using the subnet number. For neighbors connected to other 407 networks, it makes a single entry for the network as a whole, showing 408 the metric associated with that network. This metric would normally 409 be the smallest metric for the subnets to which the gateway is 410 attached. 412 Similarly, border routers must not mention host routes for nodes 413 within one of the directly-connected networks in messages to other 414 networks. Those routes will be subsumed by the single entry for the 415 network as a whole. 417 The special address 0.0.0.0 is used to describe a default route. A 418 default route is used when it is not convenient to list every 419 possible network in the RIP updates, and when one or more closely- 420 connected gateways in the system are prepared to handle traffic to 421 the networks that are not listed explicitly. These gateways should 422 create RIP entries for the address 0.0.0.0, just as if it were a 423 network to which they are connected. The decision as to how gateways 424 create entries for 0.0.0.0 is left to the implementor. Most 425 commonly, the system administrator will be provided with a way to 426 specify which gateways should create entries for 0.0.0.0; however, 427 other mechanisms are possible. For example, an implementor might 428 decide that any gateway which speaks BGP should be declared to be a 429 default gateway. It may be useful to allow the network administrator 430 to choose the metric to be used in these entries. If there is more 431 than one default gateway, this will make it possible to express a 432 preference for one over the other. The entries for 0.0.0.0 are 433 handled by RIP in exactly the same manner as if there were an actual 434 network with this address. System administrators should take care to 435 make sure that routes to 0.0.0.0 do not propagate further than is 436 intended. Generally, each autonomous system has its own preferred 437 default gateway. Thus, routes involving 0.0.0.0 should generally not 438 leave the boundary of an autonomous system. The mechanisms for 439 enforcing this are not specified in this document. 441 3.6 Timers 443 This section describes all events that are triggered by timers. 445 Every 30 seconds, the RIP process is awakened to send an unsolicited 446 Response message containing the complete routing table (see section 447 3.9 on Split Horizon) to every neighboring router. When there are 448 many routers on a single network, there is a tendency for them to 449 synchronize with each other such that they all issue updates at the 450 same time. This can happen whenever the 30 second timer is affected 451 by the processing load on the system. It is undesirable for the 452 update messages to become synchronized, since it can lead to 453 unnecessary collisions on broadcast networks. Therefore, 454 implementations are required to take one of two precautions: 456 - The 30-second updates are triggered by a clock whose rate is not 457 affected by system load or the time required to service the 458 previous update timer. 460 - The 30-second timer is offset by a small random time (+/- 0 to 5 461 seconds) each time it is set. 463 There are two timers associated with each route, a "timeout" and a 464 "garbage-collection" time. Upon expiration of the timeout, the route 465 is no longer valid; however, it is retained in the routing table for 466 a short time so that neighbors can be notified that the route has 467 been dropped. Upon expiration of the garbage-collection timer, the 468 route is finally removed from the routing table. 470 The timeout is initialized when a route is established, and any time 471 an update message is received for the route. If 180 seconds elapse 472 from the last time the timeout was initialized, the route is 473 considered to have expired, and the deletion process described below 474 begins for that route. 476 Deletions can occur for one of two reasons: the timeout expires, or 477 the metric is set to 16 because of an update received from the 478 current router (see section 3.7.2 for a discussion of processing 479 updates from other routers). In either case, the following events 480 happen: 482 - The garbage-collection timer is set for 120 seconds. 484 - The metric for the route is set to 16 (infinity). This causes the 485 route to be removed from service. 487 - The route change flag is set to indicate that this entry has been 488 changed. 490 - The output process is signalled to trigger a response. 492 Until the garbage-collection timer expires, the route is included in 493 all updates sent by this router. When the garbage-collection timer 494 expires, the route is deleted from the routing table. 496 Should a new route to this network be established while the garbage- 497 collection timer is running, the new route will replace the one that 498 is about to be deleted. In this case the garbage-collection timer 499 must be cleared. 501 Triggered updates also use a small timer; however, this is best 502 described in section 3.9.1. 504 3.7 Input Processing 506 This section will describe the handling of datagrams received on the 507 RIP port. Processing will depend upon the value in the command 508 field. 510 See sections 4.6 and 5.1 for details on handling version numbers. 512 3.7.1 Request Messages 514 A Request is used to ask for a response containing all or part of a 515 routers's routing table. Normally, Requests are sent as broadcasts 516 (multicasts for RIP-2), from the RIP port, by routers which have just 517 come up and are seeking to fill in their routing tables as quickly as 518 possible. However, there may be situations (e.g., router monitoring) 519 where the routing table of only a single router is needed. In this 520 case, the Request should be sent directly to that router from a UDP 521 port other than the RIP port. If such a Request is received, the 522 router responds directly to the requestor's address and port. 524 The Request is processed entry by entry. If there are no entries, no 525 response is given. There is one special case. If there is exactly 526 one entry in the request, and it has an address family identifier of 527 zero and a metric of infinity (i.e., 16), then this is a request to 528 send the entire routing table. In that case, a call is made to the 529 output process to send the routing table to the requesting 530 address/port. Except for this special case, processing is quite 531 simple. Examine the list of RTEs in the Request one by one. For 532 each entry, look up the destination in the router's routing database 533 and, if there is a route, put that route's metric in the metric field 534 of the RTE. If there is no explicit route to the specified 535 destination, put infinity in the metric field. Once all the entries 536 have been filled in, change the command from Request to Response and 537 send the datagram back to the requestor. 539 Note that there is a difference in metric handling for specific and 540 whole-table requests. If the request is for a complete routing 541 table, normal output processing is done, including Split Horizon (see 542 section 3.9 on Split Horizon). If the request is for specific 543 entries, they are looked up in the routing table and the information 544 is returned as is; no Split Horizon processing is done. The reason 545 for this distinction is the expectation that these requests are 546 likely to be used for different purposes. When a router first comes 547 up, it multicasts a Request on every connected network asking for a 548 complete routing table. It is assumed that these complete routing 549 tables are to be used to update the requestor's routing table. For 550 this reason, Split Horizon must be done. It is further assumed that 551 a Request for specific networks is made only by diagnostic software, 552 and is not used for routing. In this case, the requester would want 553 to know the exact contents of the routing table and would not want 554 any information hidden or modified. 556 3.7.2 Response Messages 558 A Response can be received for one of several different reasons: 560 - response to a specific query 561 - regular update (unsolicited response) 562 - triggered update caused by a route change 564 Processing is the same no matter why the Response was generated. 566 Because processing of a Response may update the router's routing 567 table, the Response must be checked carefully for validity. The 568 Response must be ignored if it is not from the RIP port. The 569 datagram's IPv4 source address should be checked to see whether the 570 datagram is from a valid neighbor; the source of the datagram must be 571 on a directly-connected network. It is also worth checking to see 572 whether the response is from one of the router's own addresses. 573 Interfaces on broadcast networks may receive copies of their own 574 broadcasts/multicasts immediately. If a router processes its own 575 output as new input, confusion is likely so such datagrams must be 576 ignored. 578 Once the datagram as a whole has been validated, process the RTEs in 579 the Response one by one. Again, start by doing validation. 580 Incorrect metrics and other format errors usually indicate 581 misbehaving neighbors and should probably be brought to the 582 administrator's attention. For example, if the metric is greater 583 than infinity, ignore the entry but log the event. The basic 584 validation tests are: 586 - is the destination address valid (e.g., unicast; not net 0 or 127) 587 - is the metric valid (i.e., between 1 and 16, inclusive) 589 If any check fails, ignore that entry and proceed to the next. 590 Again, logging the error is probably a good idea. 592 Once the entry has been validated, update the metric by adding the 593 cost of the network on which the message arrived. If the result is 594 greater than infinity, use infinity. That is, 596 metric = MIN (metric + cost, infinity) 598 Now, check to see whether there is already an explicit route for the 599 destination address. If there is no such route, add this route to 600 the routing table, unless the metric is infinity (there is no point 601 in adding a route which is unusable). Adding a route to the routing 602 table consists of: 604 - Setting the destination address to the destination address in the 605 RTE 607 - Setting the metric to the newly calculated metric (as described 608 above) 610 - Set the next hop address to be the address of the router from which 611 the datagram came 613 - Initialize the timeout for the route. If the garbage-collection 614 timer is running for this route, stop it (see section 3.6 for a 615 discussion of the timers) 617 - Set the route change flag 619 - Signal the output process to trigger an update (see section 3.8.1) 621 If there is an existing route, compare the next hop address to the 622 address of the router from which the datagram came. If this datagram 623 is from the same router as the existing route, reinitialize the 624 timeout. Next, compare the metrics. If the datagram is from the 625 same router as the existing route, and the new metric is different 626 than the old one; or, if the new metric is lower than the old one; do 627 the following actions: 629 - Adopt the route from the datagram (i.e., put the new metric in and 630 adjust the next hop address, if necessary). 632 - Set the route change flag and signal the output process to trigger 633 an update 635 - If the new metric is infinity, start the deletion process 636 (described above); otherwise, re-initialize the timeout 638 If the new metric is infinity, the deletion process begins for the 639 route, which is no longer used for routing packets. Note that the 640 deletion process is started only when the metric is first set to 641 infinity. If the metric was already infinity, then a new deletion 642 process is not started. 644 If the new metric is the same as the old one, it is simplest to do 645 nothing further (beyond re-initializing the timeout, as specified 646 above); but, there is a heuristic which could be applied. Normally, 647 it is senseless to replace a route if the new route has the same 648 metric as the existing route; this would cause the route to bounce 649 back and forth, which would generate an intolerable number of 650 triggered updates. However, if the existing route is showing signs 651 of timing out, it may be better to switch to an equally-good 652 alternative route immediately, rather than waiting for the timeout to 653 happen. Therefore, if the new metric is the same as the old one, 654 examine the timeout for the existing route. If it is at least 655 halfway to the expiration point, switch to the new route. This 656 heuristic is optional, but highly recommended. 658 Any entry that fails these tests is ignored, as it is no better than 659 the current route. 661 3.8 Output Processing 663 This section describes the processing used to create response 664 messages that contain all or part of the routing table. This 665 processing may be triggered in any of the following ways: 667 - By input processing, when a Request is received (this Response is 668 unicast to the requestor; see section 3.7.1) 670 - By the regular routing update (broadcast/multicast every 30 671 seconds) router. 673 - By triggered updates (broadcast/multicast when a route changes) 675 When a Response is to be sent to all neighbors (i.e., a regular or 676 triggered update), a Response message is directed to the router at 677 the far end of each connected point-to-point link, and is broadcast 678 (multicast for RIP-2) on all connected networks which support 679 broadcasting. Thus, one Response is prepared for each directly- 680 connected network, and sent to the appropriate address (direct or 681 broadcast/multicast). In most cases, this reaches all neighboring 682 routers. However, there are some cases where this may not be good 683 enough. This may involve a network that is not a broadcast network 684 (e.g., the ARPANET), or a situation involving dumb routers. In such 685 cases, it may be necessary to specify an actual list of neighboring 686 routers and send a datagram to each one explicitly. It is left to 687 the implementor to determine whether such a mechanism is needed, and 688 to define how the list is specified. 690 3.8.1 Triggered Updates 692 Triggered updates require special handling for two reasons. First, 693 experience shows that triggered updates can cause excessive load on 694 networks with limited capacity or networks with many routers on them. 695 Therefore, the protocol requires that implementors include provisions 696 to limit the frequency of triggered updates. After a triggered 697 update is sent, a timer should be set for a random interval between 1 698 and 5 seconds. If other changes that would trigger updates occur 699 before the timer expires, a single update is triggered when the timer 700 expires. The timer is then reset to another random value between 1 701 and 5 seconds. A triggered update should be suppressed if a regular 702 update is due by the time the triggered update would be sent. 704 Second, triggered updates do not need to include the entire routing 705 table. In principle, only those routes which have changed need to be 706 included. Therefore, messages generated as part of a triggered 707 update must include at least those routes that have their route 708 change flag set. They may include additional routes, at the 709 discretion of the implementor; however, sending complete routing 710 updates is strongly discouraged. When a triggered update is 711 processed, messages should be generated for every directly-connected 712 network. Split Horizon processing is done when generating triggered 713 updates as well as normal updates (see section 3.9). If, after Split 714 Horizon processing for a given network, a changed route will appear 715 unchanged on that network (e.g., it appears with an infinite metric), 716 the route need not be sent. If no routes need be sent on that 717 network, the update may be omitted. Once all of the triggered 718 updates have been generated, the route change flags should be 719 cleared. 721 If input processing is allowed while output is being generated, 722 appropriate interlocking must be done. The route change flags should 723 not be changed as a result of processing input while a triggered 724 update message is being generated. 726 The only difference between a triggered update and other update 727 messages is the possible omission of routes that have not changed. 728 The remaining mechanisms, described in the next section, must be 729 applied to all updates. 731 3.8.2 Generating Response Messages 733 This section describes how a Response message is generated for a 734 particular directly-connected network: 736 Set the version number to either 1 or 2. The mechanism for deciding 737 which version to send is implementation specific; however, if this is 738 the Response to a Request, the Response version should match the 739 Request version. Set the command to Response. Set the bytes labeled 740 "must be zero" to zero. Start filling in RTEs. Recall that there is 741 a limit of 25 RTEs to a Response; if there are more, send the current 742 Response and start a new one. There is no defined limit to the 743 number of datagrams which make up a Response. 745 To fill in the RTEs, examine each route in the routing table. If a 746 triggered update is being generated, only entries whose route change 747 flags are set need be included. If, after Split Horizon processing, 748 the route should not be included, skip it. If the route is to be 749 included, then the destination address and metric are put into the 750 RTE. Routes must be included in the datagram even if their metrics 751 are infinite. 753 3.9 Split Horizon 755 Split Horizon is a algorithm for avoiding problems caused by 756 including routes in updates sent to the gateway from which they were 757 learned. The basic split horizon algorithm omits routes learned from 758 one neighbor in updates sent to that neighbor. In the case of a 759 broadcast network, all routes learned from any neighbor on that 760 network are omitted from updates sent on that network. 762 Split Horizon with Poisoned Reverse (more simply, Poison Reverse) 763 does include such routes in updates, but sets their metrics to 764 infinity. In effect, advertising the fact that these routes are not 765 reachable. This is the preferred method of operation; however, 766 implementations should provide a per-interface control allowing no 767 horizoning, split horizoning, and poisoned reverse to be selected. 769 For a theoretical discussion of Split Horizon and Poison Reverse, and 770 why they are needed, see section 2.1.1 of [1]. 772 4. Protocol Extensions 774 This section does not change the RIP protocol per se. Rather, it 775 provides extensions to the message format which allows routers to 776 share important additional information. 778 The same header format is used for RIP-1 and RIP-2 messages (see 779 section 3.4). The format for the 20-octet route entry (RTE) for 780 RIP-2 is: 782 0 1 2 3 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Address Family Identifier (2) | Route Tag (2) | 786 +-------------------------------+-------------------------------+ 787 | IP Address (4) | 788 +---------------------------------------------------------------+ 789 | Subnet Mask (4) | 790 +---------------------------------------------------------------+ 791 | Next Hop (4) | 792 +---------------------------------------------------------------+ 793 | Metric (4) | 794 +---------------------------------------------------------------+ 795 The Address Family Identifier, IP Address, and Metric all have the 796 meanings defined in section 3.4. The Version field will specify 797 version number 2 for RIP messages which use authentication or carry 798 information in any of the newly defined fields. 800 4.1 Authentication 802 Since authentication is a per message function, and since there is 803 only one 2-octet field available in the message header, and since any 804 reasonable authentication scheme will require more than two octets, 805 the authentication scheme for RIP version 2 will use the space of an 806 entire RIP entry. If the Address Family Identifier of the first (and 807 only the first) entry in the message is 0xFFFF, then the remainder of 808 the entry contains the authentication. This means that there can be, 809 at most, 24 RIP entries in the remainder of the message. If 810 authentication is not in use, then no entries in the message should 811 have an Address Family Identifier of 0xFFFF. A RIP message which 812 contains an authentication entry would begin with the following 813 format: 815 0 1 2 3 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Command (1) | Version (1) | unused | 819 +---------------+---------------+-------------------------------+ 820 | 0xFFFF | Authentication Type (2) | 821 +-------------------------------+-------------------------------+ 822 ~ Authentication (16) ~ 823 +---------------------------------------------------------------+ 825 Currently, the only Authentication Type is simple password and it 826 is type 2. The remaining 16 octets contain the plain text password. If 827 the password is under 16 octets, it must be left-justified and 828 padded to the right with nulls (0x00). 830 4.2 Route Tag 832 The Route Tag (RT) field is an attribute assigned to a route which 833 must be preserved and readvertised with a route. The intended use 834 of the Route Tag is to provide a method of separating "internal" 835 RIP routes (routes for networks within the RIP routing domain) 836 from "external" RIP routes, which may have been imported from an 837 EGP or another IGP. 839 Routers supporting protocols other than RIP should be configurable 840 to allow the Route Tag to be configured for routes imported from 841 different sources. For example, routes imported from EGP or BGP 842 should be able to have their Route Tag either set to an arbitrary 843 value, or at least to the number of the Autonomous System from 844 which the routes were learned. 846 Other uses of the Route Tag are valid, as long as all routers in 847 the RIP domain use it consistently. This allows for the 848 possibility of a BGP-RIP protocol interactions document, which 849 would describe methods for synchronizing routing in a transit 850 network. 852 4.3 Subnet mask 854 The Subnet Mask field contains the subnet mask which is applied to 855 the IP address to yield the non-host portion of the address. If this 856 field is zero, then no subnet mask has been included for this entry. 858 On an interface where a RIP-1 router may hear and operate on the 859 information in a RIP-2 routing entry the following rules apply: 861 1) information internal to one network must never be advertised into 862 another network, 864 2) information about a more specific subnet may not be advertised 865 where RIP-1 routers would consider it a host route, and 867 3) supernet routes (routes with a netmask less specific than 868 the "natural" network mask) must not be advertised where they 869 could be misinterpreted by RIP-1 routers. 871 4.4 Next Hop 873 The immediate next hop IP address to which packets to the destination 874 specified by this route entry should be forwarded. Specifying a 875 value of 0.0.0.0 in this field indicates that routing should be via 876 the originator of the RIP advertisement. An address specified as 877 a next hop must, per force, be directly reachable on the logical 878 subnet over which the advertisement is made. 880 The purpose of the Next Hop field is to eliminate packets being routed 881 through extra hops in the system. It is particularly useful when RIP 882 is not being run on all of the routers on a network. A simple example 883 is given in Appendix A. Note that Next Hop is an "advisory" field. That 884 is, if the provided information is ignored, a possibly sub-optimal, 885 but absolutely valid, route may be taken. If the received Next Hop 886 is not directly reachable, it should be treated as 0.0.0.0. 888 4.5 Multicasting 890 In order to reduce unnecessary load on those hosts which are not 891 listening to RIP-2 messages, an IP multicast address will be used for 892 periodic broadcasts. The IP multicast address is 224.0.0.9. Note that 893 IGMP is not needed since these are inter-router messages which are not 894 forwarded. 896 On NBMA networks, unicast addressing may be used. However, if a 897 response addressed to the RIP-2 multicast address is received, it 898 should be accepted. 900 In order to maintain backwards compatibility, the use of the 901 multicast address will be configurable, as described in section 5.1. If 902 multicasting is used, it should be used on all interfaces which support 903 it. 905 4.6 Queries 907 If a RIP-2 router receives a RIP-1 Request, it should respond with a 908 RIP-1 Response. If the router is configured to send only RIP-2 909 messages, it should not respond to a RIP-1 Request. 911 5. Compatibility 913 RFC 1058 showed considerable forethought in its specification of 914 the handling of version numbers. It specifies that RIP messages of 915 version 0 are to be discarded, that RIP messages of version 1 are 916 to be discarded if any Must Be Zero (MBZ) field is non-zero, and that 917 RIP messages of any version greater than 1 should not be discarded 918 simply because an MBZ field contains a value other than zero. This 919 means that the new version of RIP is totally backwards compatible 920 with existing RIP implementations which adhere to this part of the 921 specification. 923 5.1 Compatibility Switch 925 A compatibility switch is necessary for two reasons. First, there 926 are implementations of RIP-1 in the field which do not follow RFC 927 1058 as described above. Second, the use of multicasting would 928 prevent RIP-1 systems from receiving RIP-2 updates (which may 929 be a desired feature in some cases). This switch should be configurable 930 on a per-interface basis. 932 The switch has four settings: RIP-1, in which only RIP-1 messages are 933 sent; RIP-1 compatibility, in which RIP-2 messages are broadcast; 934 RIP-2, in which RIP-2 messages are multicast; and "none", which 935 disables the sending of RIP messages. It is recommended that the 936 default setting be either RIP-1 or RIP-2, but not RIP-1 compatibility. 937 This is because of the potential problems which can occur on some 938 topologies. RIP-1 compatibility should only be used when all of the 939 consequences of its use are well understood by the network administrator. 941 For completeness, routers should also implement a receive control 942 switch which would determine whether to accept, RIP-1 only, RIP-2 943 only, both, or none. It should also be configurable on a 944 per-interface basis. It is recommended that the default be compatible 945 with the default chosen for sending updates. 947 5.2 Authentication 949 The following algorithm should be used to authenticate a RIP message. If 950 the router is not configured to authenticate RIP-2 messages, then RIP-1 951 and unauthenticated RIP-2 messages will be accepted; authenticated 952 RIP-2 messages shall be discarded. If the router is configured to 953 authenticate RIP-2 messages, then RIP-1 messages and RIP-2 messages 954 which pass authentication testing shall be accepted; unauthenticated 955 and failed authentication RIP-2 messages shall be discarded. For 956 maximum security, RIP-1 messages should be ignored when authentication 957 is in use (see section 4.1); otherwise, the routing information from 958 authenticated messages will be propagated by RIP-1 routers in an 959 unauthenticated manner. 961 Since an authentication entry is marked with an Address Family 962 Identifier of 0xFFFF, a RIP-1 system would ignore this entry since 963 it would belong to an address family other than IP. It should 964 be noted, therefore, that use of authentication will not prevent 965 RIP-1 systems from seeing RIP-2 messages. If desired, this may 966 be done using multicasting, as described in sections 4.5 and 5.1. 968 5.3 Larger Infinity 970 While on the subject of compatibility, there is one item which people 971 have requested: increasing infinity. The primary reason that this 972 cannot be done is that it would violate backwards compatibility. A 973 larger infinity would obviously confuse older versions of rip. At 974 best, they would ignore the route as they would ignore a metric of 975 16. There was also a proposal to make the Metric a single octet and reuse 976 the high three octets, but this would break any implementations which 977 treat the metric as a 4-octet entity. 979 5.4 Addressless Links 981 As in RIP-1, addressless links will not be supported by RIP-2. 983 6. Security Considerations 985 The basic RIP protocol is not a secure protocol. To bring RIP-2 986 in line with more modern routing protocols, an extensible authentication 987 mechanism has been incorporated into the protocol enhancements. This 988 mechanism is described in sections 4.1 and 5.2. Security is further 989 enhanced by the mechanism described in [3]. 991 Appendix A 993 This is a simple example of the use of the next hop field in a rip entry. 995 ----- ----- ----- ----- ----- ----- 996 |IR1| |IR2| |IR3| |XR1| |XR2| |XR3| 997 --+-- --+-- --+-- --+-- --+-- --+-- 998 | | | | | | 999 --+-------+-------+---------------+-------+-------+-- 1000 <-------------RIP-2-------------> 1002 Assume that IR1, IR2, and IR3 are all "internal" routers which are 1003 under one administration (e.g. a campus) which has elected to use 1004 RIP-2 as its IGP. XR1, XR2, and XR3, on the other hand, are under 1005 separate administration (e.g. a regional network, of which the campus 1006 is a member) and are using some other routing protocol (e.g. OSPF). 1007 XR1, XR2, and XR3 exchange routing information among themselves such 1008 that they know that the best routes to networks N1 and N2 are via 1009 XR1, to N3, N4, and N5 are via XR2, and to N6 and N7 are via XR3. By 1010 setting the Next Hop field correctly (to XR2 for N3/N4/N5, to XR3 for 1011 N6/N7), only XR1 need exchange RIP-2 routes with IR1/IR2/IR3 for 1012 routing to occur without additional hops through XR1. Without the 1013 Next Hop (for example, if RIP-1 were used) it would be necessary for 1014 XR2 and XR3 to also participate in the RIP-2 protocol to eliminate 1015 extra hops. 1017 References 1019 [1] Hedrick, C., Routing Information Protocol, Request For Comments 1020 (RFC) 1058, Rutgers University, June 1988. 1022 [2] Malkin, G., and F. Baker, RIP Version 2 MIB Extension, Request 1023 For Comments (RFC) 1389, Xylogics, Inc., Advanced Computer 1024 Communications, January 1993. 1026 [3] Baker, F., Atkinson, R., "RIP-II MD5 Authentication", draft- 1027 ietf-ripv2-md5-auth-00.txt, March 1997. 1029 [4] Bellman, R. E., "Dynamic Programming", Princeton University 1030 Press, Princeton, N.J., 1957. 1032 [5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", 1033 Prentice-Hall, Englewood Cliffs, N.J., 1987. 1035 [6] Braden, R., and Postel, J., "Requirements for Internet Gateways", 1036 USC/Information Sciences Institute, RFC-1009, June 1987. 1038 [7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M., 1039 "Pup: An Internetwork Architecture", IEEE Transactions on 1040 Communications, April 1980. 1042 [8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks", 1043 Princeton University Press, Princeton, N.J., 1962. 1045 [9] Xerox Corp., "Internet Transport Protocols", Xerox System 1046 Integration Standard XSIS 028112, December 1981. 1048 Author's Address 1050 Gary Scott Malkin 1051 Bay Networks 1052 8 Federal Street 1053 Billerica, MA 01821 1055 Phone: (508) 916-4237 1056 EMail: gmalkin@baynetworks.com