---
{
  "title": "ARP and local address resolution",
  "summary": "Understand IPv4 local address resolution, the gateway’s role, and why an ARP entry is a forwarding clue rather than authenticated identity.",
  "topic": "networking",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "Cisco: Networking basics",
      "url": "https://www.cisco.com/site/us/en/learn/topics/networking/what-is-computer-networking.html"
    },
    {
      "title": "IETF: Ethernet Address Resolution Protocol, RFC 826",
      "url": "https://www.rfc-editor.org/rfc/rfc826.html"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Resolve a local next hop

Address Resolution Protocol, or ARP, connects IPv4 addressing with local-link delivery on networks such as Ethernet. When a host needs to send to a particular IPv4 next hop on its local link, it needs the corresponding link-layer address to construct the appropriate frame.

The scope matters. ARP does not normally discover the MAC address of a remote website across the internet. For an off-link destination, the relevant local next hop is usually a gateway. [[routing-and-switching]] explains why local frame delivery and IP routing are different responsibilities.

## Follow a request leaving the lab

Imagine a fictional learner's laptop opens an external course website. The laptop uses its configured prefix and routing information to decide that the destination requires a gateway. It may then resolve the gateway's IPv4 address to a local link-layer address.

The outgoing frame is directed toward the gateway on that link, while the IP packet identifies the remote destination. As traffic crosses other links, the frame context can change. The remote destination does not become a local Ethernet neighbor merely because the learner has a working connection.

This example is useful when interpreting captures: several different address types can appear in the same observation and have different scopes.

## Cached information has limits

Hosts keep neighbor-resolution information so that every packet does not require a new exchange. An entry describes a mapping the host currently uses or has learned. Its presence is not cryptographic proof that a particular person controls the associated device.

Entries can change, become stale, or reflect unexpected network behavior. During troubleshooting, record where the information came from and when it was observed. Do not treat one workstation's current cache as a complete historical inventory of the network.

## Trust assumptions affect security

Basic ARP does not provide strong authentication of mapping claims. Incorrect or malicious mappings can redirect local traffic or disrupt communication. The practical defensive lesson is understanding the local trust boundary and the protections available in the actual environment.

[[man-in-the-middle]] explains interception at a broader level. Protected application channels such as TLS can reduce some consequences of an untrusted path, while local network controls and monitoring address other parts of the problem. No single mechanism removes every risk.

## Keep IPv6 distinct

IPv6 uses Neighbor Discovery mechanisms rather than ARP. Similar-looking operational tasks do not make the protocols interchangeable. An IPv4 ARP cache cannot explain all neighbor behavior on a dual-stack network.

For a safe exercise, inspect the neighbor information on a device and network you control. Identify its default gateway, then explain why the gateway's local address can appear when the application talks to a remote service. Compare a local peer and an off-link destination without generating misleading traffic or modifying anyone else's mappings. Continue with [[network-segmentation]] to understand how local-link scope fits into the larger security design.