Summary

  • IPv4's LSRR and SSRR options let a sender provide intermediate addresses; a participating hop moved the next address into the destination field, recorded its own outgoing address, and advanced a pointer.
  • Later host requirements and security guidance did not erase the wire format. They moved authority to local policy: non-local forwarding defaulted off, and routers and firewalls were advised to default to dropping the options.

An IPv4 destination address normally answers a simple question: where should this datagram end? Source routing made the answer provisional. A packet could arrive at the address in its destination field, yet still carry another address waiting in an option. If the receiver agreed to participate, it exchanged those values: the next listed address became the destination, the address of the outgoing interface was written into the newly vacant option slot, and the pointer moved forward by four octets.

That mutation is the mechanism at the centre of the story. The route was not merely a label for later analysis. It could influence the next forwarding decision while accumulating a record of the interfaces that had processed it. IPv4 offered two versions. Loose Source and Record Route, or LSRR, named waypoints while allowing ordinary routing between them. Strict Source and Record Route, or SSRR, required the next named address to be directly reachable; an unlisted intervening router was not permitted.

In RFC 791, this was part of IPv4's ordinary option vocabulary. LSRR used type 131 and SSRR type 137. Each carried a length, a pointer and address slots. Both were copied into every fragment, so fragmentation did not silently detach later pieces from the supplied route. Yet the machinery was tightly bounded: the whole IPv4 header could be no longer than 60 octets, leaving little room for an ambitious itinerary after the base header and option metadata.

The apparent power also had a precise limit. A source route was a request processed by each participating system, not a command that displaced every routing decision. LSRR still relied on gateways to find paths between listed points. SSRR could fail when the next address was not on a directly connected network. A malformed length or pointer could not safely be treated as an instruction at all. The sender supplied bytes; each receiving system still decided whether and how to act on them.

RFC 1122 made that local authority more visible. It permitted a host to forward a source-routed datagram as an intermediate hop, but only under gateway-like rules. It separated local source routing—where the next hop leaves through the same physical interface on which the packet arrived—from non-local forwarding. A host that supported the non-local case had to provide a switch to disable it, and the switch had to default to disabled. Policy filters still applied. Failure could be reported with ICMP Destination Unreachable code 5, Source Route Failed.

This was not a deletion of source routing. A host could still originate, receive or explicitly enable relevant behavior. But the default had changed in meaning. Packet syntax no longer implied that a multi-interface host should lend its forwarding position to a sender. The mechanism crossed an administrative boundary, so the administrator's policy became part of whether the route existed in practice.

Security analysis later explained why that boundary mattered. A sender-selected path could be used to approach systems through an unexpected interface, bypass assumptions embedded in routing or firewall rules, expose topology, or make traffic traverse an intentionally wasteful sequence. Implementations also had to defend the mutable parser state itself. Before reading the next address or writing an interface address, they needed to confirm that the length and pointer described a valid four-octet slot.

RFC 6274 consequently recommended that systems drop LSRR and SSRR by default while retaining an explicit enable control for the exceptional environment that needed them. It did not pretend the options had never served legitimate work: debugging and some peering arrangements appeared in the record. The judgement was narrower and more consequential. Those benefits no longer justified automatic participation by every system that understood the format.

RFC 7126 turned that judgement into operationally explicit advice for routers, security gateways and firewalls. An implementation should offer an option-specific choice: drop the packet, ignore the option and forward according to the ordinary destination, or process the source route under RFC 791. The default should be drop, and the default must be documented.

Those choices are not interchangeable. Ignoring an option can deliver the packet somewhere other than the sender expected at that stage of its itinerary. Dropping preserves the fact that the requested forwarding semantics were refused. Processing accepts the packet's proposed path subject to local checks and policy. A configuration knob therefore does more than turn a legacy feature on or off; it identifies which interpretation the network promises when those bytes arrive.

The resulting history is not a clean march from useful to obsolete. It is a transfer of practical authority. RFC 791 supplied a language in which the sender could propose intermediate hops. RFC 1122 made non-local host participation opt-in. RFC 6274 catalogued the risks and implementation obligations. RFC 7126 treated default-drop behavior as the defensible baseline while preserving an explicit, documented exception.

Sources