RFC 1722

RIP Version 2 Protocol Applicability Statement 🦋

okay bestie, the title block is giving paperwork 📄💅 so here's the tea:

• Series: Network Working Group 🌸
• Request for Comments: 1722 ✨
• Author: G. Malkin (that's Gary Scott Malkin) from Xylogics, Inc. 🧚
• Category: Standards Track 👑
• Date: November 1994 🍓
• Obsoletes: RFC 1388, which specifies an update to the "Routing Information Protocol" RFC 1058 (STD 34) 🔥
• Will obsolete: RFC 1389 💜

Status of This Memo ✨

okay so this is an Internet standards track protocol for the whole Internet community 🌈 it's literally asking for discussion and suggestions for improvements, so speak up 🫶 for the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📜 and distribution of this memo is unlimited, so share it freely 💖

Abstract 🌸

as required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIP-2 protocol within the Internet ⭐ it's a prerequisite to advancing RIP-2 on the standards track, so it's kind of a big deal 😭

1. Protocol Documents 🎀

the RIP-2 protocol analysis is documented in RFC 1721 [1] 📚

the RIP-2 protocol description is defined in RFC 1723 [2] 💅 this memo obsoletes RFC 1388, which specifies an update to the "Routing Information Protocol" RFC 1058 (STD 34) 👑

the RIP-2 MIB description is defined in RFC 1724 [3] 🦋 this memo will obsolete RFC 1389 ✨

2. Introduction 💖

okay so this report is all about how RIP-2 can be useful within the Internet 🌸 the environments where RIP-2 is the IGP of choice are a superset of the environments where RIP-1, as defined in RFC 1058 [1], has traditionally been used 🧚 and it's important to remember that RIP-2 is an extension to RIP-1. RIP-2 is not a new protocol! 🙈 so the operational aspects of distance-vector routing protocols, and RIP-1 in particular, within an autonomous system are well understood 💜

RIP-2 is not intended to be a substitute for OSPF in large autonomous systems 😬 the restrictions on AS diameter and complexity that applied to RIP-1 also apply to RIP-2. instead, RIP-2 lets the smaller, simpler, distance-vector protocol work in environments that need authentication or variable length subnet masks, but aren't big or complicated enough to need the larger, more complex, link-state protocol 🍓

the rest of this report covers how each of the extensions to RIP-1 may be used to increase the overall usefulness of RIP-2 🫶

3. Extension Applicability 🧚

3.1 Subnet Masks 🍓

okay so the original reason RIP-2 was created was to include subnet masks in the routing information exchanged by RIP 💅 this was needed because subnetting wasn't defined when RIP was first created 🙈 as long as the subnet mask was fixed for a network and well known by all the nodes on that network, a heuristic could be used to figure out if a route was a subnet route or a host route. but with variable length subnetting, CIDR, and supernetting, a heuristic could no longer reasonably tell network, subnet, and host routes apart 😭

by using the 32-bit field immediately following the IP address in a RIP routing entry, it became possible to positively identify a route's type ✨ in fact, you could even say that including the subnet mask effectively creates a 64-bit address that eliminates the network, subnet, host distinction 🌈

so including subnet masks in RIP-2 lets it be used in an AS that needs precise knowledge of the subnet mask for a given route, but doesn't otherwise need OSPF 👑

3.2 Next Hop 🦋

the purpose of the Next Hop field is to stop packets from being routed through extra hops in the system 💖 it's especially useful when RIP isn't running on all of the routers on a network. here's an example topology:

      -----   -----         -----   -----
      |IR1|   |IR2|         |XR1|   |XR2|
      --+--   --+--         --+--   --+--
        |       |             |       |
      --+-------+-------------+-------+--
        |--------RIP-2--------|

the Internal Routers (IR1 and IR2) are only running RIP-2 🧚 the External Routers (XR1 and XR2) are both running BGP, for example. however, only XR1 is running BGP and RIP-2 💅 since XR2 isn't running RIP-2, the IRs won't know it exists and will never use it as a next hop, even if it's a better next hop than XR1 😬 but XR1 knows this and can indicate, via the Next Hop field, that XR2 is the better next hop for some routes 👑

there's another use for Next Hop too 🌸 check out this topology:

           -----
           |COR|
           -----
           /   \
          /     \
      -----     -----     -----
      |RO1|-----|RO2|=====| R |
      -----     -----     -----

the three links between the Central Office Router (COR) and the Remote Office routers (RO1 and RO2) are all Dial-On-Demand (DOD) links 📞 the link between RO2 and R is a fixed link. once all the routers have been initialized, the only routes they know about are the configured static routes for the DOD links 🙈 say connections between COR and RO1, and COR and RO2, are established and RIP information is passing between the routers. RO1 will ignore COR's route to RO2 because it already has a better one, but it will learn to reach R via COR 🫶

if we assume RO1 and RO2 can only establish one link at a time, then RO1 won't be able to reach RO2, but RO1 will be able to reach R 😭 worse still, if we assume traffic stops and the DOD links drop due to inactivity, an attempt by RO1 to reach R will trigger the dialing of two links (through COR) 💀 but once RO1 establishes a link to RO2, the problem fixes itself because the new route to R is one hop shorter ✨

to fix this, the routers may use the Next Hop field to indicate their next hop. here are the route advertisements during the period described above (before the RO1/RO2 link has ever been established):

   Sender  Recvr   Route   NextHop  Metric
   =======================================
   RO2     COR     R       0        1
   ---------------------------------------
   COR     RO1     RO2     0        1
                   R       RO2      2
   ---------------------------------------

when RO1 gets the two routes from COR, it ignores the route for RO2, as mentioned above 🧚 but since R isn't in RO1's routing table, it adds it using a next hop of RO2 (because RO2 is directly connected, after a fashion) 💖 note that COR counts itself in R's metric. this is less than accurate, but totally safe and correctable (when the RO1/RO2 link comes up) 🌈 now suppose the RO1/RO2 link didn't exist. RO1 would ignore the specification of RO2 as the next hop to R and use COR, just like it would if no Next Hop had been specified 🍓

heads up: this isn't a recursive algorithm. it only works to eliminate a single extra hop from the path. there are ways this mechanism might be extended to include bigger optimizations, but the potential to create routing loops hasn't been sufficiently analyzed to specify them here ⚠️

3.3 Authentication 🔐

the need for authentication in a routing protocol is obvious 💅 it's usually not important to conceal the information in the routing messages, but it's essential to prevent bogus routing information from being inserted into the routers 😤 so while the authentication mechanism specified in RIP-2 is less than ideal, it does stop anyone who can't directly access the network (someone who can't sniff the routing packets to find the password) from inserting bogus routing information 🛡️

