This article is a part of a series on Address Resolution Protocol (ARP). Use the navigation boxes to view the rest of the articles.
- Traditional ARP
- Proxy ARP
- Gratuitous ARP
- ARP Probe and ARP Announcement
As we’ve learned before, the Address Resolution Protocol (ARP) is the process by which a known L3 address is mapped to an unknown L2 address. The purpose for creating such a mapping is so a packet’s L2 header can be properly populated to deliver a packet to the next NIC in the path between two end points.
The “next NIC” in the path will become the target of the ARP request.
If a host is speaking to another host on the same IP network, the target for the ARP request is the other host’s IP address. If a host is speaking to another host on a different IP network, the target for the ARP request will be the Default Gateway’s IP address.
In the same way, if a Router is delivering a packet to the destination host, the Router’s ARP target will be the Host’s IP address. If a Router is delivering a packet to the next Router in the path to the host, the ARP target will be the other Router’s Interface IP address – as indicated by the relative entry in the Routing table.
The Address Resolution itself is a two step process – a request and a response.
It starts with the initiator sending an ARP Request as a broadcast frame to the entire network. This request must be a broadcast, because at this point the initiator does not know the target’s MAC address, and is therefore unable to send a unicast frame to the target.
Since it was a broadcast, all nodes on the network will receive the ARP Request. All nodes will take a look at the content of the ARP request to determine whether they are the intended target. The nodes which are not the intended target will silently discard the packet.
The node which is the target of the ARP Request will then send an ARP Response back to the original sender. Since the target knows who sent the initial ARP Request, it is able to send the ARP Response unicast, directly back to the initiator.
The entire process is illustrated in this animation:
Notice the ARP Request includes the sender’s MAC address. This is what allows the target (Host B, in this case) to respond directly back to the initiator (Host A).
Now that you understand the general process, let’s take a deeper look at the contents of the ARP Request and ARP Response packets between Host A and Host B.
The ARP Request is an ARP payload carried within the appropriate L2 frame for the medium in use. The majority of the time this will be Ethernet, which will also be the L2 medium we will be looking at in our examples.
The Ethernet header will include three fields: a Destination MAC address, a Source MAC address, and an EtherType.
Notice the Layer 2 Destination is
ffff.ffff.ffff, this is the special reserved MAC address indicating a broadcast frame. This is what makes an ARP Request a broadcast. Had Host A chosen to send this frame using a specific host’s MAC address in the destination, then the ARP request would have been unicast.
The Source MAC address is, unsurprisingly, the MAC address of our sender – Host A.
The EtherType contains the hex value
0x0806, which is the reserved EtherType for Address Resolution packets.
This particular Ethernet header also includes some padding. The size of the Destination/Source/Type fields is 14 bytes, the size of the ensuing ARP Payload (pictured below) is 28 bytes, and the size of the trailing FCS (not pictured) is 4 bytes. Which means an additional 18 bytes of padding had to be added to ensure this frame reaches the minimum acceptable length of 64 bytes.
The ARP payload itself has a few fields which are worth discussing.
The Hardware Type and Protocol Type fields indicate what type of addresses are being mapped to each other. In this case, we are mapping an Ethernet address (MAC address) to an IPv4 address.
The Hardware Size and Protocol Size refer to the amount of bytes in each of the aforementioned types of addresses: a MAC address is 6 bytes (or 48 bits), and an IPv4 address is 4 bytes (or 32 bits).
The Opcode indicates what type of ARP packet this is. There are really only two values you will see. A value of
1 indicates this ARP packet is a Request, or a value of
2 would indicates this ARP packet is a Response (visible in the next section).
Finally there are two sets of MAC addresses and IP addresses, which make up the crux of the ARP payload.
The Sender MAC address and Sender IP address are, unsurprisingly, the MAC and IP address of the initiator of the ARP request. In this case, these are the addresses for Host A. Since the Request included the MAC address of Host A, the Response can be sent directly back to Host A, without necessitating a broadcast.
The Target MAC address and Target IP address refer to intended target of the ARP Request – in this case, Host B. Notice the Target IP address is filled in (
10.0.0.22), but the Target MAC address is all zeros. Since Host A does not know Host B’s MAC address, Host A can only populate the Target IP address field and leave the Target MAC address, essentially, blank.
Notice Host B is referred to as the target, and not the destination. This is an important distinction.
The ARP Request’s destination was the broadcast MAC address (
ffff.ffff.ffff). The ARP Request existed for the purpose of resolving Host B’s MAC address, hence the target is Host B.
Consider the target to mean the subject of the ARP conversation. This will make it easier to understand what is going on when we discuss Proxy ARP and Gratuitous ARP in the next articles in this series.
The ARP Response has a very similar packet structure. We will again look at the Ethernet header first, then the ARP payload.
The Ethernet header has the same three parts: a Destination MAC address, a Source MAC address, and an EtherType.
The Destination MAC is Host A — the initial requester, and the Source MAC is Host B — the original target. Notice the frame is addressed directly back to Host A – this is what makes the response unicast.
The EtherType again contains the hex value of
0x0806, to indicate an ARP packet. In addition, the same amount of padding is included in the ARP Response, as the size of the Ethernet Frame and ARP Response is the same as that of the ARP Request.
The ARP Response payload contains the same fields as the request above.
Hardware Type and Hardware Size indicate an Ethernet (or MAC) address that is 6 bytes (48 bits).
Protocol Type and Protocol Size indicate an IPv4 address that is 4 bytes (32 bits).
The major difference between the Request and the Response is in the Opcode field. In an ARP Response, this field contains a value of
The Sender MAC and Sender IP Address include the addresses for Host B, which is expected given Host B sent the ARP Response.
The Target MAC and Target IP Address include the addresses for Host A, as this is the target of the ARP Response.
When the ARP process completes, the information learned is stored in an ARP Table, or ARP Cache. Every device that has an IP address maintains such a table. Entries in this table expire after certain a duration.
Typically, for clients and end hosts, the ARP timeout will be pretty short – typically 60 seconds or less. The reason for this is at the client level, lots of mobility and movement happens, and you don’t want to cache an ARP entry for a very long time.
Whereas for network infrastructure devices (routers, firewalls, etc), the ARP timeout is very long – typically 2-4 hours. The reason for this is at the infrastructure level, the nodes joining and leaving the network should remain pretty consistent. A router is added to the network when it is initially built out, than occasionally as the network scales. Whereas hosts will be added and removed to your network on a day by day basis.
Of course, a Router has no way of knowing whether an entry in its ARP Cache is a host or another infrastructure device. Instead, to keep up with the mobility of clients, a Router’s cache is updated whenever it receives an ARP request.
Which is to say, if a Host is refreshing its default gateway’s ARP mapping every 30~ seconds due to the host’s shorter ARP timing, the default gateway’s ARP mapping of that same host will also be updated every 30 seconds.
There are also other strategies that exist that serve the purpose of keeping an ARP mapping up to date. We’ll explore those in a later article in this series.
I am not seeing RARP in here or anywhere on the site. Any plan to post on that?
No plans to post about Reverse ARP. It’s only use case is within Frame Relay. And Frame Relay doesn’t see much any longer.
Reverse ARP is like DHCP server, where each mac-address is mapped with one ip in the RARP server. when ever a pc requests for the ip from RARP server, the RARP server will check the mac address and give the ip add mapped for that mac address in the RARP server. this was used earlier days before DHCP server.
RARP works within a local LAN and not external network. for each LAN one RARP server is reqd.
Thank you for such a beautiful explanation. Cheers !!
I want to understand more about the ARP Table process. When computers are joined to the network and send a Free ARP, all others that were already connected receive and add IP ADDRESS AND MAC ADDRESS to their tables. When I manually delete the ARP entries received in the ARP table with the command arp -d from “Computer A” and after a few seconds or minutes, the entries with the IP ADDRESS AND MAC ADDRESS will return to the table again. Was it “Computer A” itself that sent a package asking again to update the table? Is this package a Traditional ARP? It seems that devices are always sending a Traditional ARP asking for a device’s MAC ADDRESS. In Wireshark I see traditional arp packets being sent as Unicast and traditional arp packets being sent as Broadcast. I believe it is because some arp entries must have expired from the table and some have not, so some were sent as Unicast.
If a host sends a Gratuitous ARP, or an ARP Announcement, than any other node on the network has all the information in order to populate their ARP table with that host’s ARP mapping — however, not all clients choose to record this information. Every operating system is free to choose how “greedy” it populates it’s ARP table.
Also consider, at any given time, your computer is being chatty on the network — in particular windows computers. They are often trying to broadcast and discover other windows computer to see what sort of shared services (files, printers, whatever) exist which means they are often talking to each other “behind the scenes” without you (the user) explicitly sending packets (via ping, or something).
Finally. Occasionally, as an ARP entry is set to expire, a host will try to refresh the entry by sending a Unicast traditional ARP. This is purely an optimization by the client, and not a rule per the protocol. I wrote about this behavior in this post:
Good questions! Hope these answers help.
Excellent explanation. Thank very much. I learn a lot from your articles. An article of this level is rare to find on the internet.
You’re very welcome. =)
What if there are two switches in middle between Request and Reply. How does the ARP reply work? How does the responder send the packet?
Host A is connected to SW-A on VLAN10 on Fa0/3
SW-A is connected to SW-B as a trunk to carry VLAN10 traffic. SW-A – Fa0/1 SW-B – Fa0/1
Host B is connected to SW-B on VLAN10 on Fa0/3
The ARP process would be completely independent of how one or more switches would operate. ARP is something initiated by Nodes (i.e., devices with IP addresses — hosts, routers, etc…).
A switch, or any number of switches, are merely the transport between the Nodes.
To understand how multiple switches operate in conjunction with one another, check out this article:
Well, that is a well defined question, 2 nodes in between the sender and the receiver. Wont the action be the same here, As the nodes whose mac address doesn’t correspond will ignore the ARP and the one on other side which correspond to the mac do reply
Great series of articles. Question:
I was reviewing a trace recently and noticed that in the ARP response, the Source and Sender mac addresses differed. I’ve seen this with VRRP, but in this case both the Source and Sender had Cisco OUIs (no VRRP or HSRP).
I thought maybe proxy arp, but in reviewing your article, the screen shot shows these addresses matching. Are you aware of any specific scenarios that would cause the ARP response to have a Sender mac address that is different from the Source?
My mind also went to Proxy ARP. Initially I’m thinking something is providing an ARP response on behalf of something else in the same Network. I would still consider it a “Proxy” ARP — the responder is saying “hey, to get to that IP address, go that way”.
The difference between that and the Proxy ARP example in the next article is in my Proxy ARP example the “that way” is the sender of the Proxy ARP itself.
Thanks for the quick reply. Yeah, I just couldn’t seem to find any other examples out there that show those two mac addresses being different.
However, I may have just stumbled upon what I was looking for. I believe that the catalyst for this may be GLBP (Gateway Load Balancing Protocol)
I need to read up more on it, but I filtered for that in the trace and the virtual mac it calls out is the different sender address in my ARP responses.
Posting that back here in case anyone else runs into it. What started this is, I have a device that does not appear to be acknowledging the ARP reply because of the difference between source and sender. Obviously an endpoint issue, but had never run into this before.
That makes sense then. The load balancing in GLBP works by answering ARP requests with different possible gateway MAC addresses. So indeed, it is Proxy ARP for devices on the same IP Network.
Great presentation. Especially your animated diagram. Many thanks !
You’re welcome, Riley!
How can a device recognize that an incoming packet is an ARP request?
The OpCode & the Ethernet “EtherType” field 0x0806 will indicate the type of packet.
Does traditional ARP happen only within the network ? I read proxy ARP article and in that it was mentioned that the host misunderstood that the destination host was in the same network and hence the router acted as a proxy . What if a host knew the destination was in a different network . Wouldn’t the router has to still act as proxy in order to communicate ? Or will the ARP request be passed on to the destination IP by the router ?
PS: Sorry if my question doesn’t make sense .
Yes, traditional ARP occurs in the same network.
Proxy ARP is merely Traditional ARP done on behalf of another host (typically in a foreign network). There will be more examples in the Proxy ARP article that follows in the series.
Will nodes that are not the intended target drop the packet without adding an arp entry to the cache? Will only the node that is the target of the ARP request store the information in the arp cache?
Typically, yes, that is the behavior I’ve seen. But all the information is there if an operating system decides to “greedily” learn all ARP entries it can. It is up to the OS to implement ARP how they see fit.
Thank you very much for that great explanation. Such a lot of effort! The only thing left for me is being a smartass:
“The ARP Request is an ARP payload carried within the appropriate L2 header for the medium in use. The majority of the time this will be Ethernet, which will also be the L2 medium we will be looking at in our examples.”
–> The ARP payload is not carried within the L2 Header, it should be L2 Frame, shouldn’t it?
“The Destination MAC is Host A — the initial requester, and the Source MAC is Host B — the original target. Notice the frame is addressed directly back to Host A – this is what makes the request unicast.”
The word request should actually be message or response as the context is an ARP response
It’s not being a smartass to help me ensure I have the best article I can produce. =) Thank you for the corrections, and good catches. I’ve fixed them both!
Great article! I have a small question: In an ARP response, is the target info (MAC, IP) strictly necessary? Anything bad would happen if the target info is wrong or missing?
Yes, the target IP/MAC is strictly necessary, that is in fact what provides the answer to the question =). If it were missing, it would be a malformed packet. If it were wrong, it would lead to the wrong MAC address receiving the intended data.
Wow, kudos to this entire website. I’ve had struggles understanding networking whenever it became relevant on the job, but these articles are very clearly written and quick to read! Thanks for taking the effort writing these articles. I finally know what a broadcast really does. 🙂
thanks very much