ARP

ARP is defined in RFC 826, which has been republished as STD 37 (ARP is an
Internet Standard protocol). However, RFC 826 contained some vagaries which
were clarified in RFC 1122 (Host Network Requirements). As such, ARP implementations
need to incorporate both RFC 826 and RFC 1122 in order to work reliably
and consistently with other implementations.
RFC 826 introduced the concept of an Address Resolution Protocol as a useful way
for devices to locate the Ethernet hardware address of another IP host on the same
local network. As it turns out, ARP is also useful for many network topologies—
not just Ethernet—and has since become incorporated into most of the other network
topologies. All LAN media—and many WAN media—now use ARP to locate
the hardware addresses of other IP devices on the local network.
When a device needs to send an IP packet to another device on the local network,
the IP software will first check to see if it knows the hardware address associated
with the destination IP address. If so, then the sender just transmits the data
to the destination system, using the protocols and addressing appropriate for whatever
network medium is in use by the two devices. However, if the destination
system’s hardware address is not known, then the IP software has to locate it
before any data can be sent. At this point, IP will call on ARP to locate the hardware
address of the destination system.
ARP achieves this task by issuing a low-level broadcast onto the network, requesting
that the system that is using the specified IP address respond with its hardware
address. If the destination system is powered up and on the network, it will see this
broadcast (as will all of the other devices on the local network), and it will return
an ARP response back to the original system. Note that the response is not broadcast
back over the network, but is instead sent directly to the requesting system.
This process is illustrated in Figure 3-1. In that example, Ferret issues an ARP
request for the hardware address associated with 192.168.10.40 to the networkspecific
broadcast address in use on that LAN. When Froggy sees the ARP request,
it unicasts an ARP reply (containing Froggy’s hardware address) to Ferret directly.
Having gained the information it needed, Ferret can then send whatever data it
has for Froggy to that host’s hardware address, using the protocols that are specific
to the underlying network medium.
ARP packets communicate with the data-link layer directly, the same as IP packets.
As such, ARP packets are completely separate from IP packets; they even have
a different protocol ID of 0806, instead of 0800 as used with IP.


When a device issues an ARP request, it fills in three of the four address-related
fields, providing its own hardware and IP address, as well as the IP address of the
target (the target’s hardware address is unknown, so that field is filled with
zeroes). In addition, it will set the message-type field to indicate that the current
packet is an ARP request, and then broadcast the request onto the local network
for all devices to see.
All of the local devices should monitor the network for ARP broadcasts, and whenever
they see a request for themselves (as indicated in the destination IP address
field of the ARP request), they should generate a response packet and send it back
to the requesting system. The response packet will consist of the local device’s IP
and hardware addresses (placed into the sender fields), and the IP and hardware
address of the original sender (placed in the destination fields of the response
packet). The response will also be marked as such, with the message-type field
indicating that the current packet is an ARP response. The new ARP packet is then
unicast directly to the original requester, where it is received and processed.


In this model, a higher-layer protocol such as TCP may notice that a problem has
occurred and attempt a retransmission, which would in turn generate another IP
packet (and another ARP request). Other protocols (such as UDP and ICMP) will
not do this, however, and will simply treat a failed ARP lookup as a general timeout
error (if a timer is being kept).
For example, if you try to use the ping program to test a host that is powered off,
that host will not be able to respond to ARP broadcasts, and as such the local
ICMP software will not be able to send an ICMP Echo Request message to the destination
system. However, ping may continue generating ICMP Echo Request messages,
which will result in multiple ARP lookups. ping may report timeout errors to
the user for each of the failed lookups (since no response was received to the
ICMP Echo Request message that was never actually sent over the network),
although these errors will be generated by ping, and not by ARP.