Exercises — ARP — address resolution, ARP cache, gratuitous ARP

Destination MAC = ==FF:FF:FF:FF:FF:FF== (the Ethernet broadcast address). Why: the sender does not yet know the target's MAC — that is the entire reason it is asking. The only way to reach a machine whose MAC is unknown is to address the frame to everyone on the local segment. A switch floods a broadcast frame out every port, so every host sees the question.

• Request → broadcast
• Reply → unicast
• EtherType → ==0x0806==

Why the reply is unicast: the replier read the sender MAC field out of the request, so it already knows exactly where to send the answer. Bothering the whole LAN again would be wasteful.

(a) dynamic — learned via an ARP exchange and removed on timeout. (b) static — manually pinned, immune to expiry (and immune to being overwritten by a forged reply, which matters for security).

Frame 1 — ARP Request (broadcast):

• Source MAC = 11:11:11:11:11:11 (A)
• Destination MAC = FF:FF:FF:FF:FF:FF
• Payload asks "Who has 10.0.0.5? Tell 10.0.0.1."

Frame 2 — ARP Reply (unicast):

• Source MAC = BB:BB:BB:BB:BB:BB (B)
• Destination MAC = 11:11:11:11:11:11 (A) — B learned this from Frame 1's sender field.
• Payload states "10.0.0.5 is at BB:BB:BB:BB:BB:BB."

Frame 3, 4, … — the real data (e.g. the ICMP echo) now flow unicast A↔B, because A cached the mapping.

WHY only two ARP frames? A single question–answer pair is enough to fill both caches at once. Frame 1 carries A's own IP→MAC in its sender fields, so B learns A for free just by receiving the request. Frame 2 carries B's IP→MAC, so A learns B from the reply. After these two frames each side holds the other's mapping, so nothing further needs resolving — the data frames go straight out as unicast. ARP therefore costs exactly 2 frames to bootstrap a conversation, then never again until the entry expires.

A ARPs for the ==default gateway 10.0.0.254==, not for 8.8.8.8.

Why: A applies its subnet mask /24 (i.e. 255.255.255.0) to both its own IP and the destination. 10.0.0.1 and 8.8.8.8 are in different networks (10.0.0 ≠ 8.8.8), so the destination is remote. ARP is link-local — routers do not forward ARP broadcasts — so A cannot resolve 8.8.8.8 directly. Instead A sends the frame to the router's MAC (resolved by ARPing 10.0.0.254), and the router forwards onward. See IP addressing & subnetting and Default gateway & routing.

Immediately after the swap, A still has the stale entry 10.0.0.5 → AA:BB:CC:11:22:33. Frames go to the old MAC and are dropped (no card owns it) → temporary loss of connectivity to B.

Recovery: the dynamic entry has a timeout. When it expires, A deletes it. The next packet to 10.0.0.5 triggers a fresh ARP Request; B replies with the new MAC; A caches 10.0.0.5 → AA:BB:CC:99:99:99 and connectivity resumes. The timeout is precisely the safety net that bounds how long stale data can hurt you. (A gratuitous ARP from B would have made recovery instant — see L4.)

Benefit: fewer ARP Requests are broadcast, since cached entries live longer → less broadcast noise, slightly less CPU/interrupt load on every host. Harm: if a host's MAC changes (card swap, VIP failover) and no gratuitous ARP is sent, the stale mapping persists for up to 4 hours → long connectivity outage.

WHY the trade-off exists — from ARP's mechanics: ARP has no cache-invalidation signal built in. In the normal reactive protocol, a host only re-checks a mapping when its cached entry expires and a new packet forces a fresh Request. So the timeout is doing two jobs at once out of the same knob:

1. It limits how often you broadcast (a cost you want to minimize → argues for a long timeout).
2. It is your only automatic mechanism to discover that a cached mapping has silently gone wrong (freshness you want to maximize → argues for a short timeout).

Because both jobs are controlled by the single timeout value and pull in opposite directions, you cannot optimize one without hurting the other. The tension is fundamental: short timeout = fresher data, more broadcasts; long timeout = fewer broadcasts, slower to notice change. (Gratuitous ARP is the escape hatch — it lets a host push an update instead of waiting for the timeout, breaking the deadlock in the one case that matters most: a planned MAC change.)

The difference is what each side already knows:

• When A builds the Request, it knows B's IP but not B's MAC → it cannot address the frame to B, so it must broadcast.
• The Request frame carries A's own MAC in the Sender Hardware Address (source MAC) field. B reads that field. Now B knows A's MAC exactly → B can send the Reply as a unicast straight back to A.

So the asymmetry is not a design quirk; it falls directly out of the fact that the reply inherits the requester's MAC from the request itself. (A nice side effect: B also caches A's IP→MAC, so a later B→A conversation needs no fresh ARP.)

• ARP cache (lives on a host): key = IP address, value = MAC address. It answers "which MAC owns this IP?" — a Layer-3 → Layer-2 translation.
• Switch MAC table (lives on a switch): key = MAC address, value = switch port. It answers "out of which port do I reach this MAC?" — pure Layer-2 forwarding.

They are complementary: ARP tells the host what MAC to put in the frame; the MAC table tells the switch where to send that frame. A frame's destination MAC is filled using the ARP cache, then steered using the switch table. See Switching & MAC learning tables.

(a) Up to the full timeout, 20 minutes. A client with a fresh entry only re-ARPs after its cached mapping expires, so worst case it sends to S1 (dead) for the entire 20-minute window → downtime.

(b) Server2 broadcasts a gratuitous ARP announcing "10.0.0.100 is at S2." Hosts that already have an entry for 10.0.0.100 overwrite it on seeing the announcement → near-instant cutover instead of waiting 20 minutes. The fields that make it gratuitous: in the ARP header the ==Sender Protocol Address (SPA) equals the Target Protocol Address (TPA)==. Both hold the host's own IP (10.0.0.100), while the Sender Hardware Address (SHA) carries the new MAC S2. Because SPA == TPA, the packet is about the sender's own address, unsolicited (nobody asked). Receiving hosts update their cache to 10.0.0.100 → S2, and the switch also updates its MAC table so frames now flow to Server2's port.

This is duplicate-IP (address conflict) detection. By gratuitous-ARPing its own address, the host is effectively asking "is anyone else already using 10.0.0.42?" A reply means another host already owns that IP — an address conflict.

What to do: the booting host must not use 10.0.0.42. In practice it declines the address, logs a conflict, and (for DHCP-assigned addresses) declines the lease so the DHCP server hands out a different address. Using a duplicated IP would cause both machines' ARP entries to fight and traffic to flip-flop between them.

• 1 broadcast: A's ARP Request (flooded to all ports).
• 1 unicast: B's ARP Reply → A.
• 1 unicast: ICMP Echo Request A → B.
• 1 unicast: ICMP Echo Reply B → A.

Totals: 1 broadcast, 3 unicast = 4 frames. Notice ARP costs exactly one broadcast to bootstrap; everything afterward is efficient point-to-point because both hosts now have each other cached (B learned A from the request, A learned B from the reply).

The attack (ARP spoofing / cache poisoning): M broadcasts (or unicasts to V) forged ARP Replies claiming "10.0.0.254 is at M's MAC." Often M also poisons G with "V's IP is at M's MAC," so both directions route through M.

Why V believes it: ARP has no authentication. A host caches any reply it receives — it cannot tell an honest reply from a forged one. V overwrites 10.0.0.254 → G_MAC with 10.0.0.254 → M_MAC and unknowingly sends all gateway-bound traffic to M, who forwards it on (staying invisible) = man-in-the-middle.

Two defenses (any two):

1. Dynamic ARP Inspection (DAI) — the switch validates ARP replies against a trusted DHCP-snooping binding table and drops forgeries.
2. Static ARP entries for critical hosts (e.g. the gateway) — a pinned entry cannot be overwritten by a forged dynamic reply.
3. Port security limiting MACs per port. See Network security — MITM & ARP spoofing.

Partly right, partly wrong.

• Right: IPv6 does not use ARP. It uses NDP (Neighbor Discovery Protocol) over ICMPv6 multicast — a host sends a Neighbor Solicitation and the owner answers with a Neighbor Advertisement, instead of the Layer-2 broadcast Request/Reply that ARP uses. So classic ARP spoofing, which forges ARP Replies, does not apply because there are no ARP packets to forge. See NDP — IPv6 Neighbor Discovery.
• Wrong: the underlying vulnerability — an unauthenticated neighbor-mapping cache — is exactly the same. By default a host still trusts and caches any Neighbor Advertisement it receives, so an attacker can forge Neighbor Advertisements to poison the IPv6 neighbor cache. This is NDP spoofing, the direct analogue of ARP spoofing. The real cure is authentication/inspection of the mapping messages, e.g. SEND (Secure Neighbor Discovery) or switch features like RA Guard / ND inspection — not merely "switching to IPv6."

Verdict: switching to IPv6 removes ARP (and its specific spoofing packets), but it does not remove the class of attack — an unauthenticated address-resolution cache is poisonable in both worlds. The colleague is wrong to treat IPv6 as a security fix on its own.

• A broadcasts the Request; every host sees it, but the target IP matches nobody, so no reply comes back.
• A waits a short interval, receives nothing, and typically retransmits the ARP Request a few times (implementation-dependent, e.g. 2–3 attempts).
• If still no reply, A cannot resolve the IP → the pending packet(s) to 10.0.0.5 are dropped, and the application sees a failure such as "host unreachable" / timeout. No cache entry is created (or a short-lived "incomplete"/failed entry may be recorded so A doesn't hammer the LAN).

Key point: ARP has no "not found" reply — absence of a reply is the signal that nobody owns the address. This is exactly why a gratuitous ARP that does get a reply signals a conflict (Exercise 4.2): silence = free, an answer = taken.