Address Resolution Protocol (ARP)

An IP address is the logical addressing

scheme for nodes on a network. IP Addresses exist at the Network layer of
the OSI Model and help facilitate the L3 goal of “end to end” delivery.

A MAC address is the physical addressing scheme for individual NIC cards on
each node of a network. MAC addresses exist at the Data Link layer of the
OSI Model and help facilitate the L2 goal of “hop to hop” delivery.

The Address Resolution Protocol (ARP) creates the correlation which

makes the union between these two addressing schemes possible.

We’ve already discussed the basic functionality of ARP and its role in how
packets move through a network. However, there are different iterations of
address resolution – each employed at different times and for different
situations.

This article series will discuss each of these iterations and the situations for
which they are used.

 Traditional ARP

 Proxy ARP

 Gratuitous ARP

 ARP Probe and ARP Announcement

Traditional ARP

This article is a part of a series on Address Resolution Protocol (ARP). Use the
navigation boxes to view the rest of the articles.
Address Resolution Protocol

 Traditional ARP

 Proxy ARP

 Gratuitous ARP

 ARP Probe and ARP Announcement

Traditional ARP

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.

ARP Process

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.

ARP Request

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.

ARP Response

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 2.

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.

You can download the packet capture of the ARP conversation above here. It
can be studied using Wireshark.

ARP Timing

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.

Proxy ARP

We’ve discussed the use cases and role of traditional ARP in the prior article
of this series. In this article we will discuss Proxy ARP and its role and
significance.

Proxy ARP occurs when one node is responding to an ARP request

on behalf of another node.

Proxy ARP is not a malicious event, it occurs to enable connectivity between

two hosts that wouldn’t otherwise be possible.

Original Use Case

The original thought process for Proxy ARP was to accommodate hosts with
misconfigured subnet masks.

As we’ve discussed before, when 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.

The item which tells a host whether another IP address is on

the same network or a different network is the subnet mask. This topology
will illustrate how it works:
Host A is configured with the IP address 10.0.0.11 and a subnet mask
of 255.255.255.0 (or /24 in CIDR). Host A will consider any IP address in the
range of 10.0.0.0 – 10.0.0.255 on its local network.

Host B is configured with the IP address 10.0.0.22 and misconfigured with a

subnet mask of 255.255.0.0 (or /16 in CIDR). Host B will consider any IP
address in the range of 10.0.0.0 – 10.0.255.255 on its local network.

Presume both of these hosts are trying to speak to Host D, which exists on
a different network and has the IP address 10.0.4.44.

When Host A tries to speak to 10.0.4.44, it would (correctly) consider Host D

on a different network and would use traditional ARP to send the packet to
the default gateway.

However, when Host B tries to speak to 10.0.4.44, it would (incorrectly)

consider Host D on the same network and would instead try to ARP for Host
D’s MAC address directly.

Host B’s ARP Request will be broadcast to the local network, but will never
make it across the Router to Host D. Therefore, the ARP Request will go
unanswered, and Host B will be unable to communicate with Host D.

Unless the Router itself responds to Host B’s ARP Request on behalf of Host D
– which is the exact definition of a Proxy ARP.

Here is the process in action (Host A is not pictured):

The ARP Response sent by the Router looks exactly like a normal ARP
response. Host B will use the response to create an ARP mapping that states
the IP 10.0.4.44 maps to the MAC address 0053.ffff.9999. All subsequent
packets sent to Host D will use this MAC address in the L2 header.

So despite the misconfigured Subnet Mask, Host B will be able to speak to

Host D, due to the Router’s heroic use of Proxy ARP.

That being said, it does impose additional work load on the Router. We used
the specific example of Host D’s single IP address, but due to Host B’s
misconfigured subnet mask there are roughly 65,000 IP addresses that Host
B now considers on its local network. When in reality only about 250 could
possibly exist on its local network.

So while Proxy ARP enabled connectivity in this example, it unfortunately

does not scale indefinitely and should not be relied upon. The long term
solution is to correct the misconfigured Subnet mask on Host B.

Moreover, this specific use case for Proxy ARP is based solely around
enabling routing despite there being a misconfiguration. With Proxy ARP,
Host B may never even realize it has an incorrect Subnet Mask.

There is another school of thought that instead would prefer Host B’s
misconfiguration to cause the communication to fail in order for Host B to be
notified that something is wrong. Thereby creating an opportunity for Host B
to fix the root problem.

Many routers these days do not send Proxy ARPs by default for this very
reason. Although most include a way to enable it if desired.

That said, there is a very important and legitimate use case for Proxy ARP —
one which does not stem from a misconfiguration. We’ll take a look at it after
exploring the Packet Structure for Proxy ARP next.

Proxy ARP Packet Structure

The ARP Request looks identical to the traditional ARP Request we looked at
in the last article. In fact, it is a traditional ARP request, as the initiator of the
ARP Request does not know whether the response will come in via proxy.

The Proxy ARP Response is slightly different, but has the same packet
structure as the traditional ARP Response packet:
Notice the response is sent Unicast, directly from the Router’s MAC address
to Host B’s MAC address.

The Opcode still contains the value 2, indicating an ARP response.

The crux of the Proxy ARP is in the Sender MAC and Sender IP address fields.

Notice, the Sender MAC address is the Router’s MAC address, but
the Sender’s IP address is Host D’s IP address. The Router is providing
its own MAC address as the owner for another hosts IP address, hence
responding to the ARP on behalf of Host D.

Finally, the Target MAC and Target IP address fields, as expected, contain
the information correlating to Host B, which is the intended recipient of this
ARP Response.

You can download the packet capture of the Proxy ARP conversation
above here. It can be studied using Wireshark.

Proxy ARP in Network Address Translation

Earlier we discussed Proxy ARP and its use case for routing for misconfigured
hosts. Of course, that use case all but disappears if every host is configured
properly.

However, there is a very legitimate and necessary use case for Proxy ARP,
and that has to do with Network Address Translation, or NAT.

We will use this topology to describe it:

Our Firewall has the IP address 72.3.4.2 in the 72.3.4.0/24 network. Our
Firewall is also configured with a Static NAT that translates the IP
address 72.3.4.55 to 10.3.4.55. These IP addresses belong to Host Y, with the
IP address 10.3.4.55. Host X is simply some host on the other side of the
Internet, using the IP 66.7.8.9.

If Host X sends a packet to Host Y, that packet will have a Source IP

of 66.7.8.9 and a Destination IP of 72.3.4.55. Routing will take that packet
across the internet until it finally arrives at Router C.

Router C now needs to deliver a packet that is destined to a network it is

directly attached to (72.3.4.0/24). Router C initiates an ARP Request to
determine the MAC address which owns the IP address 72.3.4.55.

But the device which owns that IP address is Host Y, which is not in the same
network as Router C. So Host Y would be unable to respond to this query.

The Firewall, however, having been configured to translate packets

from 72.3.4.55 to 10.3.4.55, knows it must receive the packets destined
to 72.3.4.55 so that it can translate them and deliver them to Host Y.

Therefore, the Firewall will use Proxy ARP to respond to Router C’s ARP
Request for the 72.3.4.55 IP address on behalf of Host Y.

The entire process is illustrated in this animation:

If not for the Firewall participating in Proxy ARP, the Network Address
Translation would fail, since packets sent from Router C would never arrive to
the Firewall.
Hence, for Network Address Translation to work properly, the
translation device must use Proxy ARP to properly receive packets
to be translated.

As demonstrated, any NAT deployment will require the use of Proxy ARP to
properly receive packets which must be translated.

There are ways around requiring Proxy ARP on a NAT device, but they
involves using Static Routes on the upstream Router to manually instruct the
Router to send packets which must be translated to the Firewall’s interface.
While viable, this solution does not scale.

Gratuitous ARP

We’ve talked about Traditional ARP, where a node is requesting another

node’s MAC address. We’ve also talked about Proxy ARP, where a node is
answering an ARP request on behalf of another node. Which brings us to
another iteration of ARP known as Gratuitous ARP.

A Gratuitous ARP is an ARP Response that was not prompted by an

ARP Request. The Gratuitous ARP is sent as a broadcast, as a way for a
node to announce or update its IP to MAC mapping to the entire network.

There are three typical use cases for Gratuitous ARP, and we will look at each
of them after looking at the packet structure.

Gratuitous ARP Packet Structure

The main item to point out in the Ethernet header is the Destination MAC.
Notice this frame is addressed to ffff.ffff.ffff, making it a Broadcast frame.

The Source MAC, Type, and Padding work exactly as they did in the
traditional ARP.
Similarly, in the ARP payload, the Hardware and Protocol type and
the Hardware and Protocol Size also serve the same purpose as they did in
traditional ARP.

The Opcode is set to 2, indicating a response. Despite the fact that this
packet did not actually follow a request.

This is why it is said that a Gratuitous ARP is broadcast ARP Response, that
was not prompted by an ARP Request.

The Sender MAC and Sender IP contain the ARP mapping the initiator is
advertising. These two are the important part of the ARP Packet. They are
the reason the ARP packet exists.

The Target MAC address is ffff.ffff.ffff – a reflection of the Destination MAC

address. But in reality, the contents of this field are irrelevant – they are
ignored in a Gratuitous ARP. Some implementations of ARP will
use 0000.0000.0000 in this field.

Lastly, the Target IP address once again confirms the IP address that this
particular ARP mapping is being created for.

Gratuitous ARP Use Cases

Now that we’ve understood the packet contents of a Gratuitous ARP, we can
look at their specific use cases. There are three primary cases we will
illustrate for Gratuitous ARP: updating ARP mappings, announcing a node’s
existence, and redundancy.

Updating ARP Mapping

The first use case is pretty straight forward, a node can use a Gratuitous ARP
to update the ARP mapping of the other hosts on the network should the
node’s IP to MAC mapping change.
This might happen if a user manually modifies their MAC address – they
retain the same IP address, but now have a new MAC address. Therefore, the
ARP mapping for all the nodes which are communicating with this user must
be updated.

That being said, manually changing the MAC address is pretty rare. However,
you do sometimes see this in redundant Cloud or Virtual environments,
where a particular Virtual Machine (VM) ‘jumps’ to a new physical box – the
same VM’s IP address is now being served by a different physical machine.

Announcing a Node’s Existence

The second use case for Gratuitous ARP is when a host newly joins a network
— it can use Gratuitous ARP to announce it’s existence to the network.

The intent motivating this action is useful — it is an attempt to preemptively

populate ARP caches of neighboring hosts without requiring them to initiate
the Traditional ARP process.

However, there is no mandate for hosts to cache ARP mappings in every

Gratuitous ARP they receive. As a result, this use case provides little benefit.
It causes no significant harm though, so this behavior is not discouraged.

This use case is often confused with an attempt to detect possible duplicate
IP addresses, but a Gratuitous ARP is not used for this process. To detect an
IP address conflict, hosts will use ARP Probes and Announcements, which is
the topic for the next article in the Address Resolution Protocol Series.

Redundancy

Much more substantial is Gratuitous ARP’s use case in situations where

redundancy or failover between two devices are used.

With redundancy, you typically have two scenarios: two devices sharing an IP
address, but each having their own MAC address. Or, two devices sharing
both an IP address and a MAC address.

In both of these cases, Gratuitous ARP is critically important to ensure the

continued ability to communicate with the IP address as it shifts between the
two redundant devices. Below are examples of each scenario and how
Gratuitous ARP is employed.

Redundant IP Addresses

In this scenario, only the IP address is redundant. Two devices will share a
single IP address, but each device has their own unique MAC addresses.
Our example will use two Routers sharing the IP address 10.0.0.1. The hosts
in our example will be using this shared IP address as their default gateway.

When one of the routers experiences a failure, the other router sends a
Gratuitous ARP.

The specific contents of the Gratuitous ARP match the packet structure
described above, but the essential purpose of the packet is to let everyone
on the network know that the IP 10.0.0.1 is now being served by the other
router’s MAC address.

Upon receiving the Gratuitous ARP, all the hosts update their ARP tables with
the new mapping so they can continue to send traffic to their default
gateway IP address through the non-failed Router.

The process continues indefinitely in the case of the opposite router failing.
Note, that this particular animation uses routers as the example, but nearly
any type of device that shares an IP address with another device will use
Gratuitous ARP in this manner.

Redundant IP and MAC Addresses

In this scenario, both the IP address and the MAC address are redundant. Two
devices will share both an IP address and a MAC address.

Our example will again use two Routers, but this time they will be sharing
the IP address 10.0.0.1 and the MAC address 0053.ffff.1111.
The hosts will still use the shared IP address as their default gateway, but in
this example their ARP mapping will never need to change – the shared IP
address 10.0.0.1 will always map to the shared MAC address 0053.ffff.1111.

Despite the hosts’ ARP mapping never needing to be updated, Gratuitous

ARP is still crucial. But not for the sake of updating the hosts’ ARP mapping,
but for the sake of updating the switch’s MAC address table so the shared
MAC address is associated with the correct port. Recall, switches learn MAC
address mappings from the Source MAC address of any received frame.

Notice, as a router fails, the other router sends a Gratuitous ARP. The switch
then updates its MAC address table with the new location of the device that
owns the shared MAC address.

Again, the specific contents of the Gratuitous ARP match the packet structure
described above. But the purpose is for the Switch to learn the new location
of the shared MAC address.

In this way, frames sent by the hosts addressed to 0053.ffff.1111 will always
egress the correct switch port.

First Hop Redundancy Protocols (FHRPs) like HSRP or VRRP use this exact
strategy to enable both routers to share the same IP address and MAC
address. Gratuitous ARP is instrumental to enable this type of functionality.

You can download a packet capture of a Gratuitous ARP here. Or, you can
download a packet capture of HSRP’s Gratuitous ARPs enacting the last
animation of IP and MAC redundancy. Both can be studied using Wireshark.
ARP Probe and ARP Announcement

We finally come to the last iteration of ARP that this article series will discuss.
They are the ARP Probe and the ARP Announcement. Both of these are used
in a process known as Duplicate Address Detection.

The idea is if a host acquires and puts to use an IP address that happens to
already be in use on the network, it will cause connectivity issues
for both hosts. As such, it is beneficial for a host to first test an IP address
before putting it to use to ensure it is indeed unique.

One such way of determining if an IP address in use is to use ARP. Or

specifically, an ARP Probe.

The process is pretty straight forward, send a few ARP Probes (typically 3),
and if no one responds, officially claim the IP address with an ARP
Announcement.

Both the ARP Probes and the ARP Announcements are sent as Broadcast
frames – using the destination MAC address of ffff.ffff.ffff in the Ethernet
header.

Both are sent without being solicited by a request, which therefore makes
them “gratuitous”. But technically, they are not exactly the same as
a Gratuitous ARP.

We will look at the packet structures in a moment, and they will reveal
exactly how the ARP Announcements and ARP Probes are different from a
Gratuitous ARP — despite often being incorrectly referred to as the same.

ARP Probe Packet Structure

The ARP Probe serves the purpose of polling the network to validate that an
IP address is not already in use.
 It is sent with the Opcode field set
to 1, indicating an ARP Request. The idea is if the IP address in
question is already in use, the initiator of the ARP Probe will expect a
Response from original owner. Hence, this ARP Probe is a request which
might prompt a response.

The Sender MAC address is set to the initiator’s MAC address. The Sender
IP address is set to 0.0.0.0.

The Target MAC address is set to 0000.0000.0000, and the Target

IP Address is set to the IP address being probed.

Notice there is no complete mapping provided in the packet. The

Sender IP is set to all zeros, which means it cannot map to the Sender MAC
address. The Target MAC address is all zeros, which means it cannot map to
the Target IP address.

This is intentional, because the reason for sending the ARP Probe is
to prevent an IP conflict. If the target IP address is already in use, it would be
very undesirable for other hosts on the network to inadvertently update their
ARP cache based upon the contents of the ARP Probe.

This is also the primary difference between an ARP Probe and a Gratuitous
ARP. A Gratuitous ARP is meant to update all the ARP caches on the network,
where as an ARP Probe deliberately prevents updating of ARP caches to
continue protecting against IP address conflicts.

ARP Announcement Packet Structure

If the ARP Probe does not generate a response from whomever might already
be using the IP address, the initiating host will consider this IP address
unique and will send an ARP Announcement to officially “claim” the IP
address on the network.
The ARP Announcement is very similar to a Gratuitous ARP, with one notable
exception:

The Opcode in an ARP Announcement is set to 1, indicating a request.

Typical Gratuitous ARP will have an Opcode set to 2.

Otherwise, the packet structure is identical to the ARP Probe above, with the
exception that a complete mapping exists. Both the Sender MAC address
and the Sender IP address create a complete ARP mapping, and hosts on
the network can use this pair of addresses in their ARP table.

Like the Gratuitous ARP, the Target MAC address is ignored, in this example
it is set to 0000.0000.0000, some implementations of the ARP
Announcement use ffff.ffff.ffff instead.

Finally, the Target IP again confirms the subject of the communication: the
IP address who’s uniqueness has now been confirmed.

Once again, the ARP Announcement is very similar to the Gratuitous ARP,
with their only difference being the Opcode field. They are often both simply
referred to as a Gratuitous ARP — despite technically being different
constructs. However, for everyday networking, this is a trivial misnomer,
and a little inaccuracy can sometimes save a lengthy explanation.

You can download the packet capture of the ARP Probe and ARP
Announcement process here. It can be studied using Wireshark.