RFC826. TXT
`
`Network Working Group
`Request F9r Comments: 826
`
`David C. Plummer
`(DCP@MIT-MC)
`November 1982
`
`(____ ~~-~the_rn_et ~':'::•solution Prot~~0
`
`Converting Network Protocol Addresses
`to 48. bit Ethernet Address
`·
`for Transmission on
`Ethernet Hardware
`
`Abstract
`
`The implementation of protocol Pon 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
`lOMbit Ethernet cable. To actually transmit the Ethernet packet
`a 48.bit Ethernet address must be generated. The addresses of
`hosts within protocol Pare 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 ari 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-lOMbit Ethernet hardware.
`Some packet radio
`networks are examples of such hardware.
`
`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.]
`
`Notes:
`
`This protocol was originally designed for the DEC/Intel/Xerox
`
`1 ~-:)
`
`

`

`RFC826. TXT
`
`It has been generalized to allow it to be used
`lOMbit Ethernet.
`for other types of networks. Much of the discussion will be
`directed toward the lOMbit Ethernet. Generalizations, where
`applicable, will follow the Ethernet-specific discussion.
`
`DOD Internet ProtocoJ 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-lls 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.
`
`The Problem:
`
`The world is a jungle in general, and the networking game
`contributes many animals. At nearly every layer of a network
`ar9hitecture there are several potential protocols that could be
`used. For example, at a high level, there is TELNET and SUPDUP
`for remote login. Somewhere below that there is a reliable byte
`stream protocol, which might be CHAOS protocol, DOD TCP, Xerox
`BSP or DECnet. Even closer to the hardware is the logical
`transport layer, which might be CHAOS, DOD Internet, Xerox PUP,
`or DECnet. The lOMbit Ethernet allows all of these protocols
`(and more) to coexist on a single cable by means of a type field
`in the Ethernet packet header. However,
`the lOMbit Ethernet
`requires 48.bit addresses on the physical cable, yet most
`protocol addresses are not 48.bits long, nor do they necessarily
`have any relationship to the 48.bit Ethernet address of the
`hardware. For example, CHAOS addresses are 16.bits, DOD Internet
`addresses are 32.bits, and Xerox PUP addresses are 8. bits. A
`protocol is needed to dynamically distribute the correspondences
`between a <protocol, address> pair and a 48.bit Ethernet address.
`
`Motivation·:
`
`Use of the lOMbit Ethernet is increasing as more manufacturers
`supply interfaces that conform to the specification published by
`DEC, Intel and Xerox. With this increasing availability, more
`and more software is being written for these interfaces. There
`are two alternatives: (l) Every implementor invents his/her own
`method to do some form of address resolution, or (2) every
`implementor uses a standard so that his/her code can be
`distributed to other systems without need for modification. This
`proposal attempts to set the standard.
`
`2 ~-:)
`
`

