GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc925

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]

RFC 925 October 1984 Multi-LAN Address Resolution

       method could result in an out-of-date entry persisting in a
       cache for a very long time if ARP requests for that address
       mapping were received at just less than the time out period.
    When handling regular datagrams, the BOXes must decrement the IP
    datagram Time-To-Live field (TTL) and update the IP header check
    sum.  If the TTL becomes zero the datagram is discarded (not
    forwarded).
    ARP, as currently defined, will take the most recent information
    as the best and most up-to-date.  In a complicated multi-LAN
    environment where there are loops in the connectivity it is likely
    that one will get two (or more) responses to an ARP request for a
    host on some other LAN.  It is probable that the first response
    will be from the BOX that is the most efficient path.
    The one change to the host implementation of ARP that is suggested
    here is to prevent later responses from replacing the mapping
    recorded from the first response.
 Potential Problems
    Bad Cache Entries
       If some wrong information get into a cache entry, it will stay
       there for time T3.  The persistence of old information could
       prevent communication (for a time) if a host changed its IA:HA
       mapping.
       One way to replace bad or out-of-date entries in a cache would
       be to have the BOXes explicitly interpret a broadcast ARP reply
       to require an entry with either this IA or HA to be replaced
       with this new IA:HA mapping.  One could have important servers
       send a broadcast ARP reply when they come up.
    Non-ARP Hosts
       It seems unrealistic to expect to use both ARP hosts and
       non-ARP hosts on the same LAN and expect them to communicate.
       If all the non-ARP hosts are on the same LAN the situation is
       considered with under the next heading (Non-Broadcast LANs).
       Hosts that do not implement ARP must use some other means of
       address mapping.  Either they hold a complete table of all
       hosts, or they access some such table in a server via some
       protocol; or they expect to make all routing decisions based on
       analysis of address fields.

Postel [Page 6]

RFC 925 October 1984 Multi-LAN Address Resolution

    Non-Broadcast LANs
       BOXes that are connected to LANs that do not have broadcast
       capability and/or LANs where the hosts do not respond to ARP
       may have a static or dynamic table of the IA:HA mappings for
       that LAN (or the addresses may be computed from one another).
       All the hosts on that LAN must be in the table.
       When a BOX must find the address mapping and would otherwise
       send an ARP request into a non-broadcast LAN (this can only
       happen when the sought host is not the non-broadcast LAN since
       all the hosts are in the table), it must instead send an ARP
       type request specifically to each of the other BOXes on that
       LAN.
    Size of Tables
       The worst case of the size of the tables in the BOXes is the
       number of hosts in the set of LANs for each table.  That is,
       the table kept for each LAN interface may (in the worst case)
       grow to have an entry for each host in the entire set of LANs.
       However, these tables are really caches of the entries needed
       for current communication activity and the typical case will be
       far from the worst case.  Most hosts will communicate mostly
       with other hosts on their own LAN and with a few hosts on other
       LANs.  Most communication on LANs is between work station hosts
       and server hosts.  It can be expected that there will be
       frequent communication involving the main server hosts and that
       these server hosts will be entered in the tables of most of the
       BOXes most of the time.
    Infinite Transmission Loops
       The possibility of infinite transmission loops through an
       interconnected set of LANs is prevented by keeping search lists
       in the BOXes and terminating the search when a request is
       received for an address already on the list.
       Transmission loops of regular datagrams can not persist because
       them the BOXes must decrement the TTL, and discard the datagram
       if the TTL is reduced to zero.  For debugging purposes it would
       be useful for a BOX to report to the implementer any datagrams
       discarded for this reason.

Postel [Page 7]

RFC 925 October 1984 Multi-LAN Address Resolution

    Broadcast
       Note that broadcast does not really have anything to do with
       either transparent subnets or explicit subnets.  Since it was
       discussed in [1], it will be discussed here, too.  Two of the
       three broadcast functions suggested in [1] work just the same
       and have the same effects, the third can be supported, too.
       It is also argued that the support for a broadcast
       interpretation of IAs is a bigger issue that the question of
       explicit subnets versus transparent subnets and it should be
       decided separately.
       It is also suggested that broadcast is not really what is
       desired, but rather multicast is the better function.  It may
       make sense to understand how to do an Internet multicast before
       adopting a broadcast scheme.
       This IP Network
          If the IA of this network number and an all ones host number
          (e.g., 36.255.255.255) is used, an IP level broadcast to all
          hosts on this Network (all LANs) is intended.  A BOX must
          forward this datagram.  A BOX must examine the datagram for
          potential significance to the BOX itself.
          To prevent infinite transmission loops each BOX must keep a
          list of recent broadcasts.  The entries in this list contain
          the source IA and the Identification field from the datagram
          header.  If a broadcast is received and matches an entry on
          the list it is discarded and not forwarded.  The entries on
          this list time out in time T2.
       This LAN Only
          If the IA of all ones (i.e., 255.255.255.255) is used an IP
          level broadcast to all hosts on this LAN only is intended.
          A BOX must not forward this datagram.  A BOX must examine
          the datagram for potential significance to the BOX itself.
       Another LAN Only
          Since the LANs are not individually identified in the IA
          this can not be supported in the same way. Some have also
          argued that this is a silly capability to provide.
          One way to provide it is to establish a specific IA for each

