Summary

  • RFC 925 proposed that a host could keep treating an address as local even when the target sat behind another LAN. A BOX answered the ordinary ARP request with its own hardware address, then became the agent responsible for forwarding toward the hidden target.
  • The convenience moved work rather than removing it. Per-LAN caches, unresolved-search lists, retries, timeout ordering, TTL decrement and loop suppression became the price of making several cables look like one network.
  • RFC 950 recorded the competing choice: expose a subnet boundary to implementations and obtain simpler routing, instead of rediscovering hidden location through broadcasts and learned proxy mappings. Neither document proves universal adoption or a universal winner.

A reply that did not name the destination

Imagine a machine that wants to send an IP datagram to an address it believes belongs to its own network. On an Ethernet, it cannot put the datagram on the cable until it knows the destination hardware address. Under ordinary RFC 826 ARP, it broadcasts a question. The owner of the requested protocol address replies directly with its own hardware address; the requester records the mapping and can send the next packet.

That logic quietly assumes that the local broadcast domain and the relevant IP network coincide closely enough for the owner to hear the question. A growing site with several LANs turns the assumption into a design choice. It can obtain a separate Internet network number for every cable. It can divide one network's host portion into explicit subnets. Or it can leave the addresses visually undivided and make the separate cables disappear behind a mediator.

RFC 917 set out those alternatives in 1984. Giving each cable its own number spared the site a special local illusion, but published internal connectivity into wider routing tables where it offered little value to distant networks. Explicit subnets retained one network number while making part of the address mean “which local LAN.” Transparent subnets attempted something different: preserve the host's idea of one network even when the site contained many.

RFC 925 made that attempt concrete. Its intermediary is deliberately called a BOX, connected to two or more LANs as an ordinary host would be. The host is not taught a new address format or a new discovery protocol. It broadcasts an ordinary ARP request. The BOX listens.

The revealing moment comes when the BOX already knows that the sought IP address belongs to another attached LAN. It does not repeat the target's hardware address on the first LAN; that address would not be useful there. Instead, it replies with its own hardware address on the requesting LAN. The host therefore sends the IP datagram to the BOX. The BOX has said something narrow but consequential: for this local sender, I will take the next forwarding step toward that remote host.

This is not identity. The BOX is not asserting that it is the destination, that it owns the protocol address or that it possesses a map of the whole Internet. It is accepting a bounded executor role created by the requester's local problem. Confusing those claims would make a cache entry carry more authority than the exchange contains.

Three outcomes, three kinds of knowledge

RFC 925 divides the BOX's ARP handling into three cases. If the mapping is cached for the same LAN from which the request arrived, the BOX stays silent and lets the destination reply. If the mapping is cached for a different LAN, the BOX offers its own hardware address as the agent. If no cache has the mapping, the BOX must search.

That last case shows what “transparent” costs. The BOX records the sought Internet address, the incoming interface and original source information in a search list. It then emits ARP requests on its other interfaces. A reply allows it to fill the relevant cache, remove the search entry and answer the original requester either as a local observer or as an agent. No reply is not a clean negative answer. ARP has no negative reply, so the BOX knows a search has failed only after time passes.

The search list does two jobs at once. It gives the BOX enough memory to connect a later reply to the original question. It also prevents an unknown address from being relayed forever around a loop of connected LANs. Once a request for that address is already on the list, another BOX stops propagation. A host that was down can consequently remain unavailable from other LANs until that entry expires. The same device that hides a topology must decide how long a past silence may govern a future search.

RFC 925 names three timers. T1 bounds the host's own ARP attempts. T2 is the lifetime or repeat interval for the BOX's unresolved search. T3 is the cache lifetime. The proposal requires T1 < T2 < T3; it even gives illustrative, not universal, values. The important point is the ordering. A BOX must not forget an unresolved search before the original loop of host retries could finish, and its knowledge of a discovered mapping is intentionally longer-lived than the search that found it.

But a longer-lived entry is not thereby truer. RFC 925 explicitly warns that frequency of use has no necessary relationship to correctness. Resetting a cache timer every time a mapping is used can keep obsolete information alive indefinitely when requests arrive just before expiry. A stale mapping can block communication for a time. The cache reports a recently accepted operational hypothesis, not a permanent fact about where a host is.

The bridge acquired router obligations

The word “bridge” can make the BOX sound passive. Its described work is not passive. For ordinary IP datagrams, RFC 925 says BOXes decrement Time-To-Live and update the IP header checksum; a datagram whose TTL becomes zero is discarded. An ARP search has a separate loop boundary in the search list. Broadcast forwarding has yet another recent-broadcast list.

