doc: Add RFC documents

1 files changed, 855 insertions, 0 deletions

diff --git a/doc/rfc/rfc925.txt b/doc/rfc/rfc925.txt
new file mode 100644
index 0000000..65218eb
--- /dev/null
+++ b/doc/rfc/rfc925.txt
@@ -0,0 +1,855 @@
+
+
+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]
+