As per Relevance of the word resolution, we have this rfc below:
Network Working Group David C. Plummer
Request For Comments: 826 (DCP@MIT-MC
November 1982
An Ethernet Address Resolution
-- or --
Converting Network Protocol
to 48.bit Ethernet
for Transmission
Ethernet
The implementation of protocol P on a sending host S decides
through protocol P's routing mechanism, that it wants to
to a target host T located some place on a connected piece
10Mbit Ethernet cable. To actually transmit the Ethernet
a 48.bit Ethernet address must be generated. The addresses
hosts within protocol P are not always compatible with
corresponding Ethernet address (being different lengths
values). Presented here is a protocol that allows
distribution of the information needed to build tables
translate an address A in protocol P's address space into
48.bit Ethernet address
Generalizations have been made which allow the protocol to
used for non-10Mbit Ethernet hardware. Some packet
networks are examples of such hardware
--------------------------------------------------------------------
The protocol proposed here is the result of a great deal
discussion with several other people, most notably J.
Chiappa, Yogen Dalal, and James E. Kulp, and helpful
from David Moon
[The purpose of this RFC is to present a method of
Protocol Addresses (e.g., IP addresses) to Local
Addresses (e.g., Ethernet addresses). This is a issue of
concern in the ARPA Internet community at this time.
method proposed here is presented for your consideration
comment. This is not the specification of a Internet Standard.]
Notes
------
This protocol was originally designed for the DEC/Intel/
10Mbit Ethernet. It has been generalized to allow it to be
for other types of networks. Much of the discussion will
directed toward the 10Mbit Ethernet. Generalizations,
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
first. This is the opposite of the byte addressing of
such as PDP-11s and VAXes. Therefore, special care must be
with the opcode field (ar$op) described below
An agreed upon authority is needed to manage hardware name
values (see below). Until an official authority exists,
should be submitted
David C.
Symbolics, Inc
243 Vassar
Cambridge, Massachusetts 02139
Alternatively, network mail can be sent to DCP@MIT-MC
The Problem
------------
The world is a jungle in general, and the networking
contributes many animals. At nearly every layer of a
architecture there are several potential protocols that could
used. For example, at a high level, there is TELNET and
for remote login. Somewhere below that there is a reliable
stream protocol, which might be CHAOS protocol, DOD TCP,
BSP or DECnet. Even closer to the hardware is the
transport layer, which might be CHAOS, DOD Internet, Xerox PUP
or DECnet. The 10Mbit Ethernet allows all of these
(and more) to coexist on a single cable by means of a type
in the Ethernet packet header. However, the 10Mbit
requires 48.bit addresses on the physical cable, yet
protocol addresses are not 48.bits long, nor do they
have any relationship to the 48.bit Ethernet address of
hardware. For example, CHAOS addresses are 16.bits, DOD
addresses are 32.bits, and Xerox PUP addresses are 8.bits.
protocol is needed to dynamically distribute the
between a <protocol, address> pair and a 48.bit Ethernet address
Motivation
-----------
Use of the 10Mbit Ethernet is increasing as more
supply interfaces that conform to the specification published
DEC, Intel and Xerox. With this increasing availability,
and more software is being written for these interfaces.
are two alternatives: (1) Every implementor invents his/her
method to do some form of address resolution, or (2)
implementor uses a standard so that his/her code can
distributed to other systems without need for modification.
proposal attempts to set the standard
Definitions
------------
Define the following for referring to the values put in the
field of the Ethernet packet header
ether_type$XEROX_PUP
ether_type$DOD_INTERNET
ether_type$CHAOS,
and a new one
ether_type$ADDRESS_RESOLUTION.
Also define the following values (to be discussed later):
ares_op$REQUEST (= 1, high byte transmitted first)
ares_op$REPLY (= 2),
ares_hrd$Ethernet (= 1).
Packet format
--------------
To communicate mappings from <protocol, address> pairs to 48.
Ethernet addresses, a packet format that embodies the
Resolution protocol is needed. The format of the packet follows
Ethernet transmission layer (not necessarily accessible
the user):
48.bit: Ethernet address of
48.bit: Ethernet address of
16.bit: Protocol type = ether_type$ADDRESS_
Ethernet packet data
16.bit: (ar$hrd) Hardware address space (e.g., Ethernet
Packet Radio Net.)
16.bit: (ar$pro) Protocol address space. For
hardware, this is from the set of
fields ether_typ$<protocol>.
8.bit: (ar$hln) byte length of each hardware
8.bit: (ar$pln) byte length of each protocol
16.bit: (ar$op) opcode (ares_op$REQUEST | ares_op$REPLY
nbytes: (ar$sha) Hardware address of sender of
packet, n from the ar$hln field
mbytes: (ar$spa) Protocol address of sender of
packet, m from the ar$pln field
nbytes: (ar$tha) Hardware address of target of
packet (if known).
mbytes: (ar$tpa) Protocol address of target
Packet Generation
------------------
As a packet is sent down through the network layers,
determines the protocol address of the next hop for the
and on which piece of hardware it expects to find the
with the immediate target protocol address. In the case of
10Mbit Ethernet, address resolution is needed and some
layer (probably the hardware driver) must consult the
Resolution module (perhaps implemented in the Ethernet
module) to convert the <protocol type, target protocol address
pair to a 48.bit Ethernet address. The Address Resolution
tries to find this pair in a table. If it finds the pair,
gives the corresponding 48.bit Ethernet address back to
caller (hardware driver) which then transmits the packet. If
does not, it probably informs the caller that it is throwing
packet away (on the assumption the packet will be
by a higher network layer), and generates an Ethernet packet
a type field of ether_type$ADDRESS_RESOLUTION. The
Resolution module then sets the ar$hrd field
ares_hrd$Ethernet, ar$pro to the protocol type that is
resolved, ar$hln to 6 (the number of bytes in a 48.bit
address), ar$pln to the length of an address in that protocol
ar$op to ares_op$REQUEST, ar$sha with the 48.bit ethernet
of itself, ar$spa with the protocol address of itself, and ar$
with the protocol address of the machine that is trying to
accessed. It does not set ar$tha to anything in particular
because it is this value that it is trying to determine.
could set ar$tha to the broadcast address for the hardware (
ones in the case of the 10Mbit Ethernet) if that makes
convenient for some aspect of the implementation. It then
this packet to be broadcast to all stations on the Ethernet
originally determined by the routing mechanism
Packet Reception
-----------------
When an address resolution packet is received, the
Ethernet module gives the packet to the Address Resolution
which goes through an algorithm similar to the following
Negative conditionals indicate an end of processing and
discarding of the packet
?Do I have the hardware type in ar$hrd
Yes: (almost definitely
[optionally check the hardware length ar$hln
?Do I speak the protocol in ar$pro
Yes
[optionally check the protocol length ar$pln
Merge_flag :=
If the pair <protocol type, sender protocol address>
already in my translation table, update the
hardware address field of the entry with the
information in the packet and set Merge_flag to true.
?Am I the target protocol address
Yes
If Merge_flag is false, add the triplet <protocol type
sender protocol address, sender hardware address>
the translation table
?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
Yes
Swap hardware and protocol fields, putting the
hardware and protocol addresses in the sender fields
Set the ar$op field to ares_op$
Send the packet to the (new) target hardware address
the same hardware on which the request was received
Notice that the <protocol type, sender protocol address,
hardware address> triplet is merged into the table before
opcode is looked at. This is on the assumption that
is bidirectional; if A has some reason to talk to B, then B
probably have some reason to talk to A. Notice also that if
entry already exists for the <protocol type, sender
address> pair, then the new hardware address supersedes the
one. Related Issues gives some motivation for this
Generalization: The ar$hrd and ar$hln fields allow this
and packet format to be used for non-10Mbit Ethernets. For
10Mbit Ethernet takes on the value <1, 6>.
other hardware networks, the ar$pro field may no
correspond to the Ethernet type field, but it should
associated with the protocol whose address resolution is
sought
Why is it done this way??
-------------------------
Periodic broadcasting is definitely not desired. Imagine 100
workstations on a single Ethernet, each broadcasting
resolution information once per 10 minutes (as one possible
of parameters). This is one packet every 6 seconds. This
almost reasonable, but what use is it? The workstations aren'
generally going to be talking to each other (and therefore
100 useless entries in a table); they will be mainly talking to
mainframe, file server or bridge, but only to a small number
other workstations (for interactive conversations, for example).
The protocol described in this paper distributes information
it is needed, and only once (probably) per boot of a machine
This format does not allow for more than one resolution to
done in the same packet. This is for simplicity. If things
multiplexed the packet format would be considerably harder
digest, and much of the information could be gratuitous.
of a bridge that talks four protocols telling a workstation
four protocol addresses, three of which the workstation
probably never use
This format allows the packet buffer to be reused if a reply
generated; a reply has the same length as a request, and
of the fields are the same
The value of the hardware field (ar$hrd) is taken from a list
this purpose. Currently the only defined value is for the 10
Ethernet (ares_hrd$Ethernet = 1). There has been talk of
this protocol for Packet Radio Networks as well, and this
require another value as will other future hardware mediums
wish to use this protocol
For the 10Mbit Ethernet, the value in the protocol field (ar$pro
is taken from the set ether_type$. This is a natural reuse
the assigned protocol types. Combining this with the
(ar$op) would effectively halve the number of protocols that
be resolved under this protocol and would make a monitor/
more complex (see Network Monitoring and Debugging below). It
hoped that we will never see 32768 protocols, but Murphy
some laws which don't allow us to make this assumption
In theory, the length fields (ar$hln and ar$pln) are redundant
since the length of a protocol address should be determined
the hardware type (found in ar$hrd) and the protocol type (
in ar$pro). It is included for optional consistency checking
and for network monitoring and debugging (see below).
The opcode is to determine if this is a request (which may
a reply) or a reply to a previous request. 16 bits for this
overkill, but a flag (field) is needed
The sender hardware address and sender protocol address
absolutely necessary. It is these fields that get put in
translation table
The target protocol address is necessary in the request form
the packet so that a machine can determine whether or not
enter the sender information in a table or to send a reply.
is not necessarily needed in the reply form if one assumes
reply is only provoked by a request. It is included
completeness, network monitoring, and to simplify the
processing algorithm described above (which does not look at
opcode until AFTER putting the sender information in a table).
The target hardware address is included for completeness
network monitoring. It has no meaning in the request form,
it is this number that the machine is requesting. Its meaning
the reply form is the address of the machine making the request
In some implementations (which do not get to look at the 14.
ethernet header, for example) this may save some
shuffling or stack space by sending this field to the
driver as the hardware destination address of the packet
There are no padding bytes between addresses. The packet
should be viewed as a byte stream in which only 3 byte pairs
defined to be words (ar$hrd, ar$pro and ar$op) which are
most significant byte first (Ethernet/PDP-10 byte style).
Network monitoring and debugging
---------------------------------
The above Address Resolution protocol allows a machine to
knowledge about the higher level protocol activity (e.g., CHAOS
Internet, PUP, DECnet) on an Ethernet cable. It can
which Ethernet protocol type fields are in use (by value) and
protocol addresses within each protocol type. In fact, it is
necessary for the monitor to speak any of the higher
protocols involved. It goes something like this
When a monitor receives an Address Resolution packet, it
enters the <protocol type, sender protocol address,
hardware address> in a table. It can determine the length of
hardware and protocol address from the ar$hln and ar$pln
of the packet. If the opcode is a REPLY the monitor can
throw the packet away. If the opcode is a REQUEST and the
protocol address matches the protocol address of the monitor,
monitor sends a REPLY as it normally would. The monitor
only get one mapping this way, since the REPLY to the
will be sent directly to the requesting host. The monitor
try sending its own REQUEST, but this could get two monitors
a REQUEST sending loop, and care must be taken
Because the protocol and opcode are not combined into one field
the monitor does not need to know which request opcode
associated with which reply opcode for the same higher
protocol. The length fields should also give enough
to enable it to "parse" a protocol addresses, although it has
knowledge of what the protocol addresses mean
A working implementation of the Address Resolution protocol
also be used to debug a non-working implementation. Presumably
hardware driver will successfully broadcast a packet with
type field of ether_type$ADDRESS_RESOLUTION. The format of
packet may not be totally correct, because
implementations may have bugs, and table management may
slightly tricky. Because requests are broadcast a monitor
receive the packet and can display it for debugging if desired
An Example
-----------
Let there exist machines X and Y that are on the same 10
Ethernet cable. They have Ethernet address EA(X) and EA(Y)
DOD Internet addresses IPA(X) and IPA(Y) . Let the Ethernet
of Internet be ET(IP). Machine X has just been started,
sooner or later wants to send an Internet packet to machine Y
the same cable. X knows that it wants to send to IPA(Y)
tells the hardware driver (here an Ethernet driver) IPA(Y).
driver consults the Address Resolution module to convert
IPA(Y)> into a 48.bit Ethernet address, but because X was
started, it does not have this information. It throws
Internet packet away and instead creates an ADDRESS
packet
(ar$hrd) = ares_hrd$
(ar$pro) = ET(IP
(ar$hln) = length(EA(X))
(ar$pln) = length(IPA(X))
(ar$op) = ares_op$
(ar$sha) = EA(X
(ar$spa) = IPA(X
(ar$tha) = don't
(ar$tpa) = IPA(Y
and broadcasts this packet to everybody on the cable
Machine Y gets this packet, and determines that it
the hardware type (Ethernet), that it speaks the
protocol (Internet) and that the packet is for
((ar$tpa)=IPA(Y)). It enters (probably replacing any
entry) the information that maps to EA(X).
then notices that it is a request, so it swaps fields,
EA(Y) in the new sender Ethernet address field (ar$sha), sets
opcode to reply, and sends the packet directly (not broadcast)
EA(X). At this point Y knows how to send to X, but X
doesn't know how to send to Y
Machine X gets the reply packet from Y, forms the map
to EA(Y), notices the packet is a reply
throws it away. The next time X's Internet module tries to
a packet to Y on the Ethernet, the translation will succeed,
the packet will (hopefully) arrive. If Y's Internet module
wants to talk to X, this will also succeed since Y has
the information from X's request for Address Resolution
Related issue
---------------
It may be desirable to have table aging and/or timeouts.
implementation of these is outside the scope of this protocol
Here is a more detailed description (thanks to MOON@SCRC@MIT-MC).
If a host moves, any connections initiated by that host
work, assuming its own address resolution table is cleared
it moves. However, connections initiated to it by other
will have no particular reason to know to discard their
address. However, 48.bit Ethernet addresses are supposed to
unique and fixed for all time, so they shouldn't change. A
could "move" if a host name (and address in some other protocol
were reassigned to a different physical piece of hardware. Also
as we know from experience, there is always the danger
incorrect routing information accidentally getting
through hardware or software error; it should not be allowed
persist forever. Perhaps failure to initiate a connection
inform the Address Resolution module to delete the information
the basis that the host is not reachable, possibly because it
down or the old translation is no longer valid. Or
receiving of a packet from a host should reset a timeout in
address resolution entry used for transmitting packets to
host; if no packets are received from a host for a
length of time, the address resolution entry is forgotten.
may cause extra overhead to scan the table for each
packet. Perhaps a hash or index can make this faster
The suggested algorithm for receiving address resolution
tries to lessen the time it takes for recovery if a host
move. Recall that if the <protocol type, sender
address> is already in the translation table, then the
hardware address supersedes the existing entry. Therefore, on
perfect Ethernet where a broadcast REQUEST reaches all
on the cable, each station will be get the new hardware address
Another alternative is to have a daemon perform the timeouts
After a suitable time, the daemon considers removing an entry
It first sends (with a small number of retransmissions if needed
an address resolution packet with opcode REQUEST directly to
Ethernet address in the table. If a REPLY is not seen in a
amount of time, the entry is deleted. The request is
directly so as not to bother every station on the Ethernet.
forgetting entries will likely cause useful information to
forgotten, which must be regained
Since hosts don't transmit information about anyone other
themselves, rebooting a host will cause its address mapping
to be up to date. Bad information can't persist forever by
passed around from machine to machine; the only bad
that can exist is in a machine that doesn't know that some
machine has changed its 48.bit Ethernet address.
manually resetting (or clearing) the address mapping table
suffice
This issue clearly needs more thought if it is believed to
important. It is caused by any address resolution-like protocol
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
