Multi-LAN address resolution
RFC - Unknown
(October 1984; No errata)
||RFC Editor Note
RFC 925 (Unknown)
||Send notices to
Network Working Group J. Postel
Request for Comments: 925 ISI
Multi-LAN Address Resolution
STATUS OF THIS MEMO
This memo is prompted by RFC-917 by Jeffery Mogul on "Internet
Subnets". In that memo, Mogul makes a case for the use of "explicit
subnets" in a multi-LAN environment. In this memo, I attempt to make
a case for "transparent subnets". This RFC suggests a proposed
protocol for the ARPA-Internet community, and requests discussion and
suggestions for improvements. Distribution of this memo is
The problem of treating a set of local area networks (LANs) as one
Internet network has generated some interest and concern. It is
inappropriate to give each LAN within an site a distinct Internet
network number. It is desirable to hide the details of the
interconnections between the LANs within an site from people,
gateways, and hosts outside the site. The question arises on how to
best do this, and even how to do it at all. One proposal is to use
"explicit subnets" . The explicit subnet scheme is a call to
recursively apply the mechanisms the Internet uses to manage networks
to the problem of managing LANs within one network. In this note I
urge another approach: the use of "transparent subnets" supported by
a multi-LAN extension of the Address Resolution Protocol .
To quickly review the Address Resolution Protocol (ARP). Each host
on a broadcast LAN knows both its own physical hardware address (HA)
on the LAN and its own Internet Address (IA). When Host-A is given
the IA of Host-B and told to send a datagram to it, Host-A must find
the HA that corresponds to Host-B's IA. To do this Host-A forms an
ARP packet that contains its own HA and IA and the IA of the
destination host (Host-B). Host-A broadcasts this ARP packet. The
hosts that receive this ARP packet check to see if they are
destination sought. If so, they (it should be only Host-B) send a
reply specifically addressed to the originator of the query (Host-A)
and supplying the HA that was needed. The Host-A now has both the HA
and the IA of the destination (Host-B). The Host-A adds this
information to a local cache for future use.
Note: The ARP is actually more general purpose than this brief
Postel [Page 1]
RFC 925 October 1984
Multi-LAN Address Resolution
The idea in this memo is to extend the ARP to work in an environment
of multiple interconnected LANs.
To see how this could work let us imagine a "magic box" (BOX) that is
connected as if it were an ordinary host to two (or more) LANs.
Hosts continue to behave exactly as they do with the basic ARP.
When an ARP query is broadcast by any host the BOX reads it (as do
all the hosts on that LAN). In addition to checking whether it is
the host sought (and replying if it is), the BOX checks its cache of
IA:HA address mappings in the cache that it keeps for each LAN it is
Case 1: If the mapping for the host is found in the cache for the
LAN that the query came from, the BOX does not respond (letting
the sought host respond for itself).
Case 2: If the mapping for the host is found in the cache for a
different LAN than the query came from, the BOX sends a reply
giving its own HA on the LAN the query came from. The BOX acts as
an agent for the destination host.
Case 3: If the mapping is not found in any of the caches then, the
BOX must try to find out the the address, and then respond as in
case 1 or 2.
In case 3, the BOX has to do some magic.
The BOX keeps a search list of sought hosts. Each entry
includes the IA of the host sought, the interface the ARP was
received on, and the source addresses of the original request.
When case 3 occurs, the search list is checked. If the sought
host is already listed the search is terminated, if not the
search is propagated.
To propagate the search, an entry is first made on the search
list, then the BOX composes and sends an ARP packet on each of
its interfaces except the interface the instigating ARP packet
was received on. If a reply is received, the information is
entered into the appropriate cache, the entry is deleted from
the search list and a response to the search instigating ARP is
made as in case 1 or 2. If no reply is received, give up and
do nothing -- no response is sent to the instigating host (the
entry stays on the search list).
Show full document text