RFC 1581

RFC 1581 🎀 Protocol Analysis for Extensions to RIP to Support Demand Circuits

• Network Working Group 🌸
• Author: G. Meyer (Gerry Meyer) of Spider Systems 🧚
• Category: Informational 📚
• Date: February 1994 📅
• Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🙅‍♀️

---

Status of This Memo ✨

This doc is giving information for the Internet community 💅. It does not specify an Internet standard of any kind, and distribution is unlimited, so share it with your whole group chat 🫶.

Abstract 🦋

Okay so, as Routing Protocol Criteria [1] requires, this report breaks down the key features of Routing over Demand Circuits on Wide Area Networks, which is RIP [2], plus what implementers have actually done with it so far 💖.

Acknowledgements 🫶

Huge thanks to my colleagues at Spider, especially Richard Edmonstone and Alan Turland. They built Spider's IP RIP, IPX RIP and SAP implementations and they are literally the reason this exists 👑.

---

1. Protocol Documents 📚

"Extensions to RIP to Support Demand Circuits" [2] suggests an upgrade to the "Routing Internet Protocol" (RIP) [3] and "RIP-2" [4] so they can run more cost-effectively on Wide Area Networks (WANs) 💸. Network management extensions for Demand RIP are described in RIP Version 2 MIB Extensions [5] 🧚.

2. Applicability 🎯

Bestie, Demand RIP needs an underlying mechanism that can figure out unreachability within a finite, predictable period 💀.

Demand extensions are a perfect fit for WANs where the cost, whether that's money or packet overhead, would make sending routing (or service advertising) updates on a regular schedule totally unacceptable 🙈:

• 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 demand RIP implementation runs standard RIP on Local Area Networks (LANs), so it can interoperate transparently with implementations that stick to the original specifications 🫶.

3. Key Features 🔥

The proposal shares the same basic algorithms as RIP or RIP-2 when it's running on LANs or fixed point-to-point links. Packet formats, broadcast frequency, triggered update operation and database timeouts are all unmodified, so nothing changes there 🌈.

The new features work on WANs that use switched circuits on demand to get intermittent connectivity. Instead of sending periodic 'broadcasts', information is only sent as triggered updates. The proposal also uses features of the underlying connection oriented service to get feedback on connectivity, which is so smart 🧠✨.

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 🦋.

The packet format of a RIP response is modified, with a different unique command field, to include sequence and fragment number information. An acknowledgement packet is also defined 📦.

3.2 Circuit Manager

The circuit manager runs below the IP network layer and is responsible for setting up 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 📞.

If the circuit manager fails to make a connection, a circuit down indication gets sent to the routing application. The circuit manager then tries again at (increasing) intervals to establish a connection. When it succeeds, a circuit up indication gets sent to the routing application 🔁.

3.3 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, the 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 👀.

When the circuit manager re-establishes a connection, the application exchanges full routing information with its peer 🤝.

3.4 Routing Information Flow Control 🚦

If the circuit manager reports a circuit as down, the routing application is flow controlled and stops sending further information on that circuit.

To prevent transmit queue overflow, and also to avoid 'predictable' circuit down messages, the routing application can also optionally limit the rate at which it sends routing messages to an interface 💅.

---

4. Implementations 🛠️

At this stage there is only believed to be one completed implementation 🙃.

The Spider Systems' implementation supports all the features outlined for IP RIP-1, IPX RIP and IPX SAP. RIP-2 is not currently supported. It's been tested against itself on X.25 and ISDN WANs, and it's also been tested in operation with various router and host RIP-1, IPX RIP and IPX SAP implementations on Ethernet LANs 🧪.

Two other Novell-only implementations are known to be under development 👀.

5. 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 📵.

Demand RIP can not 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 🙅‍♀️.

6. Security Considerations 🔐

Okay, security is serious here, so pay attention. Security is provided through authentication of both the logical and the 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 makes a further check against the logical address of an incoming update 🔒.

Additional security can be provided by RIP-2 authentication [2] where appropriate 🫶.

7. 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., "Extensions to RIP to Support Demand Circuits", RFC 1582, Spider Systems, February 1994.
• [3] Hedrick. C., "Routing Information Protocol", STD 34, RFC 1058, Rutgers University, June 1988.
• [4] Malkin. G., "RIP Version 2 - Carrying Additional Information", RFC 1388, Xylogics, January 1993.
• [5] Malkin. G., and F. Baker, "RIP Version 2 MIB Extensions", RFC 1389, Xylogics, ACC, January 1993.

Author's Address 📮

• Gerry Meyer
• Spider Systems
• Stanwell Street
• Edinburgh EH6 5NG
• Scotland, UK
• Phone: (UK) 31 554 9424
• Fax: (UK) 31 554 0649
• EMail: gerry@spider.co.uk