{
	"id": "4cdabe34-589e-4074-953e-649a3583e191",
	"created_at": "2026-04-06T00:15:50.236543Z",
	"updated_at": "2026-04-10T13:12:23.566918Z",
	"deleted_at": null,
	"sha1_hash": "ce27aa9e4badc63ebc28f6dd863d07c31c8ed692",
	"title": "RFC 826: An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 67027,
	"plain_text": "RFC 826: An Ethernet Address Resolution Protocol: Or\r\nConverting Network Protocol Addresses to 48.bit Ethernet Address\r\nfor Transmission on Ethernet Hardware\r\nArchived: 2026-04-05 14:33:18 UTC\r\nNetwork Working Group David C. Plummer\r\nRequest For Comments: 826 (DCP@MIT-MC)\r\n November 1982\r\n An Ethernet Address Resolution Protocol\r\n -- or --\r\n Converting Network Protocol Addresses\r\n to 48.bit Ethernet Address\r\n for Transmission on\r\n Ethernet Hardware\r\n Abstract\r\nThe implementation of protocol P on a sending host S decides,\r\nthrough protocol P's routing mechanism, that it wants to transmit\r\nto a target host T located some place on a connected piece of\r\n10Mbit Ethernet cable. To actually transmit the Ethernet packet\r\na 48.bit Ethernet address must be generated. The addresses of\r\nhosts within protocol P are not always compatible with the\r\ncorresponding Ethernet address (being different lengths or\r\nvalues). Presented here is a protocol that allows dynamic\r\ndistribution of the information needed to build tables to\r\ntranslate an address A in protocol P's address space into a\r\n48.bit Ethernet address.\r\nGeneralizations have been made which allow the protocol to be\r\nused for non-10Mbit Ethernet hardware. Some packet radio\r\nnetworks are examples of such hardware.\r\n--------------------------------------------------------------------\r\nThe protocol proposed here is the result of a great deal of\r\nhttps://tools.ietf.org/html/rfc826\r\nPage 1 of 11\n\ndiscussion with several other people, most notably J. Noel\r\nChiappa, Yogen Dalal, and James E. Kulp, and helpful comments\r\nfrom David Moon.\r\n[The purpose of this RFC is to present a method of Converting\r\nProtocol Addresses (e.g., IP addresses) to Local Network\r\nAddresses (e.g., Ethernet addresses). This is a issue of general\r\nconcern in the ARPA Internet community at this time. The\r\nmethod proposed here is presented for your consideration and\r\ncomment. This is not the specification of a Internet Standard.]\r\nNotes:\r\n------\r\nThis protocol was originally designed for the DEC/Intel/Xerox\r\n10Mbit Ethernet. It has been generalized to allow it to be used\r\nfor other types of networks. Much of the discussion will be\r\ndirected toward the 10Mbit Ethernet. Generalizations, where\r\napplicable, will follow the Ethernet-specific discussion.\r\nDOD Internet Protocol will be referred to as Internet.\r\nNumbers here are in the Ethernet standard, which is high byte\r\nfirst. This is the opposite of the byte addressing of machines\r\nsuch as PDP-11s and VAXes. Therefore, special care must be taken\r\nwith the opcode field (ar$op) described below.\r\nAn agreed upon authority is needed to manage hardware name space\r\nvalues (see below). Until an official authority exists, requests\r\nshould be submitted to\r\n David C. Plummer\r\n Symbolics, Inc.\r\n 243 Vassar Street\r\n Cambridge, Massachusetts 02139\r\nAlternatively, network mail can be sent to DCP@MIT-MC.\r\nThe Problem:\r\n------------\r\nThe world is a jungle in general, and the networking game\r\ncontributes many animals. At nearly every layer of a network\r\narchitecture there are several potential protocols that could be\r\nused. For example, at a high level, there is TELNET and SUPDUP\r\nfor remote login. Somewhere below that there is a reliable byte\r\nhttps://tools.ietf.org/html/rfc826\r\nPage 2 of 11\n\nstream protocol, which might be CHAOS protocol, DOD TCP, Xerox\r\nBSP or DECnet. Even closer to the hardware is the logical\r\ntransport layer, which might be CHAOS, DOD Internet, Xerox PUP,\r\nor DECnet. The 10Mbit Ethernet allows all of these protocols\r\n(and more) to coexist on a single cable by means of a type field\r\nin the Ethernet packet header. However, the 10Mbit Ethernet\r\nrequires 48.bit addresses on the physical cable, yet most\r\nprotocol addresses are not 48.bits long, nor do they necessarily\r\nhave any relationship to the 48.bit Ethernet address of the\r\nhardware. For example, CHAOS addresses are 16.bits, DOD Internet\r\naddresses are 32.bits, and Xerox PUP addresses are 8.bits. A\r\nprotocol is needed to dynamically distribute the correspondences\r\nbetween a \u003cprotocol, address\u003e pair and a 48.bit Ethernet address.\r\nMotivation:\r\n-----------\r\nUse of the 10Mbit Ethernet is increasing as more manufacturers\r\nsupply interfaces that conform to the specification published by\r\nDEC, Intel and Xerox. With this increasing availability, more\r\nand more software is being written for these interfaces. There\r\nare two alternatives: (1) Every implementor invents his/her own\r\nmethod to do some form of address resolution, or (2) every\r\nimplementor uses a standard so that his/her code can be\r\ndistributed to other systems without need for modification. This\r\nproposal attempts to set the standard.\r\nDefinitions:\r\n------------\r\nDefine the following for referring to the values put in the TYPE\r\nfield of the Ethernet packet header:\r\n ether_type$XEROX_PUP,\r\n ether_type$DOD_INTERNET,\r\n ether_type$CHAOS,\r\nand a new one:\r\n ether_type$ADDRESS_RESOLUTION.\r\nAlso define the following values (to be discussed later):\r\n ares_op$REQUEST (= 1, high byte transmitted first) and\r\n ares_op$REPLY (= 2),\r\nand\r\n ares_hrd$Ethernet (= 1).\r\nPacket format:\r\n--------------\r\nTo communicate mappings from \u003cprotocol, address\u003e pairs to 48.bit\r\nhttps://tools.ietf.org/html/rfc826\r\nPage 3 of 11\n\nEthernet addresses, a packet format that embodies the Address\r\nResolution protocol is needed. The format of the packet follows.\r\n Ethernet transmission layer (not necessarily accessible to\r\n the user):\r\n 48.bit: Ethernet address of destination\r\n 48.bit: Ethernet address of sender\r\n 16.bit: Protocol type = ether_type$ADDRESS_RESOLUTION\r\n Ethernet packet data:\r\n 16.bit: (ar$hrd) Hardware address space (e.g., Ethernet,\r\n Packet Radio Net.)\r\n 16.bit: (ar$pro) Protocol address space. For Ethernet\r\n hardware, this is from the set of type\r\n fields ether_typ$\u003cprotocol\u003e.\r\n 8.bit: (ar$hln) byte length of each hardware address\r\n 8.bit: (ar$pln) byte length of each protocol address\r\n 16.bit: (ar$op) opcode (ares_op$REQUEST | ares_op$REPLY)\r\n nbytes: (ar$sha) Hardware address of sender of this\r\n packet, n from the ar$hln field.\r\n mbytes: (ar$spa) Protocol address of sender of this\r\n packet, m from the ar$pln field.\r\n nbytes: (ar$tha) Hardware address of target of this\r\n packet (if known).\r\n mbytes: (ar$tpa) Protocol address of target.\r\nPacket Generation:\r\n------------------\r\nAs a packet is sent down through the network layers, routing\r\ndetermines the protocol address of the next hop for the packet\r\nand on which piece of hardware it expects to find the station\r\nwith the immediate target protocol address. In the case of the\r\n10Mbit Ethernet, address resolution is needed and some lower\r\nlayer (probably the hardware driver) must consult the Address\r\nResolution module (perhaps implemented in the Ethernet support\r\nmodule) to convert the \u003cprotocol type, target protocol address\u003e\r\npair to a 48.bit Ethernet address. The Address Resolution module\r\ntries to find this pair in a table. If it finds the pair, it\r\ngives the corresponding 48.bit Ethernet address back to the\r\ncaller (hardware driver) which then transmits the packet. If it\r\ndoes not, it probably informs the caller that it is throwing the\r\npacket away (on the assumption the packet will be retransmitted\r\nby a higher network layer), and generates an Ethernet packet with\r\na type field of ether_type$ADDRESS_RESOLUTION. The Address\r\nResolution module then sets the ar$hrd field to\r\nares_hrd$Ethernet, ar$pro to the protocol type that is being\r\nhttps://tools.ietf.org/html/rfc826\r\nPage 4 of 11\n\nresolved, ar$hln to 6 (the number of bytes in a 48.bit Ethernet\r\naddress), ar$pln to the length of an address in that protocol,\r\nar$op to ares_op$REQUEST, ar$sha with the 48.bit ethernet address\r\nof itself, ar$spa with the protocol address of itself, and ar$tpa\r\nwith the protocol address of the machine that is trying to be\r\naccessed. It does not set ar$tha to anything in particular,\r\nbecause it is this value that it is trying to determine. It\r\ncould set ar$tha to the broadcast address for the hardware (all\r\nones in the case of the 10Mbit Ethernet) if that makes it\r\nconvenient for some aspect of the implementation. It then causes\r\nthis packet to be broadcast to all stations on the Ethernet cable\r\noriginally determined by the routing mechanism.\r\nPacket Reception:\r\n-----------------\r\nWhen an address resolution packet is received, the receiving\r\nEthernet module gives the packet to the Address Resolution module\r\nwhich goes through an algorithm similar to the following.\r\nNegative conditionals indicate an end of processing and a\r\ndiscarding of the packet.\r\n?Do I have the hardware type in ar$hrd?\r\nYes: (almost definitely)\r\n [optionally check the hardware length ar$hln]\r\n ?Do I speak the protocol in ar$pro?\r\n Yes:\r\n [optionally check the protocol length ar$pln]\r\n Merge_flag := false\r\n If the pair \u003cprotocol type, sender protocol address\u003e is\r\n already in my translation table, update the sender\r\n hardware address field of the entry with the new\r\n information in the packet and set Merge_flag to true.\r\n ?Am I the target protocol address?\r\n Yes:\r\n If Merge_flag is false, add the triplet \u003cprotocol type,\r\n sender protocol address, sender hardware address\u003e to\r\n the translation table.\r\n ?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)\r\n Yes:\r\n Swap hardware and protocol fields, putting the local\r\n hardware and protocol addresses in the sender fields.\r\n Set the ar$op field to ares_op$REPLY\r\n Send the packet to the (new) target hardware address on\r\n the same hardware on which the request was received.\r\nhttps://tools.ietf.org/html/rfc826\r\nPage 5 of 11\n\nNotice that the \u003cprotocol type, sender protocol address, sender\r\nhardware address\u003e triplet is merged into the table before the\r\nopcode is looked at. This is on the assumption that communcation\r\nis bidirectional; if A has some reason to talk to B, then B will\r\nprobably have some reason to talk to A. Notice also that if an\r\nentry already exists for the \u003cprotocol type, sender protocol\r\naddress\u003e pair, then the new hardware address supersedes the old\r\none. Related Issues gives some motivation for this.\r\nGeneralization: The ar$hrd and ar$hln fields allow this protocol\r\nand packet format to be used for non-10Mbit Ethernets. For the\r\n10Mbit Ethernet \u003car$hrd, ar$hln\u003e takes on the value \u003c1, 6\u003e. For\r\nother hardware networks, the ar$pro field may no longer\r\ncorrespond to the Ethernet type field, but it should be\r\nassociated with the protocol whose address resolution is being\r\nsought.\r\nWhy is it done this way??\r\n-------------------------\r\nPeriodic broadcasting is definitely not desired. Imagine 100\r\nworkstations on a single Ethernet, each broadcasting address\r\nresolution information once per 10 minutes (as one possible set\r\nof parameters). This is one packet every 6 seconds. This is\r\nalmost reasonable, but what use is it? The workstations aren't\r\ngenerally going to be talking to each other (and therefore have\r\n100 useless entries in a table); they will be mainly talking to a\r\nmainframe, file server or bridge, but only to a small number of\r\nother workstations (for interactive conversations, for example).\r\nThe protocol described in this paper distributes information as\r\nit is needed, and only once (probably) per boot of a machine.\r\nThis format does not allow for more than one resolution to be\r\ndone in the same packet. This is for simplicity. If things were\r\nmultiplexed the packet format would be considerably harder to\r\ndigest, and much of the information could be gratuitous. Think\r\nof a bridge that talks four protocols telling a workstation all\r\nfour protocol addresses, three of which the workstation will\r\nprobably never use.\r\nThis format allows the packet buffer to be reused if a reply is\r\ngenerated; a reply has the same length as a request, and several\r\nof the fields are the same.\r\nThe value of the hardware field (ar$hrd) is taken from a list for\r\nhttps://tools.ietf.org/html/rfc826\r\nPage 6 of 11\n\nthis purpose. Currently the only defined value is for the 10Mbit\r\nEthernet (ares_hrd$Ethernet = 1). There has been talk of using\r\nthis protocol for Packet Radio Networks as well, and this will\r\nrequire another value as will other future hardware mediums that\r\nwish to use this protocol.\r\nFor the 10Mbit Ethernet, the value in the protocol field (ar$pro)\r\nis taken from the set ether_type$. This is a natural reuse of\r\nthe assigned protocol types. Combining this with the opcode\r\n(ar$op) would effectively halve the number of protocols that can\r\nbe resolved under this protocol and would make a monitor/debugger\r\nmore complex (see Network Monitoring and Debugging below). It is\r\nhoped that we will never see 32768 protocols, but Murphy made\r\nsome laws which don't allow us to make this assumption.\r\nIn theory, the length fields (ar$hln and ar$pln) are redundant,\r\nsince the length of a protocol address should be determined by\r\nthe hardware type (found in ar$hrd) and the protocol type (found\r\nin ar$pro). It is included for optional consistency checking,\r\nand for network monitoring and debugging (see below).\r\nThe opcode is to determine if this is a request (which may cause\r\na reply) or a reply to a previous request. 16 bits for this is\r\noverkill, but a flag (field) is needed.\r\nThe sender hardware address and sender protocol address are\r\nabsolutely necessary. It is these fields that get put in a\r\ntranslation table.\r\nThe target protocol address is necessary in the request form of\r\nthe packet so that a machine can determine whether or not to\r\nenter the sender information in a table or to send a reply. It\r\nis not necessarily needed in the reply form if one assumes a\r\nreply is only provoked by a request. It is included for\r\ncompleteness, network monitoring, and to simplify the suggested\r\nprocessing algorithm described above (which does not look at the\r\nopcode until AFTER putting the sender information in a table).\r\nThe target hardware address is included for completeness and\r\nnetwork monitoring. It has no meaning in the request form, since\r\nit is this number that the machine is requesting. Its meaning in\r\nthe reply form is the address of the machine making the request.\r\nIn some implementations (which do not get to look at the 14.byte\r\nethernet header, for example) this may save some register\r\nshuffling or stack space by sending this field to the hardware\r\ndriver as the hardware destination address of the packet.\r\nhttps://tools.ietf.org/html/rfc826\r\nPage 7 of 11\n\nThere are no padding bytes between addresses. The packet data\r\nshould be viewed as a byte stream in which only 3 byte pairs are\r\ndefined to be words (ar$hrd, ar$pro and ar$op) which are sent\r\nmost significant byte first (Ethernet/PDP-10 byte style).\r\nNetwork monitoring and debugging:\r\n---------------------------------\r\nThe above Address Resolution protocol allows a machine to gain\r\nknowledge about the higher level protocol activity (e.g., CHAOS,\r\nInternet, PUP, DECnet) on an Ethernet cable. It can determine\r\nwhich Ethernet protocol type fields are in use (by value) and the\r\nprotocol addresses within each protocol type. In fact, it is not\r\nnecessary for the monitor to speak any of the higher level\r\nprotocols involved. It goes something like this:\r\nWhen a monitor receives an Address Resolution packet, it always\r\nenters the \u003cprotocol type, sender protocol address, sender\r\nhardware address\u003e in a table. It can determine the length of the\r\nhardware and protocol address from the ar$hln and ar$pln fields\r\nof the packet. If the opcode is a REPLY the monitor can then\r\nthrow the packet away. If the opcode is a REQUEST and the target\r\nprotocol address matches the protocol address of the monitor, the\r\nmonitor sends a REPLY as it normally would. The monitor will\r\nonly get one mapping this way, since the REPLY to the REQUEST\r\nwill be sent directly to the requesting host. The monitor could\r\ntry sending its own REQUEST, but this could get two monitors into\r\na REQUEST sending loop, and care must be taken.\r\nBecause the protocol and opcode are not combined into one field,\r\nthe monitor does not need to know which request opcode is\r\nassociated with which reply opcode for the same higher level\r\nprotocol. The length fields should also give enough information\r\nto enable it to \"parse\" a protocol addresses, although it has no\r\nknowledge of what the protocol addresses mean.\r\nA working implementation of the Address Resolution protocol can\r\nalso be used to debug a non-working implementation. Presumably a\r\nhardware driver will successfully broadcast a packet with Ethernet\r\ntype field of ether_type$ADDRESS_RESOLUTION. The format of the\r\npacket may not be totally correct, because initial\r\nimplementations may have bugs, and table management may be\r\nslightly tricky. Because requests are broadcast a monitor will\r\nreceive the packet and can display it for debugging if desired.\r\nhttps://tools.ietf.org/html/rfc826\r\nPage 8 of 11\n\nAn Example:\r\n-----------\r\nLet there exist machines X and Y that are on the same 10Mbit\r\nEthernet cable. They have Ethernet address EA(X) and EA(Y) and\r\nDOD Internet addresses IPA(X) and IPA(Y) . Let the Ethernet type\r\nof Internet be ET(IP). Machine X has just been started, and\r\nsooner or later wants to send an Internet packet to machine Y on\r\nthe same cable. X knows that it wants to send to IPA(Y) and\r\ntells the hardware driver (here an Ethernet driver) IPA(Y). The\r\ndriver consults the Address Resolution module to convert \u003cET(IP),\r\nIPA(Y)\u003e into a 48.bit Ethernet address, but because X was just\r\nstarted, it does not have this information. It throws the\r\nInternet packet away and instead creates an ADDRESS RESOLUTION\r\npacket with\r\n (ar$hrd) = ares_hrd$Ethernet\r\n (ar$pro) = ET(IP)\r\n (ar$hln) = length(EA(X))\r\n (ar$pln) = length(IPA(X))\r\n (ar$op) = ares_op$REQUEST\r\n (ar$sha) = EA(X)\r\n (ar$spa) = IPA(X)\r\n (ar$tha) = don't care\r\n (ar$tpa) = IPA(Y)\r\nand broadcasts this packet to everybody on the cable.\r\nMachine Y gets this packet, and determines that it understands\r\nthe hardware type (Ethernet), that it speaks the indicated\r\nprotocol (Internet) and that the packet is for it\r\n((ar$tpa)=IPA(Y)). It enters (probably replacing any existing\r\nentry) the information that \u003cET(IP), IPA(X)\u003e maps to EA(X). It\r\nthen notices that it is a request, so it swaps fields, putting\r\nEA(Y) in the new sender Ethernet address field (ar$sha), sets the\r\nopcode to reply, and sends the packet directly (not broadcast) to\r\nEA(X). At this point Y knows how to send to X, but X still\r\ndoesn't know how to send to Y.\r\nMachine X gets the reply packet from Y, forms the map from\r\n\u003cET(IP), IPA(Y)\u003e to EA(Y), notices the packet is a reply and\r\nthrows it away. The next time X's Internet module tries to send\r\na packet to Y on the Ethernet, the translation will succeed, and\r\nthe packet will (hopefully) arrive. If Y's Internet module then\r\nwants to talk to X, this will also succeed since Y has remembered\r\nthe information from X's request for Address Resolution.\r\nRelated issue:\r\n---------------\r\nhttps://tools.ietf.org/html/rfc826\r\nPage 9 of 11\n\nIt may be desirable to have table aging and/or timeouts. The\r\nimplementation of these is outside the scope of this protocol.\r\nHere is a more detailed description (thanks to MOON@SCRC@MIT-MC).\r\nIf a host moves, any connections initiated by that host will\r\nwork, assuming its own address resolution table is cleared when\r\nit moves. However, connections initiated to it by other hosts\r\nwill have no particular reason to know to discard their old\r\naddress. However, 48.bit Ethernet addresses are supposed to be\r\nunique and fixed for all time, so they shouldn't change. A host\r\ncould \"move\" if a host name (and address in some other protocol)\r\nwere reassigned to a different physical piece of hardware. Also,\r\nas we know from experience, there is always the danger of\r\nincorrect routing information accidentally getting transmitted\r\nthrough hardware or software error; it should not be allowed to\r\npersist forever. Perhaps failure to initiate a connection should\r\ninform the Address Resolution module to delete the information on\r\nthe basis that the host is not reachable, possibly because it is\r\ndown or the old translation is no longer valid. Or perhaps\r\nreceiving of a packet from a host should reset a timeout in the\r\naddress resolution entry used for transmitting packets to that\r\nhost; if no packets are received from a host for a suitable\r\nlength of time, the address resolution entry is forgotten. This\r\nmay cause extra overhead to scan the table for each incoming\r\npacket. Perhaps a hash or index can make this faster.\r\nThe suggested algorithm for receiving address resolution packets\r\ntries to lessen the time it takes for recovery if a host does\r\nmove. Recall that if the \u003cprotocol type, sender protocol\r\naddress\u003e is already in the translation table, then the sender\r\nhardware address supersedes the existing entry. Therefore, on a\r\nperfect Ethernet where a broadcast REQUEST reaches all stations\r\non the cable, each station will be get the new hardware address.\r\nAnother alternative is to have a daemon perform the timeouts.\r\nAfter a suitable time, the daemon considers removing an entry.\r\nIt first sends (with a small number of retransmissions if needed)\r\nan address resolution packet with opcode REQUEST directly to the\r\nEthernet address in the table. If a REPLY is not seen in a short\r\namount of time, the entry is deleted. The request is sent\r\ndirectly so as not to bother every station on the Ethernet. Just\r\nforgetting entries will likely cause useful information to be\r\nforgotten, which must be regained.\r\nSince hosts don't transmit information about anyone other than\r\nthemselves, rebooting a host will cause its address mapping table\r\nhttps://tools.ietf.org/html/rfc826\r\nPage 10 of 11\n\nto be up to date. Bad information can't persist forever by being\r\npassed around from machine to machine; the only bad information\r\nthat can exist is in a machine that doesn't know that some other\r\nmachine has changed its 48.bit Ethernet address. Perhaps\r\nmanually resetting (or clearing) the address mapping table will\r\nsuffice.\r\nThis issue clearly needs more thought if it is believed to be\r\nimportant. It is caused by any address resolution-like protocol.\r\nSource: https://tools.ietf.org/html/rfc826\r\nhttps://tools.ietf.org/html/rfc826\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://tools.ietf.org/html/rfc826"
	],
	"report_names": [
		"rfc826"
	],
	"threat_actors": [],
	"ts_created_at": 1775434550,
	"ts_updated_at": 1775826743,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ce27aa9e4badc63ebc28f6dd863d07c31c8ed692.pdf",
		"text": "https://archive.orkl.eu/ce27aa9e4badc63ebc28f6dd863d07c31c8ed692.txt",
		"img": "https://archive.orkl.eu/ce27aa9e4badc63ebc28f6dd863d07c31c8ed692.jpg"
	}
}