ARP and Local Delivery

Why ARP exists

An IPv4 application may know a destination IP address, but Ethernet needs a destination MAC address for the next local link. The Address Resolution Protocol (ARP) supplies that missing association: it asks which local interface owns a next-hop IPv4 address and learns the MAC address in the reply.

Think of the IP address as the destination written on a journey plan and the MAC address as the delivery label needed for the next room. The analogy has a limit: ARP is a local evidence exchange, not a trusted identity check and not a way to discover every router on the end-to-end path.

ARP is carried directly inside an Ethernet frame with EtherType 0x0806; it is not carried inside an IPv4 packet. ARP resolves IPv4 next hops. IPv6 uses Neighbor Discovery instead.

Choose the next hop first

Before sending ARP, a host applies its interface prefix and routing table:

• If the destination is on-link, the host resolves the destination host's IPv4 address.
• If the destination is remote, the host resolves the selected gateway's local IPv4 address.
• The final IP destination remains unchanged when the Ethernet destination becomes the gateway MAC.

For example, 192.0.2.10/24 treats 192.0.2.20 as local, so it asks for 192.0.2.20. To reach 198.51.100.50, it instead asks for its gateway such as 192.0.2.1. A host does not ARP for a remote server across a router.

Request, reply and cache

When no usable neighbour entry exists, the normal exchange is:

1. The sender creates an ARP request: “Who has the next-hop IP? Tell the sender.”
2. Ethernet carries it to FF:FF:FF:FF:FF:FF, so the switch floods eligible interfaces except ingress.
3. Every local receiver can inspect the request, but normally only the owner answers.
4. The owner returns an ARP reply, normally by unicast, containing its IPv4-to-MAC mapping.
5. The sender caches the mapping and can finally build the data frame.

The ARP message includes hardware and protocol types, address lengths, an operation, and sender and target hardware/protocol addresses. In a request the target MAC is unknown inside the ARP message, while the enclosing Ethernet destination is broadcast. These two fields must not be confused.

Cache entries age because local evidence can change. A usable cached mapping avoids a fresh broadcast; an unanswered request can leave an incomplete entry and prevents the original frame from being built.

Interactive ARP journey

Follow the next-hop decision, open the Ethernet and ARP information at each stage, and watch the broadcast request fan out before the unicast reply returns. The player starts automatically unless reduced motion is enabled, and every stage remains available through manual controls.

Watch ARP resolve the next hop

Change the situation, then follow the next-hop decision, ARP evidence, cache state and resulting Ethernet delivery.

Choose an ARP situation

Local destinationRemote via gatewayWarm cacheNo replyProxy ARPGratuitous ARP

Host A resolves Host B's IPv4 address before it can build the Ethernet frame that carries the original packet.

• Host A: Host A eth0↔Switch: Switch Gi0/1
• Switch: Switch Gi0/2↔Host B: Host B eth0
• Switch: Switch Gi0/3↔Gateway: Gateway Gi0/0

Active: Host A

PreviousPlayNextRestartPlayback speed0.5×1×1.5×2×

Step 1 of 9

1. Choose the local next hop

Host A applies /24 to 192.0.2.20 and identifies an on-link destination. The next hop is Host B itself, not the gateway.

Packet inspector

Inside the packet

Choose packet inspection depth

Plain-language viewTechnical inspection

Host or device decision

No frame is crossing a link during this step.

Source

192.0.2.10/24

Destination

192.0.2.20

Next-hop IP

192.0.2.20Changed at this hop

Technical packet details

Decision

On-link: resolve the destination host

ARP variants and boundaries

Explore ARP variants packet by packet

Select a journey to see what is already known, what must be discovered and where the exchange is allowed to travel.

Choose an ARP-family journey

Standard ARPProxy ARPGratuitous ARPRARPInverse ARP

A host discovers the MAC address of an IPv4 neighbour on its local Layer 2 network.

• Host A: Host A eth0↔Switch: Switch Gi0/1
• Switch: Switch Gi0/2↔Host B: Host B eth0
• Switch: Switch Gi0/3↔Gateway: Gateway Gi0/0

Active: Host A

PreviousPlayNextRestartPlayback speed0.5×1×1.5×2×

Step 1 of 4

1. Check the neighbour cache

Host A has no usable mapping for 192.0.2.20, so it must ask the local broadcast domain.

Packet inspector

Inside the packet

Choose packet inspection depth

Plain-language viewTechnical inspection

Host or device decision

No frame is crossing a link during this step.

Lookup

192.0.2.20 → incompleteChanged at this hop

Technical packet details

Next action

Send a local ARP request

Standard ARP: resolve the next local hop

Scenario: Host A wants to send to Host B on the same subnet, but it knows only Host B's IPv4 address. Host A first checks its neighbour cache. If no usable mapping exists, it sends an ARP request inside an Ethernet broadcast frame. The switch floods a copy through every eligible port except the ingress port. Host B recognizes its own IPv4 address and normally sends a unicast ARP reply containing its MAC address. Host A caches the mapping and can then send the original data frame.

The important sequence is choose next hop → resolve its MAC → send the data. ARP does not find an end-to-end route, test whether an application is listening, or prove that the reply is trustworthy. For a remote destination, standard ARP resolves the gateway's local address rather than the remote server's address.

Proxy ARP: a router answers for another address

Scenario: a host treats a destination as local because of its subnet mask, even though reaching that destination actually requires a router. When Proxy ARP is enabled and the router has a suitable route, the router can answer the host's ARP request using the router interface's own MAC address. The host then sends the frame to the router, which routes the enclosed IP packet onward.

Proxy ARP can preserve connectivity for legacy systems or during a migration, but it can also conceal an incorrect mask, missing gateway, or poor network design. It increases ARP dependence and makes the Layer 3 boundary less obvious during troubleshooting. Do not confuse Proxy ARP with forwarding an ARP broadcast through a router: the request remains local; the router deliberately generates an answer.

Gratuitous ARP: announce your own mapping

Scenario: an active gateway takes over a shared virtual IP after the previous gateway fails. The new active device sends a Gratuitous ARP so nearby hosts and switches can learn that the IP-to-MAC ownership has changed. A device may also use this form of ARP while checking for a duplicate IPv4 address or refreshing neighbour caches after an interface change.

Unlike a normal resolution exchange, the sender announces or probes its own address without first receiving a matching request. The message is commonly broadcast so the local domain can inspect it, but whether a receiver updates its cache is implementation- and policy-dependent. Gratuitous ARP is useful operational evidence, not authenticated ownership; attackers can forge it, which we will examine in the later security pathway.

RARP: historical address discovery

Reverse ARP (RARP) was designed for a device that knew its hardware address but did not yet know its own IPv4 address. A diskless workstation could broadcast a request and depend on a RARP server to return a configured IPv4 address. The exchange was tied to the local link and provided far less configuration than modern bootstrapping requires.

RARP does not perform ordinary next-hop resolution. Its direction and purpose are different: it asks “Which IP address belongs to my known MAC?” rather than “Which MAC should receive traffic for this known next-hop IP?” BOOTP and then DHCP replaced RARP because they can provide addressing plus gateway, DNS, lease, and other configuration information.

Inverse ARP: discover an address across a virtual circuit

Inverse ARP starts with a known virtual circuit—such as a Frame Relay DLCI—and asks which network-layer address is reachable across it. That is the inverse of the information problem solved by ordinary ARP: the link or circuit identifier is already known, while the peer's protocol address must be learned.

Inverse ARP is not part of a normal switched-Ethernet host exchange and should not be used to explain today's Ethernet neighbour cache. It appears here so learners can recognize the term and its relationship to legacy non-broadcast multi-access networks. The full Frame Relay packet journey belongs in the later WAN lesson, where DLCIs, virtual circuits, mappings, and hub-and-spoke behavior can be shown accurately.

Compare the variants

• Standard ARP: “I know the next-hop IPv4 address; which local MAC should receive the frame?”
• Proxy ARP: “A router is answering locally on behalf of another IPv4 destination.”
• Gratuitous ARP: “I am announcing or probing my own IPv4-to-MAC mapping.”
• RARP: “I know my MAC but historically need a server to tell me my own IPv4 address.”
• Inverse ARP: “I know a virtual-circuit identifier but need to learn the peer's protocol address.”

Across these cases, keep the boundary visible: ARP broadcasts remain inside their Layer 2 broadcast domain; routers do not ordinarily forward them. A reply or announcement is local evidence and must not be treated as proof of identity.