the specification does allow for additional types of authentication to be added to the protocol 🌸 unfortunately, because of the original format of RIP packets, the amount of space available for authentication information is only 16 octets 😭

3.4 Multicasting 📡

RIP-2 provides for the IP multicasting of periodic advertisements 🦋 this feature was added to decrease the load on systems that don't support RIP-2. it also provides a mechanism where RIP-1 routers will never receive RIP-2 routes 🙈 that's a feature when correct use of an advertised route depends on knowing the precise subnet mask, which a RIP-1 router would ignore 💜

4. Conclusion 👑

because the basic protocol is unchanged, RIP-2 is as correct a routing protocol as RIP-1 💖 the enhancements make RIP-2 useful in environments RIP-1 couldn't handle, but that don't need OSPF because of requirements RIP-2 doesn't satisfy 🌈

5. References 📚

• [1] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721, Xylogics, Inc., November 1994.
• [2] Malkin, G., "RIP Version 2 - Carrying Additional Information", RFC 1723, Xylogics, Inc., November 1994.
• [3] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC 1724, Xylogics, Inc., Cisco Systems, November 1994.

6. Security Considerations 💀

plot twist: security issues are not discussed in this memo. zero. not a single word. 😱

7. Author's Address 🧚

Gary Scott Malkin
Xylogics, Inc.
53 Third Avenue
Burlington, MA 01803

Phone: (617) 272-8140 📞 Email: gmalkin@Xylogics.COM 💌

---

that's the whole RFC, bestie! 🌈✨ RIP-2 is an extension, not a new protocol 💖