RFC 2113

RFC 2113: IP Router Alert Option 🎀

okay bestie, so this is the paperwork for the IP Router Alert Option 💅 It's from the Network Working Group, written by D. Katz (Dave Katz) at cisco Systems. It's Request for Comments: 2113, the category is Standards Track, and it's dated February 1997. The title block doesn't list anything it obsoletes or updates, so it stands on its own 🦋

Status of This Memo 📜

This is an Internet standards track protocol for the Internet community, and it's basically asking for everyone to talk about it and suggest improvements 🗣️ If you want the official standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) ✨ Also, distribution of this memo is unlimited, so share it with everyone 💖

Abstract 🌸

This memo introduces a brand new IP Option type that tells transit routers to take a closer look at what's inside an IP packet 👀 It's really useful for new protocols that are addressed to one destination but need pretty complex processing from the routers along the path, and it's not limited to just that 🧚

1.0 Introduction ✨

Okay so, a recent trend in routing protocols is to loosely couple new routing functionality to existing unicast routing 🎀 The reason this is so iconic is that it lets you deploy new routing features without reinventing all the basic routing protocol functions, which seriously cuts down on the specification and implementation complexity 🙌

The catch is that the new stuff can only rely on the least common denominator in unicast routing, which is just the next hop toward the destination 😭 You can't assume anything about more detailed info, like a link state database 💀

It's also important to be able to gradually deploy the new tech, so you don't have to upgrade every single router between the source and destination 🫶 That goal kind of clashes with the least common denominator info, though, because a router that isn't directly next to another router supporting the new protocol has no way to figure out where those other routers are or who they are (unless you do something like a flooding algorithm over unicast forwarding, which goes against the simplicity goal) 🙈

One obvious approach is hop-by-hop forwarding of the new protocol packets along the path toward the ultimate destination 🍓 Every system that implements the new protocol would be responsible for addressing the packet to the next system in the path that understood it. But like we said, it's hard to know which system is the next one implementing the protocol 😤 The simple, degenerate case is to assume that every system along the path implements the protocol, and that's a real barrier to phased deployment ✋

RSVP [1] finesses this problem by putting the address of the ultimate destination in the IP Destination Address field instead 🧚 Then it asks every RSVP router to make a "small change in its ... forwarding path" so it can look for the specific RSVP packet type, pull those packets out of the mainline forwarding path, do local processing, and then forward them on 💅 This is a major perk because it allows automatic tunneling through routers that don't understand RSVP, since the packets just naturally flow toward the ultimate destination 🦋 The problem is that the performance cost of making this Small Change might be unacceptable 💀 Mainline forwarding paths in routers are super tuned, and even adding a single instruction can cost hundreds of packets per second in performance 📉

2.0 Router Alert Option 🔥

So the goal is to give routers a way to intercept packets that aren't addressed to them directly, without taking a significant performance hit 👑 This document defines a new IP option type, Router Alert, to do exactly that ✨

The Router Alert option has the semantic "routers should examine this packet more closely" 👀 By including it in the IP header of its protocol message, RSVP can get the message intercepted while causing little or no performance penalty on normal data packets 💖

Routers that support option processing in the fast path already demultiplex processing based on the option type field 🎀 If every option type is supported in the fast path, adding one more option type to process probably won't hurt performance 🌈 If some option types aren't supported in the fast path, this new option type will be unrecognized and get kicked out into the slow path. So no change to the fast path is needed, and regular data packets don't take any performance penalty 🫶

Routers that don't support option processing in the fast path will send packets carrying this new option through the slow path, so again, no fast path change is needed and no performance penalty hits regular data packets ✨

2.1 Syntax 🧚

The Router Alert option has the following format:

             +--------+--------+--------+--------+
             |10010100|00000100|  2 octet value  |
             +--------+--------+--------+--------+

Type:
  Copied flag:  1 (all fragments must carry the option)
  Option class: 0 (control)
  Option number: 20 (decimal)

Length: 4

Value:  A two octet code with the following values:
  0 - Router shall examine packet
  1-65535 - Reserved

2.2 Semantics 💅

Here's the vibe: Hosts SHALL ignore this option. Routers that do not recognize this option SHALL ignore it. Routers that do recognize it SHALL examine packets carrying it more closely (like checking the IP Protocol field, for example) to figure out whether further processing is necessary 🔍 Unrecognized value fields SHALL be silently ignored 🤫

The semantics of the other values in the Value field are still for further study 🔮

3.0 Impact on Other Protocols 🦋

For this option to be effective, its use MUST be mandated in protocols that expect routers to do significant processing on packets not directly addressed to them 🎀 Right now, those protocols include RSVP [1] and IGMP [2] 💖

4.0 Security Considerations 🔥

⚠️ Please read this one carefully, it matters 💀

If the Router Alert option is not set when it SHOULD be set, the behavior of the protocol using the Router Alert (like RSVP or IGMPv2) will be adversely affected 😭 That's because the protocol relies on the Router Alert option being used.

If the Router Alert option is set when it SHOULD NOT be set, the flow will likely experience a performance penalty 📉 A packet whose Router Alert option is set won't go through the router's fastpath, so it gets processed in the router more slowly than if the option weren't set 🐢

5.0 References 📚

[1] Braden, B. (ed.), L. Zhang, D. Estrin, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP)," work in progress, March 1996.

[2] Fenner, W., "Internet Group Management Protocol, Version 2 (IGMPv2)," work in progress, October 1996.

Author's Address 🌈

Dave Katz cisco Systems 170 W. Tasman Dr. San Jose, CA 95134-1706 USA

Phone: +1 408 526 8284 Email: dkatz@cisco.com