RFC 2453
RIP Version 2
RFC 2453: RIP Version 2 🦋✨
okay bestie, this is the RIP-2 spec, and it's giving "the upgrade that was overdue" 💅
Author: G. Malkin, Bay Networks 🌸 Date: November 1998 🗓️ Category: Standards Track 👑 STD: 56 Obsoletes: RFC 1723 and RFC 1388 (the old versions get retired, so RIP-2 is the new official one) 💀
Status of this Memo 📜
ok so this doc is an Internet standards track protocol 🎀 for the whole Internet community, and it's literally asking for discussion and suggestions for improvements 🫶. If you want to know where this protocol actually stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔥. And distribution of this memo is unlimited, so share away 🌈.
Copyright Notice ⭐
Copyright (C) The Internet Society (1998). All Rights Reserved. 💜
Abstract ✨
this document extends the Routing Information Protocol (RIP), as defined in [1] 🧚. The whole point is to fit more useful info into RIP messages AND to add a little security 🔐, which is so overdue, periodt 💅.
there are two companion docs on the way too: one will define the SNMP MIB objects for RIP-2 [2] 🍓, and another will cover cryptographic security improvements for RIP-2 [3] 🔐. so it's a whole squad 😭.
Acknowledgements 🫶
I (the author) want to shout out the IETF RIP Working Group for helping make RIP-2 happen 🎀. A big chunk of the background stuff about distance vector protocols, plus some of the explanations of how RIP operates, came from "Routing Information Protocol" by C. Hedrick [1] 📚. And Scott Bradner did a lot of the final editing 💖.
Table of Contents 🗂️
1. Justification . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Limitations of the Protocol . . . . . . . . . . . . . . . . 5
3.3. Organization of this document . . . . . . . . . . . . . . . 6
3.4 Distance Vector Algorithms . . . . . . . . . . . . . . . . . 6
3.4.1 Dealing with changes in topology . . . . . . . . . . . . 12
3.4.2 Preventing instability . . . . . . . . . . . . . . . . . 13
3.4.3 Split horizon . . . . . . . . . . . . . . . . . . . . . . 15
3.4.4 Triggered updates . . . . . . . . . . . . . . . . . . . . 17
3.5 Protocol Specification . . . . . . . . . . . . . . . . . . 18
3.6 Message Format . . . . . . . . . . . . . . . . . . . . . . . 20
3.7 Addressing Considerations . . . . . . . . . . . . . . . . . 22
3.8 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.9 Input Processing . . . . . . . . . . . . . . . . . . . . . . 25
3.9.1 Request Messages . . . . . . . . . . . . . . . . . . . . 25
3.9.2 Response Messages . . . . . . . . . . . . . . . . . . . . 26
3.10 Output Processing . . . . . . . . . . . . . . . . . . . . . 28
3.10.1 Triggered Updates . . . . . . . . . . . . . . . . . . . . 29
3.10.2 Generating Response Messages. . . . . . . . . . . . . . . 30
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 31
4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1 Compatibility Switch . . . . . . . . . . . . . . . . . . . . 34
5.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Larger Infinity . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Addressless Links . . . . . . . . . . . . . . . . . . . . . 35
6. Interaction between version 1 and version 2 . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 38
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 391. Justification 🤔
ok so with OSPF and IS-IS on the scene, some people think RIP is obsolete 💀. And yes, the newer IGP routing protocols are way superior to RIP 👑. BUT RIP still has some perks 🌸. Mainly, in a small network, RIP has super low overhead in terms of bandwidth used and configuration and management time ✨. It's also really easy to implement, especially compared to the newer IGPs 🎀.
and here's the lowkey big one: there are way, way more RIP implementations out in the field than OSPF and IS-IS combined 😭. That's probably not changing for a few years yet 🦋.
so since RIP is gonna be useful in lots of environments for a while, it makes sense to make RIP more useful 🔥. This is especially true because the gain is way bigger than the cost of making the change 💖.
2. Current RIP 🕰️
the current RIP-1 message has the bare minimum info routers need to route messages through a network 🦋. It also has a ton of unused space, because of where it came from 🙈.
the current RIP-1 protocol doesn't consider autonomous systems, IGP/EGP interactions, subnetting [11], or authentication, since those implementations came out after RIP-1 🍓. The missing subnet masks are a seriously big problem for routers, because they need a subnet mask to figure out how to determine a route 😭. If a RIP-1 route is a network route (all the non-network bits are 0), the subnet mask equals the network mask ✨. But if some of the non-network bits are set, the router can't determine the subnet mask 💀. Even worse, the router can't tell whether the RIP-1 route is a subnet route or a host route 🙈. Right now, some routers just pick the subnet mask of the interface the route was learned on, and figure out the route type from that 🧚.
3. Basic Protocol 🎀
3.1 Introduction 🌈
RIP is a routing protocol based on the Bellman-Ford (or distance vector) algorithm 💜. This algorithm has been used for routing computations in computer networks since the early days of the ARPANET 🛸. The particular packet formats and protocol described here are based on the program "routed," which ships with the Berkeley distribution of Unix 🍓.
in an international network like the Internet, it's super unlikely that one single routing protocol will be used for the whole thing 🌍. Instead, the network is organized as a collection of Autonomous Systems (AS), and each of those is, in general, run by a single entity 👑. Each AS has its own routing technology, which can differ between AS's 🦋. The routing protocol used inside an AS is called an Interior Gateway Protocol (IGP) 🏠. A separate protocol, the Exterior Gateway Protocol (EGP), is used to pass routing info between the AS's 🌉. RIP was designed to work as an IGP in moderate-size AS's, and it is not intended for more complex environments 💅. For info on the context RIP-1 is expected to fit into, see Braden and Postel [6] 📚.
RIP uses one of a class of routing algorithms called Distance Vector algorithms 🎀. The earliest description of this class of algorithms that the author knows about is in Ford and Fulkerson [8] ✨. That's why they're sometimes called Ford-Fulkerson algorithms 🧚. The term Bellman-Ford is also used, and it comes from the fact that the formulation is based on Bellman's equation [4] 🫶. The presentation in this document is closely based on [5] 💖. This document contains a protocol specification 🔥. For an intro to the math behind routing algorithms, see [1] 📚. The basic algorithms this protocol uses were already being used in computer routing as early as 1969 in the ARPANET 🛸. But the specific ancestry of this protocol is within the Xerox network protocols 🌸. The PUP protocols [7] used the Gateway Information Protocol to exchange routing info 🦋. A somewhat updated version of that protocol was adopted for the Xerox Network Systems (XNS) architecture, under the name Routing Information Protocol [9] 🍓. Berkeley's routed is largely the same as the Routing Information Protocol, except the XNS addresses got replaced by a more general address format that can handle IPv4 and other address types, and routing updates are limited to one every 30 seconds ⏰. Because of all that similarity, the term Routing Information Protocol (or just RIP) is used to refer to both the XNS protocol and the protocol used by routed 💜.
RIP is meant for use within the IP-based Internet 🌐. The Internet is organized into a bunch of networks connected by special purpose gateways called routers 🌈. The networks can be point-to-point links or more complex networks like Ethernet or token ring 🔌. Hosts and routers are handed IP datagrams addressed to some host 📦. Routing is the method a host or router uses to decide where to send the datagram 🧭. It can send the datagram directly to the destination if that destination is on one of the networks directly connected to the host or router ✨. But the interesting case is when the destination isn't directly reachable 👀.
in that case, the host or router tries to send the datagram to a router that's nearer the destination 🚀. The goal of a routing protocol is very simple: it's supposed to supply the info needed to do routing 💖.
3.2 Limitations of the Protocol 🚧
okay real talk, this protocol doesn't solve every possible routing problem 💀. Like I said above, it's primarily meant for use as an IGP in networks of moderate size 🏠. On top of that, there are these specific limitations to be aware of:
- The protocol is limited to networks whose longest path (the network's diameter) is 15 hops 🚫. The designers believe the basic protocol design is inappropriate for larger networks 🙅. Note that this limit assumes a cost of 1 is used for each network, which is how RIP is normally configured 🎀. If the system administrator chooses to use larger costs, the upper bound of 15 can easily become a problem 😬.
- The protocol depends on "counting to infinity" to resolve certain unusual situations (this gets explained in the next section) 🔁. If the system of networks has several hundred networks, and a routing loop forms involving all of them, resolving the loop would take either a lot of time (if the frequency of routing updates were limited) or a lot of bandwidth (if updates were sent whenever changes were detected) 🥵. Such a loop would eat a huge amount of network bandwidth before it got corrected 💀. The designers believe that in realistic cases this won't be a problem except on slow lines 🐢. Even then, the problem would be pretty unusual, since various precautions are taken that should prevent these problems in most cases 🛡️.
- This protocol uses fixed "metrics" to compare alternative routes 📏. It isn't appropriate for situations where routes need to be chosen based on real-time parameters like measured delay, reliability, or load ⏱️. The obvious extensions that would allow metrics of this type are likely to introduce instabilities of a sort the protocol isn't designed to handle 🌪️.
That's the first chunk of the RIP-2 spec, bestie! 🌈💖
3.3. Organization of this document ✨
Okay so the main body of this doc is split into two parts, and they take up the next two sections 🎀
- A conceptual development and justification of distance vector algorithms in general.
- The actual protocol description.
Each of these two sections can largely stand on its own 💖 Section 3.4 tries to give an informal presentation of the mathematical underpinnings of the algorithm. Note that the presentation follows a "spiral" method 🌀 An initial, fairly simple algorithm gets described first, and then refinements get added to it in successive sections. Section 3.5 is the actual protocol description. Except where specific references are made to section 3.4, it should be possible to implement RIP entirely from the specifications given in section 3.5 🫶
3.4 Distance Vector Algorithms 🦋
Okay this is the big brain part 🧠 Routing is the task of finding a path from a sender to a desired destination. In the IP "Internet model," this basically reduces to finding a series of routers between the source and destination networks. As long as a message or datagram stays on a single network or subnet, any forwarding problems are the responsibility of technology that is specific to that network. Ethernet and the ARPANET each define a way for any sender to talk to any specified destination within that one network, for example. IP routing only comes in when messages have to go from a sender on one network to a destination on a different one 🚀 In that case, the message must pass through one or more routers connecting the networks. If the networks aren't adjacent, the message may pass through several intervening networks, along with the routers connecting them. Once the message reaches a router that's on the same network as the destination, that network's own technology gets used to reach the destination 💅
Throughout this section, the term "network" is used generically to cover a single broadcast network (e.g., an Ethernet), a point to point line, or the ARPANET 🌈 The critical point is that a network is treated as a single entity by IP. Either no forwarding decision is necessary (as with a point to point line), or that forwarding is done in a manner that's transparent to IP, which lets IP treat the entire network as a single fully-connected system (as with an Ethernet or the ARPANET). Note that the term "network" gets used in a somewhat different way in discussions of IP addressing. Here we're using "network" to refer to subnets in cases where subnet addressing is in use 🤓
A number of different approaches for finding routes between networks are possible. One useful way of categorizing them is by the type of information the routers need to exchange in order to find routes 🗂️ Distance vector algorithms are based on the exchange of only a small amount of information. Each entity (router or host) that participates in the routing protocol is assumed to keep information about all of the destinations within the system. Generally, information about all entities connected to one network gets summarized by a single entry, which describes the route to all destinations on that network. This summarization works because, as far as IP is concerned, routing within a network is invisible 👀 Each entry in this routing database includes the next router to which datagrams destined for the entity should be sent. It also includes a "metric" measuring the total distance to the entity. Distance is a somewhat generalized concept. It may cover the time delay in getting messages to the entity, the dollar cost of sending messages to it, and so on. Distance vector algorithms get their name from the fact that it's possible to compute optimal routes when the only information exchanged is the list of these distances 🦋 Furthermore, information is only exchanged among entities that are adjacent, meaning entities that share a common network.
Routing is most commonly based on information about networks, but it's sometimes necessary to keep track of the routes to individual hosts 💜 The RIP protocol makes no formal distinction between networks and hosts. It simply describes exchange of information about destinations, which may be either networks or hosts. (Note however, that it's possible for an implementor to choose not to support host routes. See section 3.2.) In fact, the mathematical developments are most conveniently thought of in terms of routes from one host or router to another. When discussing the algorithm in abstract terms, it's best to think of a routing entry for a network as an abbreviation for routing entries for all of the entities connected to that network. This sort of abbreviation makes sense only because networks are treated as having no internal structure that's visible at the IP level. So we'll generally assign the same distance to every entity in a given network 🎀
We said above that each entity keeps a routing database with one entry for every possible destination in the system. An actual implementation is likely to need to keep the following information about each destination 📝
- address: in IP implementations of these algorithms, this will be the IP address of the host or network.
- router: the first router along the route to the destination.
- interface: the physical network which must be used to reach the first router.
- metric: a number, indicating the distance to the destination.
- timer: the amount of time since the entry was last updated.
In addition, various flags and other internal information will probably be included 🧃 This database gets initialized with a description of the entities that are directly connected to the system. It's then updated according to information received in messages from neighboring routers.
The most important information exchanged by the hosts and routers is carried in update messages 📬 Each entity that participates in the routing scheme sends update messages that describe the routing database as it currently exists in that entity. It's possible to maintain optimal routes for the entire system by using only information obtained from neighboring entities. The algorithm used for that will be described in the next section 🔥
As we mentioned above, the whole purpose of routing is to find a way to get datagrams to their ultimate destinations 🧚 Distance vector algorithms are based on a table in each router listing the best route to every destination in the system. Of course, to define which route is best, we need some way of measuring goodness. This is referred to as the "metric" 📏
In simple networks, it's common to use a metric that simply counts how many routers a message must go through. In more complex networks, a metric is chosen to represent the total amount of delay the message suffers, the cost of sending it, or some other quantity which may be minimized. The main requirement is that it must be possible to represent the metric as a sum of "costs" for individual hops 💖
Formally, if it's possible to get from entity i to entity j directly (i.e., without passing through another router in between), then a cost, d(i,j), is associated with the hop between i and j. In the normal case where all entities on a given network are considered to be the same, d(i,j) is the same for all destinations on a given network, and represents the cost of using that network. To get the metric of a complete route, you just add up the costs of the individual hops that make up the route. For the purposes of this memo, we assume that the costs are positive integers 🔢
Let D(i,j) represent the metric of the best route from entity i to entity j. It should be defined for every pair of entities. d(i,j) represents the costs of the individual steps. Formally, let d(i,j) represent the cost of going directly from entity i to entity j. It is infinite if i and j are not immediate neighbors. (Note that d(i,i) is infinite. That is, we don't consider there to be a direct connection from a node to itself.) Since costs are additive, it's easy to show that the best metric must be described by 🧮
D(i,i) = 0, all i
D(i,j) = min [d(i,k) + D(k,j)], otherwise
kand that the best routes start by going from i to those neighbors k for which d(i,k) + D(k,j) has the minimum value. (These things can be shown by induction on the number of steps in the routes.) Note that we can limit the second equation to k's that are immediate neighbors of i. For the others, d(i,k) is infinite, so the term involving them can never be the minimum 🙈
It turns out that you can compute the metric with a simple algorithm based on this 🤯 Entity i gets its neighbors k to send it their estimates of their distances to the destination j. When i gets the estimates from k, it adds d(i,k) to each of the numbers. This is simply the cost of traversing the network between i and k. Now and then, i compares the values from all of its neighbors and picks the smallest 💅
A proof is given in [2] that this algorithm will converge to the correct estimates of D(i,j) in finite time in the absence of topology changes. The authors make very few assumptions about the order in which the entities send each other their information, or when the min is recomputed. Basically, entities just can't stop sending updates or recomputing metrics, and the networks can't delay messages forever. (A crash of a routing entity is a topology change.) Also, their proof doesn't make any assumptions about the initial estimates of D(i,j), except that they must be non-negative. The fact that these fairly weak assumptions are good enough is important 😭 Because we don't have to make assumptions about when updates are sent, it's safe to run the algorithm asynchronously. That means each entity can send updates according to its own clock. Updates can be dropped by the network, as long as they don't all get dropped. Because we don't have to make assumptions about the starting condition, the algorithm can handle changes. When the system changes, the routing algorithm starts moving to a new equilibrium, using the old one as its starting point. It's important that the algorithm converges in finite time no matter what the starting point is. Otherwise, certain kinds of changes might lead to non-convergent behavior 🌸
The statement of the algorithm given above (and the proof) assumes that each entity keeps copies of the estimates that come from each of its neighbors, and now and then does a min over all of the neighbors. In fact, real implementations don't necessarily do that. They simply remember the best metric seen so far, and the identity of the neighbor that sent it. They replace this information whenever they see a better (smaller) metric. This lets them compute the minimum incrementally, without having to store data from all of the neighbors 👑
There is one other difference between the algorithm as described in texts and the ones used in real protocols like RIP, bestie 🧚: the description above would have each entity include an entry for itself, showing a distance of zero. In fact this is not generally done 💅. Recall that all entities on a network are normally summarized by a single entry for the network. Picture a host or router G that is connected to network A. C represents the cost of using network A (usually a metric of one). (Recall that we are assuming that the internal structure of a network is not visible to IP, so the cost of going between any two entities on it is the same 🫶.) In principle, G should get a message from every other entity H on network A, showing a cost of 0 to get from that entity to itself. G would then compute C + 0 as the distance to H. But ngl, that's a lot of identical messages to read 😭, so instead G simply starts out by making an entry for network A in its table, and assigning it a metric of C. This entry for network A should be thought of as summarizing the entries for all other entities on network A. The only entity on A that can't be summarized by that common entry is G itself, since the cost of going from G to G is 0, not C. But since we never need those 0 entries, we can safely get along with just the single entry for network A ✨. Note one other implication of this strategy: because we don't need to use the 0 entries for anything, hosts that do not function as routers don't need to send any update messages 🌸. Clearly hosts that don't function as routers (i.e., hosts that are connected to only one network) can have no useful information to contribute other than their own entry D(i,i) = 0. As they have only the one interface, it is easy to see that a route to any other network through them will simply go in that interface and then come right back out it 🙈. Thus the cost of such a route will be greater than the best cost by at least C. Since we don't need the 0 entries, non-routers need not participate in the routing protocol at all 🦋.
Let us summarize what a host or router G does 🎀. For each destination in the system, G will keep a current estimate of the metric for that destination (i.e., the total cost of getting to it) and the identity of the neighboring router on whose data that metric is based. If the destination is on a network that is directly connected to G, then G simply uses an entry that shows the cost of using the network, and the fact that no router is needed to get to the destination. It is easy to show that once the computation has converged to the correct metrics, the neighbor that is recorded by this technique is in fact the first router on the path to the destination. (If there are several equally good paths, it is the first router on one of them.) This combination of destination, metric, and router is typically referred to as a route to the destination with that metric, using that router 💜.
4.ne The method so far only has a way to lower the metric, as the existing metric is kept until a smaller one shows up. It is possible that the initial estimate might be too low. Thus, there must be a way to increase the metric. It turns out to be sufficient to use the following rule: suppose the current route to a destination has metric D and uses router G. If a new set of information arrived from some source other than G, only update the route if the new metric is better than D. But if a new set of information arrives from G itself, always update D to the new value. It is easy to show that with this rule, the incremental update process produces the same routes as a calculation that remembers the latest information from all the neighbors and does an explicit minimum. (Note that the discussion so far assumes that the network configuration is static. It does not allow for the possibility that a system might fail.) 👑
To summarize, here is the basic distance vector algorithm as it has been developed so far. (Note that this is not a statement of the RIP protocol. There are several refinements still to be added.) The following procedure is carried out by every entity that participates in the routing protocol. This must include all of the routers in the system. Hosts that are not routers may participate as well. 🌈
- Keep a table with an entry for every possible destination in the system. The entry contains the distance D to the destination, and the first router G on the route to that network. Conceptually, there should be an entry for the entity itself, with metric 0, but this is not actually included.
- Periodically, send a routing update to every neighbor. The update is a set of messages that contain all of the information from the routing table. It contains an entry for each destination, with the distance shown to that destination.
- When a routing update arrives from a neighbor G', add the cost associated with the network that is shared with G'. (This should be the network over which the update arrived.) Call the resulting distance D'. Compare the resulting distances with the current routing table entries. If the new distance D' for N is smaller than the existing value D, adopt the new route. That is, change the table entry for N to have metric D' and router G'. If G' is the router from which the existing route came, i.e., G' = G, then use the new metric even if it is larger than the old one.
3.4.1 Dealing with changes in topology 🔥
The discussion above assumes that the topology of the network is fixed. In practice, routers and lines often fail and come back up 💀. To handle this possibility, we need to modify the algorithm slightly.
The theoretical version of the algorithm involved a minimum over all immediate neighbors. If the topology changes, the set of neighbors changes. Therefore, the next time the calculation is done, the change will be reflected. However, as mentioned above, actual implementations use an incremental version of the minimization. Only the best route to any given destination is remembered. If the router involved in that route should crash, or the network connection to it break, the calculation might never reflect the change. The algorithm as shown so far depends upon a router notifying its neighbors if its metrics change. If the router crashes, then it has no way of notifying neighbors of a change 😭.
In order to handle problems of this kind, distance vector protocols must make some provision for timing out routes. The details depend upon the specific protocol. As an example, in RIP every router that participates in routing sends an update message to all its neighbors once every 30 seconds. Suppose the current route for network N uses router G. If we don't hear from G for 180 seconds, we can assume that either the router has crashed or the network connecting us to it has become unusable. Thus, we mark the route as invalid. When we hear from another neighbor that has a valid route to N, the valid route will replace the invalid one. Note that we wait for 180 seconds before timing out a route even though we expect to hear from each neighbor every 30 seconds. Unfortunately, messages are occasionally lost by networks. Thus, it is probably not a good idea to invalidate a route based on a single missed message 🫠.
As we will see below, it is useful to have a way to notify neighbors that there currently isn't a valid route to some network. RIP, along with several other protocols of this class, does this through a normal update message, by marking that network as unreachable. A specific metric value is chosen to indicate an unreachable destination; that metric value is larger than the largest valid metric that we expect to see. In the existing implementation of RIP, 16 is used. This value is normally referred to as "infinity", since it is larger than the largest valid metric. 16 may look like a surprisingly small number. It is chosen to be this small for reasons that we will see shortly. In most implementations, the same convention is used internally to flag a route as invalid. Stay tuned, this is about to get spicy 🍓
3.4.2 Preventing instability ✨
okay so the algorithm as we've described it so far will always let a host or router work out a correct routing table 💅 but ngl that's still not quite enough to make it actually useful in real life 😭. The proofs mentioned above only show that the tables will converge to the right values in finite time. They don't promise that the time will be small enough to be useful, and they don't say what happens to the metrics for networks that become inaccessible 🙈.
it's easy enough to extend the math to handle routes becoming inaccessible 🎀. The convention from before already does that. We pick a large metric value to represent "infinity" 🔥. This value must be large enough that no real metric would ever get that big. For this example we'll use 16. Say a network becomes inaccessible. All of the immediately neighboring routers time out and set the metric for that network to 16 💀. For analysis, we can pretend all the neighboring routers got a shiny new piece of hardware that connects them directly to the vanished network, with a cost of 16 🧚. Since that's the only connection to the vanished network, all the other routers will converge to new routes that go through one of those routers. It's easy to see that once convergence happens, every router will have a metric of at least 16 for the vanished network. Routers one hop away from the original neighbors would end up with metrics of at least 17, routers two hops away with at least 18, and so on. Those are bigger than the maximum metric value, so they all get set to 16 🌸. It's obvious that the system will now converge to a metric of 16 for the vanished network at all routers 👑.
unfortunately, how long convergence takes is not amenable to such a simple answer 😩. Before we go further, it's useful to look at an example (taken from [2]). Note that what we're about to show will not happen with a correct implementation of RIP. We're trying to show why certain features are needed 🫶. In the following example, the letters are routers and the lines are networks.
A-----B
\ / \
\ / |
C / all networks have cost 1, except
| / for the direct link from C to D, which
|/ has cost 10
D
|<=== target networkEach router will have a table showing a route to each network. For this illustration, though, we only show the routes from each router to the network marked at the bottom of the diagram 🦋.
D: directly connected, metric 1
B: route via D, metric 2
C: route via B, metric 3
A: route via B, metric 3Now suppose the link from B to D fails 💔. The routes should now adjust to use the link from C to D. Unfortunately, it'll take a while for this to happen. The routing changes start when B notices that its route to D is no longer usable. For simplicity, the chart below assumes that all routers send updates at the same time. It shows the metric for the target network as it appears in each router's routing table 📊.
time ------>
D: dir, 1 dir, 1 dir, 1 dir, 1 ... dir, 1 dir, 1
B: unreach C, 4 C, 5 C, 6 C, 11 C, 12
C: B, 3 A, 4 A, 5 A, 6 A, 11 D, 11
A: B, 3 C, 4 C, 5 C, 6 C, 11 C, 12
dir = directly connected
unreach = unreachablehere's the problem 🚨: B is able to get rid of its failed route using a timeout mechanism, but vestiges of that route stick around in the system for a long time. At first, A and C still think they can reach D via B. So they keep sending updates listing metrics of 3 😤. In the next round, B claims it can reach D via either A or C. Of course, it can't! The routes A and C were claiming are gone, but they have no way of knowing that yet. Even when they discover their routes via B have disappeared, each one thinks there's a route available via the other 🙃. Eventually the system converges, as all the math says it must. But it can take some time to get there. The worst case is when a network becomes completely inaccessible from some part of the system. In that case, the metrics may increase slowly, in a pattern like the one above, until they finally reach infinity. For this reason, the problem is called "counting to infinity" 🥲.
you should now see why "infinity" is chosen to be as small as possible 🧠. If a network becomes completely inaccessible, we want counting to infinity to stop as soon as possible. Infinity must be large enough that no real route is that big, but it shouldn't be any bigger than required. So choosing infinity is a tradeoff between network size and speed of convergence when counting to infinity happens 💅. The designers of RIP believed the protocol was unlikely to be practical for networks with a diameter larger than 15 🌈.
there are a few things that can be done to prevent problems like this 🛡️. The ones RIP uses are called "split horizon with poisoned reverse" and "triggered updates".
3.4.3 Split horizon 🍓
okay so some of the problem above comes from the fact that A and C are engaged in a pattern of mutual deception 🤥. Each one claims it can reach D through the other. This can be prevented by being a bit more careful about where information gets sent. Specifically, it's never useful to claim reachability for a destination network to the neighbor(s) you learned the route from 💜. "Split horizon" is a scheme for avoiding problems caused by including routes in updates sent back to the router they were learned from. The "simple split horizon" scheme omits routes learned from one neighbor in updates sent to that neighbor. "Split horizon with poisoned reverse" includes those routes in the updates, but sets their metrics to infinity 🎀.
if A thinks it can reach D via C, its messages to C should say that D is unreachable 🙅♀️. If the route through C is real, then C either has a direct connection to D or a connection through some other router. C's route can't possibly go back to A, since that would form a loop. By telling C that D is unreachable, A just guards against the possibility that C gets confused and thinks there's a route through A 🫠. This is obvious for a point-to-point line. But consider the case where A and C are connected by a broadcast network like an Ethernet, with other routers on that network too 👀. If A has a route through C, it should say D is unreachable when talking to any other router on that network. The other routers can reach C on their own and would never need to get to C via A. If A's best route really goes through C, no other router on that network needs to know that A can reach D. This is lowkey great, because it means the same update message used for C can be used for every other router on the same network. So update messages can be sent by broadcast 📡.
in general, split horizon with poisoned reverse is safer than simple split horizon 🛡️. If two routers have routes pointing at each other, advertising reverse routes with a metric of 16 breaks the loop immediately. If the reverse routes are simply not advertised, the erroneous routes have to be eliminated by waiting for a timeout ⏳. However, poisoned reverse does have a downside: it makes the routing messages bigger 🐘. Think about a campus backbone connecting a bunch of different buildings. In each building there's a router connecting the backbone to a local network. Consider what routing updates those routers should broadcast on the backbone network. All the rest of the network really needs to know about each router is which local networks it's connected to. With simple split horizon, only those routes would appear in the update messages the router sends to the backbone. With split horizon with poisoned reverse, the router must mention every route it learns from the backbone, with metrics of 16. (Note the original says "must" here in its ordinary sense, not as a BCP 14 keyword. Keep it lowercase.) If the system is large, that can make a huge update message where almost every entry says a network is unreachable 😵.
in a static sense, advertising reverse routes with a metric of 16 gives no extra information 🤷♀️. If there are lots of routers on one broadcast network, those extra entries can eat up significant bandwidth. They're there to improve dynamic behavior. When the topology changes, mentioning routes that shouldn't go through the router, as well as the ones that should, can speed up convergence ⚡. However, in some situations network managers may prefer to accept somewhat slower convergence in order to minimize routing overhead 💼. So implementors may, at their option, implement simple split horizon rather than split horizon with poisoned reverse. They may also provide a configuration option that lets the network manager choose which behavior to use 🎛️. It's also permissible to implement hybrid schemes that advertise some reverse routes with a metric of 16 and omit others. An example would be using a metric of 16 for reverse routes for a certain period of time after routing changes involving them, then omitting them from updates after that 🦄.
the router requirements RFC [11] specifies that all implementations of RIP must use split horizon and should also use split horizon with poisoned reverse, although there may be a knob to disable poisoned reverse 🎚️💖
3.4.4 Triggered updates ✨
okay so split horizon with poisoned reverse stops routing loops between just two routers 🙅♀️ but three routers can still be gaslighting each other 💀 like, A thinks it has a route through B, B thinks it's through C, and C thinks it's through A. split horizon literally can't catch that one. the loop only gets resolved once the metric hits infinity and the network gets declared unreachable 😭 so triggered updates are the glow-up that speeds all of this up 🚀
the rule is: whenever a router changes the metric for a route, it is REQUIRED to send update messages almost immediately, even if it isn't time for a regular update yet. (the timing details differ from protocol to protocol. some distance vector protocols, RIP included, add a small delay so triggered updates don't flood the network with excessive traffic 🌊)
now look at how this combines with the rules for computing new metrics 👀 say a router's route to destination N goes through router G. if an update arrives from G itself, the receiving router is REQUIRED to believe the new information, whether the new metric is higher or lower than the old one. if that changes the metric, the receiving router sends triggered updates to all the hosts and routers directly connected to it. they may each send updates to their neighbors too, so you get a whole cascade of triggered updates 🌈
it's actually easy to tell which routers and hosts get pulled into the cascade 🧠 say router G times out a route to destination N. G sends triggered updates to all of its neighbors. but the only neighbors who will believe the new info are the ones whose routes for N go through G 🫶 everyone else sees it as a new route that's worse than the one they're already using, so they just ignore it 🙈 the neighbors whose routes go through G update their metrics and send triggered updates to all of their neighbors. again, only the neighbors whose routes go through them pay attention. so the triggered updates propagate backwards along all paths leading to router G, updating the metrics to infinity. this stops as soon as it reaches a part of the network whose route to destination N takes some other path 🛑
if the system could be made to sit still while the cascade of triggered updates happens, it would be possible to prove that counting to infinity will never happen. bad routes would always be removed immediately, so no routing loops could form. 🧊
unfortunately, things are not so nice 😤 while the triggered updates are being sent, regular updates may be happening at the same time. routers that haven't received the triggered update yet will still be sending out information based on the route that no longer exists. it's possible that after the triggered update has gone through a router, that router gets a normal update from one of these routers that hasn't caught up yet 💀 and that could bring back an orphaned remnant of the faulty route 👻 if triggered updates happen quickly enough, this is very unlikely. however, counting to infinity is still possible.
the router requirements RFC [11] says every RIP implementation MUST implement triggered updates for deleted routes, and it MAY implement triggered updates for new routes or changes of routes. RIP implementations MUST also limit the rate at which triggered updates may be transmitted (see section 3.10.1) 🎀
3.5 Protocol Specification ✨
okay now the actual specs 📜 RIP is intended to let routers exchange information for computing routes through an IPv4-based network. any router that uses RIP is assumed to have interfaces to one or more networks, otherwise it isn't really a router 💅 these are called its directly-connected networks. the protocol relies on access to certain information about each of these networks, and the most important one is its metric. the RIP metric of a network is an integer between 1 and 15, inclusive. it gets set in some manner that isn't specified in this protocol. however, given the maximum path limit of 15, a value of 1 is usually used. implementations SHOULD allow the system administrator to set the metric of each network. on top of the metric, each network has an IPv4 destination address and subnet mask. these get set by the system administrator in a manner not specified in this protocol 🌸
any host that uses RIP is assumed to have interfaces to one or more networks too 🧚 these are called its "directly-connected networks". the protocol relies on access to certain info about each one, and the most important is its metric or "cost". the metric of a network is an integer between 1 and 15 inclusive. again, it's set in some manner not specified in this protocol. most existing implementations always use a metric of 1 🙃 new implementations SHOULD allow the system administrator to set the cost of each network. in addition to the cost, each network has an IPv4 network number and a subnet mask. these are set by the system administrator in a manner not specified in this protocol.
now, the rules in section 3.7 assume there's a single subnet mask applying to each IPv4 network, and that only the subnet masks for directly-connected networks are known 🤔 there may be systems that use different subnet masks for different subnets within a single network. there may also be times when it's desirable for a system to know the subnet masks of distant networks. network-wide distribution of routing information that contains different subnet masks is permitted if all routers in the network are running the extensions presented in this document 💜 but if all routers in the network are not running these extensions, distribution of routing information containing different subnet masks MUST be limited to avoid interoperability problems ⚠️ see sections 3.7 and 4.3 for the rules governing subnet distribution.
each router that implements RIP is assumed to have a routing table 📚 this table has one entry for every destination that is reachable throughout the system operating RIP. each entry contains at least the following info:
- The IPv4 address of the destination.
- A metric, which represents the total cost of getting a datagram from the router to that destination. this metric is the sum of the costs associated with the networks that would be traversed to get to the destination 🛣️
- The IPv4 address of the next router along the path to the destination (i.e., the next hop). if the destination is on one of the directly-connected networks, this item isn't needed.
- A flag to indicate that information about the route has changed recently. this is the "route change flag" 🚩
- Various timers associated with the route. see section 3.6 for more details on timers ⏰
the entries for the directly-connected networks are set up by the router using info gathered by means not specified in this protocol 🔧 the metric for a directly-connected network is set to the cost of that network. as mentioned, 1 is the usual cost, and in that case the RIP metric reduces to a simple hop-count 🦋 more complex metrics may be used when it's desirable to show preference for some networks over others (e.g., to indicate differences in bandwidth or reliability) 💎
to support the extensions detailed in this document, each entry MUST additionally contain a subnet mask 🎀 the subnet mask lets the router (along with the IPv4 address of the destination) identify the different subnets within a single network, as well as the subnet masks of distant networks.
implementors may also choose to let the system administrator enter additional routes 🫧 these would most likely be routes to hosts or networks outside the scope of the routing system, and they're called "static routes". entries for destinations other than these initial ones are added and updated by the algorithms described in the following sections.
last but definitely not least 👑 in order for the protocol to provide complete information on routing, every router in the AS MUST participate in the protocol. and in cases where multiple IGPs are in use, there MUST be at least one router which can leak routing information between the protocols 🌉
3.6 Message Format 💅
okay so RIP is UDP-based 🦋 every router running RIP has a routing process that sends and receives datagrams on UDP port number 520, aka the RIP-1/RIP-2 port. anything meant for another router's RIP process gets sent to that RIP port. all routing update messages are sent from the RIP port too. unsolicited updates have both source and destination port equal to the RIP port, but updates sent in reply to a request go back to whatever port the request came from. specific queries can come from ports other than the RIP port, but they must be directed to the RIP port on the target machine. the routing is giving organized 🎀
here's the RIP packet format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
| |
~ RIP Entry (20) ~
| |
+---------------+---------------+---------------+---------------+there can be between 1 and 25 (inclusive) RIP entries 💖 a RIP-1 entry looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IPv4 address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+field sizes are given in octets 🌸 unless said otherwise, fields hold binary integers in network byte order, with the most-significant octet first (big-endian). each tick mark is one bit, so yes, you can count them 🙈
every message has a RIP header made of a command and a version number. this section describes version 1 of the protocol, and section 4 is where the version 2 extensions live. the command field tells you what the message is for. the commands in versions 1 and 2 are:
1 - request A request for the responding system to send all or
part of its routing table.
2 - response A message containing all or part of the sender's
routing table. This message may be sent in response
to a request, or it may be an unsolicited routing
update generated by the sender.for each of these message types in version 1, the rest of the datagram is a list of Route Entries (RTEs). every RTE has an Address Family Identifier (AFI), a destination IPv4 address, and the cost to reach that destination (metric) ✨
the AFI is the type of address. for RIP-1, only AF_INET (2) is generally supported 🧚
the metric field holds a value between 1 and 15 (inclusive), which is the current metric for the destination. or it can be 16 (infinity), which means the destination is not reachable 💀
3.7 Addressing Considerations 🦋
distance vector routing can describe routes to individual hosts or to whole networks, and RIP lets you do either one 🌈 the destinations showing up in request and response messages can be networks, hosts, or a special code for a default address. which kinds of routes you actually end up using depends on the routing strategy of that particular network.
lowkey, a lot of networks are set up so that per-host routing info isn't needed at all. if every node on a given network or subnet is reachable through the same routers, there's no reason to mention individual hosts in the routing tables. BUT networks with point-to-point lines sometimes make routers track routes to certain nodes. whether that feature is required depends on the addressing and routing approach in the system. so some implementations may choose not to support host routes. if host routes aren't supported, they are to be dropped when they show up in response messages (see section 3.7.2) 🫶
the RIP-1 packet format doesn't tell apart the different types of address. fields labeled "address" can hold any of the following:
host address subnet number network number zero (default route)
entities that use RIP-1 are assumed to use the most specific information available when routing a datagram 👑 so when routing a datagram, its destination address gets checked against the list of node addresses first. then it has to be checked against any known subnet or network number. and finally, if nothing matches, the default route is used.
when a node reads information it got via RIP-1, how it interprets an address depends on whether it knows the subnet mask that applies to the net 🔥 if it does, it can tell what the address means. for example, take net 128.6. it has a subnet mask of 255.255.255.0. so 128.6.0.0 is a network number, 128.6.4.0 is a subnet number, and 128.6.4.1 is a node address. but if the node doesn't know the subnet mask, reading an address can be ambiguous 😭 if there's a non-zero node part, there's no clear way to tell whether the address is a subnet number or a node address. a subnet number is useless without the subnet mask, so in this situation addresses are assumed to represent nodes.
to dodge this ambiguity, when using version 1, nodes must not send subnet routes to nodes that can't be expected to know the appropriate subnet mask. hosts usually only know the subnet masks for directly-connected networks, so unless special provisions have been made, routes to a subnet must not be sent outside the network that the subnet belongs to. RIP-2 (see section 4) gets rid of the subnet/host ambiguity by putting the subnet mask in the routing entry ✨
this "subnet filtering" is handled by the routers on the "border" of the subnetted network 🌸 those are the routers connecting that network to some other network. inside the subnetted network, each subnet is treated as its own individual network, and RIP circulates routing entries for each subnet. but border routers only send a single entry for the whole network to nodes in other networks. that means a border router sends different info to different neighbors 🧚 for neighbors on the subnetted network, it builds a list of all the subnets it's directly connected to, using the subnet numbers. for neighbors on other networks, it makes one entry for the whole network, showing the metric for that network. that metric would normally be the smallest metric among the subnets the router is attached to.
border routers must not mention host routes for nodes inside one of their directly-connected networks in messages to other networks, either 💅 those routes get subsumed by the single entry for the whole network.
the router requirements RFC [11] says that all implementations of RIP should support host routes, but if they don't, then they must ignore any host routes they receive 🙈
the special address 0.0.0.0 describes a default route. a default route is used when it isn't convenient to list every possible network in the RIP updates, and when one or more closely-connected routers in the system are ready to handle traffic to the networks that aren't listed explicitly. these routers should create RIP entries for the address 0.0.0.0, just as if it were a network they're connected to. how routers create entries for 0.0.0.0 is left up to the implementor. most commonly, the system administrator gets a way to pick which routers should create those entries, but other mechanisms are possible. for example, an implementor might decide that any router which speaks BGP should be declared a default router 🎀 it may also be useful to let the network administrator choose the metric used in these entries. if there's more than one default router, that makes it possible to prefer one over the other.
the entries for 0.0.0.0 are handled by RIP in exactly the same way as if there were an actual network with that address. system administrators should take care to make sure routes to 0.0.0.0 don't propagate further than intended 😭 generally, each autonomous system has its own preferred default router. so routes involving 0.0.0.0 should generally not leave the boundary of an autonomous system. the mechanisms for enforcing this aren't specified in this document.
3.8 Timers ⏰
okay so this section is all about the stuff that gets kicked off by timers 🫶 let's gooo
Every 30 seconds, the RIP process wakes up and sends an unsolicited Response message 📣 with the complete routing table (see section 3.9 on Split Horizon) to every neighboring router 💖. Here's the tea: when there are a lot of routers on one network, they can totally fall into sync and all send their updates at the exact same moment 👯. That's a mess, because it can cause unnecessary collisions on broadcast networks 💀. So implementations are REQUIRED to take one of two precautions ✨:
- The 30-second updates get triggered by a clock that doesn't care about system load or how long it took to handle the previous update timer 🕰️
- The 30-second timer gets offset by a small random time (+/- 0 to 5 seconds) every time it's set. (Implementors may wish to consider even larger variation in the light of recent research results [10]) 🎲
Each route has two timers 🫧: a "timeout" and a "garbage-collection" time. When the timeout expires, the route is no longer valid, but it hangs around in the routing table for a short while so neighbors can be told it's been dropped 👋. When the garbage-collection timer expires, the route is finally removed from the routing table 🧹.
The timeout gets initialized when a route is established, and any time an update message is received for that route. If 180 seconds pass from the last time the timeout was initialized, the route is considered expired and the deletion process (described below) begins for it ⏳.
Deletions can happen for one of two reasons: the timeout expires, or the metric gets set to 16 because of an update received from the current router (see section 3.7.2 for a discussion of processing updates from other routers). Either way, these things happen 💅:
- The garbage-collection timer is set for 120 seconds.
- The metric for the route is set to 16 (infinity). This causes the route to be removed from service 🚫.
- The route change flag is set to show that this entry has changed 🚩.
- The output process is signalled to trigger a response 📤.
Until the garbage-collection timer expires, the route is still included in all updates this router sends 📬. Once that timer expires, the route gets deleted from the routing table, period 💀.
If a new route to this network gets established while the garbage-collection timer is running, the new route replaces the one that's about to be deleted 🦋. In that case the garbage-collection timer MUST be cleared.
Triggered updates also use a small timer, but that one's best explained in section 3.9.1 🧚.
3.9 Input Processing 📥
This section is where we go over how datagrams received on the RIP port get handled 🎀. What happens depends on the value in the command field, so pay attention to that 👀.
See sections 4.6 and 5.1 for the details on handling version numbers 🔢.
3.9.1 Request Messages 🙋♀️
A Request is used to ask for a response containing all or part of a router's routing table 💌. Normally, Requests go out as broadcasts (multicasts for RIP-2), sent from the RIP port, by routers that just came up and want to fill in their routing tables ASAP 🏃♀️💨. But sometimes (like with router monitoring) you only need the routing table of one single router 🔍. In that case, the Request SHOULD be sent directly to that router from a UDP port that is not the RIP port. When a Request like that comes in, the router responds directly to the requestor's address and port 📮.
The Request gets processed entry by entry. If there are no entries, no response is given 🫥. There's one special case though 👑: if there's exactly one entry in the request, and it has an address family identifier of zero and a metric of infinity (i.e., 16), then it's a request to send the entire routing table. In that situation, a call is made to the output process to send the routing table to the requesting address/port 🎁. Outside of that special case, it's pretty simple. Look at the RTEs in the Request one by one. For each entry, look up the destination in the router's routing database and, if there's a route, put that route's metric in the metric field of the RTE 🔎. If there's no explicit route to the specified destination, put infinity in the metric field ♾️. Once every entry is filled in, change the command from Request to Response and send the datagram back to the requestor 🚀.
Now here's the thing: metric handling is different for specific requests and whole-table requests 🤔. If the request is for a complete routing table, normal output processing happens, including Split Horizon (see section 3.9 on Split Horizon). If the request is for specific entries, those get looked up in the routing table and the info is returned as is, with no Split Horizon processing at all 🙅♀️. The reason for the difference is that these requests are expected to be used for different things 💅. When a router first comes up, it multicasts a Request on every connected network asking for a complete routing table. Those complete tables are assumed to be used to update the requestor's own routing table, so Split Horizon MUST be done 🫶. A Request for specific networks, on the other hand, is assumed to come only from diagnostic software and not be used for routing 🛠️. In that case the requester wants to see the exact contents of the routing table, with nothing hidden or modified 🕵️♀️.
3.9.2 Response Messages 💌
A Response can show up for one of several reasons 🎁:
- response to a specific query
- regular update (unsolicited response)
- triggered update caused by a route change
Processing is the same no matter why the Response was generated ✨.
Because processing a Response can update the router's routing table, the Response MUST be checked super carefully for validity 🧐. First off, the Response MUST be ignored if it isn't from the RIP port 🚫. The datagram's IPv4 source address SHOULD be checked to see whether the datagram is from a valid neighbor 👀, since the source of the datagram MUST be on a directly-connected network 🔌. It's also worth checking whether the response is from one of the router's own addresses 🪞. Interfaces on broadcast networks may get copies of their own broadcasts/multicasts right away, and if a router processes its own output as new input, things get confusing fast, so such datagrams MUST be ignored 🙈.
Once the whole datagram is validated, process the RTEs in the Response one by one. Again, start with validation 💅. Incorrect metrics and other format errors usually mean a misbehaving neighbor, and they SHOULD probably be brought to the administrator's attention 🚨. For example, if the metric is greater than infinity, ignore the entry but log the event 📝. The basic validation tests are:
- is the destination address valid (e.g., unicast; not net 0 or 127)
- is the metric valid (i.e., between 1 and 16, inclusive)
If any check fails, ignore that entry and move on to the next one ⏭️. Logging the error is probably a good idea too 🫶.
Once the entry passes validation, update the metric by adding the cost of the network the message arrived on. If the result is greater than infinity, use infinity instead 🧮. Like this:
metric = MIN (metric + cost, infinity)Next, check whether there's already an explicit route for the destination address 🕵️♀️. If there's no such route, add this one to the routing table, unless the metric is infinity (no point adding a route that's unusable 🙃). Adding a route to the routing table means:
- Setting the destination address to the destination address in the RTE
- Setting the metric to the newly calculated metric (as described above)
- Setting the next hop address to the address of the router the datagram came from
- Initializing the timeout for the route. If the garbage-collection timer is running for this route, stop it (see section 3.6 for a discussion of the timers) ⏹️
- Setting the route change flag 🚩
- Signalling the output process to trigger an update (see section 3.8.1) 📣
If there's an existing route, compare the next hop address to the address of the router the datagram came from 🔁. If the datagram is from the same router as the existing route, reinitialize the timeout. Then compare the metrics. If the datagram is from the same router as the existing route and the new metric is different than the old one, or if the new metric is lower than the old one, do the following:
- Adopt the route from the datagram (i.e., put the new metric in and adjust the next hop address, if necessary) 🔄
- Set the route change flag and signal the output process to trigger an update 🚩📤
- If the new metric is infinity, start the deletion process (described above). Otherwise, re-initialize the timeout ⏳
If the new metric is infinity, the deletion process begins for the route, which is no longer used for routing packets 💀. Note that the deletion process only starts when the metric is first set to infinity. If the metric was already infinity, a new deletion process is NOT started 🙅♀️.
If the new metric is the same as the old one, the simplest move is to do nothing further (beyond reinitializing the timeout, as specified above) 😌. But there's a heuristic you could apply 🧠. Normally it's senseless to replace a route when the new route has the same metric as the existing one, because the route would bounce back and forth and generate an intolerable number of triggered updates 🏓. However, if the existing route is showing signs of timing out, it may be better to switch to an equally good alternative right away instead of waiting for the timeout to happen 🏃♀️. So if the new metric is the same as the old one, examine the timeout for the existing route. If it's at least halfway to the expiration point, switch to the new route 🔀. This heuristic is OPTIONAL, but highly RECOMMENDED 🌟.
Any entry that fails these tests gets ignored, since it's no better than the current route 🥱.
3.10 Output Processing 🎀
okay so this section is all about how a router builds the response messages that carry all or some of its routing table 💅 and there are three different things that can kick this off. first, input processing: when a Request comes in, this Response gets unicast back to whoever asked (see Section 3.7.1 🦋). second, the regular routing update, which goes out broadcast or multicast every 30 seconds 🌸. third, triggered updates, which go out broadcast or multicast whenever a route changes ⚡
when a Response is headed to all neighbors (so, a regular or triggered update), it gets sent straight to the router on the far end of each connected point-to-point link, and it gets broadcast (multicast for RIP-2) on every connected network that supports broadcasting 🫶 so basically one Response gets prepared for each directly-connected network and sent to the right address, direct or broadcast/multicast ✨ in most cases that reaches every neighboring router, lowkey perfect. but sometimes it's not good enough 😭 like when the network isn't a broadcast network (the ARPANET is the classic example) or when you're dealing with dumb routers. in those situations you might need to list out the actual neighboring routers and send a datagram to each one explicitly 💜 whether that's needed is up to the implementor, and they get to decide how the list is specified 🧚
3.10.1 Triggered Updates 🌈
okay this is the spicy part bestie 🔥 triggered updates need special handling for two reasons.
first, experience shows triggered updates can absolutely wreck networks that have limited capacity or lots of routers crowded onto them 💀 so the protocol says implementors MUST include provisions to limit how often triggered updates go out. after a triggered update is sent, a timer SHOULD be set for a random interval between 1 and 5 seconds 🎀. if other changes that would trigger updates happen before that timer goes off, a single update gets triggered when it expires, and then the timer resets to another random value between 1 and 5 seconds 🦋. and a triggered update SHOULD be suppressed if a regular update is due by the time the triggered one would be sent 🙈
second, triggered updates don't have to include the whole routing table 🍓 in principle, only the routes that changed need to go out. so messages made for a triggered update MUST include at least those routes that have their route change flag set. they MAY include extra routes if the implementor wants, but sending complete routing updates is strongly discouraged 💅. when a triggered update gets processed, messages SHOULD be generated for every directly-connected network 🌸. Split Horizon processing happens for triggered updates just like normal ones (see Section 3.9) ✨. if, after Split Horizon for a given network, a changed route would look unchanged on that network (like it shows up with an infinite metric), the route doesn't need to be sent 🫶. if no routes need to go on that network, the update MAY be left out entirely 🧚. once every triggered update has been generated, the route change flags SHOULD be cleared 💜.
if input processing is allowed while output is being generated, there MUST be appropriate interlocking 🔒. the route change flags MUST NOT be changed just because input got processed while a triggered update message is being built 🙅♀️.
the only real difference between a triggered update and other updates is that a triggered one can skip routes that haven't changed 🦋. all the remaining mechanisms, covered in the next section, MUST be applied to all updates 💖.
3.10.2 Generating Response Messages 🍓
okay this bit walks through how one Response gets built for one particular directly-connected network 🎀.
set the version number to either 1 or 2. which version to send is up to the implementation 🌸, BUT if this is a Response to a Request, the Response version MUST match the Request version ✨. set the command to Response 💅. set the bytes labeled "must be zero" to zero 🫶. then start filling in RTEs. there's a limit of 25 RTEs per Response 🙈, so if there are more than that, send the current Response and start a fresh one 🧚. there's no defined limit on how many datagrams make up a Response 🌈.
to fill in the RTEs, look at every route in the routing table 👀. if it's a triggered update, only entries with their route change flags set need to be included 🔥. if a route should not be included after Split Horizon processing, skip it 🦋. if the route does get included, its destination address and metric go into the RTE 💜. routes MUST be included in the datagram even when their metrics are infinite 💀.
4. Protocol Extensions ✨
okay so this section doesn't actually change the RIP protocol itself 🎀. instead it adds extensions to the message format so routers can share some extra important info 🫶.
the same header format is used for RIP-1 and RIP-2 messages (see Section 3.4) 💅. the 20-octet route entry (RTE) for RIP-2 looks like this 👑:
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family Identifier (2) | Route Tag (2) |
+-------------------------------+-------------------------------+
| IP Address (4) |
+---------------------------------------------------------------+
| Subnet Mask (4) |
+---------------------------------------------------------------+
| Next Hop (4) |
+---------------------------------------------------------------+
| Metric (4) |
+---------------------------------------------------------------+the Address Family Identifier, IP Address, and Metric all mean exactly what Section 3.4 defined 🦋. the Version field will say version number 2 for RIP messages that use authentication or carry info in any of the newly defined fields 💖.
4.1 Authentication 🔐
okay so authentication is a per-message thing 🫶, and there's only one 2-octet field free in the message header 😭. any reasonable authentication scheme needs more than two octets, so RIP version 2's scheme uses the space of an entire RIP entry 💅. if the Address Family Identifier of the first (and only the first) entry in the message is 0xFFFF, then the rest of that entry holds the authentication 🎀. that means there can be, at most, 24 RIP entries in the rest of the message 🌸. if authentication isn't in use, then NO entries in the message SHOULD have an Address Family Identifier of 0xFFFF ✨. a RIP message that contains an authentication entry starts with this format 👑:
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command (1) | Version (1) | unused |
+---------------+---------------+-------------------------------+
| 0xFFFF | Authentication Type (2) |
+-------------------------------+-------------------------------+
~ Authentication (16) ~
+---------------------------------------------------------------+right now the only Authentication Type is simple password, and it's type 2 🔑. the remaining 16 octets hold the plain text password 💜. if the password is under 16 octets, it MUST be left-justified and padded on the right with nulls (0x00) 🦋.
4.2 Route Tag 🏷️
the Route Tag (RT) is an attribute assigned to a route that MUST be preserved and readvertised along with the route 💅. its intended use is to separate "internal" RIP routes (routes for networks inside the RIP routing domain) from "external" RIP routes that may have been imported from an EGP or another IGP 🌈.
routers that support protocols other than RIP SHOULD be configurable so the Route Tag can be set for routes imported from different sources 🎀. for example, routes imported from EGP or BGP SHOULD be able to have their Route Tag set either to an arbitrary value, or at least to the number of the Autonomous System the routes were learned from 🫶.
other uses of the Route Tag are valid, as long as all routers in the RIP domain use it consistently 🧚. this leaves room for a possible BGP-RIP protocol interactions document that would describe ways to synchronize routing in a transit network ✨.
4.3 Subnet mask 🎭
the Subnet Mask field holds the subnet mask that gets applied to the IP address to get the non-host part of the address 💖. if this field is zero, then no subnet mask was included for this entry 🙈.
on an interface where a RIP-1 router might hear and act on a RIP-2 routing entry, these rules apply 🚨:
- information internal to one network MUST NEVER be advertised into another network 🙅♀️,
- information about a more specific subnet MAY NOT be advertised where RIP-1 routers would treat it as a host route, and 💀
- supernet routes (routes with a netmask less specific than the "natural" network mask) MUST NOT be advertised where RIP-1 routers could misinterpret them 😭.
4.4 Next Hop 👉
the Next Hop is the immediate next hop IP address that packets headed to the destination in this route entry should be forwarded to 🦋. putting 0.0.0.0 in this field means routing should go via whoever originated the RIP advertisement 🌸. an address listed as a next hop MUST, per force, be directly reachable on the logical subnet the advertisement came over 💅.
the whole point of Next Hop is to stop packets from taking extra hops through the system 🧚. it's especially handy when RIP isn't running on every router on a network 🫶. Appendix A has a simple example 📖. quick heads up: Next Hop is an "advisory" field 🤓. so if the info gets ignored, a possibly sub-optimal but absolutely valid route might get taken 🙃. if the received Next Hop isn't directly reachable, it SHOULD be treated as 0.0.0.0 🎀.
4.5 Multicasting 📡
to cut down on unnecessary load on hosts that aren't listening to RIP-2 messages, an IP multicast address is used for periodic broadcasts 💜. that address is 224.0.0.9 ✨. IGMP isn't needed here, since these are inter-router messages that don't get forwarded 🌈.
on NBMA networks, unicast addressing MAY be used 🦋. but if a response addressed to the RIP-2 multicast address is received, it SHOULD be accepted 💖.
to keep backwards compatibility, using the multicast address is configurable, as described in Section 5.1 🎀. if multicasting is used, it SHOULD be used on all interfaces that support it 🫶.
4.6 Queries 🔍
if a RIP-2 router gets a RIP-1 Request, it SHOULD respond with a RIP-1 Response 💅. if the router is configured to send only RIP-2 messages, it SHOULD NOT respond to a RIP-1 Request 🙈.
5. Compatibility ✨
okay so RFC [1] was honestly so forward-thinking about version numbers, bestie 🧚💅. It says RIP messages of version 0 are to be discarded, and RIP messages of version 1 are to be discarded if any Must Be Zero (MBZ) field is non-zero. But RIP messages of any version greater than 1 SHOULD NOT be discarded just because an MBZ field has a value other than zero 🫶. So the new version of RIP is totally backwards compatible with existing RIP implementations that follow this part of the spec. It's giving stability 👑.
5.1. Compatibility Switch 🎀
Okay, a compatibility switch is NECESSARY, and here's why 🙈. First, there are RIP-1 implementations out in the wild that don't follow RFC [1] the way I just described. Second, multicasting would stop RIP-1 systems from receiving RIP-2 updates, which might be a desired feature in some cases 🦋. This switch SHOULD be configurable on a per-interface basis.
The switch has four settings 💖: RIP-1, where only RIP-1 messages are sent; RIP-1 compatibility, where RIP-2 messages are broadcast; RIP-2, where RIP-2 messages are multicast; and "none", which disables the sending of RIP messages. It is RECOMMENDED that the default setting be either RIP-1 or RIP-2, but NOT RIP-1 compatibility, because of potential problems that can happen on some topologies 😭. RIP-1 compatibility SHOULD only be used when the network administrator fully understands all of its consequences 🧐.
For completeness 💅, routers SHOULD also implement a receive control switch that decides whether to accept RIP-1 only, RIP-2 only, both, or none. It should also be configurable on a per-interface basis. It is RECOMMENDED that the default be compatible with the default chosen for sending updates ✨.
5.2. Authentication 🔐
The following algorithm SHOULD be used to authenticate a RIP message. If the router is NOT configured to authenticate RIP-2 messages, then RIP-1 and unauthenticated RIP-2 messages will be accepted, but authenticated RIP-2 messages SHALL be discarded 🙅♀️. If the router IS configured to authenticate RIP-2 messages, then RIP-1 messages and RIP-2 messages that pass authentication testing SHALL be accepted, while unauthenticated and failed-authentication RIP-2 messages SHALL be discarded 💀. For maximum security, RIP-1 messages SHOULD be ignored when authentication is in use (see section 4.1). Otherwise, routing information from authenticated messages will be propagated by RIP-1 routers in an unauthenticated manner, and that's a whole mess 😭.
Since an authentication entry is marked with an Address Family Identifier of 0xFFFF, a RIP-1 system would ignore this entry because it belongs to an address family other than IP 🍓. So, it SHOULD be noted that using authentication will NOT stop RIP-1 systems from seeing RIP-2 messages. If you want that, it can be done using multicasting, as described in sections 4.5 and 5.1 🦋.
5.3. Larger Infinity 🌈
While we're on compatibility, there's one thing people have asked for: increasing infinity 🙋♀️. The main reason this CANNOT be done is that it would break backwards compatibility. A larger infinity would totally confuse older versions of rip. At best, they would ignore the route, the same way they'd ignore a metric of 16 💀. There was also a proposal to make the Metric a single octet and reuse the high three octets, but that would break any implementations that treat the metric as a 4-octet entity 😩.
5.4. Addressless Links 🌸
As in RIP-1, addressless links will NOT be supported by RIP-2 🚫.
6. Interaction between version 1 and version 2 🎀
Because version 1 packets don't contain subnet information, the semantics used by routers on networks that contain both version 1 and version 2 networks SHOULD be limited to those of version 1 🧚. Otherwise, it's possible to create blackhole routes (i.e., routes for networks that don't exist) or to create excessive routing information in a version 1 environment 😱.
Some implementations try to automatically summarize groups of adjacent routes into single entries, with the goal of reducing the total number of entries. This is called auto-summarization ✨.
Specifically, when using both version 1 and version 2 within a network, a single subnet mask SHOULD be used throughout the network. Also, auto-summarization mechanisms SHOULD be disabled for such networks, and implementations MUST provide mechanisms to disable auto-summarization 🫶.
7. Security Considerations 🔐💀
The basic RIP protocol is NOT a secure protocol, bestie, so we have to be real about that 😭. To bring RIP-2 in line with more modern routing protocols, an extensible authentication mechanism was added to the protocol enhancements. This mechanism is described in sections 4.1 and 5.2. Security is further enhanced by the mechanism described in [3] 🔥.
Appendix A 🍓
This is a simple example of how the next hop field gets used in a RIP entry 🧚.
----- ----- ----- ----- ----- -----
|IR1| |IR2| |IR3| |XR1| |XR2| |XR3|
--+-- --+-- --+-- --+-- --+-- --+--
| | | | | |
--+-------+-------+---------------+-------+-------+--
<-------------RIP-2------------->Assume IR1, IR2, and IR3 are all "internal" routers under one administration (e.g. a campus) that has chosen to use RIP-2 as its IGP. XR1, XR2, and XR3, on the other hand, are under a separate administration (e.g. a regional network, of which the campus is a member) and are using some other routing protocol (e.g. OSPF) 💅. XR1, XR2, and XR3 exchange routing information among themselves, so they know that the best routes to networks N1 and N2 are via XR1, to N3, N4, and N5 are via XR2, and to N6 and N7 are via XR3. By setting the Next Hop field correctly (to XR2 for N3/N4/N5, to XR3 for N6/N7), only XR1 needs to exchange RIP-2 routes with IR1/IR2/IR3 for routing to happen without additional hops through XR1 🦋. Without the Next Hop (for example, if RIP-1 were used), it would be necessary for XR2 and XR3 to also participate in the RIP-2 protocol to eliminate extra hops 😩.
References 📚
[1] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058,
Rutgers University, June 1988.
[2] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC
1389, January 1993.
[3] Baker, F., and R. Atkinson, "RIP-II MD5 Authentication", RFC
2082, January 1997.
[4] Bellman, R. E., "Dynamic Programming", Princeton University
Press, Princeton, N.J., 1957.
[5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks",
Prentice-Hall, Englewood Cliffs, N.J., 1987.
[6] Braden, R., and Postel, J., "Requirements for Internet Gateways",
STD 4, RFC 1009, June 1987.
[7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M.,
"Pup: An Internetwork Architecture", IEEE Transactions on
Communications, April 1980.
[8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks",
Princeton University Press, Princeton, N.J., 1962.
[9] Xerox Corp., "Internet Transport Protocols", Xerox System
Integration Standard XSIS 028112, December 1981.
[10] Floyd, S., and V. Jacobson, "The synchronization of Periodic
Routing Messages," ACM Sigcom '93 symposium, September 1993.
[11] Baker, F., "Requirements for IP Version 4 Routers." RFC 1812,
June 1995.Author's Address 🦋
Gary Scott Malkin
Bay Networks
8 Federal Street
Billerica, MA 01821
Phone: (978) 916-4237
EMail: gmalkin@baynetworks.comFull Copyright Statement 📜
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💖
📦 where this page comes from
- ietf: rfc2453 1998-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms