More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets (RFC1029)
Original Publication Date: 1988-May-01
Included in the Prior Art Database: 2019-Feb-15
Internet Society Requests For Comment (RFCs)
This memo discusses an extension to a Bridge Protocol to detect and disclose changes in heighbouring 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.
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.
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 , . Part 1 presents an introduction to Address Resolution, whilst Part 2 discusses a reboot detection process.
CATENET: a group of IP networks linked together IP : Internet Protocol
Parr [Page 1]
RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988
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...