RFC 2092

RFC 2092: Protocol Analysis for Triggered RIP 🦋✨

Who wrote it: Steve Sherry (Xyplex) and Gerry Meyer (Shiva) 👯‍♀️ Category: Informational 🎀 Date: January 1997 📅 Obsoletes / Updates: The header doesn't list either one. The body does propose that Demand RIP [5] be obsoleted (see Section 5), so keep that in mind. 🧐

---

Status of this Memo 💜

This memo gives info to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌸

Abstract 🔥

Okay so, as required by Routing Protocol Criteria [1], this report breaks down the key features of Triggered Extensions to RIP to Support Demand Circuits [2] and what the implementations have actually been like in the wild. 💅

The improved characteristics of Triggered RIP are so good that it's proposed Demand RIP [5] be obsoleted. Iconic glow-up energy 👑

Acknowledgements 🫶

The authors want to thank Johanna Kruger and Jim Pearl of Xyplex for many comments and suggestions that made this whole effort better. Real ones 💖

1. Protocol Documents 📚

"Triggered Extensions to RIP to Support Demand Circuits" [2] suggests an enhancement to the "Routing Internet Protocol" (RIP) [3] and "RIP-2" [4]. The goal is to let them run more cost-effectively on Wide Area Networks (WANs). 🌈

2. Applicability 🎯

Triggered RIP requires that there is an underlying mechanism for determining unreachability in a finite predictable period. No cap, that's a big requirement ⏳

The triggered extensions to RIP are especially giving for WANs where the cost, whether that's money or packet overhead, would make periodic routing (or service advertising) updates unacceptable. The two main examples:

• Connection oriented Public Data Networks, for example X.25 packet switched networks or ISDN.
• Point-to-point links supporting PPP link quality monitoring or echo request to determine link failure.

A triggered RIP implementation runs standard RIP on Local Area Networks (LANs). That means it interoperates transparently with implementations that follow the original specifications. Bestie, that's the friendship goal 🫶

3. Key Features ✨

The proposal shares the same basic algorithms as RIP or RIP-2 when running on LANs. Packet formats, broadcast frequency, triggered update operation and database timeouts are all unmodified. Same vibes, no drama 💅

The new features operate on WANs that use switched circuits on demand to get intermittent connectivity. They also work on permanent WAN connections where you want to keep routing packet overhead to a minimum. Instead of periodic 'broadcasts', information only gets sent as triggered updates. The proposal also uses features of the underlying connection oriented service to give feedback on connectivity. Efficient, obsessed 😭

3.1 Triggered Updates 🌟

Updates are only sent on the WAN when an event changes the routing database. Each update gets retransmitted until it's acknowledged. Information received in an update is not timed out. Never ghosted, always remembered 🧚

The packet format of a RIP response is modified (with a different unique command field) so it can include sequence number information. There's also a brand new acknowledgement packet. 🍓

3.2 Circuit Manager 🔌

The circuit manager runs below the IP network layer. It's responsible for establishing a circuit to the next hop router whenever there's data (or a routing update) to transfer. After a period of inactivity, the circuit manager closes the circuit. Bye bye, quiet connection 👋

If the circuit manager fails to make a connection, a circuit down indication gets sent to the routing application. The circuit manager then keeps trying to connect at (increasing) intervals. When it finally succeeds, a circuit up indication gets sent to the routing application. Persistence is the whole vibe 💪

3.3 Technology Restrictions ⚠️

Heads up, this section is serious. Read it carefully, bestie 🙈

There is a small but nontrivial possibility of an incorrectly configured or poorly operating link causing severe data loss, which results in a 'black hole' in routing. This is often unidirectional. The link that route updates cross works fine, but the return path doesn't. 💀

Triggered RIP will NOT function properly (and should NOT be used) if routing information will be retained or advertised for an arbitrarily long period of time (until an update in the opposite direction fails to get a response). Not me reading that and going "absolutely not" 😭

To detect black holes in technologies that use PPP encapsulation, either Echo Request/Response or Link Quality Monitoring should be used. When a black hole is detected, a circuit down indication must be sent to the routing application. Detect it, report it, no exceptions 🚨

Current (and future) technologies that don't use PPP need to use an equivalent 'are-you-there' mechanism, or they should NOT be used with Triggered RIP. Iykyk 🙃

3.4 Presumption of Reachability 🔮

In a stable network there's no requirement to propagate routing information on a circuit. So if no routing information is (being) received on a circuit, it's assumed that:

• The most recently received information is accurate.
• The intervening path is operational (although there may be no current connection).

