When an IPv4 host sends a packet to an address outside its own subnet, whose MAC address does its ARP request ask for, and why?
answer
- the mask decides first
- next hop, not final destination
- the IP header keeps the far address
- the last router resolves the last hop
basics
~10 sThe default gateway's. The mask marks the destination off-link, so the host ARPs for the gateway's IPv4 address; the frame goes to the gateway's MAC while the IPv4 header still names the remote destination.
solid answer
~40 sBefore resolving anything the host makes RFC 1122's local/remote decision: it masks the destination and its own address with its subnet mask. If the network bits match, the destination is on-link and the host ARPs for it directly. If they differ, the destination is reachable only through a gateway, so routing picks the next hop - normally the default gateway - and the ARP request's target protocol address is the gateway's IPv4 address, not the remote host's. The data frame then carries the gateway's MAC as its destination while the IPv4 header's destination stays the remote address. The sender never resolves the remote host's MAC; the router attached to the destination's subnet does that last ARP, and if it fails, RFC 1812 has that router return ICMP Destination Unreachable, code 1 (Host Unreachable).
go deeper
Recall the rule: on-link destinations are resolved directly, off-link ones through the default gateway, so the ARP target is the gateway's IPv4 address and the frame goes to the gateway's MAC.
Walk through the mask comparison with real addresses and show which fields change: the ARP target, the frame's destination MAC, and the unchanged IPv4 destination.
Use the rule diagnostically: requests for remote addresses betray a wide mask, unanswered gateway requests a wrong gateway, and code 1 Host Unreachable a failed resolution on the far LAN.
Reason about why hosts resolve only a next hop, and how proxy ARP or overly wide masks blur that boundary in large flat networks and complicate later migrations.
## The decision comes before ARP ARP resolves a **next hop**, never an abstract destination. Before a host builds an ARP request it has to decide which IPv4 address to resolve, and that decision is routing. RFC 1122 section 3.3.1.1 spells out the host's **local/remote decision**: 1. Apply the interface's address mask to the destination address and to the host's own address. 2. If the extracted network bits match, the destination is on the connected network and the datagram is transmitted **directly** to it - the host ARPs for the destination itself. 3. If they differ, the destination "is accessible only through a gateway", so the host selects one (normally the default gateway, or the next hop of a more specific route) and **ARPs for that gateway's IPv4 address**. The remote destination's address therefore never appears in the ARP packet. It stays where it belongs, in the IPv4 header's destination field, untouched by the resolution step. ## A worked example Host `192.0.2.10/24` (MAC `00-00-5E-00-53-0A`) sends to `198.51.100.20`. Its default gateway is `192.0.2.1` (MAC `00-00-5E-00-53-01`). | Step | Value | |---|---| | Host network: `192.0.2.10` AND `255.255.255.0` | `192.0.2.0` | | Destination network: `198.51.100.20` AND `255.255.255.0` | `198.51.100.0` | | Verdict | different, so off-link: the next hop is `192.0.2.1` | | ARP request, sender protocol address | `192.0.2.10` | | ARP request, target protocol address | `192.0.2.1` | | ARP reply, sender hardware address | `00-00-5E-00-53-01` | | Data frame, Ethernet destination | `00-00-5E-00-53-01` (the gateway) | | Data packet, IPv4 destination | `198.51.100.20` (unchanged) | Once the gateway has replied, the host reuses that one mapping for **every** destination routed through it. A host talking to thousands of remote addresses through one gateway holds a single ARP entry for all of them. ## What happens past the gateway The gateway receives a frame addressed to its own MAC, finds an IPv4 packet whose destination is not one of its own addresses, and makes its own forwarding decision. On each Ethernet link along the path, the forwarding router resolves its own next hop in exactly the same way. Finally, the router attached to the destination's subnet sees that `198.51.100.20` is on-link for it and ARPs for the destination host itself. If that host does not answer, RFC 1812 section 3.3.2 says the router's link layer MUST NOT report the destination unreachable merely because no ARP entry exists; it SHOULD queue a few datagrams briefly and report failure only when resolution proves fruitless. The report is **ICMP Destination Unreachable, code 1 (Host Unreachable)**, which RFC 1812 describes as a directly connected host that "does not respond to ARP". The original sender never sees an ARP failure for a remote host: it sees that ICMP message, or nothing at all if ICMP is filtered on the way back. ## When the mask or gateway is wrong The local/remote decision is only as good as the configuration it reads: - **Mask too wide** (for example `/16` on a network that is really a `/24`): addresses on neighbouring subnets look on-link, so the host broadcasts ARP requests for them directly. No such host is on the segment, no reply comes, and traffic to them fails - unless a router on the segment answers with proxy ARP, which hides the misconfiguration rather than fixing it. - **Mask too narrow**: some genuinely local peers look off-link, so their traffic is handed to the gateway and comes back onto the same segment. It usually still works, through an unnecessary router hop, which is why this mistake can survive unnoticed for a long time. - **Wrong gateway address**: the host ARPs for an address nobody on the segment owns; the requests go unanswered and only on-link traffic works. ## Common misreadings - The router does not forward the host's ARP request to the remote subnet; ARP stops at the router. - The packet is not addressed to the router at the IP layer; only the Ethernet frame is. - The sender never learns the remote host's MAC and has no use for it. - IPv6 also sends off-link traffic to a router, but it decides what is on-link largely from prefixes that routers advertise rather than from a configured mask alone, and it resolves the router with Neighbor Discovery instead of ARP.
- Why doesn't the host simply ARP for the remote destination and let the router answer?Because ARP is confined to one broadcast domain: the remote host is not on the segment, and the broadcast never leaves it. The local/remote decision exists precisely so the host asks for an address that someone on the segment owns. A router that answers for remote addresses is doing proxy ARP, a router feature rather than the normal mechanism, and it tends to mask a wrong subnet mask.
- What does the sender observe if the last router's ARP for the destination host fails?Not an ARP failure: its own resolution of the gateway succeeded. Per RFC 1812, the last router queues the packets briefly and, when its ARP proves fruitless, returns ICMP Destination Unreachable, code 1 (Host Unreachable) to the source. If ICMP is filtered on the return path, the sender sees only silence and a timeout.
saying these in an interview costs you the question
- The host ARPs for the remote server's IP and the router forwards the request.
- The packet to the gateway carries the gateway's IPv4 address as its IP destination.
- The host must learn the remote server's MAC address before it can send.
- Each remote destination needs its own ARP entry on the sending host.
- A failed ARP at the far router shows up as an ARP timeout on the sender.