Summary

  • An early Internet host could choose a perfectly usable default gateway and still make every packet cross the local network twice. ICMP Redirect let the first gateway forward the triggering packet, then advise that host to send later traffic directly to a better neighboring gateway.
  • The advice was never meant to become a routing protocol. The host had to verify that the message came from its current first hop and that the proposed gateway was locally reachable, then alter a destination-specific cache rather than rewrite a universal map.
  • IPv6 kept the mechanism but made its local boundary easier to test through a link-local source, Hop Limit 255 and strict target checks. SEND could add cryptographic authorization, yet even protected advice remained a claim about one forwarding relationship—not ownership or global truth.

The unnecessary second crossing

Imagine a host and two routers on one shared network. The host knows Router G1 as its default. For a particular remote destination, however, G1's own table says that Router G2 is the correct next hop. G2 is not hidden behind G1. It is attached to the same local medium as the host.

The first packet therefore takes an avoidable journey. The host sends it across the link to G1. G1 receives it, discovers that the best next hop is G2, and sends the packet back across the same link toward G2. Nothing is broken. Delivery may succeed. But every later packet can repeat the same triangular crossing unless the host learns something more specific than its default.

This was the small geometry behind one of the Internet's earliest routing suggestions. RFC 791 separated a name, an address and a route. IP carried an address in each independent datagram; hosts and gateways made the next routing decision; local procedures turned the chosen Internet address into a transmission on the attached network. The protocol did not require a host to possess the routers' complete map.

That restraint made default routing possible. A host could know very little and still reach many networks. It also created a place for correction. The first gateway saw more of the topology than the host, but the host remained the machine that would execute the next local transmission. The question was how G1 could share precisely that observation without exporting its whole routing system or acquiring command over the host.

A suggestion sent after forwarding

RFC 792 called the answer Redirect. Its description used the same G1/G2 picture. G1 receives a datagram from a host on an attached network. Its table selects G2 on the way to destination network X. If G2 and the source host are on the same network, G1 sends a Redirect to the host advising it to send traffic for X directly to G2.

The order mattered. G1 also forwarded the original datagram. It did not demand that the sender understand a new route before allowing the current packet to proceed. Forwarding preserved the working path; the Redirect proposed an optimization for later packets. Advice and execution were separate events.

That is why “redirect” can be a misleadingly strong word. The message did not seize a packet in flight and hand it to a new authority. G1 had already exercised its ordinary forwarding responsibility. It then told one source host that the same result could be reached with one fewer local crossing next time.

ICMP itself supplied no reliability guarantee. RFC 792 explicitly warned that control feedback did not make IP reliable and that neither a datagram nor its control report was guaranteed to arrive. If the Redirect disappeared, the default route could continue to work. If the next packet again passed through G1, another bounded opportunity for advice might arise. Silence was not proof that the first hop was optimal, and one message was not proof that the suggested path would remain so.

The quoted packet as a receipt

The Redirect carried more than the address of G2. It included the original Internet header and the first 64 bits of the datagram's data. In the design of the time, that was enough to let the host associate the feedback with the traffic that provoked it, including transport ports when they occurred at the start of the quoted data.

The quotation was a compact receipt. G1 was not sending an abstract declaration that “all traffic should trust me.” It was returning evidence tied to a datagram the host had just emitted and to a destination for which G1 had just made a forwarding decision. The message type and code distinguished redirects for a network, a host and their then-defined type-of-service variants; the gateway field identified the proposed next hop.

Yet the quotation was deliberately incomplete. It did not contain the path beyond G2, the policies that produced G1's table, a proof that G2 would accept the packet, or a certificate of who owned X. It described the boundary visible to G1: this source used me, I forwarded this traffic, and another neighbor is the next hop I selected.

This is network-resource evidence in a narrow form. The quoted packet identifies the operational event. The current gateway's position gives it reason to speak. The proposed gateway names an executor. The host still has to decide whether the message satisfies the rules for changing local state.

The current gateway had to be the messenger

The original packet format alone did not make a Redirect trustworthy. Any message that can alter a next-hop cache creates an obvious control surface. RFC 1122 therefore paired the obligation to process Redirects with checks on both the messenger and the proposed executor.

A host should silently discard a Redirect if the new gateway is not on the same connected subnet through which the message arrived. A remote machine cannot legitimately introduce a next hop that the host cannot reach on that local link. The host should also discard the message if its source is not the current first-hop gateway for the stated destination. Merely knowing how to construct ICMP does not create standing to change the route.

These tests do not prove benevolence. A compromised current gateway may still lie, and a hostile participant on a shared link may attempt to imitate local authority. But the checks express a vital limit: the only router eligible to propose this correction is the one whose existing forwarding role the host can already verify from its own state.

The rule is relational rather than institutional. The host does not need to decide whether G1 speaks for a region, a standards body or the remote network. It asks a smaller question: is this the router I currently use for this destination, and is the suggested replacement reachable through the link on which this advice arrived?

One destination, not a new map

RFC 1122 also narrowed what the host should change. Its routing model used a route cache. After a valid Redirect, the host replaced the next-hop gateway in the appropriate cache entry so later datagrams to that destination could go directly to G2.

The distinction between the old Network and Host Redirect codes might suggest that one message could safely install a route for an entire remote network. Host Requirements resisted that inference. A host generally did not know the subnet mask appropriate to the remote destination. It was therefore told to treat a Network Redirect like a Host Redirect: update only the cache entry for the destination host.

This was a practical admission of incomplete knowledge. G1 might have good evidence about the packet it had just forwarded without supplying enough information to define every address covered by X. Expanding a narrow observation into a broad prefix could redirect traffic whose topology had never been tested. Destination-specific state kept the claim proportional to the evidence.

