Summary

  • RFC 2113 defined a four-octet IPv4 option that asks transit routers to examine a packet more closely without making every packet pay the same classification cost.
  • RFC 6398 later showed why that privilege belongs inside controlled trust boundaries rather than as an end-to-end dependency across the open Internet.

Attention carried inside the packet

Ordinary forwarding asks a router to read enough header state to choose the next hop. RSVP and IGMP presented a different problem: some packets not addressed to the router still required significant work from routers along the path. Inspecting every packet deeply would have taxed the fast path. RFC 2113 instead made the exception visible.

Router Alert is four octets. Type 148 encodes a copied control option numbered 20; the next octet says the length is 4; the final two octets hold a value. The original value zero meant that the router should examine the packet. Values 1 through 65535 were reserved.

The instruction stops short of naming an application. A recognizing router looks more closely—perhaps at the IP Protocol field—and then decides whether further processing is necessary. Hosts ignore the option. Routers that do not recognize it ignore it, and recognizing routers silently ignore unknown values. The mark requests classification; it does not authenticate the sender or prove that scarce processing is deserved.

RFC 2113 already contained the tradeoff. A dependent protocol can malfunction if the option is omitted. A packet marked without need can leave the fast path and move more slowly. The design protected ordinary traffic from universal inspection by creating an explicit door to exceptional work.

The door became an attack surface

RFC 6398 documented the consequence. Implementations may punt most or all marked traffic into a slow path shared by control-plane applications. A flood of unwanted Router Alert packets can consume that capacity and cause unrelated control traffic to be dropped. Unlike a relationship with a pre-identified routing peer, an IPv4 packet bearing Router Alert may arrive with arbitrary source and destination addresses.

Triage is difficult. The next protocol number cannot always separate applications that share a transport. The two-octet Router Alert value gained an IANA registry, but it still offers only coarse discrimination, and implementations have not treated it uniformly. The option therefore does not supply a universal boundary between wanted and unwanted attention.

The later guidance did not erase Router Alert. It relocated the conditions under which dependence is defensible. Applications should not rely on its processing end to end across independent administrative domains in the open Internet. Within one controlled domain, however, trusted sources, filtering and rate limits can bound the request. Tunnelling can carry marked packets across a provider core without exposing core routers; water-tight and leak-controlled overlays can specify exactly where attention is permitted.

RFC 2711 provides a comparison boundary, not the IPv4 format: IPv6 Router Alert is a Hop-by-Hop option with its own type and two-octet value rules. The shared lesson is narrower. A packet-carried request for router attention is useful only when the network controls who may make the request and where its cost is paid.

Sources