rfc925.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 856 行 · 第 1/3 页

Network Working Group                                          J. Postel
Request for Comments: 925                                            ISI
                                                            October 1984

                      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
   unlimited.

INTRODUCTION

   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].

OVERVIEW

   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).




Postel                                                          [Page 2]



RFC 925                                                     October 1984
Multi-LAN Address Resolution


         To terminate the search, give up and do nothing -- no response
         is sent to the instigating host (the entry stays on the search
         list).

   The entries in the caches and the search list must time out.

   For every ARP request that is received, the BOX must also put the
   sending host's IA:HA address mapping into the cache for the LAN it
   was received on.

THE MULTI-LAN ADDRESS RESOLUTION PROTOCOL

   The plan is to use ARP just as it is.  The new element is the "magic
   box" ("ARP-based bridge") that relays the ARP request into
   neighboring LANs and acts as an agent for relaying datagrams to hosts
   on other LANs.

   The Details

      Hosts continue to behave exactly as they do with the basic ARP.

      The LANs are connected together by BOXes (computers that are
      attached to two or more LANs exactly as hosts are attached to
      LANs).  The BOXes implement the following procedure.

      Each BOX keeps a table for each LAN it is connected to (or for
      each LAN interface).  Entries in these tables time out, so these
      tables are caches of recent information.  The entries in these
      caches are the IA:HA address pairs for that LAN.

      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 to see if it
      is the host sought (and replying if it is), the BOX checks its
      cache of IA:HA address mappings in the table 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).  The time out on
         this entry is not reinitialized.

         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 time out
         on this entry is not reinitialized.

            In this case the BOX is indicating that it will act as an


Postel                                                          [Page 3]



RFC 925                                                     October 1984
Multi-LAN Address Resolution


            agent for the destination host.  When an IP datagram arrives
            at the BOX, the BOX must attempt to forward it using the
            information in its address mapping caches.

         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 this case, the BOX has to do some magic.

            The BOX keeps a search list of sought (but not yet found)
            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.  These ARP requests contain the
            IA and HA of the BOX and the IA of the sought host, and
            request the HA of the sought host.  If a reply is received
            to the ARP request, the information is entered into the
            appropriate cache, the entry is deleted from the search list
            and a response to the search instigating ARP requests is
            made as in case 1 or 2 above.  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).

               Note that the BOX must make a reasonable effort with its
               ARP requests,  if it is normal for ordinary hosts to
               retry ARP requests five times, then a BOX must also retry
               it's ARP requests five times.

            To terminate the search, give up and do nothing -- no
            response is sent to the instigating host (the entry stays on
            the search list).

            There is no negative feedback from an ARP request, so there
            is no way to decide that a search was unsuccessful except by
            means of a time out.

      For every ARP request that is received, the BOX must also put the
      sending hosts IA:HA address mapping into the cache for the LAN it
      was received on.

      The entries in the caches and the search list must time out.


Postel                                                          [Page 4]



RFC 925                                                     October 1984
Multi-LAN Address Resolution


      The search list must be kept and the termination rule followed to
      avoid an infinite relaying of an ARP request for a host that does
      not respond.  Once a host is listed in the search list, ARP
      requests will not be relayed.  If a host that is down (or
      otherwise not responding to ARP requests), comes up (or otherwise
      begins responding to ARP requests) it will still not become
      available to hosts in other LANs until the search list entry times
      out.

         There are two approaches to this problem: first, to have a
         relatively short time out on the search list entries; or
         second, to have the BOX periodically send ARPs for each entry
         on the search list.

      There are several time outs involved in this scheme.

         First, the hosts try to get the address resolved using ARP.
         They may actually make several attempts before giving up if a
         host is not responding.  One must have an good estimate of the
         length of time that a host may keep trying.  Call this time T1.

         Second, there is the time that an entry stays on the search
         list, or the time between BOX generated ARPs to resolve these
         addresses.  Call this time T2.

            Note that this time (T2) must be greater than the sum of the
            T1s for the longest loop of LANs.

         Third, there is the time that entries stay in the cache for
         each LAN.  Call this time T3.

         The relationship must be  T1 < T2 < T3.

            One suggestion is that T1 be less than one minute, T2 be ten
            minutes, and T3 be one hour.

         If the environment is very stable, making T3 longer will result
         in fewer searches (less overhead in ARP traffic).  If the
         environment is very dynamic making T3 shorter will result in
         more rapid adaptation to the changes.

         Another possibility is to restart the timer on the cache
         entries each time they are referenced, and have a small value
         for T3.  This would result in entries that are frequently used
         staying in the cache, but infrequently used information being
         discarded quickly.  Unfortunately there is no necessary
         relationship between frequency of use and correctness.  This


Postel                                                          [Page 5]