idnits 2.17.1 draft-ietf-ripv2-protocol-v2-05.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. == 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: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1998) is 9446 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' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Malkin 2 Obsoletes RFCs 1723, 1388 Bay Networks 3 June 1998 5 RIP Version 2 6 Carrying Additional Information 8 10 Abstract 12 This document specifies an extension of the Routing Information 13 Protocol (RIP), as defined in [1], to expand the amount of useful 14 information carried in RIP messages and to add a measure of security. 16 A companion document will define the SNMP MIB objects for RIP-2 [2]. 17 An additional document will define cryptographic security 18 improvements for RIP-2 [3]. 20 Status of this Memo 22 This document is an Internet Draft. Internet Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its Areas, 24 and its Working Groups. Note that other groups may also distribute 25 working documents as Internet Drafts. 27 Internet Drafts are draft documents valid for a maximum of six 28 months. Internet Drafts may be updated, replaced, or obsoleted by 29 other documents at any time. It is not appropriate to use Internet 30 Drafts as reference material or to cite them other than as a "working 31 draft" or "work in progress." 33 Please check the I-D abstract listing contained in each Internet 34 Draft directory to learn the current status of this or any other 35 Internet Draft. 37 It is intended that this document will be submitted to the IESG for 38 consideration as a standards document. Distribution of this document 39 is unlimited. 41 Acknowledgements 43 I would like to thank the IETF RIP Working Group for their help in 44 improving the RIP-2 protocol. Much of the text for the background 45 discussions about distance vector protocols and some of the 46 descriptions of the operation of RIP were taken from "Routing 47 Information Protocol" by C. Hedrick[1]. Some of the final editing on 48 the document was done by Scott Bradner. 50 Table of Contents 52 1. Justification . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Basic Protocol . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2 Limitations of the Protocol . . . . . . . . . . . . . . . . 6 59 3.3. Organization of this document . . . . . . . . . . . . . . . 6 60 3.4 Distance Vector Algorithms . . . . . . . . . . . . . . . . . 6 61 3.4.1 Dealing with changes in topology . . . . . . . . . . . . 12 62 3.4.2 Preventing instability . . . . . . . . . . . . . . . . . 13 63 3.4.3 Split horizon . . . . . . . . . . . . . . . . . . . . . . 16 64 3.4.4 Triggered updates . . . . . . . . . . . . . . . . . . . . 17 65 3.5 Protocol Specification . . . . . . . . . . . . . . . . . . 18 66 3.6 Message Format . . . . . . . . . . . . . . . . . . . . . . . 20 67 3.7 Addressing Considerations . . . . . . . . . . . . . . . . . 21 68 3.8 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 69 3.9 Input Processing . . . . . . . . . . . . . . . . . . . . . . 25 70 3.9.1 Request Messages . . . . . . . . . . . . . . . . . . . . 25 71 3.9.2 Response Messages . . . . . . . . . . . . . . . . . . . . 26 72 3.10 Output Processing . . . . . . . . . . . . . . . . . . . . . 28 73 3.10.1 Triggered Updates . . . . . . . . . . . . . . . . . . . . 29 74 3.10.2 Generating Response Messages. . . . . . . . . . . . . . . 29 76 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 30 77 4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 31 78 4.2 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . 31 79 4.3 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . 32 80 4.4 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 32 81 4.5 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 32 82 4.6 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 33 84 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 33 85 5.1 Compatibility Switch . . . . . . . . . . . . . . . . . . . . 33 86 5.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 34 87 5.3 Larger Infinity . . . . . . . . . . . . . . . . . . . . . . 34 88 5.4 Addressless Links . . . . . . . . . . . . . . . . . . . . . 34 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 92 Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 94 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 98 1. Justification 100 With the advent of OSPF and IS-IS, there are those who believe that 101 RIP is obsolete. While it is true that the newer IGP routing 102 protocols are far superior to RIP, RIP does have some advantages. 103 Primarily, in a small network, RIP has very little overhead in terms 104 of bandwidth used and configuration and management time. RIP is also 105 very easy to implement, especially in relation to the newer IGPs. 107 Additionally, there are many, many more RIP implementations in the 108 field than OSPF and IS-IS combined. It is likely to remain that way 109 for some years yet. 111 Given that RIP will be useful in many environments for some period of 112 time, it is reasonable to increase RIP's usefulness. This is 113 especially true since the gain is far greater than the expense of the 114 change. 116 2. Current RIP 118 The current RIP-1 message contains the minimal amount of information 119 necessary for routers to route messages through a network. It also 120 contains a large amount of unused space, owing to its origins. 122 The current RIP-1 protocol does not consider autonomous systems and 123 IGP/EGP interactions, subnetting[11], and authentication since 124 implementations of these postdate RIP-1. The lack of subnet masks is 125 a particularly serious problem for routers since they need a subnet 126 mask to know how to determine a route. If a RIP-1 route is a network 127 route (all non-network bits 0), the subnet mask equals the network 128 mask. However, if some of the non-network bits are set, the router 129 cannot determine the subnet mask. Worse still, the router cannot 130 determine if the RIP-1 route is a subnet route or a host route. 131 Currently, some routers simply choose the subnet mask of the 132 interface over which the route was learned and determine the route 133 type from that. 135 3. Basic Protocol 137 3.1 Introduction 139 RIP is a routing protocol based on the Bellman-Ford (or distance 140 vector) algorithm. This algorithm has been used for routing 141 computations in computer networks since the early days of the 142 ARPANET. The particular packet formats and protocol described here 143 are based on the program "routed," which is included with the 144 Berkeley distribution of Unix. 146 In an international network, such as the Internet, it is very 147 unlikely that a single routing protocol will used for the entire 148 network. Rather, the network will be organized as a collection of 149 Autonomous Systems (AS), each of which will, in general, be 150 administered by a single entity. Each AS will have its own routing 151 technology, which may differ among AS's. The routing protocol used 152 within an AS is referred to as an Interior Gateway Protocol (IGP). A 153 separate protocol, called an Exterior Gateway Protocol (EGP), is used 154 to transfer routing information among the AS's. RIP was designed to 155 work as an IGP in moderate-size AS's. It is not intended for use in 156 more complex environments. For information on the context into which 157 RIP-1 is expected to fit, see Braden and Postel [6]. 159 RIP uses one of a class of routing algorithms known as Distance 160 Vector algorithms. The earliest description of this class of 161 algorithms known to the author is in Ford and Fulkerson [8]. Because 162 of this, they are sometimes known as Ford-Fulkerson algorithms. The 163 term Bellman-Ford is also used, and derives from the fact that the 164 formulation is based on Bellman's equation [4]. The presentation in 165 this document is closely based on [5]. This document contains a 166 protocol specification. For an introduction to the mathematics of 167 routing algorithms, see [1]. The basic algorithms used by this 168 protocol were used in computer routing as early as 1969 in the 169 ARPANET. However, the specific ancestry of this protocol is within 170 the Xerox network protocols. The PUP protocols [7] used the Gateway 171 Information Protocol to exchange routing information. A somewhat 172 updated version of this protocol was adopted for the Xerox Network 173 Systems (XNS) architecture, with the name Routing Information 174 Protocol [9]. Berkeley's routed is largely the same as the Routing 175 Information Protocol, with XNS addresses replaced by a more general 176 address format capable of handling IPv4 and other types of address, 177 and with routing updates limited to one every 30 seconds. Because of 178 this similarity, the term Routing Information Protocol (or just RIP) 179 is used to refer to both the XNS protocol and the protocol used by 180 routed. 182 RIP is intended for use within the IP-based Internet. The Internet 183 is organized into a number of networks connected by special purpose 184 gateways known as routers. The networks may be either point-to-point 185 links or more complex networks such as Ethernet or the ARPANET. 186 Hosts and routers are presented with IP datagrams addressed to some 187 host. Routing is the method by which the host or router decides 188 where to send the datagram. It may be able to send the datagram 189 directly to the destination, if that destination is on one of the 190 networks that are directly connected to the host or router. However, 191 the interesting case is when the destination is not directly 192 reachable. In this case, the host or router attempts to send the 193 datagram to a router that is nearer the destination. The goal of a 194 routing protocol is very simple: It is to supply the information that 195 is needed to do routing. 197 3.2 Limitations of the Protocol 199 This protocol does not solve every possible routing problem. As 200 mentioned above, it is primary intended for use as an IGP in networks 201 of moderate size. In addition, the following specific limitations 202 are be mentioned: 204 - The protocol is limited to networks whose longest path (the 205 network's diameter) is 15 hops. The designers believe that the 206 basic protocol design is inappropriate for larger networks. Note 207 that this statement of the limit assumes that a cost of 1 is used 208 for each network. This is the way RIP is normally configured. If 209 the system administrator chooses to use larger costs, the upper 210 bound of 15 can easily become a problem. 212 - The protocol depends upon "counting to infinity" to resolve certain 213 unusual situations. (This will be explained in the next section.) 214 If the system of networks has several hundred networks, and a 215 routing loop was formed involving all of them, the resolution of 216 the loop would require either much time (if the frequency of 217 routing updates were limited) or bandwidth (if updates were sent 218 whenever changes were detected). Such a loop would consume a large 219 amount of network bandwidth before the loop was corrected. We 220 believe that in realistic cases, this will not be a problem except 221 on slow lines. Even then, the problem will be fairly unusual, 222 since various precautions are taken that should prevent these 223 problems in most cases. 225 - This protocol uses fixed "metrics" to compare alternative routes. 226 It is not appropriate for situations where routes need to be chosen 227 based on real-time parameters such a measured delay, reliability, 228 or load. The obvious extensions to allow metrics of this type are 229 likely to introduce instabilities of a sort that the protocol is 230 not designed to handle. 232 3.3. Organization of this document 234 The main body of this document is organized into two parts, which 235 occupy the next two sections: 237 A conceptual development and justification of distance vector 238 algorithms in general. 240 The actual protocol description. 242 Each of these two sections can largely stand on its own. Section 3.4 243 attempts to give an informal presentation of the mathematical 244 underpinnings of the algorithm. Note that the presentation follows a 245 "spiral" method. An initial, fairly simple algorithm is described. 246 Then refinements are added to it in successive sections. Section 3.5 247 is the actual protocol description. Except where specific references 248 are made to section 3.4, it should be possible to implement RIP 249 entirely from the specifications given in section 3.5. 251 3.4 Distance Vector Algorithms 253 Routing is the task of finding a path from a sender to a desired 254 destination. In the IP "Internet model" this reduces primarily to a 255 matter of finding a series of routers between the source and 256 destination networks. As long as a message or datagram remains on a 257 single network or subnet, any forwarding problems are the 258 responsibility of technology that is specific to the network. For 259 example, Ethernet and the ARPANET each define a way in which any 260 sender can talk to any specified destination within that one network. 261 IP routing comes in primarily when messages must go from a sender on 262 one network to a destination on a different one. In that case, the 263 message must pass through one or more routers connecting the 264 networks. If the networks are not adjacent, the message may pass 265 through several intervening networks, and the routers connecting 266 them. Once the message gets to a router that is on the same network 267 as the destination, that network's own technology is used to get to 268 the destination. 270 Throughout this section, the term "network" is used generically to 271 cover a single broadcast network (e.g., an Ethernet), a point to 272 point line, or the ARPANET. The critical point is that a network is 273 treated as a single entity by IP. Either no forwarding decision is 274 necessary (as with a point to point line), or that forwarding is done 275 in a manner that is transparent to IP, allowing IP to treat the 276 entire network as a single fully-connected system (as with an 277 Ethernet or the ARPANET). Note that the term "network" is used in a 278 somewhat different way in discussions of IP addressing. We are using 279 the term "network" here to refer to subnets in cases where subnet 280 addressing is in use. 282 A number of different approaches for finding routes between networks 283 are possible. One useful way of categorizing these approaches is on 284 the basis of the type of information the routers need to exchange in 285 order to be able to find routes. Distance vector algorithms are 286 based on the exchange of only a small amount of information. Each 287 entity (router or host) that participates in the routing protocol is 288 assumed to keep information about all of the destinations within the 289 system. Generally, information about all entities connected to one 290 network is summarized by a single entry, which describes the route to 291 all destinations on that network. This summarization is possible 292 because as far as IP is concerned, routing within a network is 293 invisible. Each entry in this routing database includes the next 294 router to which datagrams destined for the entity should be sent. In 295 addition, it includes a "metric" measuring the total distance to the 296 entity. Distance is a somewhat generalized concept, which may cover 297 the time delay in getting messages to the entity, the dollar cost of 298 sending messages to it, etc. Distance vector algorithms get their 299 name from the fact that it is possible to compute optimal routes when 300 the only information exchanged is the list of these distances. 301 Furthermore, information is only exchanged among entities that are 302 adjacent, that is, entities that share a common network. 304 Although routing is most commonly based on information about 305 networks, it is sometimes necessary to keep track of the routes to 306 individual hosts. The RIP protocol makes no formal distinction 307 between networks and hosts. It simply describes exchange of 308 information about destinations, which may be either networks or 309 hosts. (Note however, that it is possible for an implementor to 310 choose not to support host routes. See section 3.2.) In fact, the 311 mathematical developments are most conveniently thought of in terms 312 of routes from one host or router to another. When discussing the 313 algorithm in abstract terms, it is best to think of a routing entry 314 for a network as an abbreviation for routing entries for all of the 315 entities connected to that network. This sort of abbreviation makes 316 sense only because we think of networks as having no internal 317 structure that is visible at the IP level. Thus, we will generally 318 assign the same distance to every entity in a given network. 320 We said above that each entity keeps a routing database with one 321 entry for every possible destination in the system. An actual 322 implementation is likely to need to keep the following information 323 about each destination: 325 - address: in IP implementations of these algorithms, this will be 326 the IP address of the host or network. 328 - router: the first router along the route to the destination. 330 - interface: the physical network which must be used to reach the 331 first router. 333 - metric: a number, indicating the distance to the destination. 335 - timer: the amount of time since the entry was last updated. 337 In addition, various flags and other internal information will 338 probably be included. This database is initialized with a 339 description of the entities that are directly connected to the 340 system. It is updated according to information received in messages 341 from neighboring routers. 343 The most important information exchanged by the hosts and routers is 344 carried in update messages. Each entity that participates in the 345 routing scheme sends update messages that describe the routing 346 database as it currently exists in that entity. It is possible to 347 maintain optimal routes for the entire system by using only 348 information obtained from neighboring entities. The algorithm used 349 for that will be described in the next section. 351 As we mentioned above, the purpose of routing is to find a way to get 352 datagrams to their ultimate destinations. Distance vector algorithms 353 are based on a table in each router listing the best route to every 354 destination in the system. Of course, in order to define which route 355 is best, we have to have some way of measuring goodness. This is 356 referred to as the "metric". 358 In simple networks, it is common to use a metric that simply counts 359 how many routers a message must go through. In more complex 360 networks, a metric is chosen to represent the total amount of delay 361 that the message suffers, the cost of sending it, or some other 362 quantity which may be minimized. The main requirement is that it 363 must be possible to represent the metric as a sum of "costs" for 364 individual hops. 366 Formally, if it is possible to get from entity i to entity j directly 367 (i.e., without passing through another router between), then a cost, 368 d(i,j), is associated with the hop between i and j. In the normal 369 case where all entities on a given network are considered to be the 370 same, d(i,j) is the same for all destinations on a given network, and 371 represents the cost of using that network. To get the metric of a 372 complete route, one just adds up the costs of the individual hops 373 that make up the route. For the purposes of this memo, we assume 374 that the costs are positive integers. 376 Let D(i,j) represent the metric of the best route from entity i to 377 entity j. It should be defined for every pair of entities. d(i,j) 378 represents the costs of the individual steps. Formally, let d(i,j) 379 represent the cost of going directly from entity i to entity j. It 380 is infinite if i and j are not immediate neighbors. (Note that d(i,i) 381 is infinite. That is, we don't consider there to be a direct 382 connection from a node to itself.) Since costs are additive, it is 383 easy to show that the best metric must be described by 384 D(i,i) = 0, all i 385 D(i,j) = min [d(i,k) + D(k,j)], otherwise 386 k 388 and that the best routes start by going from i to those neighbors k 389 for which d(i,k) + D(k,j) has the minimum value. (These things can 390 be shown by induction on the number of steps in the routes.) Note 391 that we can limit the second equation to k's that are immediate 392 neighbors of i. For the others, d(i,k) is infinite, so the term 393 involving them can never be the minimum. 395 It turns out that one can compute the metric by a simple algorithm 396 based on this. Entity i gets its neighbors k to send it their 397 estimates of their distances to the destination j. When i gets the 398 estimates from k, it adds d(i,k) to each of the numbers. This is 399 simply the cost of traversing the network between i and k. Now and 400 then i compares the values from all of its neighbors and picks the 401 smallest. 403 A proof is given in [2] that this algorithm will converge to the 404 correct estimates of D(i,j) in finite time in the absence of topology 405 changes. The authors make very few assumptions about the order in 406 which the entities send each other their information, or when the min 407 is recomputed. Basically, entities just can't stop sending updates 408 or recomputing metrics, and the networks can't delay messages 409 forever. (Crash of a routing entity is a topology change.) Also, 410 their proof does not make any assumptions about the initial estimates 411 of D(i,j), except that they must be non-negative. The fact that 412 these fairly weak assumptions are good enough is important. Because 413 we don't have to make assumptions about when updates are sent, it is 414 safe to run the algorithm asynchronously. That is, each entity can 415 send updates according to its own clock. Updates can be dropped by 416 the network, as long as they don't all get dropped. Because we don't 417 have to make assumptions about the starting condition, the algorithm 418 can handle changes. When the system changes, the routing algorithm 419 starts moving to a new equilibrium, using the old one as its starting 420 point. It is important that the algorithm will converge in finite 421 time no matter what the starting point. Otherwise certain kinds of 422 changes might lead to non-convergent behavior. 424 The statement of the algorithm given above (and the proof) assumes 425 that each entity keeps copies of the estimates that come from each of 426 its neighbors, and now and then does a min over all of the neighbors. 427 In fact real implementations don't necessarily do that. They simply 428 remember the best metric seen so far, and the identity of the 429 neighbor that sent it. They replace this information whenever they 430 see a better (smaller) metric. This allows them to compute the 431 minimum incrementally, without having to store data from all of the 432 neighbors. 434 There is one other difference between the algorithm as described in 435 texts and those used in real protocols such as RIP: the description 436 above would have each entity include an entry for itself, showing a 437 distance of zero. In fact this is not generally done. Recall that 438 all entities on a network are normally summarized by a single entry 439 for the network. Consider the situation of a host or router G that 440 is connected to network A. C represents the cost of using network A 441 (usually a metric of one). (Recall that we are assuming that the 442 internal structure of a network is not visible to IP, and thus the 443 cost of going between any two entities on it is the same.) In 444 principle, G should get a message from every other entity H on 445 network A, showing a cost of 0 to get from that entity to itself. G 446 would then compute C + 0 as the distance to H. Rather than having G 447 look at all of these identical messages, it simply starts out by 448 making an entry for network A in its table, and assigning it a metric 449 of C. This entry for network A should be thought of as summarizing 450 the entries for all other entities on network A. The only entity on 451 A that can't be summarized by that common entry is G itself, since 452 the cost of going from G to G is 0, not C. But since we never need 453 those 0 entries, we can safely get along with just the single entry 454 for network A. Note one other implication of this strategy: because 455 we don't need to use the 0 entries for anything, hosts that do not 456 function as routers don't need to send any update messages. Clearly 457 hosts that don't function as routers (i.e., hosts that are connected 458 to only one network) can have no useful information to contribute 459 other than their own entry D(i,i) = 0. As they have only the one 460 interface, it is easy to see that a route to any other network 461 through them will simply go in that interface and then come right 462 back out it. Thus the cost of such a route will be greater than the 463 best cost by at least C. Since we don't need the 0 entries, non- 464 routers need not participate in the routing protocol at all. 466 Let us summarize what a host or router G does. For each destination 467 in the system, G will keep a current estimate of the metric for that 468 destination (i.e., the total cost of getting to it) and the identity 469 of the neighboring router on whose data that metric is based. If the 470 destination is on a network that is directly connected to G, then G 471 simply uses an entry that shows the cost of using the network, and 472 the fact that no router is needed to get to the destination. It is 473 easy to show that once the computation has converged to the correct 474 metrics, the neighbor that is recorded by this technique is in fact 475 the first router on the path to the destination. (If there are 476 several equally good paths, it is the first router on one of them.) 477 This combination of destination, metric, and router is typically 478 referred to as a route to the destination with that metric, using 479 that router. 481 The method so far only has a way to lower the metric, as the existing 482 metric is kept until a smaller one shows up. It is possible that the 483 initial estimate might be too low. Thus, there must be a way to 484 increase the metric. It turns out to be sufficient to use the 485 following rule: suppose the current route to a destination has metric 486 D and uses router G. If a new set of information arrived from some 487 source other than G, only update the route if the new metric is 488 better than D. But if a new set of information arrives from G 489 itself, always update D to the new value. It is easy to show that 490 with this rule, the incremental update process produces the same 491 routes as a calculation that remembers the latest information from 492 all the neighbors and does an explicit minimum. (Note that the 493 discussion so far assumes that the network configuration is static. 494 It does not allow for the possibility that a system might fail.) 496 To summarize, here is the basic distance vector algorithm as it has 497 been developed so far. (Note that this is not a statement of the RIP 498 protocol. There are several refinements still to be added.) The 499 following procedure is carried out by every entity that participates 500 in the routing protocol. This must include all of the routers in the 501 system. Hosts that are not routers may participate as well. 503 - Keep a table with an entry for every possible destination in the 504 system. The entry contains the distance D to the destination, and 505 the first router G on the route to that network. Conceptually, 506 there should be an entry for the entity itself, with metric 0, but 507 this is not actually included. 509 - Periodically, send a routing update to every neighbor. The update 510 is a set of messages that contain all of the information from the 511 routing table. It contains an entry for each destination, with the 512 distance shown to that destination. 514 - When a routing update arrives from a neighbor G', add the cost 515 associated with the network that is shared with G'. (This should 516 be the network over which the update arrived.) Call the resulting 517 distance D'. Compare the resulting distances with the current 518 routing table entries. If the new distance D' for N is smaller 519 than the existing value D, adopt the new route. That is, change 520 the table entry for N to have metric D' and router G'. If G' is 521 the router from which the existing route came, i.e., G' = G, then 522 use the new metric even if it is larger than the old one. 524 3.4.1 Dealing with changes in topology 526 The discussion above assumes that the topology of the network is 527 fixed. In practice, routers and lines often fail and come back up. 528 To handle this possibility, we need to modify the algorithm slightly. 530 The theoretical version of the algorithm involved a minimum over all 531 immediate neighbors. If the topology changes, the set of neighbors 532 changes. Therefore, the next time the calculation is done, the 533 change will be reflected. However, as mentioned above, actual 534 implementations use an incremental version of the minimization. Only 535 the best route to any given destination is remembered. If the router 536 involved in that route should crash, or the network connection to it 537 break, the calculation might never reflect the change. The algorithm 538 as shown so far depends upon a router notifying its neighbors if its 539 metrics change. If the router crashes, then it has no way of 540 notifying neighbors of a change. 542 In order to handle problems of this kind, distance vector protocols 543 must make some provision for timing out routes. The details depend 544 upon the specific protocol. As an example, in RIP every router that 545 participates in routing sends an update message to all its neighbors 546 once every 30 seconds. Suppose the current route for network N uses 547 router G. If we don't hear from G for 180 seconds, we can assume 548 that either the router has crashed or the network connecting us to it 549 has become unusable. Thus, we mark the route as invalid. When we 550 hear from another neighbor that has a valid route to N, the valid 551 route will replace the invalid one. Note that we wait for 180 552 seconds before timing out a route even though we expect to hear from 553 each neighbor every 30 seconds. Unfortunately, messages are 554 occasionally lost by networks. Thus, it is probably not a good idea 555 to invalidate a route based on a single missed message. 557 As we will see below, it is useful to have a way to notify neighbors 558 that there currently isn't a valid route to some network. RIP, along 559 with several other protocols of this class, does this through a 560 normal update message, by marking that network as unreachable. A 561 specific metric value is chosen to indicate an unreachable 562 destination; that metric value is larger than the largest valid 563 metric that we expect to see. In the existing implementation of RIP, 564 16 is used. This value is normally referred to as "infinity", since 565 it is larger than the largest valid metric. 16 may look like a 566 surprisingly small number. It is chosen to be this small for reasons 567 that we will see shortly. In most implementations, the same 568 convention is used internally to flag a route as invalid. 570 3.4.2 Preventing instability 572 The algorithm as presented up to this point will always allow a host 573 or router to calculate a correct routing table. However, that is 574 still not quite enough to make it useful in practice. The proofs 575 referred to above only show that the routing tables will converge to 576 the correct values in finite time. They do not guarantee that this 577 time will be small enough to be useful, nor do they say what will 578 happen to the metrics for networks that become inaccessible. 580 It is easy enough to extend the mathematics to handle routes becoming 581 inaccessible. The convention suggested above will do that. We 582 choose a large metric value to represent "infinity". This value must 583 be large enough that no real metric would ever get that large. For 584 the purposes of this example, we will use the value 16. Suppose a 585 network becomes inaccessible. All of the immediately neighboring 586 routers time out and set the metric for that network to 16. For 587 purposes of analysis, we can assume that all the neighboring routers 588 have gotten a new piece of hardware that connects them directly to 589 the vanished network, with a cost of 16. Since that is the only 590 connection to the vanished network, all the other routers in the 591 system will converge to new routes that go through one of those 592 routers. It is easy to see that once convergence has happened, all 593 the routers will have metrics of at least 16 for the vanished 594 network. Routers one hop away from the original neighbors would end 595 up with metrics of at least 17; routers two hops away would end up 596 with at least 18, etc. As these metrics are larger than the maximum 597 metric value, they are all set to 16. It is obvious that the system 598 will now converge to a metric of 16 for the vanished network at all 599 routers. 601 Unfortunately, the question of how long convergence will take is not 602 amenable to quite so simple an answer. Before going any further, it 603 will be useful to look at an example (taken from [2]). Note that 604 what we are about to show will not happen with a correct 605 implementation of RIP. We are trying to show why certain features 606 are needed. In the following example the letters correspond to 607 routers, and the lines to networks. 609 A-----B 610 \ / \ 611 \ / | 612 C / all networks have cost 1, except 613 | / for the direct link from C to D, which 614 |/ has cost 10 615 D 616 |<=== target network 618 Each router will have a table showing a route to each network. 620 However, for purposes of this illustration, we show only the routes 621 from each router to the network marked at the bottom of the diagram. 623 D: directly connected, metric 1 624 B: route via D, metric 2 625 C: route via B, metric 3 626 A: route via B, metric 3 628 Now suppose that the link from B to D fails. The routes should now 629 adjust to use the link from C to D. Unfortunately, it will take a 630 while for this to this to happen. The routing changes start when B 631 notices that the route to D is no longer usable. For simplicity, the 632 chart below assumes that all routers send updates at the same time. 633 The chart shows the metric for the target network, as it appears in 634 the routing table at each router. 636 time ------> 638 D: dir, 1 dir, 1 dir, 1 dir, 1 ... dir, 1 dir, 1 639 B: unreach C, 4 C, 5 C, 6 C, 11 C, 12 640 C: B, 3 A, 4 A, 5 A, 6 A, 11 D, 11 641 A: B, 3 C, 4 C, 5 C, 6 C, 11 C, 12 643 dir = directly connected 644 unreach = unreachable 646 Here's the problem: B is able to get rid of its failed route using a 647 timeout mechanism, but vestiges of that route persist in the system 648 for a long time. Initially, A and C still think they can get to D 649 via B. So, they keep sending updates listing metrics of 3. In the 650 next iteration, B will then claim that it can get to D via either A 651 or C. Of course, it can't. The routes being claimed by A and C are 652 now gone, but they have no way of knowing that yet. And even when 653 they discover that their routes via B have gone away, they each think 654 there is a route available via the other. Eventually the system 655 converges, as all the mathematics claims it must. But it can take 656 some time to do so. The worst case is when a network becomes 657 completely inaccessible from some part of the system. In that case, 658 the metrics may increase slowly in a pattern like the one above until 659 they finally reach infinity. For this reason, the problem is called 660 "counting to infinity". 662 You should now see why "infinity" is chosen to be as small as 663 possible. If a network becomes completely inaccessible, we want 664 counting to infinity to be stopped as soon as possible. Infinity 665 must be large enough that no real route is that big. But it 666 shouldn't be any bigger than required. Thus the choice of infinity 667 is a tradeoff between network size and speed of convergence in case 668 counting to infinity happens. The designers of RIP believed that the 669 protocol was unlikely to be practical for networks with a diameter 670 larger than 15. 672 There are several things that can be done to prevent problems like 673 this. The ones used by RIP are called "split horizon with poisoned 674 reverse", and "triggered updates". 676 3.4.3 Split horizon 678 Note that some of the problem above is caused by the fact that A and 679 C are engaged in a pattern of mutual deception. Each claims to be 680 able to get to D via the other. This can be prevented by being a bit 681 more careful about where information is sent. In particular, it is 682 never useful to claim reachability for a destination network to the 683 neighbor(s) from which the route was learned. "Split horizon" is a 684 scheme for avoiding problems caused by including routes in updates 685 sent to the router from which they were learned. The "simple split 686 horizon" scheme omits routes learned from one neighbor in updates 687 sent to that neighbor. "Split horizon with poisoned reverse" 688 includes such routes in updates, but sets their metrics to infinity. 690 If A thinks it can get to D via C, its messages to C should indicate 691 that D is unreachable. If the route through C is real, then C either 692 has a direct connection to D, or a connection through some other 693 router. C's route can't possibly go back to A, since that forms a 694 loop. By telling C that D is unreachable, A simply guards against 695 the possibility that C might get confused and believe that there is a 696 route through A. This is obvious for a point to point line. But 697 consider the possibility that A and C are connected by a broadcast 698 network such as an Ethernet, and there are other routers on that 699 network. If A has a route through C, it should indicate that D is 700 unreachable when talking to any other router on that network. The 701 other routers on the network can get to C themselves. They would 702 never need to get to C via A. If A's best route is really through C, 703 no other router on that network needs to know that A can reach D. 704 This is fortunate, because it means that the same update message that 705 is used for C can be used for all other routers on the same network. 706 Thus, update messages can be sent by broadcast. 708 In general, split horizon with poisoned reverse is safer than simple 709 split horizon. If two routers have routes pointing at each other, 710 advertising reverse routes with a metric of 16 will break the loop 711 immediately. If the reverse routes are simply not advertised, the 712 erroneous routes will have to be eliminated by waiting for a timeout. 713 However, poisoned reverse does have a disadvantage: it increases the 714 size of the routing messages. Consider the case of a campus backbone 715 connecting a number of different buildings. In each building, there 716 is a router connecting the backbone to a local network. Consider 717 what routing updates those routers should broadcast on the backbone 718 network. All that the rest of the network really needs to know about 719 each router is what local networks it is connected to. Using simple 720 split horizon, only those routes would appear in update messages sent 721 by the router to the backbone network. If split horizon with 722 poisoned reverse is used, the router must mention all routes that it 723 learns from the backbone, with metrics of 16. If the system is 724 large, this can result in a large update message, almost all of whose 725 entries indicate unreachable networks. 727 In a static sense, advertising reverse routes with a metric of 16 728 provides no additional information. If there are many routers on one 729 broadcast network, these extra entries can use significant bandwidth. 730 The reason they are there is to improve dynamic behavior. When 731 topology changes, mentioning routes that should not go through the 732 router as well as those that should can speed up convergence. 733 However, in some situations, network managers may prefer to accept 734 somewhat slower convergence in order to minimize routing overhead. 735 Thus implementors may at their option implement simple split horizon 736 rather than split horizon with poisoned reverse, or they may provide 737 a configuration option that allows the network manager to choose 738 which behavior to use. It is also permissible to implement hybrid 739 schemes that advertise some reverse routes with a metric of 16 and 740 omit others. An example of such a scheme would be to use a metric of 741 16 for reverse routes for a certain period of time after routing 742 changes involving them, and thereafter omitting them from updates. 744 The router requirements RFC[11] specifies that all implementation of 745 RIP must use split horizon and should also use split horizon with 746 poisoned reverse, although there may be a knob to disable poisoned 747 reverse. 749 3.4.4 Triggered updates 751 Split horizon with poisoned reverse will prevent any routing loops 752 that involve only two routers. However, it is still possible to end 753 up with patterns in which three routers are engaged in mutual 754 deception. For example, A may believe it has a route through B, B 755 through C, and C through A. Split horizon cannot stop such a loop. 756 This loop will only be resolved when the metric reaches infinity and 757 the network involved is then declared unreachable. Triggered updates 758 are an attempt to speed up this convergence. To get triggered 759 updates, we simply add a rule that whenever a router changes the 760 metric for a route, it is required to send update messages almost 761 immediately, even if it is not yet time for one of the regular update 762 message. (The timing details will differ from protocol to protocol. 763 Some distance vector protocols, including RIP, specify a small time 764 delay, in order to avoid having triggered updates generate excessive 765 network traffic.) Note how this combines with the rules for 766 computing new metrics. Suppose a router's route to destination N 767 goes through router G. If an update arrives from G itself, the 768 receiving router is required to believe the new information, whether 769 the new metric is higher or lower than the old one. If the result is 770 a change in metric, then the receiving router will send triggered 771 updates to all the hosts and routers directly connected to it. They 772 in turn may each send updates to their neighbors. The result is a 773 cascade of triggered updates. It is easy to show which routers and 774 hosts are involved in the cascade. Suppose a router G times out a 775 route to destination N. G will send triggered updates to all of its 776 neighbors. However, the only neighbors who will believe the new 777 information are those whose routes for N go through G. The other 778 routers and hosts will see this as information about a new route that 779 is worse than the one they are already using, and ignore it. The 780 neighbors whose routes go through G will update their metrics and 781 send triggered updates to all of their neighbors. Again, only those 782 neighbors whose routes go through them will pay attention. Thus, the 783 triggered updates will propagate backwards along all paths leading to 784 router G, updating the metrics to infinity. This propagation will 785 stop as soon as it reaches a portion of the network whose route to 786 destination N takes some other path. 788 If the system could be made to sit still while the cascade of 789 triggered updates happens, it would be possible to prove that 790 counting to infinity will never happen. Bad routes would always be 791 removed immediately, and so no routing loops could form. 793 Unfortunately, things are not so nice. While the triggered updates 794 are being sent, regular updates may be happening at the same time. 795 Routers that haven't received the triggered update yet will still be 796 sending out information based on the route that no longer exists. It 797 is possible that after the triggered update has gone through a 798 router, it might receive a normal update from one of these routers 799 that hasn't yet gotten the word. This could reestablish an orphaned 800 remnant of the faulty route. If triggered updates happen quickly 801 enough, this is very unlikely. However, counting to infinity is 802 still possible. 804 The router requirements RFC[11] specifies that all implementation of 805 RIP must implement triggered update for deleted routes and may 806 implement triggered updates for new routes or change of routes. RIP 807 implementations must also limit the rate which of triggered updates 808 may be trandmitted. (see section 3.10.1) 810 3.5 Protocol Specification 812 RIP is intended to allow routers to exchange information for 813 computing routes through an IPv4-based network. Any router that uses 814 RIP is assumed to have interfaces to one or more networks, otherwise 815 it isn't really a router. These are referred to as its directly- 816 connected networks. The protocol relies on access to certain 817 information about each of these networks, the most important of which 818 is its metric. The RIP metric of a network is an integer between 1 819 and 15, inclusive. It is set in some manner not specified in this 820 protocol; however, given the maximum path limit of 15, a value of 1 821 is usually used. Implementations should allow the system 822 administrator to set the metric of each network. In addition to the 823 metric, each network will have an IPv4 destination address and subnet 824 mask associated with it. These are to be set by the system 825 administrator in a manner not specified in this protocol. 827 Any host that uses RIP is assumed to have interfaces to one or more 828 networks. These are referred to as its "directly-connected 829 networks". The protocol relies on access to certain information 830 about each of these networks. The most important is its metric or 831 "cost". The metric of a network is an integer between 1 and 15 832 inclusive. It is set in some manner not specified in this protocol. 833 Most existing implementations always use a metric of 1. New 834 implementations should allow the system administrator to set the cost 835 of each network. In addition to the cost, each network will have an 836 IPv4 network number and a subnet mask associated with it. These are 837 to be set by the system administrator in a manner not specified in 838 this protocol. 840 Note that the rules specified in section 3.7 assume that there is a 841 single subnet mask applying to each IPv4 network, and that only the 842 subnet masks for directly-connected networks are known. There may be 843 systems that use different subnet masks for different subnets within 844 a single network. There may also be instances where it is desirable 845 for a system to know the subnets masks of distant networks. Network- 846 wide distribution of routing information which contains different 847 subnet masks is permitted if all routers in the network are running 848 the extensions presented in this document. However, if all routers in 849 the network are not running these extensions distribution of routing 850 information containing different subnet masks must be limited to 851 avoid interoperability problems. See sections 3.7 and 4.3 for the 852 rules governing subnet distribution. 854 Each router that implements RIP is assumed to have a routing table. 855 This table has one entry for every destination that is reachable 856 throughout the system operating RIP. Each entry contains at least 857 the following information: 859 - The IPv4 address of the destination. 861 - A metric, which represents the total cost of getting a datagram 862 from the router to that destination. This metric is the sum of the 863 costs associated with the networks that would be traversed to get 864 to the destination. 866 - The IPv4 address of the next router along the path to the 867 destination (i.e., the next hop). If the destination is on one of 868 the directly-connected networks, this item is not needed. 870 - A flag to indicate that information about the route has changed 871 recently. This will be referred to as the "route change flag." 873 - Various timers associated with the route. See section 3.6 for more 874 details on timers. 876 The entries for the directly-connected networks are set up by the 877 router using information gathered by means not specified in this 878 protocol. The metric for a directly-connected network is set to the 879 cost of that network. As mentioned, 1 is the usual cost. In that 880 case, the RIP metric reduces to a simple hop-count. More complex 881 metrics may be used when it is desirable to show preference for some 882 networks over others (e.g., to indicate of differences in bandwidth 883 or reliability). 885 To support the extensions detailed in this document, each entry must 886 additionally contain a subnet mask. The subnet mask allows the router 887 (along with the IPv4 address of the destination) to identify the 888 different subnets within a single network as well as the subnets 889 masks of distant networks. 891 Implementors may also choose to allow the system administrator to 892 enter additional routes. These would most likely be routes to hosts 893 or networks outside the scope of the routing system. They are 894 referred to as "static routes." Entries for destinations other than 895 these initial ones are added and updated by the algorithms described 896 in the following sections. 898 In order for the protocol to provide complete information on routing, 899 every router in the AS must participate in the protocol. In cases 900 where multiple IGPs are in use, there must be at least one router 901 which can leak routing information between the protocols. 903 3.6 Message Format 905 RIP is a UDP-based protocol. Each router that uses RIP has a routing 906 process that sends and receives datagrams on UDP port number 520, the 907 RIP-1/RIP-2 port. All communications intended for another routers's 908 RIP process are sent to the RIP port. All routing update messages 909 are sent from the RIP port. Unsolicited routing update messages have 910 both the source and destination port equal to the RIP port. Update 911 messages sent in response to a request are sent to the port from 912 which the request came. Specific queries may be sent from ports 913 other than the RIP port, but they must be directed to the RIP port on 914 the target machine. 916 The RIP packet format is: 918 0 1 2 3 919 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 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | command (1) | version (1) | must be zero (2) | 922 +---------------+---------------+-------------------------------+ 923 | | 924 ~ RIP Entry (20) ~ 925 | | 926 +---------------+---------------+---------------+---------------+ 928 There may be between 1 and 25 (inclusive) RIP entries. A RIP-1 entry 929 has the following format: 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | address family identifier (2) | must be zero (2) | 935 +-------------------------------+-------------------------------+ 936 | IPv4 address (4) | 937 +---------------------------------------------------------------+ 938 | must be zero (4) | 939 +---------------------------------------------------------------+ 940 | must be zero (4) | 941 +---------------------------------------------------------------+ 942 | metric (4) | 943 +---------------------------------------------------------------+ 945 Field sizes are given in octets. Unless otherwise specified, fields 946 contain binary integers, in network byte order, with the most- 947 significant octet first (big-endian). Each tick mark represents one 948 bit. 950 Every message contains a RIP header which consists of a command and a 951 version number. This section of the document describes version 1 of 952 the protocol; section 4 describes the version 2 extensions. The 953 command field is used to specify the purpose of this message. The 954 commands implemented in version 1 and 2 are: 956 1 - request A request for the responding system to send all or 957 part of its routing table. 959 2 - response A message containing all or part of the sender's 960 routing table. This message may be sent in response 961 to a request, or it may be an unsolicited routing 962 update generated by the sender. 964 For each of these message types, in version 1, the remainder of the 965 datagram contains a list of Route Entries (RTEs). Each RTE in this 966 list contains an Address Family Identifier (AFI), destination IPv4 967 address, and the cost to reach that destination (metric). 969 The AFI is the type of address. For RIP-1, only AF_INET (2) is 970 generally supported. 972 The metric field contains a value between 1 and 15 (inclusive) which 973 specifies the current metric for the destination; or the value 16 974 (infinity), which indicates that the destination is not reachable. 976 3.7 Addressing Considerations 978 Distance vector routing can be used to describe routes to individual 979 hosts or to networks. The RIP protocol allows either of these 980 possibilities. The destinations appearing in request and response 981 messages can be networks, hosts, or a special code used to indicate a 982 default address. In general, the kinds of routes actually used will 983 depend upon the routing strategy used for the particular network. 984 Many networks are set up so that routing information for individual 985 hosts is not needed. If every node on a given network or subnet is 986 accessible through the same routers, then there is no reason to 987 mention individual hosts in the routing tables. However, networks 988 that include point-to-point lines sometimes require routers to keep 989 track of routes to certain nodes. Whether this feature is required 990 depends upon the addressing and routing approach used in the system. 991 Thus, some implementations may choose not to support host routes. If 992 host routes are not supported, they are to be dropped when they are 993 received in response messages (see section 3.7.2). 995 The RIP-1 packet format does not distinguish among various types of 996 address. Fields that are labeled "address" can contain any of the 997 following: 999 host address subnet number network number zero (default route) 1001 Entities which use RIP-1 are assumed to use the most specific 1002 information available when routing a datagram. That is, when routing 1003 a datagram, its destination address must first be checked against the 1004 list of node addresses. Then it must be checked to see whether it 1005 matches any known subnet or network number. Finally, if none of 1006 these match, the default route is used. 1008 When a node evaluates information that it receives via RIP-1, its 1009 interpretation of an address depends upon whether it knows the subnet 1010 mask that applies to the net. If so, then it is possible to 1011 determine the meaning of the address. For example, consider net 1012 128.6. It has a subnet mask of 255.255.255.0. Thus 128.6.0.0 is a 1013 network number, 128.6.4.0 is a subnet number, and 128.6.4.1 is a node 1014 address. However, if the node does not know the subnet mask, 1015 evaluation of an address may be ambiguous. If there is a non-zero 1016 node part, there is no clear way to determine whether the address 1017 represents a subnet number or a node address. As a subnet number 1018 would be useless without the subnet mask, addresses are assumed to 1019 represent nodes in this situation. In order to avoid this sort of 1020 ambiguity, when using version 1, nodes must not send subnet routes to 1021 nodes that cannot be expected to know the appropriate subnet mask. 1022 Normally hosts only know the subnet masks for directly-connected 1023 networks. Therefore, unless special provisions have been made, 1024 routes to a subnet must not be sent outside the network of which the 1025 subnet is a part. RIP-2 (see section 4) eliminates the subnet/host 1026 ambiguity by including the subnet mask in the routing entry. 1028 This "subnet filtering" is carried out by the routers at the "border" 1029 of the subnetted network. These are routers which connect that 1030 network with some other network. Within the subnetted network, each 1031 subnet is treated as an individual network. Routing entries for each 1032 subnet are circulated by RIP. However, border routers send only a 1033 single entry for the network as a whole to nodes in other networks. 1034 This means that a border router will send different information to 1035 different neighbors. For neighbors connected to the subnetted 1036 network, it generates a list of all subnets to which it is directly 1037 connected, using the subnet number. For neighbors connected to other 1038 networks, it makes a single entry for the network as a whole, showing 1039 the metric associated with that network. This metric would normally 1040 be the smallest metric for the subnets to which the router is 1041 attached. 1043 Similarly, border routers must not mention host routes for nodes 1044 within one of the directly-connected networks in messages to other 1045 networks. Those routes will be subsumed by the single entry for the 1046 network as a whole. 1048 The router requirements RFC[11] specifies that all implementation of 1049 RIP should support host routes but if they do not then they must 1050 ignore any received host routes. 1052 The special address 0.0.0.0 is used to describe a default route. A 1053 default route is used when it is not convenient to list every 1054 possible network in the RIP updates, and when one or more closely- 1055 connected routers in the system are prepared to handle traffic to the 1056 networks that are not listed explicitly. These routers should create 1057 RIP entries for the address 0.0.0.0, just as if it were a network to 1058 which they are connected. The decision as to how routers create 1059 entries for 0.0.0.0 is left to the implementor. Most commonly, the 1060 system administrator will be provided with a way to specify which 1061 routers should create entries for 0.0.0.0; however, other mechanisms 1062 are possible. For example, an implementor might decide that any 1063 router which speaks BGP should be declared to be a default router. 1064 It may be useful to allow the network administrator to choose the 1065 metric to be used in these entries. If there is more than one 1066 default router, this will make it possible to express a preference 1067 for one over the other. The entries for 0.0.0.0 are handled by RIP 1068 in exactly the same manner as if there were an actual network with 1069 this address. System administrators should take care to make sure 1070 that routes to 0.0.0.0 do not propagate further than is intended. 1071 Generally, each autonomous system has its own preferred default 1072 router. Thus, routes involving 0.0.0.0 should generally not leave 1073 the boundary of an autonomous system. The mechanisms for enforcing 1074 this are not specified in this document. 1076 3.8 Timers 1078 This section describes all events that are triggered by timers. 1080 Every 30 seconds, the RIP process is awakened to send an unsolicited 1081 Response message containing the complete routing table (see section 1082 3.9 on Split Horizon) to every neighboring router. When there are 1083 many routers on a single network, there is a tendency for them to 1084 synchronize with each other such that they all issue updates at the 1085 same time. This can happen whenever the 30 second timer is affected 1086 by the processing load on the system. It is undesirable for the 1087 update messages to become synchronized, since it can lead to 1088 unnecessary collisions on broadcast networks. Therefore, 1089 implementations are required to take one of two precautions: 1091 - The 30-second updates are triggered by a clock whose rate is not 1092 affected by system load or the time required to service the 1093 previous update timer. 1095 - The 30-second timer is offset by a small random time (+/- 0 to 5 1096 seconds) each time it is set. (Implementors may wish to consider 1097 even larger variation in the light of recent research results [10]) 1099 There are two timers associated with each route, a "timeout" and a 1100 "garbage-collection" time. Upon expiration of the timeout, the route 1101 is no longer valid; however, it is retained in the routing table for 1102 a short time so that neighbors can be notified that the route has 1103 been dropped. Upon expiration of the garbage-collection timer, the 1104 route is finally removed from the routing table. 1106 The timeout is initialized when a route is established, and any time 1107 an update message is received for the route. If 180 seconds elapse 1108 from the last time the timeout was initialized, the route is 1109 considered to have expired, and the deletion process described below 1110 begins for that route. 1112 Deletions can occur for one of two reasons: the timeout expires, or 1113 the metric is set to 16 because of an update received from the 1114 current router (see section 3.7.2 for a discussion of processing 1115 updates from other routers). In either case, the following events 1116 happen: 1118 - The garbage-collection timer is set for 120 seconds. 1120 - The metric for the route is set to 16 (infinity). This causes the 1121 route to be removed from service. 1123 - The route change flag is set to indicate that this entry has been 1124 changed. 1126 - The output process is signalled to trigger a response. 1128 Until the garbage-collection timer expires, the route is included in 1129 all updates sent by this router. When the garbage-collection timer 1130 expires, the route is deleted from the routing table. 1132 Should a new route to this network be established while the garbage- 1133 collection timer is running, the new route will replace the one that 1134 is about to be deleted. In this case the garbage-collection timer 1135 must be cleared. 1137 Triggered updates also use a small timer; however, this is best 1138 described in section 3.9.1. 1140 3.9 Input Processing 1142 This section will describe the handling of datagrams received on the 1143 RIP port. Processing will depend upon the value in the command 1144 field. 1146 See sections 4.6 and 5.1 for details on handling version numbers. 1148 3.9.1 Request Messages 1150 A Request is used to ask for a response containing all or part of a 1151 router's routing table. Normally, Requests are sent as broadcasts 1152 (multicasts for RIP-2), from the RIP port, by routers which have just 1153 come up and are seeking to fill in their routing tables as quickly as 1154 possible. However, there may be situations (e.g., router monitoring) 1155 where the routing table of only a single router is needed. In this 1156 case, the Request should be sent directly to that router from a UDP 1157 port other than the RIP port. If such a Request is received, the 1158 router responds directly to the requestor's address and port. 1160 The Request is processed entry by entry. If there are no entries, no 1161 response is given. There is one special case. If there is exactly 1162 one entry in the request, and it has an address family identifier of 1163 zero and a metric of infinity (i.e., 16), then this is a request to 1164 send the entire routing table. In that case, a call is made to the 1165 output process to send the routing table to the requesting 1166 address/port. Except for this special case, processing is quite 1167 simple. Examine the list of RTEs in the Request one by one. For 1168 each entry, look up the destination in the router's routing database 1169 and, if there is a route, put that route's metric in the metric field 1170 of the RTE. If there is no explicit route to the specified 1171 destination, put infinity in the metric field. Once all the entries 1172 have been filled in, change the command from Request to Response and 1173 send the datagram back to the requestor. 1175 Note that there is a difference in metric handling for specific and 1176 whole-table requests. If the request is for a complete routing 1177 table, normal output processing is done, including Split Horizon (see 1178 section 3.9 on Split Horizon). If the request is for specific 1179 entries, they are looked up in the routing table and the information 1180 is returned as is; no Split Horizon processing is done. The reason 1181 for this distinction is the expectation that these requests are 1182 likely to be used for different purposes. When a router first comes 1183 up, it multicasts a Request on every connected network asking for a 1184 complete routing table. It is assumed that these complete routing 1185 tables are to be used to update the requestor's routing table. For 1186 this reason, Split Horizon must be done. It is further assumed that 1187 a Request for specific networks is made only by diagnostic software, 1188 and is not used for routing. In this case, the requester would want 1189 to know the exact contents of the routing table and would not want 1190 any information hidden or modified. 1192 3.9.2 Response Messages 1194 A Response can be received for one of several different reasons: 1196 - response to a specific query 1197 - regular update (unsolicited response) 1198 - triggered update caused by a route change 1200 Processing is the same no matter why the Response was generated. 1202 Because processing of a Response may update the router's routing 1203 table, the Response must be checked carefully for validity. The 1204 Response must be ignored if it is not from the RIP port. The 1205 datagram's IPv4 source address should be checked to see whether the 1206 datagram is from a valid neighbor; the source of the datagram must be 1207 on a directly-connected network. It is also worth checking to see 1208 whether the response is from one of the router's own addresses. 1209 Interfaces on broadcast networks may receive copies of their own 1210 broadcasts/multicasts immediately. If a router processes its own 1211 output as new input, confusion is likely so such datagrams must be 1212 ignored. 1214 Once the datagram as a whole has been validated, process the RTEs in 1215 the Response one by one. Again, start by doing validation. 1216 Incorrect metrics and other format errors usually indicate 1217 misbehaving neighbors and should probably be brought to the 1218 administrator's attention. For example, if the metric is greater 1219 than infinity, ignore the entry but log the event. The basic 1220 validation tests are: 1222 - is the destination address valid (e.g., unicast; not net 0 or 127) 1223 - is the metric valid (i.e., between 1 and 16, inclusive) 1225 If any check fails, ignore that entry and proceed to the next. 1226 Again, logging the error is probably a good idea. 1228 Once the entry has been validated, update the metric by adding the 1229 cost of the network on which the message arrived. If the result is 1230 greater than infinity, use infinity. That is, 1232 metric = MIN (metric + cost, infinity) 1234 Now, check to see whether there is already an explicit route for the 1235 destination address. If there is no such route, add this route to 1236 the routing table, unless the metric is infinity (there is no point 1237 in adding a route which is unusable). Adding a route to the routing 1238 table consists of: 1240 - Setting the destination address to the destination address in the 1241 RTE 1243 - Setting the metric to the newly calculated metric (as described 1244 above) 1246 - Set the next hop address to be the address of the router from which 1247 the datagram came 1249 - Initialize the timeout for the route. If the garbage-collection 1250 timer is running for this route, stop it (see section 3.6 for a 1251 discussion of the timers) 1253 - Set the route change flag 1255 - Signal the output process to trigger an update (see section 3.8.1) 1257 If there is an existing route, compare the next hop address to the 1258 address of the router from which the datagram came. If this datagram 1259 is from the same router as the existing route, reinitialize the 1260 timeout. Next, compare the metrics. If the datagram is from the 1261 same router as the existing route, and the new metric is different 1262 than the old one; or, if the new metric is lower than the old one; do 1263 the following actions: 1265 - Adopt the route from the datagram (i.e., put the new metric in and 1266 adjust the next hop address, if necessary). 1268 - Set the route change flag and signal the output process to trigger 1269 an update 1271 - If the new metric is infinity, start the deletion process 1272 (described above); otherwise, re-initialize the timeout 1274 If the new metric is infinity, the deletion process begins for the 1275 route, which is no longer used for routing packets. Note that the 1276 deletion process is started only when the metric is first set to 1277 infinity. If the metric was already infinity, then a new deletion 1278 process is not started. 1280 If the new metric is the same as the old one, it is simplest to do 1281 nothing further (beyond re-initializing the timeout, as specified 1282 above); but, there is a heuristic which could be applied. Normally, 1283 it is senseless to replace a route if the new route has the same 1284 metric as the existing route; this would cause the route to bounce 1285 back and forth, which would generate an intolerable number of 1286 triggered updates. However, if the existing route is showing signs 1287 of timing out, it may be better to switch to an equally-good 1288 alternative route immediately, rather than waiting for the timeout to 1289 happen. Therefore, if the new metric is the same as the old one, 1290 examine the timeout for the existing route. If it is at least 1291 halfway to the expiration point, switch to the new route. This 1292 heuristic is optional, but highly recommended. 1294 Any entry that fails these tests is ignored, as it is no better than 1295 the current route. 1297 3.10 Output Processing 1298 This section describes the processing used to create response 1299 messages that contain all or part of the routing table. This 1300 processing may be triggered in any of the following ways: 1302 - By input processing, when a Request is received (this Response is 1303 unicast to the requestor; see section 3.7.1) 1305 - By the regular routing update (broadcast/multicast every 30 1306 seconds) router. 1308 - By triggered updates (broadcast/multicast when a route changes) 1310 When a Response is to be sent to all neighbors (i.e., a regular or 1311 triggered update), a Response message is directed to the router at 1312 the far end of each connected point-to-point link, and is broadcast 1313 (multicast for RIP-2) on all connected networks which support 1314 broadcasting. Thus, one Response is prepared for each directly- 1315 connected network, and sent to the appropriate address (direct or 1316 broadcast/multicast). In most cases, this reaches all neighboring 1317 routers. However, there are some cases where this may not be good 1318 enough. This may involve a network that is not a broadcast network 1319 (e.g., the ARPANET), or a situation involving dumb routers. In such 1320 cases, it may be necessary to specify an actual list of neighboring 1321 routers and send a datagram to each one explicitly. It is left to 1322 the implementor to determine whether such a mechanism is needed, and 1323 to define how the list is specified. 1325 3.10.1 Triggered Updates 1327 Triggered updates require special handling for two reasons. First, 1328 experience shows that triggered updates can cause excessive load on 1329 networks with limited capacity or networks with many routers on them. 1330 Therefore, the protocol requires that implementors include provisions 1331 to limit the frequency of triggered updates. After a triggered 1332 update is sent, a timer should be set for a random interval between 1 1333 and 5 seconds. If other changes that would trigger updates occur 1334 before the timer expires, a single update is triggered when the timer 1335 expires. The timer is then reset to another random value between 1 1336 and 5 seconds. A triggered update should be suppressed if a regular 1337 update is due by the time the triggered update would be sent. 1339 Second, triggered updates do not need to include the entire routing 1340 table. In principle, only those routes which have changed need to be 1341 included. Therefore, messages generated as part of a triggered 1342 update must include at least those routes that have their route 1343 change flag set. They may include additional routes, at the 1344 discretion of the implementor; however, sending complete routing 1345 updates is strongly discouraged. When a triggered update is 1346 processed, messages should be generated for every directly-connected 1347 network. Split Horizon processing is done when generating triggered 1348 updates as well as normal updates (see section 3.9). If, after Split 1349 Horizon processing for a given network, a changed route will appear 1350 unchanged on that network (e.g., it appears with an infinite metric), 1351 the route need not be sent. If no routes need be sent on that 1352 network, the update may be omitted. Once all of the triggered 1353 updates have been generated, the route change flags should be 1354 cleared. 1356 If input processing is allowed while output is being generated, 1357 appropriate interlocking must be done. The route change flags should 1358 not be changed as a result of processing input while a triggered 1359 update message is being generated. 1361 The only difference between a triggered update and other update 1362 messages is the possible omission of routes that have not changed. 1363 The remaining mechanisms, described in the next section, must be 1364 applied to all updates. 1366 3.10.2 Generating Response Messages 1368 This section describes how a Response message is generated for a 1369 particular directly-connected network: 1371 Set the version number to either 1 or 2. The mechanism for deciding 1372 which version to send is implementation specific; however, if this is 1373 the Response to a Request, the Response version should match the 1374 Request version. Set the command to Response. Set the bytes labeled 1375 "must be zero" to zero. Start filling in RTEs. Recall that there is 1376 a limit of 25 RTEs to a Response; if there are more, send the current 1377 Response and start a new one. There is no defined limit to the 1378 number of datagrams which make up a Response. 1380 To fill in the RTEs, examine each route in the routing table. If a 1381 triggered update is being generated, only entries whose route change 1382 flags are set need be included. If, after Split Horizon processing, 1383 the route should not be included, skip it. If the route is to be 1384 included, then the destination address and metric are put into the 1385 RTE. Routes must be included in the datagram even if their metrics 1386 are infinite. 1388 4. Protocol Extensions 1390 This section does not change the RIP protocol per se. Rather, it 1391 provides extensions to the message format which allows routers to 1392 share important additional information. 1394 The same header format is used for RIP-1 and RIP-2 messages (see 1395 section 3.4). The format for the 20-octet route entry (RTE) for 1396 RIP-2 is: 1398 0 1 2 3 3 1399 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 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 | Address Family Identifier (2) | Route Tag (2) | 1402 +-------------------------------+-------------------------------+ 1403 | IP Address (4) | 1404 +---------------------------------------------------------------+ 1405 | Subnet Mask (4) | 1406 +---------------------------------------------------------------+ 1407 | Next Hop (4) | 1408 +---------------------------------------------------------------+ 1409 | Metric (4) | 1410 +---------------------------------------------------------------+ 1412 The Address Family Identifier, IP Address, and Metric all have the 1413 meanings defined in section 3.4. The Version field will specify 1414 version number 2 for RIP messages which use authentication or carry 1415 information in any of the newly defined fields. 1417 4.1 Authentication 1419 Since authentication is a per message function, and since there is 1420 only one 2-octet field available in the message header, and since any 1421 reasonable authentication scheme will require more than two octets, 1422 the authentication scheme for RIP version 2 will use the space of an 1423 entire RIP entry. If the Address Family Identifier of the first (and 1424 only the first) entry in the message is 0xFFFF, then the remainder of 1425 the entry contains the authentication. This means that there can be, 1426 at most, 24 RIP entries in the remainder of the message. If 1427 authentication is not in use, then no entries in the message should 1428 have an Address Family Identifier of 0xFFFF. A RIP message which 1429 contains an authentication entry would begin with the following 1430 format: 1432 0 1 2 3 3 1433 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 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | Command (1) | Version (1) | unused | 1436 +---------------+---------------+-------------------------------+ 1437 | 0xFFFF | Authentication Type (2) | 1438 +-------------------------------+-------------------------------+ 1439 ~ Authentication (16) ~ 1440 +---------------------------------------------------------------+ 1441 Currently, the only Authentication Type is simple password and it 1442 is type 2. The remaining 16 octets contain the plain text password. If 1443 the password is under 16 octets, it must be left-justified and 1444 padded to the right with nulls (0x00). 1446 4.2 Route Tag 1448 The Route Tag (RT) field is an attribute assigned to a route which 1449 must be preserved and readvertised with a route. The intended use 1450 of the Route Tag is to provide a method of separating "internal" 1451 RIP routes (routes for networks within the RIP routing domain) 1452 from "external" RIP routes, which may have been imported from an 1453 EGP or another IGP. 1455 Routers supporting protocols other than RIP should be configurable 1456 to allow the Route Tag to be configured for routes imported from 1457 different sources. For example, routes imported from EGP or BGP 1458 should be able to have their Route Tag either set to an arbitrary 1459 value, or at least to the number of the Autonomous System from 1460 which the routes were learned. 1462 Other uses of the Route Tag are valid, as long as all routers in 1463 the RIP domain use it consistently. This allows for the 1464 possibility of a BGP-RIP protocol interactions document, which 1465 would describe methods for synchronizing routing in a transit 1466 network. 1468 4.3 Subnet mask 1470 The Subnet Mask field contains the subnet mask which is applied to 1471 the IP address to yield the non-host portion of the address. If this 1472 field is zero, then no subnet mask has been included for this entry. 1474 On an interface where a RIP-1 router may hear and operate on the 1475 information in a RIP-2 routing entry the following rules apply: 1477 1) information internal to one network must never be advertised into 1478 another network, 1480 2) information about a more specific subnet may not be advertised 1481 where RIP-1 routers would consider it a host route, and 1483 3) supernet routes (routes with a netmask less specific than 1484 the "natural" network mask) must not be advertised where they 1485 could be misinterpreted by RIP-1 routers. 1487 4.4 Next Hop 1488 The immediate next hop IP address to which packets to the destination 1489 specified by this route entry should be forwarded. Specifying a 1490 value of 0.0.0.0 in this field indicates that routing should be via 1491 the originator of the RIP advertisement. An address specified as 1492 a next hop must, per force, be directly reachable on the logical 1493 subnet over which the advertisement is made. 1495 The purpose of the Next Hop field is to eliminate packets being routed 1496 through extra hops in the system. It is particularly useful when RIP 1497 is not being run on all of the routers on a network. A simple example 1498 is given in Appendix A. Note that Next Hop is an "advisory" field. That 1499 is, if the provided information is ignored, a possibly sub-optimal, 1500 but absolutely valid, route may be taken. If the received Next Hop 1501 is not directly reachable, it should be treated as 0.0.0.0. 1503 4.5 Multicasting 1505 In order to reduce unnecessary load on those hosts which are not 1506 listening to RIP-2 messages, an IP multicast address will be used for 1507 periodic broadcasts. The IP multicast address is 224.0.0.9. Note that 1508 IGMP is not needed since these are inter-router messages which are not 1509 forwarded. 1511 On NBMA networks, unicast addressing may be used. However, if a 1512 response addressed to the RIP-2 multicast address is received, it 1513 should be accepted. 1515 In order to maintain backwards compatibility, the use of the 1516 multicast address will be configurable, as described in section 5.1. If 1517 multicasting is used, it should be used on all interfaces which support 1518 it. 1520 4.6 Queries 1522 If a RIP-2 router receives a RIP-1 Request, it should respond with a 1523 RIP-1 Response. If the router is configured to send only RIP-2 1524 messages, it should not respond to a RIP-1 Request. 1526 5. Compatibility 1528 RFC [1] showed considerable forethought in its specification of 1529 the handling of version numbers. It specifies that RIP messages of 1530 version 0 are to be discarded, that RIP messages of version 1 are 1531 to be discarded if any Must Be Zero (MBZ) field is non-zero, and that 1532 RIP messages of any version greater than 1 should not be discarded 1533 simply because an MBZ field contains a value other than zero. This 1534 means that the new version of RIP is totally backwards compatible 1535 with existing RIP implementations which adhere to this part of the 1536 specification. 1538 5.1 Compatibility Switch 1540 A compatibility switch is necessary for two reasons. First, there 1541 are implementations of RIP-1 in the field which do not follow RFC 1542 [1] as described above. Second, the use of multicasting would 1543 prevent RIP-1 systems from receiving RIP-2 updates (which may 1544 be a desired feature in some cases). This switch should be configurable 1545 on a per-interface basis. 1547 The switch has four settings: RIP-1, in which only RIP-1 messages are 1548 sent; RIP-1 compatibility, in which RIP-2 messages are broadcast; 1549 RIP-2, in which RIP-2 messages are multicast; and "none", which 1550 disables the sending of RIP messages. It is recommended that the 1551 default setting be either RIP-1 or RIP-2, but not RIP-1 compatibility. 1552 This is because of the potential problems which can occur on some 1553 topologies. RIP-1 compatibility should only be used when all of the 1554 consequences of its use are well understood by the network administrator. 1556 For completeness, routers should also implement a receive control 1557 switch which would determine whether to accept, RIP-1 only, RIP-2 1558 only, both, or none. It should also be configurable on a 1559 per-interface basis. It is recommended that the default be compatible 1560 with the default chosen for sending updates. 1562 5.2 Authentication 1564 The following algorithm should be used to authenticate a RIP message. If 1565 the router is not configured to authenticate RIP-2 messages, then RIP-1 1566 and unauthenticated RIP-2 messages will be accepted; authenticated 1567 RIP-2 messages shall be discarded. If the router is configured to 1568 authenticate RIP-2 messages, then RIP-1 messages and RIP-2 messages 1569 which pass authentication testing shall be accepted; unauthenticated 1570 and failed authentication RIP-2 messages shall be discarded. For 1571 maximum security, RIP-1 messages should be ignored when authentication 1572 is in use (see section 4.1); otherwise, the routing information from 1573 authenticated messages will be propagated by RIP-1 routers in an 1574 unauthenticated manner. 1576 Since an authentication entry is marked with an Address Family 1577 Identifier of 0xFFFF, a RIP-1 system would ignore this entry since 1578 it would belong to an address family other than IP. It should 1579 be noted, therefore, that use of authentication will not prevent 1580 RIP-1 systems from seeing RIP-2 messages. If desired, this may 1581 be done using multicasting, as described in sections 4.5 and 5.1. 1583 5.3 Larger Infinity 1585 While on the subject of compatibility, there is one item which people 1586 have requested: increasing infinity. The primary reason that this 1587 cannot be done is that it would violate backwards compatibility. A 1588 larger infinity would obviously confuse older versions of rip. At 1589 best, they would ignore the route as they would ignore a metric of 1590 16. There was also a proposal to make the Metric a single octet and reuse 1591 the high three octets, but this would break any implementations which 1592 treat the metric as a 4-octet entity. 1594 5.4 Addressless Links 1596 As in RIP-1, addressless links will not be supported by RIP-2. 1598 6. Security Considerations 1600 The basic RIP protocol is not a secure protocol. To bring RIP-2 1601 in line with more modern routing protocols, an extensible authentication 1602 mechanism has been incorporated into the protocol enhancements. This 1603 mechanism is described in sections 4.1 and 5.2. Security is further 1604 enhanced by the mechanism described in [3]. 1606 Appendix A 1608 This is a simple example of the use of the next hop field in a rip entry. 1610 ----- ----- ----- ----- ----- ----- 1611 |IR1| |IR2| |IR3| |XR1| |XR2| |XR3| 1612 --+-- --+-- --+-- --+-- --+-- --+-- 1613 | | | | | | 1614 --+-------+-------+---------------+-------+-------+-- 1615 <-------------RIP-2-------------> 1617 Assume that IR1, IR2, and IR3 are all "internal" routers which are 1618 under one administration (e.g. a campus) which has elected to use 1619 RIP-2 as its IGP. XR1, XR2, and XR3, on the other hand, are under 1620 separate administration (e.g. a regional network, of which the campus 1621 is a member) and are using some other routing protocol (e.g. OSPF). 1622 XR1, XR2, and XR3 exchange routing information among themselves such 1623 that they know that the best routes to networks N1 and N2 are via 1624 XR1, to N3, N4, and N5 are via XR2, and to N6 and N7 are via XR3. By 1625 setting the Next Hop field correctly (to XR2 for N3/N4/N5, to XR3 for 1626 N6/N7), only XR1 need exchange RIP-2 routes with IR1/IR2/IR3 for 1627 routing to occur without additional hops through XR1. Without the 1628 Next Hop (for example, if RIP-1 were used) it would be necessary for 1629 XR2 and XR3 to also participate in the RIP-2 protocol to eliminate 1630 extra hops. 1632 References 1634 [1] Hedrick, C., Routing Information Protocol, Request For Comments 1635 (RFC) 1058, Rutgers University, June 1988. 1637 [2] Malkin, G., and F. Baker, RIP Version 2 MIB Extension, Request 1638 For Comments (RFC) 1389, Xylogics, Inc., Advanced Computer 1639 Communications, January 1993. 1641 [3] Baker, F., Atkinson, R., "RIP-II MD5 Authentication", draft-ietf- 1642 ripv2-md5-auth-00.txt, March 1997. 1644 [4] Bellman, R. E., "Dynamic Programming", Princeton University 1645 Press, Princeton, N.J., 1957. 1647 [5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", Prentice- 1648 Hall, Englewood Cliffs, N.J., 1987. 1650 [6] Braden, R., and Postel, J., "Requirements for Internet Gateways", 1651 USC/Information Sciences Institute, RFC-1009, June 1987. 1653 [7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M., 1654 "Pup: An Internetwork Architecture", IEEE Transactions on 1655 Communications, April 1980. 1657 [8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks", 1658 Princeton University Press, Princeton, N.J., 1962. 1660 [9] Xerox Corp., "Internet Transport Protocols", Xerox System 1661 Integration Standard XSIS 028112, December 1981. 1663 [10] Floyd, S., and V. Jacobson, "The synchronization of Periodic 1664 Routing Messages," ACM Sigcom '93 symposium, September 1993. 1666 [11] Baker, F., "Requirements for IP Version 4 Routers." RFC 1812, 1667 June 1995, section 2.2.5 1669 Author's Address 1671 Gary Scott Malkin 1672 Bay Networks 1673 8 Federal Street 1674 Billerica, MA 01821 1676 Phone: (978) 916-4237 1677 EMail: gmalkin@baynetworks.com