Postel [Page 8]

RFC 925 October 1984 Multi-LAN Address Resolution

          LAN that means "broadcast on this LAN".  For example,
          36.255.255.128 means broadcast on LAN A, and 36.255.255.187
          means broadcast on LAN B, etc.  These addresses would be
          specially interpreted by the BOXes attached to the specific
          LAN where they had the special interpretation, other BOXes
          would treat these address as any other IAs.   Where these
          addresses are specially interpreted they are converted to
          the broadcast on this LAN only address.

DISCUSSION

 The claim for the extended ARP scheme is that the average host need
 not even know it is in a multi-LAN environment.
    If a host took the trouble to analyze its local cache of IA:AH
    address mappings it might discover that several of the IAs mapped
    to the same HA.  And if it took timing measurements it might
    discover that some hosts responded with less delay that others.
    And further, it might be able to find a correlation between these
    discoveries.  But few hosts would take the trouble.
 Address Structure
    In the explicit subnet scheme, some IA bits are devoted to
    identifying the subnet (i.e., the LAN).  The address is broken up
    into network, subnet, and host fields.  Generally, when fields are
    use the density of the assigned addresses in the address space
    goes down.  That is, there is a less efficient use of the address
    space.  Significant implementation problems may arise if more
    subnets than planned are installed and it becomes necessary to
    change the size of the subnet field.  It seems totally impractical
    to use the explicit subnet scheme with a class C IA.
    In the extended ARP scheme the address is simply the network, and
    host fields.  The extended ARP scheme may be used with any class
    of IA.
 Relocating Hosts
    In the explicit subnet scheme when a host is unplugged from one
    LAN and plugged into another its IA must change.
    In the extended ARP scheme it may keep the same IA.

Postel [Page 9]

RFC 925 October 1984 Multi-LAN Address Resolution

 One view of the situation suggests that there are really two
 problems:
    1. How does the host discover if the destination is in this LAN or
    some other LAN?
       This question assumes that a host should know the difference
       and should do something different in the two cases, and further
       that once the host knows the answer it also know how to send
       the data (e.g., directly to the host, or to the box).
          The claim here is that the hosts should not know the
          difference and should always do the same thing.
    2. How do the BOXes that connect LANs know which BOXes are the
    routes to which LANs?
       This question assumes that the BOXes need some kind of
       topological knowledge, and exchange BOX-to-BOX protocol
       information about connectivity.
          The claim here is that the BOXes do not need topological
          knowledge and do not need to explicitly know about the
          existence of other BOXes.
 It has been suggested that there are two problems: first, how the
 hosts do routing; and second, how the BOXes do routing.  A claim has
 been made that the competing strategies each have an approach to each
 problems and one could select a solution made up partly from one
 approach and partly from another.
    For example: use ARP within the LAN and have the BOX send ARP
    replies and act as a agent (as in the extended ARP scheme), but
    use a BOX-to-BOX protocol to get the "which hosts are where"
    information into the BOXes (as in the explicit subnet scheme).
 There are two places where code is involved: a large number of hosts,
 and a small number of BOXes.  In considering the trade off between
 explicit subnet scheme and extended ARP scheme, the work done in the
 hosts should weigh a lot more than the work done in the BOXes.
    What do hosts do?
       Explicit Subnet Scheme
          The host must be able to decide if this IA is on this LAN or

Postel [Page 10]

RFC 925 October 1984 Multi-LAN Address Resolution

          some other LAN.  If on this LAN then use some procedure to
          find the HA.  If on some other LAN then use some procedure
          to find the HA of a BOX.
       Extended ARP Scheme
          In every case the host uses ARP to get a IA:HA mapping.
    What do the BOXes do?
       Explicit Subnet Scheme
          The BOX must be able to decide which LAN within the site the
          destination host is on.  The BOXes must have some routing
          table that tells for each LAN in the site which interface to
          send datagrams on.  This routing table must be kept up to
          date, probably by a BOX-to-BOX protocol much like the
          Internet Gateway-to-Gateway protocol.
       Extended ARP Scheme
          The BOX must keep caches for each LAN it is attached to of
          IA:HA mappings, and it must keep a search list.  It does not
          run any BOX-to-BOX protocol, It does not even know if any
          other BOXes exist.
 Topology and Implementation Complexity
    Trees
       If the organization of the LANs and the BOXes is tree
       structured, the BOXes may be very simple, they don't have to
       keep the search lists at all, since there won't be any loops
       for the ARP-request to traverse.
    Loops
       If the organization has loops then the search lists are
       essential.  If the topology is kept balanced so that there are
       no long loops (all loops are about the same size), and the LANs
       are reasonably compatible in delay characteristics, then the
       procedure described here will work well.
    Complex
       If the organization is very complex, topologically unbalanced,

