Summary

  • RFC 2390’s worked Frame Relay example showed the same circuit leaving station A under DLCI 50 and arriving at station B under DLCI 70 because DLCIs were normally local to each interface.
  • That rewrite made every hardware-address field carried inside an arriving InARP packet invalid; the receiver used the Q.922 address in the outer frame header to reconstruct the inner source-hardware field.
  • The reconstructed value identified a receiver-local delivery coordinate. It did not authenticate the peer, authorize any action, prove the protocol address truthful or establish an end-to-end outcome.

One circuit, two numbers

The small diagram added to RFC 2390 in September 1998 exposed something that prose about “known hardware addresses” could hide. Station A saw its virtual connection to station B as DLCI 50. Station B saw the same connection as DLCI 70. The network changed the address in the Frame Relay header while the frame crossed it.

Nothing was inconsistent. The two numbers belonged to different local namespaces. RFC 2427 described the rule directly: a virtual circuit was uniquely identified at each Frame Relay interface, and its Data Link Connection Identifier usually had strictly local significance. A DLCI worked more like a platform number inside one station than a globally stable street address. The connection could persist while its visible label changed at the boundary.

This is the narrow historical point that distinguishes RFC 2390 from the earlier RFC 1293. RFC 1293 already defined Inverse ARP’s central problem: a station knew the link-layer handle for an established virtual circuit but did not know the protocol address at the far end. RFC 2390 retained that mechanism. Its declared changes were modest—more formal language, a packet diagram, a worked section 7.2 example and a security section. Yet the example made a difficult implementation truth inspectable: the address inside the packet could be wrong precisely because the outer network had delivered the packet correctly.

The sender could not know the receiver’s coordinate

Ordinary ARP’s packet shape includes a sender hardware address, sender protocol address, target hardware address and target protocol address. On Ethernet, the sender can normally insert its own hardware address. Frame Relay’s local DLCIs disrupted that assumption.

An end station did not possess one universal DLCI that it could write into a message for every observer. It knew the outgoing number for a particular virtual circuit on its own interface. It did not know which number the far interface would use for the same circuit. If A placed 50 inside the InARP message, that value expressed A’s route toward B, not B’s local coordinate for traffic received from A. When B received the frame, the outer header correctly said 70, but the inner value still reflected the wrong namespace.

RFC 2390 therefore described an apparently awkward request. A sent an InARP request toward DLCI 50 with ar$sha, the source hardware address, unknown. The target hardware address encoded the locally known circuit as Q.922 value 0x0C21. After transit, B received the frame under DLCI 70, whose two-octet Q.922 value in the example was 0x1061 once the C/R, FECN, BECN and DE bits were treated as zero.

At that moment B had the only value that mattered to B’s local interpretation. It did not come from the message body. It came from the delivery envelope.

The outer header repaired one inner field

RFC 2390 was blunt: when an InARP message reached its destination, all hardware addresses in the message were invalid. The address in the Frame Relay header, however, was correct. The receiving interface could use that address as the sender hardware address even though doing so violated the purity of layering.

So B rewrote the request’s source hardware field. What had been unknown became 0x1061, the Q.922 form of B’s local DLCI 70. B could then process the request with a sender coordinate meaningful at B. The same repair happened in the other direction. B’s response left with an unknown source hardware field; when A received it, A extracted its outer header address and inserted 0x0C21, its local representation of DLCI 50.

The interface intervened only on incoming packets. That directionality was not an arbitrary implementation detail. The sender could not supply a fact owned by the receiver’s namespace. Only after the network had selected and exposed the arrival-side DLCI could the receiver reconstruct the correct source value.

The target hardware field did not deserve the same rescue. RFC 2390 said it was invalid in both request and response and that InARP did not rely on it. Implementations could zero-fill or ignore it. This was disciplined field semantics: repair the field whose local value can be derived from observed delivery; refuse to invent meaning for a field the protocol does not need.

Reconstruction was provenance, not authentication

The operation established a very specific fact: this message arrived on this interface under this locally meaningful Q.922 address. That is stronger than accepting a stale inner value. It is still much weaker than proving who the peer is.

RFC 2390 added a security section precisely where RFC 1293 had said the issue was not addressed. It noted that ARP-family protocols lacked authentication, that host impersonation was a known problem and that InARP added no new security mechanism. Copying an outer coordinate into an inner field therefore did not sign the packet, validate the protocol address in the response or authorize the sender.

The distinction matters because the reconstructed field looks clean after the operation. A diagnostic tool may show a valid Q.922 address where the packet originally carried “unknown.” Clean representation can be mistaken for stronger epistemic status. But the receiver created that value from local observation. It is provenance about the ingress path, not testimony from the remote station and not a universal name.

The protocol-address value occupies another evidence layer. A peer may reply with its protocol address; local software may cache the association; later packets may use it. None of those steps retroactively authenticates the peer. A current circuit indication does not prove the remote configuration. A reply does not prove authorization. A cache entry does not prove continued reachability. Delivery to the receiving interface does not prove delivery to an application.

A useful violation of layering purity

Protocol diagrams often imply that each layer reads its own header and leaves the next layer untouched. RFC 2390 documented a counterexample without pretending the abstraction had held. The lower layer possessed the only valid local address, so the interface projected that observation into the ARP-shaped payload before the upper logic consumed it.

This was not a licence for arbitrary cross-layer inference. The transformation was narrow, deterministic and bounded by a field whose meaning depended on the lower-layer namespace. The outer Q.922 address supplied the value. The receiver performed the projection. The source field received it. The target field remained ignorable. Security remained absent.

That boundary resembles a sound registry or telemetry design. A record can be corrected from the layer that actually observes the fact. The correction should retain its provenance and scope. It should not be promoted into authority over facts the observing layer cannot know.

IANA’s current ARP Parameters registry preserves hardware type 15 for Frame Relay and operation codes 8 and 9 for InARP request and reply. Those entries keep shared numbers from colliding. They do not say that a network implements InARP, that a particular exchange was authentic or that a mapping succeeded. The registry coordinates syntax; the running interface supplies the local observation.

What the diagram contributed

The RFC’s authors called the revision from RFC 1293 minor. Historically, the diagram was still consequential because it forced four records apart.

First was the circuit as a network relationship. Second was A’s local label 50. Third was B’s local label 70. Fourth was the inner InARP field after B reconstructed it from the frame B actually received. The records referred to one connection but were not interchangeable.

Had the RFC treated 50 as a global identity, B would have preserved an unusable coordinate. Had it treated 70 as proof of a named peer, it would have claimed more than the interface observed. Instead it chose a thin rule: let the arrival header describe arrival, translate that observation into the field the local protocol engine requires, and leave identity and trust to other mechanisms.

That is why the address inside the packet had to be invalid before it could become locally correct. The network had changed the coordinate at a legitimate boundary. RFC 2390 did not hide the change behind a universal identifier. It made the receiver responsible for reconstructing reality from the layer that could actually see it.

Sources