IP Router Alert Option (RFC2113)
Original Publication Date: 1997-Feb-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for, but not limited to, new protocols that are addressed to a destination but require relatively complex processing in routers along the path.
Network Working Group D. Katz
Request for Comments: 2113 cisco Systems
Category: Standards Track February 1997
IP Router Alert Option
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
This memo describes a new IP Option type that alerts transit routers
to more closely examine the contents of an IP packet. This is useful
for, but not limited to, new protocols that are addressed to a
destination but require relatively complex processing in routers
along the path.
A recent trend in routing protocols is to loosely couple new routing
functionality to existing unicast routing. The motivation for this
is simple and elegant -- it allows deployment of new routing
functionality without having to reinvent all of the basic routing
protocol functions, greatly reducing specification and implementation
The downside of this is that the new functionality can only depend on
the least common denominator in unicast routing, the next hop toward
the destination. No assumptions can be made about the existence of
more richly detailed information (such as a link state database).
It is also desirable to be able to gradually deploy the new
technology, specifically to avoid having to upgrade all routers in
the path between source and destination. This goal is somewhat at
odds with the least common denominator information available, since a
router that is not immediately adjacent to another router supporting
the new protocol has no way of determining the location or identity
of other such routers (unless something like a flooding algorithm is
implemented over unicast forwarding, which conflicts with the
One obvious approach to leveraging unicast routing is to do hop-by-
hop forwarding of the new protocol packets along the path toward the
ultimate destination. Each system that implements the new protocol
would be responsible for addressing the packet to the next system in
the path that understood it. As noted above, however, it is
difficult to know the next system implementing the protocol. The
simple, degenerate case is to assume that every system along the path
implements the protocol. This is a barrier to phased deployment of
the new protocol, however.
RSVP  finesses the problem by instead putting the address of the
ultimate destination in the IP Destination Address field, and then
asking that every RSVP router make a "small change in its ...
forwarding path" to look for the specific RSVP packet t...