`

`RFC826. TXT
`
`Definitions:
`
`Define the following for referring to the values put in the TYPE
`field of the Ethernet packet header:
`ether_type$XERox_PUP,
`ether_ type$DOD_I NTERNET,
`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) and
`ares_op$REPLY
`( = 2),
`
`and
`
`ares_hrd$Ethernet (= 1).
`
`Packet format:
`
`To communicate mappings from <protocol, address> pairs to 48.bit
`Ethernet addresses, a packet format that embodies the Address
`Resolution protocol is needed. The format of the packet follows.
`
`Ethernet transmission layer (not necessarily accessible to
`the user):
`48.bit: Ethernet address of destination
`48.bit: Ethernet address of sender
`16.bit: Protocol type= ether_type$ADDRESS_RESOLUTION
`Ethernet packet data:
`16.bit: (ar$hrd) Hardware address space (e.g., Ethernet,
`Packet Radio Net.)
`16.bit: (ar$pro) Protocol address space. For Ethernet
`hardware, this is from the set of type
`fields ether_typ$<protocol>.
`8.bit: (ar$hln) byte length of each hardware address
`8.bit: (ar$pln) byte length of each protocol address
`16.bit: (ar$op) opcode (ares_op$REQUEST I ares_op$REPLY)
`nbytes: (ar$sha) Hardware address of sender of this
`packet, n from the ar$hln field.
`mbytes: (ar$spa) Protocol address of sender of this
`packet, m from the ar$pln field.
`nbytes: (arStha) Hardware address of target of this
`packet (if known).
`mbytes: (ar$tpa)-Protocol address of target.
`
`Packet Generation:
`
`As a packet is sent down through the network layers, routing
`determines the protocol address of the next hop for the packet
`and on which piece of hardware it expects to find the station
`with the immediate target protocol address.
`In the case of the
`lOMbit Ethernet, address resolution is needed and some lower
`
`3 ~-:)
`
`

`

`RFC826. TXT
`
`layer (probably the hardware driver) must consult the Address
`Resolution module (perhaps implemented· in the Ethernet support
`module) to convert the <protocol type, target protocol address>
`pair to a 48.bit Ethernet address. The Address Resolution module
`tries to find this pair in a table.
`If it finds the pair, it
`gives the corresponding 48.bit Ethernet address back to the
`caller (hardware driver) which then transmits the packet.
`If it
`does not, it probably informs the caller that it is throwing the
`packet away (on the assumption the packet will be retransmitted
`by a higher network layer), and generates an Ethernet packet with
`a type field of ether_type$ADDRESS_RESOLUTION. The Address
`Resolution module then sets the ar$hrd field to
`ares_hrd$Ethernet, ar$pro to the protocol type that is being
`resolved, ar$hln to 6 (the number of bytes in a 48.bit Ethernet
`address), ar$pln to the length of an address in that protocol,
`ar$op to ares_op$REQUEST, arSsha with the 48.bit ethernet address
`of itself, ar$spa with the protocol address of itself, and ar$tpa
`with the protocol address of the machine that is trying to be
`accessed.
`It does not set ar$tha to anything in particular,
`because 'it is this value that it is trying to determine.
`It
`could set ar$tha to the broadcast address for the hardware (all
`ones in the case of the lOMbit Ethernet) if that makes it
`convenient for some aspect of the implementation.
`It then causes
`this packet to be broadcast 'to all stations on the Ethernet cable
`originally determined by the routing mechanism.
`
`Packet Reception:
`
`When an adaress resolution packet is received, the receiving
`Ethernet module gives the packet to the Address Resolution module
`which goes through an algorithm similar to the following.
`Negative conditionals indicate an end of processing and a
`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 := false
`If the pair <protocol type, sender protocol address> is
`already in my translation table, update the sender
`hardware address field of the entry with the new
`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> to
`the translation table.
`?Is the opcode ares_opSREQUEST?
`Yes:
`
`(NOW look at the opcode!!)
`
`

`

`RFC826. TXT
`
`Swap hardware and protocol fields, putting the local
`hardware and protocol addresses in the sender fields.
`Set the ar$op field to ares_op$REPLY
`Send the packet to the (new) target hardware address on
`the same hardware on which the request was received.
`
`Notice that the <protocol type, sender protocol address, sender
`hardware address> triplet is merged into the table before the
`opcode is looked at. This is on the assumption that communcation
`is bidirectional; if A has some reason to talk to B,
`then B will
`probably have some reason to talk to A. Notice also that if an
`entry already exists for the <protocol type, sender protocol
`address> pair, then the new hardware address supersedes the old
`one. Related Issues gives some motivation for this.
`
`Generalization: The ar$hrd and ar$hln fields allow this protocol
`and packet format to be used for non-lOMbit Ethernets. For the
`lOMbit Ethernet <ar$hrd, ar$hln> takes on the value <l, 6>. For
`other hardware networks, the ar$pro field may no longer
`correspond to the Ethernet type field, but it should be
`associated with the protocol whose address resolution is being
`sought.
`
`Why is it done this way??
`
`Imagine 100
`Periodic broadcasting is definitely not desired.
`workstations on a single Ethernet, each broadcasting address
`resolution information once per 10 minutes (as one possible set
`of parameters). This is one packet every 6 seconds. This is
`almost reasonable, but what use is it? The workstations aren't
`generally going to be talking to each other (and therefore have
`100 useless entries in a table); they will be mainly talking to a
`mainframe, file server or bridge, but only to a small number of
`other workstations (for interactive conversations, for example)~
`The protocol described in this paper distributes information as
`it is needed, and only once (probably) per boot of a machine.
`
`This format does not allow for more than one resolution to be
`done in the same packet. This is for simplicity.
`If things were
`multiplexed the packet format would be considerably harder to
`digest, and much of the information could be gratuitous. Think
`of a bridge that talks four protocols telling a workstation all
`four protocol addresses, three of which the workstation will
`probably never use.
`
`This format allows the packet buffer to be reused if a reply is
`generated; a reply has the same length as a request, and several
`of the fields are the same.
`
`The value of the hardware field (ar$hrd) is taken from a list for
`this purpose. Currently the only defined value is for the lOMbit
`Ethernet (ares_hrd$Ethernet = 1). There has been talk of using
`this protocol for Packet Radio Networks as well, and this will
`
`5 ~-1/
`
`

`

`RFC826. TXT
`
`require another value as will other future hardware mediums.that
`wish to use this protocol.
`
`For the lOMbit Ethernet, the value in the protocol field (ar$pro)
`is taken from the set ether_type$. This is a natural reuse of
`the assigned protocol types. Combining this with the opcode
`(ar$op) would.effectively halve the number of protocols that can
`be resolved under this protocol and would make a monitor/debugger
`more complex (see Network Monitoring and Debugging below).
`It is
`hoped that we will never see 32768 protocols, but Murphy made
`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 by
`the hardware type (found in ar$hrd) and the protocol type (found
`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 cause
`a reply) or a reply to a previous request.
`16 bits for this is
`overkill, but a flag (field) is needed.
`
`The sender hardware address and sender protocol address are
`absolutely necessary.
`It is these fields that get put in a
`translation table.
`
`The target protocol address is necessary in the request form of
`the packet so that a machine can determine whether or not to
`enter the sender information in a table or to send a reply .. It
`is not necessarily needed in the reply form if.one assumes a
`reply is only provoked by a request.
`It is included for
`completeness, network monitoring, and to simplify the suggested
`processing algorithm described above (which does not look at the
`opcode until AFTER putting the sender information in a table).
`
`The target hardware address is included for completeness and
`network moni taring.
`It has no meaning in the request form, since
`it is this number that the machine is requesting.
`Its meaning in
`the reply form is the address of the machine making the request.
`In some implementations (which do not get to look at the 14.byte
`ethernet header, for example) this may save some register
`shuffling or stack space by sending this field to the hardware
`driver as the hardware destination address of the packet.
`
`There are no padding bytes between addresses. The packet data
`should be viewed as a byte stream in which only 3 byte pairs are
`defined to be words (arShrd, ar$pro and arSop) which are sent
`most significant byte first (Ethernet/PDP-10 byte style).
`
`Network monitoring and debugging:
`
`The above Address Resolution protocol allows a machine to gain
`knowledge about the higher level protocol activity (e.g., CHAOS,
`
`6 ~-:)
`
`

`

`RFC826. TXT
`
`It can determine
`Internet, PUP, DECnet) on an Ethernet cable.
`which Ethernet protocol type fields are in use (by value) and the
`protocol addresses within each protocol type.
`In fact, it is not
`necessary for the monitor to speak any of the higher level
`protocols involved.
`It goes something like this:
`
`When a monitor receives an Address Resolution packet, it always
`enters the <protocol type, sender protocol address, sender
`hardware address> in·a table.
`It can determine the length of the
`hardware and protocol address from the arShln and ar$pln fields
`of the packet.
`If the opcode is a REPLY the monitor can then
`throw the packet away.
`If the opcode is a REQUEST and the target
`protocol address matches the protocol address of the monito~ the
`monitor sends a REPLY as it normally would. The monitor will
`only get one mapping this way, since the REPLY to the REQUEST
`will be sent directly to the requesting host. The monitor could
`try sending its own REQUEST, but this could get two monitors into
`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 is
`associated with which reply opcode for the same higher level
`protocol. The length fields should also give enough information
`to enable it to "parse" a protocol addresses, although it has no
`knowledge of what the protocol addresses mean.
`
`A working implementation of the Address Resolution protocol can
`also be used to debug a non-working implementation. Presumably a
`hardware driver will successfully broadcast a packet with Ethernet
`type field of ether_type$ADDRESS_RESOLUTION. The format of the
`packet may not be totally correct, because initial
`implementations may have bugs, and table management may be
`slightly tricky. Because requests are broadcast a monitor will
`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 lOMbit
`Ethernet cable. They have Ethernet address EA(X) and EA(Y) and
`DOD Internet addresses IPA(X) and IPA(Y). Let the Ethernet type
`of Internet be ET(IP). Machine X has just been started, and
`sooner or later wants to send an Internet packet to machine Yon
`the same cable. X knows that it wants to send to IPA(Y) and
`tells the hardware driver (here an Ethernet driver) IPA(Y). The
`driver consults the Address Resolution module to convert <ET(IP),
`IPA(Y)> into a 48.bit Ethernet address, but because X was just
`started, it does not have this information.
`It throws the
`Internet packet away and instead creates an ADDRESS RESOLUTION
`packet with
`(ar$hrd) = ares_hrdSEthernet
`(ar$pro) = ET(IP)
`(ar$hln) = length(EA(X))
`(ar$pln) :: length(! PA(X))
`
`7 ~-:)
`
`

`

`RFC826. TXT
`
`(ar$op) = ares_op$REQUEST
`(ar$sha) = EA(X)
`(ar$spa) = IPA(X)
`(ar$tha) = don't care
`(ar$tpa) = IPA(Y)
`and broadcasts this packet to everybody on the cable.
`
`Machine Y gets 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
`((ar$tpa)=IPA(Y)).
`It enters (probably replacing any existing
`entry) the information that <ET(IP),
`IPA(X)> maps to EA(X).
`It
`then notices that it is a request, so it swaps fields, putting
`EA(Y) in the new sender Ethernet address field (ar$sha), sets the
`opcode to reply, and sends the packet directly (not broadcast) to
`EA(X). At this point Y knows how to send to X, but X still
`doesn't know how to send to Y.
`
`Machine X gets the reply packet from Y, forms the map from
`<ET(IP),
`IPA(Y)> to EA(Y), notices the packet is a reply and
`throws it away. The next time X's Internet module tries to send
`a packet to Yon the Ethernet, the translation will succeed, and
`the packet will (hopefully) arrive.
`If Y's Internet module then
`wants to talk to X,
`this will also succeed since Y has remembered
`the information from X's request for Address Resolution.
`
`Related issue:
`
`It may be desirable to have table aging and/or timeouts. The
`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 will
`work. assuming its own address resolution table is cleared when
`it moves. However, connections initiated to it by other hosts
`will have no particular reason to know to discard their old
`address. However, 48.bit Ethernet addresses are supposed to be
`unique and fixed for all time, so they shouldn't change. A host
`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 of
`incorrect routing information accidentally getting transmitted
`through hardware or software error; it should not be allowed to
`persist forever. Perhaps failure to initiate a connection should
`inform the Address Resolution module to delete the information on
`the basis that the host is not reachable, possibly because it is
`down or the old translation is no longer valid. Or perhaps
`receiving of a packet from a host should reset a timeout in the
`address resolution entry used for transmitting packets to that
`host; if no packets are received from a host for a suitable
`length of time, the address resolution entry is forgotten. This
`may cause extra overhead to scan the table for each incoming
`packet. Perhaps a hash or index can make this faster.
`
`

`

`, ·.
`
`•
`
`p
`
`RFC826. TXT
`
`The suggested algorithm for receiving address resolution packets
`tries to lessen the time it takes for recovery if a host does
`move. Recall that if the <protocol type, sender protocol
`address> is already in the translation table, then the sender
`hardware address supersedes the existing entry. Therefore, on a
`perfect Ethernet where a broadcast REQUEST reaches all stations
`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 the
`Ethernet address in the table.
`If a REPLY is not seen in a short
`amount of time, the entry is deleted. The request is sent
`Just
`directly so as not to bother every station on the Ethernet.
`forgetting entries will likely cause useful information to be
`forgotten, which must be regained.
`
`Since hosts don't transmit information about anyone other than
`themselves, rebooting a host will cause its address mapping table
`to be·up to date. Bad information can't persist forever by being
`passed around from machine to machine; the only bad information
`that can exist is in a machine that doesn't know that some other
`machine has changed its 48.bit Ethernet address. Perhaps
`manually resetting (or clearing) the address mapping table will
`suffice.
`
`This issue clearly needs more thought if it is believed to be
`important.
`It is caused by any address resolution-like protocol.
`
`