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 pair, and a 48 bit Ethernet
address.
Parr [Page 2]
RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988
EXAMPLE ARP OPERATION
Here is a review of the operation of ARP as defined in RFC-826 [5].
Let hosts X and Y exist on the same Ethernet cable. They have
physical Ethernet addresses EA(X), and EA(Y), and DoD Internet
addresses IPA(X), and IPA(Y). Let the Ethernet type of Internet be
ET(IP). Host X begins an application, and sooner or later wishes to
communicate an Internet packet to host Y. Host X has knowledge of
the Internet address of Y, i.e., (IPA(Y)), and informs the lower
level that it wishes to talk to IPA(Y). The lower-level subsequently
consults the ARP Module (ARM) to convert into a 48
bit Ethernet address but because X has not talked to Y previously, it
does not have this information in its Translation Cache (TC). It
discards (or queues) the Internet packet, and creates a new Address
Resolution packet with:
PACKET FIELD VALUE ASSIGNED
HRDTYP ETHERNET
PROTYP ET(IP)
HRDLEN length (EA(X))
PROTLEN length (IPA(X))
ARPOPC REQUEST
SOURCE HWR EA(X)
SOURCE PROT IPA(X)
TARGET HWR don't know
TARGET PROT IPA(Y)
It then broadcasts this packet to all hosts on the connecting cable.
Host Y picks up this packet and determines that it understands the
hardware type (Ethernet), that it speaks the indicated protocol
(Internet), and that the packet is for it, that is, TARGET PROTOCOL
ADDRESS = IPA(Y). Replacing any previous entry, it enters the
information that