A cache is also different from ownership. It records how this host intends to execute later delivery under present conditions. It neither assigns the destination address nor changes a registry record. The same remote host may be reached differently from another source, interface or moment. The route is useful precisely because it is local and revisable.

Discovery did not become routing

Hosts still needed a way to find an initial router. Static configuration worked, but it imposed administrative work and could not track availability by itself. Listening to routing-protocol traffic exposed hosts to whatever protocol happened to run on the local network. RFC 1256 introduced Router Solicitations and Advertisements so hosts could discover neighboring routers independently of the routers' own routing protocol.

The document was careful about the boundary. Router Discovery was not a routing protocol. An advertisement could tell a host which neighboring routers were available, their preference and the lifetime of that information. It did not tell the host which router was best for every remote destination.

The host chose a preferred default when it lacked a more specific entry. If that choice was poor for a particular destination, the selected router could send a Redirect identifying a better neighbor. Discovery and correction therefore formed two layers: a broad, expiring list of possible first hops and a narrow observation tied to actual traffic.

Neither layer required the host to join the routers' exchange of reachability. That preserved implementation and administrative separation. The host needed enough information to choose and revise an executor, not enough authority or topology to become another routing speaker.

Why routers were forbidden to obey

The same message that was useful for hosts was dangerous as a router-to-router learning channel. RFC 1812 made that separation explicit. A router using a routing protocol must not consider paths learned from ICMP Redirects when forwarding packets. Routers have other mechanisms for exchanging routing information; a redirect contradicting those mechanisms could create loops.

The rule reveals that identical bytes do not have identical authority at every recipient. A host with a simple default route may legitimately use a Redirect as destination-specific advice. A router participating in a routing protocol possesses a different evidence system, different dependencies and a wider blast radius. Treating local host advice as an inter-router route would let one packet-triggered message bypass that system.

RFC 1812 also confined generation. A router must not send a Redirect unless the packet is being forwarded through the same physical interface on which it arrived, the packet's source and the better next hop share the relevant logical subnet, and the packet carries no IP source-route option. The Redirect source address must belong to the same logical subnet as the destination host receiving it.

Each condition closes an expansion path. Different interfaces would turn a local shortcut into cross-boundary route instruction. A source outside the better next hop's subnet would lack direct reachability. A source route would mean the sender had already specified an exceptional path. Redirect belonged only to the plain local triangle it was designed to remove.

IPv6 tightened the boundary

IPv6 did not discard the idea. It incorporated Redirect into Neighbor Discovery, alongside router discovery, prefix discovery, address resolution and neighbor reachability. RFC 4861 lets a router tell a host either that a better first-hop router exists or that the destination is actually a neighbor reachable directly on-link.

The validation rules make locality visible in the packet. The source must be a link-local address. The IPv6 Hop Limit must be 255, which means a forwarded packet could not have arrived with that value after any router decremented it. The ICMP checksum and code must be valid. The sender must be the current first-hop router for the destination. The destination cannot be multicast. The target must be a link-local router address or equal the destination when the router is declaring that destination on-link.

A valid message updates the host's Destination Cache; a supplied target link-layer address can update its Neighbor Cache. Again the recipient executes the change. The router does not reach inside the host's table, and RFC 4861 forbids routers from updating their own routing tables when they receive Redirects.

IPv6's Hop Limit check is particularly revealing. It does not prove that a neighboring router is honest. It proves something smaller and mechanically useful: the message was not forwarded from beyond the link. The mechanism defends the geographic boundary of the claim before asking whether the claimant is authorized within that boundary.

Security without universal authority

Locality is necessary but not sufficient on a shared link. A rogue local router can be more dangerous than a remote stranger because hosts need router information before they can communicate beyond the link. RFC 3971 described Secure Neighbor Discovery, or SEND, to protect Neighbor Discovery messages with signatures, Cryptographically Generated Addresses and certification paths anchored in configured trust.

For routers, the trust chain can authorize advertised address ranges. SEND's Redirect rules add range checks when a router claims that a destination is on-link. A signed message can establish that the sender holds a key and, under the configured certificate path, is authorized to act as a router for a bounded scope.

That protection remains easy to overread. A signature does not prove that the proposed next hop is globally shortest, commercially acceptable or permanently reachable. Router authorization does not establish ownership of the destination, nor does it convert an operational address range into an institution's sovereign territory. It authenticates a message and an authorization relationship under selected trust anchors.

SEND also describes coexistence between secured and unsecured Neighbor Discovery. Operators can choose to accept both or require secured messages. The choice carries consequences: strictness can reject unauthenticated local advice, while compatibility can preserve exposure to participants not covered by the trust system. The standard defines the control surface; it does not erase local deployment judgment.

Sources and evidence limits

RFC 791 supplies the datagram and routing model. RFC 792 defines Redirect and its original G1/G2 exchange. RFC 1122 supplies host validation and destination-cache scope. RFC 1256 separates default-router discovery from destination choice. RFC 1812 confines router generation and forbids routing-protocol routers from learning through Redirect. RFC 3971 defines optional cryptographic authorization for Neighbor Discovery. RFC 4861 defines the IPv6 form, validation and cache effects.

These documents do not establish one universal adoption date, current operating-system defaults or the prevalence of attacks and filtering. They do not prove that every valid Redirect is wise, or that silence means the existing first hop is optimal. They establish a narrower historical fact: the Internet designed a local correction whose authority depended on the sender's current forwarding role, the target's on-link reachability and the recipient host's own validated state change.