RFC 1723
RIP Version 2 - Carrying Additional Information
RIP Version 2 🎀
okay bestie, let's talk about RFC 1723 🦋 It's called RIP Version 2: Carrying Additional Information and G. Malkin from Xylogics, Inc. wrote it in November 1994 🧚 It's a Standards Track doc in the Network Working Group stream, so it's giving official protocol energy 💅 It obsoletes RFC 1388 and updates RFC 1058 🌈 Lowkey the whole thing is a glow-up for RIP 💖
Status of this Memo 📜
This doc specifies an Internet standards track protocol for the Internet community, and it's asking everyone for discussion and suggestions for improvements 💬 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) ✨ Distribution of this memo is unlimited, so share it with your whole group chat 🫶
Abstract ✨
Okay so this doc extends the Routing Information Protocol (RIP), as defined in [1,2], to pack more useful info into RIP messages and add a little bit of security 🔐 It obsoletes RFC 1388, which was an update to the "Routing Information Protocol" STD 34, RFC 1058 💅
The RIP-2 protocol analysis is documented in RFC 1721 [4] 📚
The RIP-2 applicability statement is documented in RFC 1722 [5] 🌸
The RIP-2 MIB description is defined in RFC 1724 [3] 🍓 This memo obsoletes RFC 1389 💀
Acknowledgements 🫶
I'd love to thank the IETF ripv2 Working Group for helping make the RIP-2 protocol better. Y'all are iconic 👑
Table of Contents 📚
1. Justification . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Next Hop . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . 5
3.6 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Compatibility Switch . . . . . . . . . . . . . . . . . . . . 6
4.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Larger Infinity . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Addressless Links . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 91. Justification ✨
Okay, so when OSPF and IS-IS showed up, some people decided RIP was obsolete 🙄 Honestly the newer IGP routing protocols are way superior to RIP, but RIP still has some main-character advantages 💅 Mainly, in a small network, RIP has very little overhead in terms of bandwidth used and configuration and management time 🌿 It's also super easy to implement, especially compared to the newer IGPs 🍓
Also, there are many, many more RIP implementations out in the field than OSPF and IS-IS combined 😭 That's probably going to stay true for some years yet 🦋
So since RIP is going to be useful in lots of environments for a while, it makes total sense to make RIP more useful 🧚 This is especially true since the gain is way bigger than the cost of the change 💖
2. Current RIP 🌸
The current RIP message only carries the bare minimum info that routers need to route messages through a network 🫠 It also has a ton of unused space, which is giving history, because of where it came from 📜
The current RIP protocol doesn't think about autonomous systems, IGP/EGP interactions, subnetting, or authentication, since those were implemented after RIP existed 💀 The lack of subnet masks is a seriously big problem for routers, because they need a subnet mask to figure out how to determine a route 😩 If a RIP route is a network route (all non-network bits 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 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 over, and then work out the route type from that 🫠
3. Protocol Extensions 🧚
This doc doesn't change the RIP protocol per se 🌈 Instead, it adds extensions to the message format so routers can share important extra info 💖
The first four octets of a RIP message are the RIP header ✨ The rest of the message is made up of 1 - 25 route entries (20 octets each) 🎀 The new RIP message format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command (1) | Version (1) | unused |
+---------------+---------------+-------------------------------+
| Address Family Identifier (2) | Route Tag (2) |
+-------------------------------+-------------------------------+
| IP Address (4) |
+---------------------------------------------------------------+
| Subnet Mask (4) |
+---------------------------------------------------------------+
| Next Hop (4) |
+---------------------------------------------------------------+
| Metric (4) |
+---------------------------------------------------------------+The Command, Address Family Identifier (AFI), IP Address, and Metric all mean what they meant in RFC 1058 🍓 The Version field is set to version number 2 for RIP messages that use authentication or carry info in any of the newly defined fields 🔥 The contents of the unused field (two octets) SHALL be ignored 🙈
All fields are coded in IP network byte order (big-endian) 💅
3.1 Authentication 🔐
Authentication is a per message function 🫶 There's only one 2-octet field available in the message header, and any reasonable authentication scheme needs more than two octets, so RIP version 2 uses the space of an entire RIP entry for it 💫 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 remainder 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 begins 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 to the right with nulls (0x00) 💜
3.2 Route Tag 🏷️
The Route Tag (RT) field is an attribute assigned to a route, and it MUST be preserved and readvertised along with the route 🎀 The whole point of the Route Tag is to separate "internal" RIP routes (routes for networks inside the RIP routing domain) from "external" RIP routes, which 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 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 every router in the RIP domain uses it consistently 🫶 That leaves room for a BGP-RIP protocol interactions document, which would describe ways to sync routing in a transit network 🌈
3.3 Subnet mask 🎀
The Subnet Mask field holds the subnet mask that gets applied to the IP address to find the non-host portion 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 the info in 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 👀
- Supernet routes (routes with a netmask less specific than the "natural" network mask) MUST NOT be advertised where RIP-1 routers could misinterpret them 💀
3.4 Next Hop 🦋
The Next Hop field 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 through whoever originated the RIP advertisement 🍓 An address specified as a next hop MUST, per force, be directly reachable on the logical subnet the advertisement is sent over 💅
The whole purpose 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 in a network 😤 There's a simple example in Appendix A ✨ Note that Next Hop is an "advisory" field 🫶 So if the info gets ignored, a possibly sub-optimal, but totally valid, route may be taken 🌈 If the received Next Hop isn't directly reachable, it SHOULD be treated as 0.0.0.0 🙌
3.5 Multicasting 📣
To cut down on pointless load on hosts that aren't listening to RIP-2 messages, an IP multicast address gets used for periodic broadcasts 🌸 That address is 224.0.0.9 💖 IGMP isn't needed here, since these are inter-router messages that never get forwarded 🙅♀️
For backwards compatibility, the multicast address use is configurable, as described in section 4.1 🎀 If multicasting is used, it SHOULD be used on all interfaces that support it ✨
3.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 🙈
4. Compatibility ✨
okay so RFC 1058 was SO thoughtful about version numbers 🧠💖. Here's the vibe: RIP messages of version 0 MUST be discarded, and RIP messages of version 1 MUST be discarded if any Must Be Zero (MBZ) field is non-zero. But messages of any version greater than 1 SHOULD NOT be discarded just because an MBZ field has a non-zero value 🫶. That's why the new version is totally backwards compatible with existing RIP implementations that follow this part of the spec. Slay the foresight 👑.
4.1. Compatibility Switch 🎀
okay this one is lowkey important 😭. A compatibility switch is REQUIRED for two reasons. First, there are RIP-1 implementations out in the wild that don't follow RFC 1058 the way I just described 💀. Second, multicasting would stop RIP-1 systems from receiving RIP-2 updates, and sometimes that's actually what you want 🦋. 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 sending RIP messages altogether 🙈. The RECOMMENDED default is RIP-1 compatibility ✨.
For completeness, routers SHOULD also implement a receive control switch 🧚. It decides whether to accept RIP-1 only, RIP-2 only, both, or none. This one should also be configurable on a per-interface basis 🍓.
4.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 MUST be discarded 🙅♀️. If the router IS configured to authenticate RIP-2 messages, then RIP-1 messages and RIP-2 messages that pass authentication testing MUST be accepted, and unauthenticated and failed-authentication RIP-2 messages MUST be discarded 😤. For maximum security, RIP-1 messages SHOULD be ignored when authentication is in use (see Section 4.1) 🔥.
Here's the tea ☕: an authentication entry is marked with an Address Family Identifier of 0xFFFF. A RIP-1 system would ignore that entry because it belongs to an address family other than IP 🙃. So it's worth knowing that using authentication will NOT stop RIP-1 systems from seeing RIP-2 messages. If you want that, you can do it with multicasting, as described in Sections 3.5 and 4.1 🦋.
4.3. Larger Infinity 🌈
okay while we're on compatibility, people have asked for one thing: a bigger infinity 🥺. The main reason this can't happen is that it would break backwards compatibility 💔. A larger infinity would totally confuse older versions of RIP. At best, they'd ignore the route the same way they 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 💀.
4.4. Addressless Links 🍂
as in RIP-1, addressless links will NOT be supported by RIP-2 🙅♀️.
5. Security Considerations 🛡️
bestie, the basic RIP protocol is NOT a secure protocol 😬. To bring RIP-2 in line with more modern routing protocols, an extensible authentication mechanism was added to the protocol enhancements 🔐. You can read about it in Sections 3.1 and 4.2 💅.
Appendix A 📖
This is a simple example of how the next hop field works in a RIP entry 🦋.
----- ----- ----- ----- ----- -----
|IR1| |IR2| |IR3| |XR1| |XR2| |XR3|
--+-- --+-- --+-- --+-- --+-- --+--
| | | | | |
--+-------+-------+---------------+-------+-------+--
<-------------RIP-2------------->okay so assume IR1, IR2, and IR3 are all "internal" routers under one administration (e.g. a campus) that chose RIP-2 as its IGP 🎓. XR1, XR2, and XR3 are under a separate administration (e.g. a regional network that the campus is a member of) and use some other routing protocol (e.g. OSPF) 🌍. XR1, XR2, and XR3 trade routing info among themselves, so they know the best routes to networks N1 and N2 go via XR1, to N3, N4, and N5 via XR2, and to N6 and N7 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, and routing still happens without extra hops through XR1 🙌. Without the Next Hop (for example, if RIP-1 were used), XR2 and XR3 would ALSO have to participate in the RIP-2 protocol to get rid of those extra hops 😩.
References 📚
[1] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058, Rutgers University, June 1988.
[2] Malkin, G., "RIP Version 2 - Carrying Additional Information", RFC 1388, Xylogics, Inc., January 1993.
[3] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC 1724, Xylogics, Inc., Cisco Systems, November 1994.
[4] Malkin, G., "RIP Version 2 Protocol Analysis", RFC 1721, Xylogics, Inc., November 1994.
[5] Malkin, G., "RIP Version 2 Protocol Applicability Statement", RFC 1722, Xylogics, Inc., November 1994.
Author's Address 🌸
Gary Scott Malkin Xylogics, Inc. 53 Third Avenue Burlington, MA 01803
Phone: (617) 272-8140 EMail: gmalkin@Xylogics.COM
📦 where this page comes from
- ietf: rfc1723 1994-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms