Which Destination Address Is Used In An Arp Request Frame

WhichDestination Address Is Used in an ARP Request Frame

Address Resolution Protocol (ARP) is a fundamental networking mechanism that lets devices on the same Ethernet segment discover the hardware (MAC) address that corresponds to a given IPv4 address. While the protocol itself is simple, the details of how an ARP request is framed often cause confusion, especially regarding the destination address placed in the Ethernet header versus the address carried inside the ARP payload. This article explains exactly which addresses are used, why they are chosen, and how they differ between the request and the reply.

Introduction

When a host needs to send an IP packet to another host on the same local network, it must first know the destination’s MAC address. If that information is not already cached, the host broadcasts an ARP request. The Ethernet frame that carries this request has a specific destination MAC address, while the ARP payload inside the frame contains the target protocol address (the IP address being resolved). Understanding the distinction between these two layers is essential for troubleshooting network connectivity, interpreting packet captures, and designing efficient LAN designs.

How ARP Works – A Quick Overview

1. Host A wants to send an IP packet to Host B but only knows Host B’s IPv4 address.
2. Host A checks its ARP cache. If the MAC address for Host B is missing, it builds an ARP request.
3. The request is placed inside an Ethernet frame and transmitted onto the LAN.
4. All devices on the segment receive the frame because the destination MAC address is a special broadcast value. 5. Only the device whose IP address matches the target protocol address in the ARP payload responds with an ARP reply.
5. Host A updates its cache and can now forward the original IP packet using the learned MAC address.

Ethernet Frame Structure Relevant to ARP

An Ethernet II frame (the most common type used today) consists of the following fields:

The destination MAC field is the only address that switches and NICs use to decide whether to forward, flood, or drop the frame. The ARP payload, meanwhile, holds its own set of addresses: sender hardware address, sender protocol address, target hardware address (usually all zeros in a request), and target protocol address.

Destination MAC Address in an ARP Request Frame

The Broadcast Address

In an ARP request, the Ethernet frame’s destination MAC address is set to the broadcast address:

FF:FF:FF:FF:FF:FF```

*Why broadcast?*  
- The sender does not yet know the MAC address of the target host, so it cannot address the frame to a specific NIC.  
- By using the broadcast address, the frame is flooded to **every** device on the same LAN segment.  
- All NICs accept the frame, examine the ARP payload, and only the device whose IP matches the *target protocol address* will generate a reply.

### Technical Details  

- The broadcast MAC is defined by the IEEE 802.3 standard as all bits set to one.  
- Switches treat a frame with this destination as unknown unicast and therefore **flood** it out all ports except the ingress port (unless port‑based filtering or VLANs restrict it).  
- In wireless LANs (802.11), the same concept applies: the frame is sent to the **broadcast SSID** (or to the AP, which then forwards it to all associated stations).

---

## Destination IP Address Inside the ARP Payload  

While the Ethernet header uses a broadcast MAC, the ARP request carries the **target protocol address** (TPA) – the IPv4 address you are trying to resolve. This field is **not** a destination address for the frame; it is merely data that the receiver inspects.

| ARP Field               | Size (bytes) | Value in a Request |
|-------------------------|--------------|--------------------|
| Hardware Type (HTYPE)   | 2            | 1 (Ethernet) |
| Protocol Type (PTYPE)   | 2            | 0x0800 (IPv4) |
| Hardware Length (HLEN)  | 1            | 6 |
| Protocol Length (PLEN)  | 1            | 4 |
| Operation (OPER)        | 2            | 1 (request) |
| Sender Hardware Address (SHA) | 6    | Sender’s MAC |
| Sender Protocol Address (SPA) | 4    | Sender’s IPv4 |
| **Target Hardware Address (THA)** | 6 | **00:00:00:00:00:00** (unknown) |
| **Target Protocol Address (TPA)** | 4 | **IPv4 address of the host you want to resolve** |

Thus, the *destination address* that matters for the ARP logic is the **TPA** inside the payload, while the Ethernet destination MAC is always the broadcast address.

---

## Why the Broadcast MAC Is Used – Conceptual Rationale  

1. **Zero‑knowledge assumption** – ARP is designed for the scenario where the sender knows nothing about the receiver’s MAC.  
2. **Efficiency on LANs** – Broadcasting a small ARP request (typically 42 bytes) is far less costly than sending unicast frames to every possible host individually.  
3. **Simplicity** – All NICs already have hardware support for recognizing the broadcast MAC; no extra logic is needed to parse a list of possible destinations.  4. **Scalability limit** – Broadcast domains are kept small (usually a single subnet) to prevent ARP storms. VLANs, subnetting, and proxy ARP are used to contain the scope.

---

## What Happens in an ARP Reply?  

When the target host (the one whose IP matches the TPA) receives the broadcast ARP request, it constructs an ARP reply:

- **Ethernet destination MAC** becomes the **sender’s MAC address** (the original requester’s SHA).  
- **Ethernet source MAC** is the responder’s own MAC.  
- **ARP payload**:  
  - OPER = 2 (reply)  
  - SHA = responder’s MAC  

When the target host recognizes that its own IPv4 address matches the TPA field in the incoming ARP request, it builds an ARP reply that essentially mirrors the request but swaps the roles of sender and target. The Ethernet frame carrying the reply is no longer broadcast; it is a unicast frame directed straight to the original requester.

**Ethernet header of the reply**  
- Destination MAC = SHA from the request (the MAC of the host that sent the ARP request).  - Source MAC = the responder’s own MAC address.  
- EtherType = 0x0806 (ARP).

**ARP payload of the reply**  | Field | Value in the reply | Meaning |
|-------|-------------------|---------|
| HTYPE | 1 | Ethernet |
| PTYPE | 0x0800 | IPv4 |
| HLEN  | 6 | MAC length |
| PLEN  | 4 | IPv4 length |
| OPER  | 2 | ARP reply |
| SHA   | responder’s MAC | now the sender hardware address |
| SPA   | responder’s IPv4 | the protocol address being announced |
| THA   | requester’s MAC (SHA from request) | the target hardware address – the host that asked |
| TPA   | requester’s IPv4 (SPA from request) | the protocol address of the requester |

Upon receiving this unicast reply, the original requester updates its ARP cache: it maps the responder’s IPv4 address (SPA) to the responder’s MAC address (SHA). With the MAC now known, any subsequent IP packets destined for that IPv4 address can be encapsulated in an Ethernet frame with the correct destination MAC and sent as a normal unicast transmission.

### ARP Cache Management
- **Timeouts:** Most operating systems expire dynamic ARP entries after a period (typically 20 – 60 minutes of inactivity) to reclaim memory and to allow for topology changes.  
- **Refresh:** Before an entry expires, the host may send a unicast ARP request to the cached MAC to verify reachability; if no reply is received, the entry is flushed.  
- **Static entries:** Administrators can manually bind an IP to a MAC (e.g., for critical servers) to prevent ARP‑based attacks, though this reduces flexibility.

### Special ARP Variants| Variant | Purpose | Typical Use |
|---------|---------|-------------|
| **Gratuitous ARP** | Announces or updates a host’s own IP‑to‑MAC mapping without a prior request. | Detects IP address conflicts, notifies switches of a MAC move after VM migration, or updates redundant gateway protocols (e.g., VRRP/HSRP). |
| **Proxy ARP** | A device answers ARP requests on behalf of another host, usually because the target lies on a different subnet but is reachable via the proxy. | Facilitates communication in legacy networks where hosts lack proper routing, or in scenarios like NAT/load‑balancers. |
| **ARP Spoofing (Poisoning)** | An attacker sends falsified ARP replies to associate its MAC with a victim’s IP, enabling man‑in‑the‑middle interception. | Mitigated by Dynamic ARP Inspection (DAI) on switches, port security, static ARP entries, or cryptographic solutions such as SEcure Neighbor Discovery (SEND) for IPv6. |

### Security ConsiderationsBecause ARP operates without authentication, trusting any ARP reply is inherently risky. Modern defenses include:
- **Switch‑based DAI:** Validates ARP packets against a trusted DHCP snooping database before forwarding.  
- **802.1X / MACsec:** Provides port‑level authentication and encryption, reducing the chance that a rogue device can inject malicious ARP frames.  
- **Host‑based monitoring:** Tools like `arpwatch` or OS‑level ARP cache anomaly detectors alert administrators to sudden MAC changes for a given IP.

### Conclusion
The brilliance of ARP lies in its simplicity: a broadcast Ethernet frame carries a small payload that asks, “Who has this IP address?” The responder then replies directly to the asker, completing the address‑resolution handshake with minimal overhead. While this mechanism works flawlessly in a trusted LAN, its lack of built‑in authentication necessitates additional safeguards—ranging from cache timeouts and gratuitous ARPs to advanced switch features—to maintain both efficiency and security in modern networks. Understanding the interplay between the Ethernet broadcast destination and the ARP protocol’s internal fields is essential for troubleshooting connectivity issues, designing resilient network architectures, and defending against ARP‑based threats.