Summary

  • RFC 1433 let a routing entry carry an ARP Helper Address so a host or router could try to resolve a next hop on another IP network sharing the same link-level service.
  • The helper had to be locally resolvable and could not invoke Directed ARP recursively; requests also faced route, interface and flood/loop filters before they could be forwarded or answered.
  • Even a returned link address was not a path guarantee: RFC 1433 showed that link-layer filters could be asymmetric or non-transitive, leaving a third-party next hop resolved but unusable.

One link, several IP networks

The phrase “on the same link” sounds like a complete answer. In the network RFC 1433 imagined, it was only the beginning. A large public data service such as SMDS could carry several separately administered IP networks over one link-level network. A router with an address in two of those IP networks could see that both occupied the same underlying service. It could advertise a route whose next hop avoided an unnecessary turn through itself.

The receiving host or router then encountered a smaller and more physical problem. Its routing table contained an IP address for the proposed next hop, but its own address-resolution procedure belonged to its own IP network. It might not know the multicast or request address used by the foreign network. It might not even know whether that network used ARP rather than an administered mapping service. A route could therefore be syntactically valid and topologically attractive while offering no link-layer destination to which a frame could be sent.

This was not the same problem as choosing a route. The routing process had already selected a destination, next-hop IP address and interface. Resolution still had to turn that next-hop address into the address used by the attached service. Only then could the link driver encapsulate and transmit the packet.

RFC 1433 called its bridge between those decisions Directed ARP. The name can mislead a modern reader into imagining a more assertive routing protocol. Its actual move was narrower: retain the normal ARP packet and add an accountable place to send a resolution request when the target belonged to a foreign IP network.

The helper was part of the route

A Directed ARP implementation associated an ARP Helper Address with each routing-table entry. A null helper meant the node already knew how to perform local resolution for the selected next hop or destination. A non-null helper named the router that had supplied the information indicating that the foreign address occupied the same link-level network.

That field recorded dependency, not decoration. The route said where traffic should go at IP level. The helper said which router would assist the attempt to discover the corresponding link address. If a route arrived through an ICMP Redirect, the router that sent the Redirect normally became the helper. If it arrived through a distance-vector update, the advertising router filled the same role unless the receiver already knew how to resolve the advertised next hop.

The resolution sequence exposed the boundary. First consult the local address-resolution table. If the target is absent and the helper is null, use the local procedure. If a helper exists, resolve the helper through the local procedure, send an ordinary ARP Request for the foreign target to the helper's link-level address, and wait. No response means failure.

The chain deliberately stopped there. Directed ARP could not recursively resolve the ARP Helper Address. A helper that itself required another helper would turn a bounded dependency into an unbounded search, hide loops inside resolution and make failure ownership impossible to locate. The first helper had to be local enough to resolve without the mechanism it was enabling.

Forwarding a question was not answering it

When a host received an ARP Request not addressed to itself, it discarded the request. A router could consider directing it, but only after several checks. The target had to appear as an eligible next hop or a directly reachable destination. The corresponding route had to use the same physical interface on which the request arrived. A route through another interface could not justify reflecting the question back into the incoming link.

The next action depended on the target network. If its local resolution procedure used ARP, the router forwarded the request to the link-level request address associated with that network. The target could answer for itself. If the target network used another resolution procedure, the router could resolve the address locally and perform “published ARP,” sending a response on behalf of the target.

Those cases carried different evidence. A relayed request followed by a response showed that some downstream participant answered the target question. A published response showed that the helper's own local procedure supplied the mapping and that the helper chose to represent it in ARP. Neither response established who operated the target, whether the route was authorized, or whether return traffic would pass.

The distinction also located maintenance responsibility. A stale target mapping, a broken request address and a helper answering from an administered table did not have the same custodian. Compressing them into “ARP succeeded” would preserve the bytes while losing the system that vouched for them.

A request could become a storm

Forwarding a broadcast-like discovery request creates amplification risk. RFC 1433 required routers to filter Directed ARP propagation so misbehaving hosts or routers could not create unbounded floods and so loops caused by unstable routes or bad manual configuration would terminate. The memo did not pretend one filter would fit every link service. It offered constraints and left exact implementation to operators.

One proposal limited identical requests—same source and target IP pair—within a small time interval. Another refused to send a request back to the same link-level destination to which the received frame had been addressed. A further rule used the host requirement that the IP/link interface identify link-level broadcast reception: a router could refuse to forward any request that had arrived as a link broadcast.

Each test asked a different question. Rate limiting bounded repetition. Destination comparison blocked a simple reflection. The broadcast flag limited scope. None proved the mapping true. They governed how far an unanswered question could travel before the question itself damaged the network.

The configurable values also mattered. A legitimate host might repeat a request because the first was lost. A limit of one forever would turn packet loss into permanent silence; no limit would permit a loop to persist. The mechanism therefore required a policy record: which request was seen, which filter accepted or rejected it, which timer applied, and whether a response arrived before state expired.

A failed answer invalidated the advertised shortcut

RFC 1433 treated resolution failure as evidence against the route state that depended on it. When a host learned a foreign next hop through an ICMP Redirect and could no longer resolve it—perhaps because the helper's own cache entry had timed out—it had to flush the associated routing entry. The route was not preserved as a timeless truth while its execution dependency disappeared.

Interoperation made the same point. A router supporting Directed ARP might advertise a foreign next hop to a peer that did not support it. The peer could not use the advertisement. Depending on the routing protocol, the advertiser might need to offer itself as a conventional, higher-cost next hop, or administrators might decide that foreign next hops should not be advertised across that relationship.

This is where protocol capability became part of route validity. The same next-hop value could be actionable for one receiver and unusable for another because only one carried the helper state and procedure. A route exchange did not transfer the entire means of execution by implication.

The third-party next hop stood outside the promise

The strongest warning in RFC 1433 concerned third-party next hops. Dynamic routing normally makes the advertising router answer for information it distributes: if that information becomes invalid, the advertiser withdraws or replaces it; if the source disappears, dependent information becomes invalid. A third-party next hop weakens that chain because the advertiser may not be on the actual data path and may not observe its failure.

The underlying link service could make the gap worse. RFC 1433 gave an SMDS filter example in which R1 could communicate with R2 and R2 with R3, while policy blocked R1 from communicating directly with R3. R2 could truthfully know R3 and still advertise a direct next hop that R1 could not use. Shared attachment was not transitive reachability.

Filters could also be asymmetric. R3 might send to R1 while R1 could not send to R3. An address-resolution response or a frame seen in one direction did not certify the reverse direction. “Same network” described administrative and protocol placement; it did not erase pairwise access rules.

That distinction turns a familiar diagram into a dangerous assumption. Drawing three nodes on one line suggests every pair can exchange traffic. In a switched or policy-filtered service, the line is not evidence. Each relevant pair and direction can have a different result.

Test the adjacency without routing around it

RFC 1433 suggested a direct link-level ICMP echo to test connectivity with a proposed next-hop router before installing or first using the route. The packet had to be sent to the next hop's link address. If the echo were routed to its IP address, another route could carry it and produce a successful answer without testing the disputed local adjacency.

The test was still bounded. It could show that one direct exchange worked at a time. It did not prove that all packet classes passed, that filters were symmetric, that the next hop would forward a particular destination, or that the condition would persist. Detecting later link changes belonged to dynamic routing and fell outside the memo.

The useful evidence chain is therefore longer than “ARP replied.” Record the route and advertiser, the helper, the interface, the local resolution of the helper, the directed request, the responder and mapping, the filter decision, the direct adjacency probe, the first attempted data packet and the return observation. Every rung answers a different question.

Sources and evidence limits

RFC 1433 supplies the mechanism and its explicit limits. RFC 826 supplies the ARP packet and address-resolution foundation. RFC 1209 supplies the SMDS setting. RFC 1267 and RFC 1247 supply the contemporary BGP-3 and OSPF contexts to which the memo applied its idea. RFC 1122 and RFC 792 supply host and ICMP constraints.

The packet does not establish current deployment, vendor behavior, present attack rates or modern operating guidance. RFC 1433 is an Experimental historical proposal whose security section says security issues are not discussed. Its continuing value lies in the boundary it exposed: a control plane can name a plausible executor without making the attached service resolve, admit or sustain the actual exchange.

Sources