If the circuit manager determines that the intervening path is NOT operational, routing information previously received on that circuit gets timed out. It's worth stressing that it can be ANY routed datagram that triggers the event. Main character energy from literally any packet 🎬

When the circuit manager re-establishes a connection, the application exchanges full routing information with its peer. Catching up after a long time apart 🥹

3.5 Routing Information Flow Control 🚦

If the circuit manager reports a circuit as down, the routing application gets flow controlled and can't send further information on that circuit. Pause, bestie 🛑

4. Relationship to Demand RIP ⚖️

The Triggered RIP proposal [2] has a bunch of efficiency advantages over the Demand RIP proposal [5]. Let's compare 👀

• When routing information changes, Demand RIP sends the full database to its partner.

Once a router has exchanged all routing information with its partner, Triggered RIP sends only the changed information. This can dramatically decrease how much information needs propagating when a route change happens. Why send the whole thing when you only changed one thing? 🙄

• Demand RIP requires a full routing update to be stored by the receiver before it applies changes to the routing database.

A Triggered RIP receiver can apply all changes immediately upon receiving each packet from its partner. So systems need less memory than they would with Demand RIP. Lightweight queen 👸

• Demand RIP has an upper limit of 255 fragments in an update. That sets an upper limit on the sizes of routing and service advertising databases that can be propagated.

This restriction is lifted in Triggered RIP, which doesn't use fragmentation. Freedom 🕊️

In all other respects, Demand RIP and Triggered RIP perform the same function. Same job, better outfit 💅

5. Obsoleting Demand RIP 🪦

It's possible that systems could support both Demand RIP and Triggered RIP. But the internal maintenance of structures is likely to differ significantly, and the method of propagating the information also differs significantly. In practice, it's unlikely that systems would support both. Two different lives can't really live in one body 😅

The improved characteristics of Triggered RIP are the reason it's proposed that Demand RIP [5] be obsoleted. Glow-up complete 🦋

6. Implementations 🛠️

At this stage, there are believed to be two completed implementation. Two is giving "we did it" 🥳

The Xyplex implementation supports all the features outlined for IP RIP-1, IP RIP-2, IPX RIP, and IPX SAP. However, it only supports one outstanding acknowledgement per partner. It was tested against itself on X.25, ISDN, Frame Relay, V42bis CSU/DSUs, and asynchronous modems. It was also tested in operation with various router and host implementations on Ethernet LANs. Tested, tried, and true 🔥

The DEC implementation supports IP RIP-1 over ISDN, Frame Relay, leased lines and V.25bis. The Xyplex and DEC IP RIP-1 implementations have been checked for interoperability over ISDN without problems. They get along, periodt 🤝

7. Restrictions 🚧

Demand RIP relies on the ability to place a call in either direction. Some dialup services, like DTR dialing, only allow calls to be made in one direction. Ouch 🙈

Demand RIP can't operate with third-party advertisement of routes on the WAN. The next hop IP address in RIP-2 should always be 0.0.0.0 for any routes advertised on the WAN. Keep it clean, keep it 0.0.0.0 💖

8. Security Considerations 🔐

Okay, this part is dramatic and I'm so here for it 😤

Security comes from authenticating both the logical and physical address of the sender of the routing update. Incoming call requests are matched by the circuit manager against a list of physical addresses (the ones used to make outgoing calls). The routing application then does a further check against the logical address of an incoming update. Double-checked, no sneaking in 🕵️‍♀️

Additional security can be provided by RIP-2 authentication [2] where appropriate. Extra lock, extra slay 🔒✨

References 📖

[1] Hinden, R., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, Bolt Beranek and Newman, Inc, October 1991.

[2] Meyer. G.M. and Sherry, S., "Triggered Extensions to RIP to Support Demand Circuits", RFC 2091, Shiva and Xyplex, Aug 1995.

[3] Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers University, June 1988.

[4] Malkin. G., "RIP Version 2 - Carrying Additional Information", RFC 1723, Xylogics, November 1994.

[5] Meyer. G., "Extensions to RIP to Support Demand Circuits", Spider Systems, February 1994.

Authors' Address 📬

Steve Sherry
Xyplex
295 Foster St.
Littleton, MA 01460

Phone: (US) 508 952 4745
Fax:   (US) 508 952 4887
Email: shs@xyplex.com

Gerry Meyer
Shiva Europe Ltd
Stanwell Street
Edinburgh EH6 5NG
Scotland, UK

Phone: (UK) 131 561 4223
Fax:   (UK) 131 561 4083
Email: gerry@europe.shiva.com

That's the whole spec, babe. Iconic work from these two 🌈💜