Those separate controls matter because the objects are different. A datagram can contain a hop limit. An ARP query does not come with a negative result or a universal traversal budget, so RFC 925 supplies remembered search state and timeout. A network-wide broadcast needs an identity made from the source address and IP Identification field so a BOX can recognize a recent copy. One mechanism cannot honestly serve as proof for all three.

The proposal also acknowledges that the first reply in a looped multi-LAN environment may merely be probably the most efficient path. It suggests that a host should not replace the first recorded mapping with later replies. This is a pragmatic selection rule, not a proof that the first responder is optimal, reachable forever or authorized beyond its local forwarding undertaking. The distinction is valuable: speed of observation is not a universal routing metric.

The bounds appear again at inconvenient media edges. For a LAN without broadcast capability or without ARP-speaking hosts, RFC 925 says the BOX needs a complete mapping table for that LAN and must send an ARP-type request to each other BOX when it would otherwise broadcast there. In the worst case, each interface's table can grow toward the number of hosts across the whole collection of LANs. Transparency has not eliminated topology; it has converted topology into discovery traffic, cache state and exceptional tables.

Broadcast was a separate decision

RFC 925 is unusually clear that broadcast is not the same question as transparent versus explicit subnets. The memo discusses the two because RFC 917 did, then argues that broadcast interpretation should be decided separately.

For the all-ones host part associated with the site's network number, the proposal intends an IP broadcast to all hosts across all its LANs and requires a BOX to forward it while suppressing loops. For 255.255.255.255, it intends a broadcast only on the current LAN and says a BOX must not forward it. A request to broadcast on some other hidden LAN is harder precisely because the IP address no longer identifies individual LANs in the same way.

That is not a side issue. It exposes the contract of the illusion. The more physical distinctions an address hides, the more extra state or special convention is required when a sender wants one of those distinctions back. A system cannot both decline to name each LAN in the ordinary address interpretation and obtain every LAN-specific action for free.

An explicit boundary changed the accounting

The following year, RFC 950 again listed the three approaches. It described transparent subnets in almost the same terms: bridges intercept ARP for non-local targets so a collection of LANs appears as a single Internet network. It also states the limits plainly. The technique does not fit every LAN technology, depends on ARP and broadcast behavior, requires bridges to discover which LAN contains a host, expands broadcast cost as the LAN collection grows, and can require translation caches proportional to all hosts.

RFC 950 then specifies explicit subnetting as an Internet standard procedure. It concedes that hosts already in use need relatively minor IP changes to support it, but calls the result simple and efficient. The value of that contrast is not that one document issued a final verdict on every network. It is that two designs placed uncertainty in different places.

Transparent subnets asked intermediary boxes to turn an incomplete view into an action. Explicit subnets asked implementations to interpret a declared address partition and choose a local gateway accordingly. The former preserves an old host-facing interface; the latter makes a new routing boundary legible. Each has compatibility consequences. Neither title, standard number or cached answer itself deploys the design. Operational reality appears only when hosts, boxes and routers run a compatible choice.

RFC 1812 later retained a narrow place for address-sharing or transparent routers. It says they can be useful, but characterizes the model as suitable for geographically and topologically limited stub environments and warns that an apparent same-network service may not be fully emulated. In the same requirements document, subnets are a mandatory extension for conforming IPv4 routers. These later words do not rewrite RFC 925's history. They show that hiding address structure remains a scoped technique, while explicit subnet handling became common architectural machinery.

What the hidden host could and could not know

The elegance of RFC 925 is also its cautionary lesson. A host did not have to understand every cable before communicating. That is a real reduction in exposed complexity. But the complexity had to exist somewhere observable enough to act on: caches per interface, search lists, retry windows, TTL accounting, loop suppression and an agent that could be wrong, stale or unreachable.

The BOX's answer was therefore a promise with a perimeter. It could take the datagram because it had exposed its own hardware address on the requester's LAN. It could search other attached LANs because it operated at that physical boundary. It could forget because its observations were not permanent. It could not turn a silent ARP search into proof that the target never existed, a fast reply into proof of the best path, or an address translation into a right to redefine the site's topology for every participant.

That discipline travels beyond this proposal. When a system hides structure for compatibility, operators should ask which component now bears discovery, which result is merely cached, how loops terminate, how failure becomes visible, and how a stale conclusion loses power. The answer is never “the topology disappeared.” It is “the topology acquired a different ledger.”

Sources and evidence limits

The closed evidence set is RFC 826, RFC 917, RFC 925, RFC 950 and RFC 1812. They establish the stated protocol mechanisms, comparison and later router-requirement framing. They do not establish a current product's behavior, universal implementation, a measured performance advantage, the prevalence of transparent topologies, or an exact date on which one design displaced another.