Annotation of embedaddon/ipguard/doc/rfc826.txt, revision 1.1
1.1 ! misho 1: Network Working Group David C. Plummer
! 2: Request For Comments: 826 (DCP@MIT-MC)
! 3: November 1982
! 4:
! 5:
! 6: An Ethernet Address Resolution Protocol
! 7: -- or --
! 8: Converting Network Protocol Addresses
! 9: to 48.bit Ethernet Address
! 10: for Transmission on
! 11: Ethernet Hardware
! 12:
! 13:
! 14:
! 15:
! 16:
! 17: Abstract
! 18:
! 19: The implementation of protocol P on a sending host S decides,
! 20: through protocol P's routing mechanism, that it wants to transmit
! 21: to a target host T located some place on a connected piece of
! 22: 10Mbit Ethernet cable. To actually transmit the Ethernet packet
! 23: a 48.bit Ethernet address must be generated. The addresses of
! 24: hosts within protocol P are not always compatible with the
! 25: corresponding Ethernet address (being different lengths or
! 26: values). Presented here is a protocol that allows dynamic
! 27: distribution of the information needed to build tables to
! 28: translate an address A in protocol P's address space into a
! 29: 48.bit Ethernet address.
! 30:
! 31: Generalizations have been made which allow the protocol to be
! 32: used for non-10Mbit Ethernet hardware. Some packet radio
! 33: networks are examples of such hardware.
! 34:
! 35: --------------------------------------------------------------------
! 36:
! 37: The protocol proposed here is the result of a great deal of
! 38: discussion with several other people, most notably J. Noel
! 39: Chiappa, Yogen Dalal, and James E. Kulp, and helpful comments
! 40: from David Moon.
! 41:
! 42:
! 43:
! 44:
! 45: [The purpose of this RFC is to present a method of Converting
! 46: Protocol Addresses (e.g., IP addresses) to Local Network
! 47: Addresses (e.g., Ethernet addresses). This is a issue of general
! 48: concern in the ARPA Internet community at this time. The
! 49: method proposed here is presented for your consideration and
! 50: comment. This is not the specification of a Internet Standard.]
! 51:
! 52: Notes:
! 53: ------
! 54:
! 55: This protocol was originally designed for the DEC/Intel/Xerox
! 56: 10Mbit Ethernet. It has been generalized to allow it to be used
! 57: for other types of networks. Much of the discussion will be
! 58: directed toward the 10Mbit Ethernet. Generalizations, where
! 59: applicable, will follow the Ethernet-specific discussion.
! 60:
! 61: DOD Internet Protocol will be referred to as Internet.
! 62:
! 63: Numbers here are in the Ethernet standard, which is high byte
! 64: first. This is the opposite of the byte addressing of machines
! 65: such as PDP-11s and VAXes. Therefore, special care must be taken
! 66: with the opcode field (ar$op) described below.
! 67:
! 68: An agreed upon authority is needed to manage hardware name space
! 69: values (see below). Until an official authority exists, requests
! 70: should be submitted to
! 71: David C. Plummer
! 72: Symbolics, Inc.
! 73: 243 Vassar Street
! 74: Cambridge, Massachusetts 02139
! 75: Alternatively, network mail can be sent to DCP@MIT-MC.
! 76:
! 77: The Problem:
! 78: ------------
! 79:
! 80: The world is a jungle in general, and the networking game
! 81: contributes many animals. At nearly every layer of a network
! 82: architecture there are several potential protocols that could be
! 83: used. For example, at a high level, there is TELNET and SUPDUP
! 84: for remote login. Somewhere below that there is a reliable byte
! 85: stream protocol, which might be CHAOS protocol, DOD TCP, Xerox
! 86: BSP or DECnet. Even closer to the hardware is the logical
! 87: transport layer, which might be CHAOS, DOD Internet, Xerox PUP,
! 88: or DECnet. The 10Mbit Ethernet allows all of these protocols
! 89: (and more) to coexist on a single cable by means of a type field
! 90: in the Ethernet packet header. However, the 10Mbit Ethernet
! 91: requires 48.bit addresses on the physical cable, yet most
! 92: protocol addresses are not 48.bits long, nor do they necessarily
! 93: have any relationship to the 48.bit Ethernet address of the
! 94: hardware. For example, CHAOS addresses are 16.bits, DOD Internet
! 95: addresses are 32.bits, and Xerox PUP addresses are 8.bits. A
! 96: protocol is needed to dynamically distribute the correspondences
! 97: between a <protocol, address> pair and a 48.bit Ethernet address.
! 98:
! 99: Motivation:
! 100: -----------
! 101:
! 102: Use of the 10Mbit Ethernet is increasing as more manufacturers
! 103: supply interfaces that conform to the specification published by
! 104: DEC, Intel and Xerox. With this increasing availability, more
! 105: and more software is being written for these interfaces. There
! 106: are two alternatives: (1) Every implementor invents his/her own
! 107: method to do some form of address resolution, or (2) every
! 108: implementor uses a standard so that his/her code can be
! 109: distributed to other systems without need for modification. This
! 110: proposal attempts to set the standard.
! 111:
! 112: Definitions:
! 113: ------------
! 114:
! 115: Define the following for referring to the values put in the TYPE
! 116: field of the Ethernet packet header:
! 117: ether_type$XEROX_PUP,
! 118: ether_type$DOD_INTERNET,
! 119: ether_type$CHAOS,
! 120: and a new one:
! 121: ether_type$ADDRESS_RESOLUTION.
! 122: Also define the following values (to be discussed later):
! 123: ares_op$REQUEST (= 1, high byte transmitted first) and
! 124: ares_op$REPLY (= 2),
! 125: and
! 126: ares_hrd$Ethernet (= 1).
! 127:
! 128: Packet format:
! 129: --------------
! 130:
! 131: To communicate mappings from <protocol, address> pairs to 48.bit
! 132: Ethernet addresses, a packet format that embodies the Address
! 133: Resolution protocol is needed. The format of the packet follows.
! 134:
! 135: Ethernet transmission layer (not necessarily accessible to
! 136: the user):
! 137: 48.bit: Ethernet address of destination
! 138: 48.bit: Ethernet address of sender
! 139: 16.bit: Protocol type = ether_type$ADDRESS_RESOLUTION
! 140: Ethernet packet data:
! 141: 16.bit: (ar$hrd) Hardware address space (e.g., Ethernet,
! 142: Packet Radio Net.)
! 143: 16.bit: (ar$pro) Protocol address space. For Ethernet
! 144: hardware, this is from the set of type
! 145: fields ether_typ$<protocol>.
! 146: 8.bit: (ar$hln) byte length of each hardware address
! 147: 8.bit: (ar$pln) byte length of each protocol address
! 148: 16.bit: (ar$op) opcode (ares_op$REQUEST | ares_op$REPLY)
! 149: nbytes: (ar$sha) Hardware address of sender of this
! 150: packet, n from the ar$hln field.
! 151: mbytes: (ar$spa) Protocol address of sender of this
! 152: packet, m from the ar$pln field.
! 153: nbytes: (ar$tha) Hardware address of target of this
! 154: packet (if known).
! 155: mbytes: (ar$tpa) Protocol address of target.
! 156:
! 157:
! 158: Packet Generation:
! 159: ------------------
! 160:
! 161: As a packet is sent down through the network layers, routing
! 162: determines the protocol address of the next hop for the packet
! 163: and on which piece of hardware it expects to find the station
! 164: with the immediate target protocol address. In the case of the
! 165: 10Mbit Ethernet, address resolution is needed and some lower
! 166: layer (probably the hardware driver) must consult the Address
! 167: Resolution module (perhaps implemented in the Ethernet support
! 168: module) to convert the <protocol type, target protocol address>
! 169: pair to a 48.bit Ethernet address. The Address Resolution module
! 170: tries to find this pair in a table. If it finds the pair, it
! 171: gives the corresponding 48.bit Ethernet address back to the
! 172: caller (hardware driver) which then transmits the packet. If it
! 173: does not, it probably informs the caller that it is throwing the
! 174: packet away (on the assumption the packet will be retransmitted
! 175: by a higher network layer), and generates an Ethernet packet with
! 176: a type field of ether_type$ADDRESS_RESOLUTION. The Address
! 177: Resolution module then sets the ar$hrd field to
! 178: ares_hrd$Ethernet, ar$pro to the protocol type that is being
! 179: resolved, ar$hln to 6 (the number of bytes in a 48.bit Ethernet
! 180: address), ar$pln to the length of an address in that protocol,
! 181: ar$op to ares_op$REQUEST, ar$sha with the 48.bit ethernet address
! 182: of itself, ar$spa with the protocol address of itself, and ar$tpa
! 183: with the protocol address of the machine that is trying to be
! 184: accessed. It does not set ar$tha to anything in particular,
! 185: because it is this value that it is trying to determine. It
! 186: could set ar$tha to the broadcast address for the hardware (all
! 187: ones in the case of the 10Mbit Ethernet) if that makes it
! 188: convenient for some aspect of the implementation. It then causes
! 189: this packet to be broadcast to all stations on the Ethernet cable
! 190: originally determined by the routing mechanism.
! 191:
! 192:
! 193:
! 194: Packet Reception:
! 195: -----------------
! 196:
! 197: When an address resolution packet is received, the receiving
! 198: Ethernet module gives the packet to the Address Resolution module
! 199: which goes through an algorithm similar to the following.
! 200: Negative conditionals indicate an end of processing and a
! 201: discarding of the packet.
! 202:
! 203: ?Do I have the hardware type in ar$hrd?
! 204: Yes: (almost definitely)
! 205: [optionally check the hardware length ar$hln]
! 206: ?Do I speak the protocol in ar$pro?
! 207: Yes:
! 208: [optionally check the protocol length ar$pln]
! 209: Merge_flag := false
! 210: If the pair <protocol type, sender protocol address> is
! 211: already in my translation table, update the sender
! 212: hardware address field of the entry with the new
! 213: information in the packet and set Merge_flag to true.
! 214: ?Am I the target protocol address?
! 215: Yes:
! 216: If Merge_flag is false, add the triplet <protocol type,
! 217: sender protocol address, sender hardware address> to
! 218: the translation table.
! 219: ?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
! 220: Yes:
! 221: Swap hardware and protocol fields, putting the local
! 222: hardware and protocol addresses in the sender fields.
! 223: Set the ar$op field to ares_op$REPLY
! 224: Send the packet to the (new) target hardware address on
! 225: the same hardware on which the request was received.
! 226:
! 227: Notice that the <protocol type, sender protocol address, sender
! 228: hardware address> triplet is merged into the table before the
! 229: opcode is looked at. This is on the assumption that communcation
! 230: is bidirectional; if A has some reason to talk to B, then B will
! 231: probably have some reason to talk to A. Notice also that if an
! 232: entry already exists for the <protocol type, sender protocol
! 233: address> pair, then the new hardware address supersedes the old
! 234: one. Related Issues gives some motivation for this.
! 235:
! 236: Generalization: The ar$hrd and ar$hln fields allow this protocol
! 237: and packet format to be used for non-10Mbit Ethernets. For the
! 238: 10Mbit Ethernet <ar$hrd, ar$hln> takes on the value <1, 6>. For
! 239: other hardware networks, the ar$pro field may no longer
! 240: correspond to the Ethernet type field, but it should be
! 241: associated with the protocol whose address resolution is being
! 242: sought.
! 243:
! 244:
! 245: Why is it done this way??
! 246: -------------------------
! 247:
! 248: Periodic broadcasting is definitely not desired. Imagine 100
! 249: workstations on a single Ethernet, each broadcasting address
! 250: resolution information once per 10 minutes (as one possible set
! 251: of parameters). This is one packet every 6 seconds. This is
! 252: almost reasonable, but what use is it? The workstations aren't
! 253: generally going to be talking to each other (and therefore have
! 254: 100 useless entries in a table); they will be mainly talking to a
! 255: mainframe, file server or bridge, but only to a small number of
! 256: other workstations (for interactive conversations, for example).
! 257: The protocol described in this paper distributes information as
! 258: it is needed, and only once (probably) per boot of a machine.
! 259:
! 260: This format does not allow for more than one resolution to be
! 261: done in the same packet. This is for simplicity. If things were
! 262: multiplexed the packet format would be considerably harder to
! 263: digest, and much of the information could be gratuitous. Think
! 264: of a bridge that talks four protocols telling a workstation all
! 265: four protocol addresses, three of which the workstation will
! 266: probably never use.
! 267:
! 268: This format allows the packet buffer to be reused if a reply is
! 269: generated; a reply has the same length as a request, and several
! 270: of the fields are the same.
! 271:
! 272: The value of the hardware field (ar$hrd) is taken from a list for
! 273: this purpose. Currently the only defined value is for the 10Mbit
! 274: Ethernet (ares_hrd$Ethernet = 1). There has been talk of using
! 275: this protocol for Packet Radio Networks as well, and this will
! 276: require another value as will other future hardware mediums that
! 277: wish to use this protocol.
! 278:
! 279: For the 10Mbit Ethernet, the value in the protocol field (ar$pro)
! 280: is taken from the set ether_type$. This is a natural reuse of
! 281: the assigned protocol types. Combining this with the opcode
! 282: (ar$op) would effectively halve the number of protocols that can
! 283: be resolved under this protocol and would make a monitor/debugger
! 284: more complex (see Network Monitoring and Debugging below). It is
! 285: hoped that we will never see 32768 protocols, but Murphy made
! 286: some laws which don't allow us to make this assumption.
! 287:
! 288: In theory, the length fields (ar$hln and ar$pln) are redundant,
! 289: since the length of a protocol address should be determined by
! 290: the hardware type (found in ar$hrd) and the protocol type (found
! 291: in ar$pro). It is included for optional consistency checking,
! 292: and for network monitoring and debugging (see below).
! 293:
! 294: The opcode is to determine if this is a request (which may cause
! 295: a reply) or a reply to a previous request. 16 bits for this is
! 296: overkill, but a flag (field) is needed.
! 297:
! 298: The sender hardware address and sender protocol address are
! 299: absolutely necessary. It is these fields that get put in a
! 300: translation table.
! 301:
! 302: The target protocol address is necessary in the request form of
! 303: the packet so that a machine can determine whether or not to
! 304: enter the sender information in a table or to send a reply. It
! 305: is not necessarily needed in the reply form if one assumes a
! 306: reply is only provoked by a request. It is included for
! 307: completeness, network monitoring, and to simplify the suggested
! 308: processing algorithm described above (which does not look at the
! 309: opcode until AFTER putting the sender information in a table).
! 310:
! 311: The target hardware address is included for completeness and
! 312: network monitoring. It has no meaning in the request form, since
! 313: it is this number that the machine is requesting. Its meaning in
! 314: the reply form is the address of the machine making the request.
! 315: In some implementations (which do not get to look at the 14.byte
! 316: ethernet header, for example) this may save some register
! 317: shuffling or stack space by sending this field to the hardware
! 318: driver as the hardware destination address of the packet.
! 319:
! 320: There are no padding bytes between addresses. The packet data
! 321: should be viewed as a byte stream in which only 3 byte pairs are
! 322: defined to be words (ar$hrd, ar$pro and ar$op) which are sent
! 323: most significant byte first (Ethernet/PDP-10 byte style).
! 324:
! 325:
! 326: Network monitoring and debugging:
! 327: ---------------------------------
! 328:
! 329: The above Address Resolution protocol allows a machine to gain
! 330: knowledge about the higher level protocol activity (e.g., CHAOS,
! 331: Internet, PUP, DECnet) on an Ethernet cable. It can determine
! 332: which Ethernet protocol type fields are in use (by value) and the
! 333: protocol addresses within each protocol type. In fact, it is not
! 334: necessary for the monitor to speak any of the higher level
! 335: protocols involved. It goes something like this:
! 336:
! 337: When a monitor receives an Address Resolution packet, it always
! 338: enters the <protocol type, sender protocol address, sender
! 339: hardware address> in a table. It can determine the length of the
! 340: hardware and protocol address from the ar$hln and ar$pln fields
! 341: of the packet. If the opcode is a REPLY the monitor can then
! 342: throw the packet away. If the opcode is a REQUEST and the target
! 343: protocol address matches the protocol address of the monitor, the
! 344: monitor sends a REPLY as it normally would. The monitor will
! 345: only get one mapping this way, since the REPLY to the REQUEST
! 346: will be sent directly to the requesting host. The monitor could
! 347: try sending its own REQUEST, but this could get two monitors into
! 348: a REQUEST sending loop, and care must be taken.
! 349:
! 350: Because the protocol and opcode are not combined into one field,
! 351: the monitor does not need to know which request opcode is
! 352: associated with which reply opcode for the same higher level
! 353: protocol. The length fields should also give enough information
! 354: to enable it to "parse" a protocol addresses, although it has no
! 355: knowledge of what the protocol addresses mean.
! 356:
! 357: A working implementation of the Address Resolution protocol can
! 358: also be used to debug a non-working implementation. Presumably a
! 359: hardware driver will successfully broadcast a packet with Ethernet
! 360: type field of ether_type$ADDRESS_RESOLUTION. The format of the
! 361: packet may not be totally correct, because initial
! 362: implementations may have bugs, and table management may be
! 363: slightly tricky. Because requests are broadcast a monitor will
! 364: receive the packet and can display it for debugging if desired.
! 365:
! 366:
! 367: An Example:
! 368: -----------
! 369:
! 370: Let there exist machines X and Y that are on the same 10Mbit
! 371: Ethernet cable. They have Ethernet address EA(X) and EA(Y) and
! 372: DOD Internet addresses IPA(X) and IPA(Y) . Let the Ethernet type
! 373: of Internet be ET(IP). Machine X has just been started, and
! 374: sooner or later wants to send an Internet packet to machine Y on
! 375: the same cable. X knows that it wants to send to IPA(Y) and
! 376: tells the hardware driver (here an Ethernet driver) IPA(Y). The
! 377: driver consults the Address Resolution module to convert <ET(IP),
! 378: IPA(Y)> into a 48.bit Ethernet address, but because X was just
! 379: started, it does not have this information. It throws the
! 380: Internet packet away and instead creates an ADDRESS RESOLUTION
! 381: packet with
! 382: (ar$hrd) = ares_hrd$Ethernet
! 383: (ar$pro) = ET(IP)
! 384: (ar$hln) = length(EA(X))
! 385: (ar$pln) = length(IPA(X))
! 386: (ar$op) = ares_op$REQUEST
! 387: (ar$sha) = EA(X)
! 388: (ar$spa) = IPA(X)
! 389: (ar$tha) = don't care
! 390: (ar$tpa) = IPA(Y)
! 391: and broadcasts this packet to everybody on the cable.
! 392:
! 393: Machine Y gets this packet, and determines that it understands
! 394: the hardware type (Ethernet), that it speaks the indicated
! 395: protocol (Internet) and that the packet is for it
! 396: ((ar$tpa)=IPA(Y)). It enters (probably replacing any existing
! 397: entry) the information that <ET(IP), IPA(X)> maps to EA(X). It
! 398: then notices that it is a request, so it swaps fields, putting
! 399: EA(Y) in the new sender Ethernet address field (ar$sha), sets the
! 400: opcode to reply, and sends the packet directly (not broadcast) to
! 401: EA(X). At this point Y knows how to send to X, but X still
! 402: doesn't know how to send to Y.
! 403:
! 404: Machine X gets the reply packet from Y, forms the map from
! 405: <ET(IP), IPA(Y)> to EA(Y), notices the packet is a reply and
! 406: throws it away. The next time X's Internet module tries to send
! 407: a packet to Y on the Ethernet, the translation will succeed, and
! 408: the packet will (hopefully) arrive. If Y's Internet module then
! 409: wants to talk to X, this will also succeed since Y has remembered
! 410: the information from X's request for Address Resolution.
! 411:
! 412: Related issue:
! 413: ---------------
! 414:
! 415: It may be desirable to have table aging and/or timeouts. The
! 416: implementation of these is outside the scope of this protocol.
! 417: Here is a more detailed description (thanks to MOON@SCRC@MIT-MC).
! 418:
! 419: If a host moves, any connections initiated by that host will
! 420: work, assuming its own address resolution table is cleared when
! 421: it moves. However, connections initiated to it by other hosts
! 422: will have no particular reason to know to discard their old
! 423: address. However, 48.bit Ethernet addresses are supposed to be
! 424: unique and fixed for all time, so they shouldn't change. A host
! 425: could "move" if a host name (and address in some other protocol)
! 426: were reassigned to a different physical piece of hardware. Also,
! 427: as we know from experience, there is always the danger of
! 428: incorrect routing information accidentally getting transmitted
! 429: through hardware or software error; it should not be allowed to
! 430: persist forever. Perhaps failure to initiate a connection should
! 431: inform the Address Resolution module to delete the information on
! 432: the basis that the host is not reachable, possibly because it is
! 433: down or the old translation is no longer valid. Or perhaps
! 434: receiving of a packet from a host should reset a timeout in the
! 435: address resolution entry used for transmitting packets to that
! 436: host; if no packets are received from a host for a suitable
! 437: length of time, the address resolution entry is forgotten. This
! 438: may cause extra overhead to scan the table for each incoming
! 439: packet. Perhaps a hash or index can make this faster.
! 440:
! 441: The suggested algorithm for receiving address resolution packets
! 442: tries to lessen the time it takes for recovery if a host does
! 443: move. Recall that if the <protocol type, sender protocol
! 444: address> is already in the translation table, then the sender
! 445: hardware address supersedes the existing entry. Therefore, on a
! 446: perfect Ethernet where a broadcast REQUEST reaches all stations
! 447: on the cable, each station will be get the new hardware address.
! 448:
! 449: Another alternative is to have a daemon perform the timeouts.
! 450: After a suitable time, the daemon considers removing an entry.
! 451: It first sends (with a small number of retransmissions if needed)
! 452: an address resolution packet with opcode REQUEST directly to the
! 453: Ethernet address in the table. If a REPLY is not seen in a short
! 454: amount of time, the entry is deleted. The request is sent
! 455: directly so as not to bother every station on the Ethernet. Just
! 456: forgetting entries will likely cause useful information to be
! 457: forgotten, which must be regained.
! 458:
! 459: Since hosts don't transmit information about anyone other than
! 460: themselves, rebooting a host will cause its address mapping table
! 461: to be up to date. Bad information can't persist forever by being
! 462: passed around from machine to machine; the only bad information
! 463: that can exist is in a machine that doesn't know that some other
! 464: machine has changed its 48.bit Ethernet address. Perhaps
! 465: manually resetting (or clearing) the address mapping table will
! 466: suffice.
! 467:
! 468: This issue clearly needs more thought if it is believed to be
! 469: important. It is caused by any address resolution-like protocol.
! 470:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to rfc826.txt CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / ipguard / doc