Skip to content
academia.sh

Lesson 06 / 18

ARP

Resolving an IP address to a hardware address, the request–reply cycle, cache behavior, proxy and gratuitous usage, and address poisoning.

Contents

The previous lesson showed that a hardware address is written into a frame’s destination field. Yet applications specify the destination by IP address: the client on the example network wants to reach 198.51.100.20, knows its gateway is 192.168.10.193, but knows the hardware equivalent of neither address.

A bridge is needed between the two address spaces. This lesson’s question is how that bridge is built, and what assumptions are made while building it.

Two Address Spaces

There is no computable relationship between an IP address and a MAC address. One is a logical name assigned by a network administrator or a leasing service; the other is a physical address tied to the interface’s hardware. When the same machine moves from network to network, its IP address changes; its MAC address does not.

Since the mapping cannot be computed, it must be asked. ARP (Address Resolution Protocol) is the protocol that asks this question. The method is direct: a broadcast is sent to the entire local network asking “who has this IP address?” and the owner of the address replies.

ARP is not carried inside IP; it is carried directly in the Ethernet frame with type value 0x0806. This is a concrete example of the observation from the previous topic that “some protocols concern two layers at once”: an ARP message carries a network-layer address, but does not use a network-layer header.

The Fields of the Message

An ARP message is 28 bytes and consists of nine fields.

Field Size Example value
Hardware type 2 bytes 1 (Ethernet)
Protocol type 2 bytes 0x0800 (IPv4)
Hardware address length 1 byte 6
Protocol address length 1 byte 4
Operation 2 bytes 1 request, 2 reply
Sender hardware address 6 bytes MAC address of the one asking
Sender protocol address 4 bytes IP address of the one asking
Target hardware address 6 bytes Zero in the request, filled in the reply
Target protocol address 4 bytes The IP address being asked about

The presence of the length fields shows the protocol is not limited to Ethernet and IPv4: the format is designed for technologies with different address widths.

The program below builds the request the client on the example network sends asking for its gateway, and the reply that comes back.

import ipaddress
import struct

FORMAT = "!HHBBH6s4s6s4s"


def pack_mac(mac: str) -> bytes:
    return bytes(int(x, 16) for x in mac.split(":"))


def format_mac(raw: bytes) -> str:
    return ":".join(f"{b:02x}" for b in raw)


def arp_message(operation: int, sender_mac: str, sender_ip: str,
               target_mac: str, target_ip: str) -> bytes:
    return struct.pack(
        FORMAT,
        1,          # hardware type: Ethernet
        0x0800,     # protocol type: IPv4
        6,          # hardware address length
        4,          # protocol address length
        operation,      # 1 = request, 2 = reply
        pack_mac(sender_mac), ipaddress.ip_address(sender_ip).packed,
        pack_mac(target_mac), ipaddress.ip_address(target_ip).packed,
    )


def print_arp(raw: bytes) -> None:
    fields = struct.unpack(FORMAT, raw)
    operation = {1: "request", 2: "reply"}[fields[4]]
    print(f"op={operation:7s} sender={format_mac(fields[5])} / {ipaddress.ip_address(fields[6])}"
          f"  target={format_mac(fields[7])} / {ipaddress.ip_address(fields[8])}")


request = arp_message(1, "00:00:5e:00:53:01", "192.168.10.196",
                   "00:00:00:00:00:00", "192.168.10.193")
reply = arp_message(2, "00:00:5e:00:53:00", "192.168.10.193",
                   "00:00:5e:00:53:01", "192.168.10.196")

print("message size:", len(request), "bytes")
print(request.hex())
print_arp(request)
print(reply.hex())
print_arp(reply)

Output:

message size: 28 bytes
000108000604000100005e005301c0a80ac4000000000000c0a80ac1
op=request sender=00:00:5e:00:53:01 / 192.168.10.196  target=00:00:00:00:00:00 / 192.168.10.193
000108000604000200005e005300c0a80ac100005e005301c0a80ac4
op=reply   sender=00:00:5e:00:53:00 / 192.168.10.193  target=00:00:5e:00:53:01 / 192.168.10.196

The target hardware address field in the request message is zero — that is the question itself. In the reply this field is filled in, and the sender and target roles swap.

How the Request and Reply Are Carried

As much as the message itself, the addresses of the frame carrying it matter:

ARP request ARP reply
Frame source address 00:00:5e:00:53:01 00:00:5e:00:53:00
Frame destination address ff:ff:ff:ff:ff:ff 00:00:5e:00:53:01
Devices it reaches The entire broadcast domain Only the one who asked

The request goes by broadcast because it is not known which device holds the address being asked about. The reply, by contrast, goes to a unicast address: the responder has learned both of the asker’s addresses from the sender fields inside the request.

This asymmetry has a side effect: every device in the broadcast domain sees the request and, if it wants, writes the sender’s mapping into its own cache. This behavior is the basis of the security problem covered in a later section.

Local or Remote

The first decision made before a packet is sent is whether the destination is on the same network. The decision is made by comparing the destination address against the local netmask; netmask arithmetic is built up in the Subnetting lesson. The result of this decision determines which address gets resolved:

Destination Same network? Address asked via ARP Frame’s destination MAC
192.168.10.200 Yes 192.168.10.200 The destination’s own MAC address
198.51.100.20 No 192.168.10.193 (gateway) The gateway’s MAC address

The second row is the most frequently misunderstood point in network mechanics. In a packet headed to a remote destination, the IP destination address is the remote server, the MAC destination address is the gateway. The two addresses point to different devices, and this is not an inconsistency: the IP address specifies the end-to-end destination, the MAC address specifies the next hop.

The remote server’s MAC address is never asked for. It cannot be, either: an ARP request travels by broadcast, and a broadcast does not cross a router.

The ARP Cache

Because broadcasting for every resolution would be expensive, results are kept in a cache. The client on the example network’s cache, after talking to its gateway and reaching a printer in the same section, holds this content:

IP address MAC address State
192.168.10.193 00:00:5e:00:53:00 Reachable
192.168.10.210 00:00:5e:00:53:04 Reachable
192.168.10.205 Incomplete (awaiting reply)

Entries are not permanent. An entry unused for a while is removed; removal lets the mapping correct itself when a device’s network card changes or an address moves to another device. The first send after an entry is removed triggers a fresh resolution, and that send is delayed slightly.

The commands used to read cache state and their output formats vary by operating system. What stays constant is the three pieces of information shown in the table above: protocol address, hardware address, and the entry’s state.

Gratuitous and Proxy Usage

Gratuitous ARP is a device announcing its own address without anyone asking: a request is broadcast whose target protocol address is the device’s own address. It serves three purposes. It detects an address conflict — if a reply comes back, the same address is on another device. A standby device announces it has taken over an address during failover and refreshes switches’ tables. It updates neighbors’ stale mappings when an interface comes up.

Proxy ARP is a router replying for an address that is not its own. If the address asked about is remote, the router gives its own MAC address and takes on the traffic. It keeps clients with a misconfigured netmask working; but because it hides the problem itself and produces many identical-looking entries in caches, it makes diagnosis harder.

ARP Poisoning

ARP’s design has no authentication. Who sent a reply is not checked; even an unsolicited reply gets written to the cache in many implementations. The result is the attack called ARP poisoning.

If a device in the same broadcast domain sends replies claiming that 192.168.10.193 is at its own MAC address, its neighbors’ caches are corrupted and traffic meant for the gateway gets redirected to the attacker. The attacker can keep the connection alive by forwarding the traffic on to the gateway; in that case the user sees no interruption at all.

The source of the vulnerability is not an implementation bug but the protocol’s design assumption: devices on the same local network are assumed trustworthy. Countermeasures are therefore outside ARP itself:

  • Shrinking broadcast domains and putting untrusted devices on separate networks.
  • ARP inspection on the switch: allowing a port to announce only the addresses assigned to that device.
  • Pinning critical mappings.
  • Using end-to-end encryption and authentication: an intermediary listening to the traffic cannot read or modify the content.

The last item is an application of the end-to-end principle: when a layer inside the network cannot make a security promise, the promise has to be made at the endpoints.

Its Counterpart in IPv6

IPv6 does not use ARP. The equivalent function has moved into ICMPv6 under the name neighbor discovery, and uses multicast instead of broadcast: the question is delivered only to the multicast group associated with the address being asked about. This keeps every device in the broadcast domain from having to process every question. Neighbor discovery also takes on functions like duplicate address detection and router advertisement; these are covered in the IPv6 lesson.

Summary

  • There is no computable relationship between an IP address and a MAC address; the mapping is asked for with ARP.
  • An ARP request travels by broadcast, the reply returns to a unicast address; the message is 28 bytes and uses no IP header.
  • If the destination is on the same network, its own address is resolved; if not, the gateway’s address is; in a packet headed to a remote destination, the IP target is the server, the MAC target is the gateway.
  • Resolution results are kept in a time-limited cache; when the time expires, the mapping corrects itself.
  • Gratuitous ARP is used for address announcement and conflict detection, proxy ARP for taking on another network’s address.
  • ARP has no authentication; countermeasures against poisoning are shrinking the broadcast domain, switch-level inspection, and end-to-end encryption.

Next Step

Up to this point, IP addresses were used like labels: 192.168.10.196 was written, its meaning was not questioned. Yet there is a structure inside this number — one part points to the network, one part to the host within that network. The next lesson covers the bit structure of the IPv4 address, the split between network and host parts, and the blocks set aside for special purposes.

To keep your progress and take notes, Log in

My notes

Log in to take notes.

Start typing to search.

↑↓ Esc navigate · open · close