More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets
RFC 1029

Document Type RFC - Unknown (May 1988; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1029 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           G. Parr
Request For Comments: 1029                         University of Ulster
                                                               May 1988

        A MORE FAULT TOLERANT APPROACH TO ADDRESS RESOLUTION FOR
                    A MULTI-LAN SYSTEM OF ETHERNETS

STATUS OF THIS MEMO

   This memo discusses an extension to a Bridge Protocol to detect and
   disclose changes in neighbouring host address parameters in a Multi-
   LAN system of Ethernets.  The problem is one which is appearing more
   and more regularly as the interconnected systems grow larger on
   Campuses and in Commercial Institutions.  This RFC suggests a
   protocol enhancement for the Internet community, and requests
   discussion and suggestions for improvements.  Distribution of this
   memo is unlimited.

ABSTRACT

   Executing a protocol P, a sending host S decides, through P's routing
   mechanism, that it wants to transmit to a target host T located
   somewhere on a connected piece of 10Mbit Ethernet cable which
   conforms to IEEE 802.3.  To actually transmit the Ethernet packet, a
   48 bit Ethernet/hardware address must be generated.  The addresses
   assigned to hosts within protocol P are not always compatible with
   the corresponding Ethernet address (being different address space
   byte orderings or values).  A protocol is presented which allows
   dynamic distribution of the information required to build tables that
   translate a host's address in protocol P's address space into a 48
   bit Ethernet address.  An extension is incorporated to allow such a
   protocol to be flexible enough to exist in a Transparent Bridge, or
   generic Host.  The capability of the Bridge to detect host reboot
   conditions in a multi-LAN environment is also discussed, emphasising
   particularly the effect on channel bandwidth.  To illustrate the
   operation of the protocol mechanisms, the Internet Protocol (IP) is
   used as a benchmark [6], [8].  Part 1 presents an introduction to
   Address Resolution, whilst Part 2 discusses a reboot detection
   process.

DEFINITIONS:

      CATENET: a group of IP networks linked together
      IP     : Internet Protocol

Parr                                                            [Page 1]
RFC 1029           Fault Tolerant ARP for Multi-LANs            May 1988

                                 PART 1

INTRODUCTION

   In the Ethernet, while all packets are broadcast, the hardware
   interface selects only those with either the explicit hardware
   broadcast address or the individual hardware address of this
   interface.  Packets which do not have one of these two addresses are
   rejected by the interface and do not get passed to the host software.
   This saves a great deal of otherwise wasted effort by the host
   software having to examine packets and reject them.  If the interface
   hardware selected packets to pass to the host software by means of
   the protocol address, there would be no need for any translation from
   protocol to Ethernet address.  Although it is very important to
   minimize the number of packets which each host must examine, so
   reducing especially needless inspections, use of the hardware
   broadcast address should be confined to those situations where it is
   uniquely beneficial.  Perhaps if one were designing a new local
   network one could eliminate the need for an address translation, but
   in the real world of existing networks it fills a very important
   purpose.  A rare use of the broadcast hardware address, which avoids
   putting any processing load on the other hosts of the Ethernet, is
   where hosts obtain the information they need to use the specific and
   individual hardware addresses to exchange most of their packets.

REASONING BEHIND ADDRESS RESOLUTION

   The process of converting from the logical host address to the
   physical Ethernet address has been termed ADDRESS RESOLUTION, and has
   prompted research into a method which can be easily interfaced,
   whilst at the same time remaining portable.

   The Ethernet requires 48 bit addresses on the physical cable [11] due
   to the fact that the manufacturers of the LAN interface controllers
   assign a unique 48 bit address during production.  Of course, Network
   Managers do not want to be bothered using this address to identify
   the destination at the higher-level.  Rather, they would prefer to
   assign their logical names to the hosts within their supervision, and
   allow some lower level protocol to perform a resolving operation.
   Most of these logical protocol addresses are not 48 bits long, nor do
   they necessarily have any relationship to the 48 bit address space.

   For example, IP addresses have a 32 bit address space [6], thus
   giving rise to the need to distribute dynamically the correspondences
   between a <PROTOCOLTYPE,PROTOCOL-ADDRESS> pair, and a 48 bit Ethernet
   address.

Parr                                                            [Page 2]
Show full document text