RFC 826
Network Working Group
Request For Comments: 826
David C. Plummer
(DCP@MIT-MC)
November 1982
An Ethernet Address Resolution Protocol
-- or --
Converting Network Protocol Addresses
to 48.bit Ethernet Address
for Transmission on
Ethernet Hardware
Abstract
The implementation of protocol P on a sending host S decides,
through protocol P's routing mechanism, that it wants to transmit
to a target host T located some place on a connected piece of
10Mbit Ethernet cable. To actually transmit the Ethernet packet
a 48.bit Ethernet address must be generated. The addresses of
hosts within protocol P are not always compatible with the
corresponding Ethernet address (being different lengths or
values). Presented here is a protocol that allows dynamic
distribution of the information needed to build tables to
translate an address A in protocol P's address space into a
48.bit Ethernet address.
Generalizations have been made which allow the protocol to be
used for non-10Mbit Ethernet hardware. Some packet radio
networks are examples of such hardware.
Notes
The protocol proposed here is the result of a great deal of
discussion with several other people, most notably J. Noel
Chiappa, Yogen Dalal, and James E. Kulp, and helpful comments
from David Moon.
[The purpose of this RFC is to present a method of Converting
Protocol Addresses (e.g., IP addresses) to Local Network
Addresses (e.g., Ethernet addresses). This is a issue of general
concern in the ARPA Internet community at this time. The
method proposed here is presented for your consideration and
comment. This is not the specification of a Internet Standard.]
This protocol was originally designed for the DEC/Intel/Xerox
10Mbit Ethernet. It has been generalized to allow it to be used
for other types of networks. Much of the discussion will be
directed toward the 10Mbit Ethernet. Generalizations, where
applicable, will follow the Ethernet-specific discussion.
DOD Internet Protocol will be referred to as Internet.
Numbers here are in the Ethernet standard, which is high byte
first. This is the opposite of the byte addressing of machines
such as PDP-11s and VAXes. Therefore, special care must be taken
with the opcode field (ar$op) described below.
An agreed upon authority is needed to manage hardware name space
values (see below). Until an official authority exists, requests
should be submitted to
David C. Plummer
Symbolics, Inc.
243 Vassar Street
Cambridge, Massachusetts 02139
Alternatively, network mail can be sent to DCP@MIT-MC.
