IPv4 Address Resolution with ARP

In IPv4, IP addresses are mapped to Link Layer addresses by ARP, which is specified in RFC 826, "An Ethernet Address Resolution Protocol", November 1982. ARP lives in the Link Layer, and has no real protection against hacking attacks (so it is the target of many dangerous attacks).

When a node (alice-pc) wants to send a packet to another node (bob-pc) which is in the same subnet, it first checks to see if it has done so recently, which means it might have bob-pc's MAC address cached. This cache is called the ARP table. This is a list of IP addresses and corresponding MAC addresses, complete with a timestamp (to determine when that information becomes "stale" and should be discarded). If bob-pc's IP address (and corresponding MAC address) is already in alice-pc's ARP cache, alice-pc just gets bob-pc's MAC address from its ARP cache, and builds the outgoing Ethernet frame.

If you type "arp -a" in Windows, you will see the current contents of the ARP cache. The dynamic entries were learned through ARP requests, and they will eventually expire. The static entries were generated from multicast addresses, and never expire.

 

arp-cache

 

ARP Request

Assuming bob-pc's IP address is not in the table, alice-pc will send an ARP Request to all nodes on the subnet. Let's assume alice-pc and bob-pc have the following IP and MAC addresses:

alice-pc: IP address 172.20.2.1, MAC address: 00:22:15:24:32:9c

bob-pc:  IP address 172.20.2.11, MAC address 00:17:a4:ec:11:9c

The ARP request from alice-pc says

"Hey everyone! I own IP address 172.20.2.1 and MAC address 00:22:15:24:32:9c. Who owns IP address 172.20.2.11?".

This is sent via Ethernet broadcast (MAC address ff:ff:ff:ff:ff:ff) to all nodes on the subnet. Here is a packet capture of this ARP request:

arp-request

 

ARP Reply

When bob-pc receives this ARP request, it updates its ARP cache with the sender's IP address and MAC address, for future use.

All of the nodes except bob-pc see that ARP request and discard it as not relevant to them ("not my business!"). Node bob-pc however, recognizes its own IP address, and responds directly to alice-pc with an ARP response:

"Hey 00:22:15:24:32:9c, I own IP address 172.20.2.11, and my MAC address is 00:17:a4:ec:11:9c".

Since bob-pc knows the MAC address of alice-pc (from the ARP request), it sends the reply directly to alice-pc (not to everyone). Here is a packet capture of the ARP reply:

arp-reply

When alice-pc receives this reply, it updates its ARP cache with the sender's IP address and MAC address, which it then uses to create the Ethernet frame needed to transmit the IP packet.

 

Gratuitous ARP

There is an interesting variant on the ARP request, called a Gratuitous ARP. This involves a node sending an ARP request for information about its own IP address. This is basically saying:

"Hey everyone! I own IP address 10.3.2.56 and MAC address 00:19:5b:2f:14:6b. Who owns IP address 10.3.2.56?".

Here is a packet capture of one:

gratuitous-arp

This seems like an odd thing for a node to do. If you were another node and saw this, you might think "idiot, YOU own it - you just said you did." There are two reasons for a node to send such a request:

First, when a node (say, alice-pc) first connects to a subnet (or when its interface is enabled), it sends a gratuitous ARP and then waits for a short while hoping that no one replies. If someone does reply (say bob-pc), then the IP address in question is already in use by the node that responded, so the new node (alice-bc) cannot also use that address (that would produce an address conflict). It must configure a new address and try again. If alice-pc doesn't hear any reply, it assumes the address is "fair game" and begins using it. Note that if bob-pc did own the address, but is currently not connected (or is powered off), alice-pc will not know that bob-pc already has the address. When bob-pc later connects to the subnet, it will find out that its address is already in use by alice-pc (assuming alice-pc is connected at that time). Node bob-pc just lost ownership of that address, and must configure another one.

Second, switches in a subnet can learn what interface various nodes are connected to, by listening for gratuitous ARPs (they don't send a reply, of course). They build a table of MAC addresses connected to its various interfaces, which is used to optimize traffic flow.