Multi-LAN address resolution
RFC 925

Document Type RFC - Unknown (October 1984; No errata)
Last updated 2013-03-02
Stream Legacy stream
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 925 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          J. Postel
Request for Comments: 925                                            ISI
                                                            October 1984

                      Multi-LAN Address Resolution


   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" [1].  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 [2].


   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
      sketch indicates.

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
   attached to.

      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