Postel [Page 11]

RFC 925 October 1984 Multi-LAN Address Resolution

       and/or composed of mix of different types of LANS with vastly
       different delay characteristics, then it may be better to use a
       BOX-to-BOX routing protocol.

SUMMARY

 It would be useful if the Internet community could come to some
 agreement on a solution to the multi-LAN network problem and could
 with a unified voice urge work station manufacturers to provide that
 solution built in.
 I urge consideration of the extended ARP scheme expounded on here.
 I think that most work stations will be connected to LANs that have a
 broadcast capability.  I think that most work stations will be used
 in situations that do not require explicit subnets, and most will be
 used in situations where a class C Internet addresses would be
 appropriate (and explicit subnets impossible).  Thus, i think it
 would be best to ask manufacturers to include support for ARP in work
 stations off the shelf.  I also think we ought to get busy and
 create, develop, test, and produce the magic boxes I suggest so that
 they too are available off the shelf.
 Please note that neither this note nor [1] proposes a specific
 routing procedure or BOX-to-BOX protocol.  This is because such a
 routing procedure is a very hard problem.  The plan proposed here
 will let us get started on using multi-LAN environments in a
 reasonable way.  If we later decide on a routing procedure to be used
 between the BOXes we can redo the BOXes without having to redo the
 hosts.

Postel [Page 12]

RFC 925 October 1984 Multi-LAN Address Resolution

GLOSSARY

 ARP
    Address Resolution Protocol (see [2]).
 BOX
    Magic Box.  A box (computer) connected to two or more LANs of the
    same Network.  Also called an "ARP-based bridge".
 Bridge
    A node (computer) connected to two or more administratively
    indistinguishable but physically distinct subnets, that
    automatically forwards datagrams when necessary, but whose
    existence is not know to other hosts.  Also called a "software
    repeater".
 Datagram
    The unit of communication at the IP level.
 Explicit Subnet
    A Subnet explicitly identified in the the Internet Address by a
    subnet address field, and so visible to others both in side and
    out side the Network.
 Gateway
    A node (computer) connected to two or more administratively
    distinct networks and/or subnets, to which hosts send datagrams to
    be forwarded.
 HA
    Hardware Address, the address used in a packet on a LAN.
 Host Number
    The address of a host within an Network, the low-order part of an
    IA.
 IA
    Internet Address, as defined in IP.

Postel [Page 13]

RFC 925 October 1984 Multi-LAN Address Resolution

 Internet
    The collection of connected Internet Networks (also known as the
    Catenet).  A set of interconnected networks using IP.
 IP
    Internet Protocol (see [3]).
 LAN
    Local Area Network.
 Multi-LAN Network
    A set of LANs treated as one Network, i.e., using one Network
    Number in common.  The individual LANs may be either Explicit
    Subnets or Transparent Subnets.
 Network
    A single Internet Network (possibly divided into subnets or
    composed of multiple LANs), identified by an individual Network
    Number.
 Network Number
    An IP Network Number, the high-order part of an IA.
 Packet
    The unit of communication at the LAN hardware level.
 Subnet
    A subnet of Network. A portion of a Network (either logical or
    physical).
 Transparent Subnet
    A Subnet not identified in the Internet Address, and so invisible
    to others, (see Multi-LAN Network).
 TTL
    The IP Time-To-Live field.

Postel [Page 14]

RFC 925 October 1984 Multi-LAN Address Resolution

REFERENCES

 [1]  J. Mogul, "Internet Subnets",  RFC-917, Stanford University,
      October 1984.
 [2]  D. Plummer, "An Ethernet Address Resolution Protocol or
      Converting Network Protocol Addresses to 48-bit Ethernet
      Addresses for Transmission on Ethernet Hardware",  RFC-826,
      Symbolics, November 1982.
 [3]  J. Postel, "Internet Protocol",  RFC-791, USC-ISI,
      September 1981.

Postel [Page 15]

/data/webs/external/dokuwiki/data/pages/rfc/rfc925.txt · Last modified: 1992/09/22 21:03 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki