Summary

  • RFC 1293, published in January 1992, added Inverse Address Resolution Protocol messages to ARP so that a station with a known hardware-address-like identifier could ask for the corresponding protocol address. Its motivating case was a Frame Relay DLCI on an established virtual circuit whose far-side protocol address was unknown.
  • An InARP request is directed rather than broadcast because the target hardware address is already known. A reply is conditional: the receiving station may answer, may cache the requester’s mapping, or may ignore a request it is unable or unwilling to answer. A reply can complete a local table entry, but learned information may later age or be invalidated.

The most useful sentence in RFC 1293 is not a packet-field instruction. It is the description of a circuit that exists yet cannot be used for the purpose the station needs. Frame Relay signalling can announce a new virtual circuit and its Data Link Connection Identifier. The DLCI identifies one virtual connection through the wide-area network and is the Frame Relay equivalent of a hardware address. But the announcement does not include the protocol address of the station at the other side. A station has learned a path label without learning whom, at the protocol layer, it can address through that path.

That is a narrow but consequential state. The circuit is not imaginary. The identifier is not missing. The network may have signalled it. Still, without configuration or a discovery mechanism for the peer’s protocol address, the RFC says the circuit is unusable. The word matters. It does not say that the circuit is absent, unsafe, permanently broken, or worthless. It says that one needed link in an addressing chain remains unavailable. RFC 1293 was designed to fill that link with an exchange whose scope stays visible.

A virtual circuit announcement did not name the peer

In the Frame Relay example, a Permanent Virtual Circuit, and eventually a Switched Virtual Circuit, is identified by a DLCI. That identifier tells the local station which virtual connection a frame can use. It does not carry the protocol address that another layer needs when it wants to form an IP or other protocol conversation with the far end. The gap is not between “network exists” and “network does not exist.” It is between a lower-layer reachability handle and an upper-layer name for the other station.

Treating those two facts as one would make configuration look simpler than it was. A station could receive a signal for a new connection and be able to identify that connection, yet have no information for addressing the other side. It could not honestly infer a protocol address from the DLCI, and RFC 1293 did not license it to manufacture one. The new circuit was a route for a question, not the answer to the question.

This distinction is useful outside the particular 1992 environment. A system often learns an identifier for an attachment, channel, queue, tunnel or session before it learns the identity or address needed for the next operation. The identifier can be precise within its own layer and still be insufficient at another. When those layers are compressed into “the peer is known,” operators lose the ability to say which statement actually holds: a link is announced, a direct query has been sent, a party replied, a local mapping exists, or a later operation succeeded.

InARP reversed the question without treating reverse as symmetry

RFC 1293 calls the protocol Inverse Address Resolution because the initiating station begins with a hardware address and requests a protocol address. It extended the familiar ARP format rather than inventing a wholly separate envelope. The operation codes are InARP request 8 and InARP reply 9.

The RFC is careful about a nearby mechanism that sounded suitable but answered a different question. Reverse ARP was considered and rejected because its response gives the protocol address of the requesting station, not the address of the station receiving the request that the Frame Relay case needed to learn. “Reverse” in a protocol name did not mean that every inverse-looking operational question was interchangeable. The desired direction of information, and the party about whom the information is returned, matter.

IP-only solutions were also rejected because the authors wanted protocol-address resolution for multiple protocols. That limit is easy to overlook when reading the document only as a historical step on the road to IP networking. RFC 1293 described a mapping problem at the boundary between a known destination hardware address and a corresponding protocol address. It did not define that mapping as an IP ownership registry, a routing authority or a general identity service.

Knowing the target hardware address removed broadcast, not uncertainty

Ordinary ARP broadcasts a request because it begins without the destination hardware address. InARP does not broadcast. The destination hardware address is already known. The requester puts its own source hardware and protocol addresses into the request, includes the known target hardware address, zero-fills the target protocol-address field, encapsulates the packet for the relevant network and sends it directly to that target.

The packet construction records a useful division of knowledge. The requester contributes what it knows about itself and the lower-layer target. The empty target protocol-address field expresses what it is trying to learn. A direct delivery choice narrows where the question goes; it does not establish what answer will come back. It is not a broadcast search for any owner of a protocol address, and it is not a declaration that the circuit already carries a usable peer relationship.

This is why directness must not be confused with certainty. A directed request can avoid the multiple-copy cost of simulated broadcast and can be more flexible than static configuration, as RFC 1293 explains. But efficient discovery is still discovery. The protocol does not prove that the far station supports InARP, that it has an appropriate address, that it is currently configured to respond, or that a resulting mapping will remain valid beyond the local cache policy.

The receiver could answer, cache, or ignore

On receipt of an InARP request, a station may place the requester’s protocol-address/hardware-address mapping in its ARP cache just as it might for an ARP request. It may assume that an InARP request it receives is directed to it and may construct a reply by using the source addresses from the request as the target addresses of the reply. The word “may” remains important. If the station is unable or unwilling to reply, RFC 1293 says it ignores the request.

Silence is therefore a defined possibility in the interaction, not permission for the requester to invent a success state. The RFC does not provide a positive response where no suitable reply is available. A trace that shows a transmitted request but no reply can show that the request was attempted. It does not, from this document alone, identify why there was no answer: the remote station may have been unable, unwilling, configured differently, unavailable, incompatible, or subject to a condition beyond the scope of the memo. The protocol preserves the absence of an answer rather than replacing it with a false identity claim.

When a requester does receive an InARP reply, it may complete the ARP-table entry and use the address information supplied. That is a useful local operational fact, but it has a narrow grammar. It says the requester received a reply containing address information and may place it in its table. It does not establish a universal, permanent or independently certified binding. RFC 1293 explicitly notes that information learned via InARP may be aged or invalidated under certain circumstances.

A local table entry was not a durable authority record

Ageing and invalidation are more than maintenance details. They prevent a learned mapping from silently becoming a timeless identity. A cache is a record that a station has chosen to retain for a while; it is not the same as an unchanging assertion about the topology, the remote host, its authorisation or the eventual success of traffic sent afterward.

The distinction becomes clearer if the evidence is recorded as a sequence. First, an announcement or local configuration identifies a circuit and DLCI. Second, a local station creates a directed InARP request. Third, a receiving station replies or does not. Fourth, the requester may create or complete a table entry. Fifth, its local policy may age or invalidate that entry. A later data-plane exchange would add a sixth record, with its own destination, route, permissions, timing and result. RFC 1293 specifies parts of the first five; it does not compress the sixth into the presence of a mapping.

This is also why an InARP reply should not be reported as a security conclusion. The RFC’s Security Considerations section says that security issues are not addressed. The memo does not establish authentication, integrity, authorization or protection against any particular attack. A successful mapping exchange and a secure neighbour relationship are different claims requiring different evidence.

Multi-addressed hosts made the answer conditional on the asker

The multi-addressed-host rule is one of the document’s most revealing safeguards. A station with multiple protocol addresses on a single interface cannot simply return any one of them. It must first consider the requester’s protocol address and respond with an address corresponding to the requester’s network. In the IP example, if it has no IP address on the requested subnet, it should not respond.

The reply is therefore not merely an attribute of the responder. It depends on the relationship between a particular request and the responder’s configuration. The same station may have several addresses but no appropriate answer for this requester. A multi-addressed host may send an InARP request for each address defined on an interface; the receiving side may answer some or none of those requests, depending on its configuration.

This rule prevents an appealing but false shorthand: “the far end has an address.” The usable question is more specific: does the responding station have an address appropriate to this requester’s network for this request? The difference is a reminder that resolution messages connect contexts, not just strings. A list of possible addresses does not by itself determine which one belongs in a given local table entry.

The protocol drew a boundary around configuration, not through it

RFC 1293 presents InARP as more efficient than simulating broadcast with multiple copies of a message and more flexible than relying on static configuration. Neither comparison means that configuration disappears. The motivation itself states that, without a new configuration or a mechanism for discovering the protocol address of the other side, a newly announced circuit cannot be used for addressing that side. InARP is that mechanism where its assumptions are met. It is not evidence that configuration elsewhere is unnecessary or that every signalled circuit will produce a reply.

The boundary is practical. A network can reveal a virtual connection. The local station can formulate an InARP request. The distant station has a decision surface: choose an appropriate address and reply, or ignore. The requester can retain a mapping under its cache policy. Operators remain responsible for circuit provision, protocol settings, address assignment, route policy, support and any later service validation. The RFC adds a message exchange between these responsibilities; it does not absorb them.

Sources and evidence limits

This article uses RFC 1293 — Inverse Address Resolution Protocol. The source supports its January 1992 standards-track status, the DLCI/PVC motivation, the missing peer protocol address, the rejection of RARP and IP-only mechanisms for this purpose, InARP request and reply operation codes, direct non-broadcast request construction, conditional replies or silence, cache completion, ageing or invalidation, multi-address selection and the statement that security issues are not addressed.

It does not support a claim that any particular Frame Relay circuit existed or currently exists; that a remote station was configured, reachable, willing or able to respond; that a reply was correct, authorized or secure; that an ARP entry persisted; that an IP route or packet delivery succeeded; or that a user or organization obtained a service result. The interpretation that a known DLCI is a bounded coordination fact rather than a usable-neighbour verdict is an editorial reading of these mechanisms, not a recorded deployment observation.