Week 2: Ethernet and ARP

Every IP packet that travels on a local network gets wrapped in an Ethernet frame. Every Ethernet frame needs a MAC address to reach its destination. ARP is the protocol that turns IP addresses into MAC addresses. This week you see the link layer in its byte-level detail.

Theme

Your laptop has an IP address (say, 192.168.1.100) and a MAC address (a 48-bit hardware address burned into the network card). When your laptop wants to send a packet to your router, it needs to know the router's MAC address -- IP addresses alone are not enough to reach a device on the local network. It finds the MAC address by broadcasting an ARP request: "Who has 192.168.1.1? Tell me your MAC." The router replies with its MAC. Your laptop records that answer in its ARP cache and sends the Ethernet frame to the correct destination. This week you watch that exchange happen at the byte level.

Reading (~45 minutes)

1. Stevens TCP/IP Illustrated Ch 4 ("ARP: Address Resolution Protocol"): ARP request, ARP reply, the ARP cache
2. Kurose & Ross Ch 6 §6.1-6.2 ("Introduction to the Link Layer", "Error-Detection and Correction Techniques"): what the link layer is and what Ethernet does at the physical level
3. Optional: Wireshark wiki, "Ethernet" (https://wiki.wireshark.org/Ethernet): the Ethernet frame format field by field

Lecture outline (~2 hours)

Section 1: The Ethernet frame

• Ethernet is the dominant link-layer protocol for wired LANs and the underlying layer for most Wi-Fi frames at the logical level
• An Ethernet frame contains:

• MAC addresses: 48 bits, written as 6 hex pairs separated by colons (e.g., 02:00:00:aa:bb:cc)
• The first 24 bits (3 bytes) are the OUI (Organizationally Unique Identifier) assigned to the manufacturer. Wireshark resolves OUIs to vendor names by default.
• Locally administered vs globally administered: the second-least-significant bit of the first byte indicates local (1) vs global (0). Academy fixture captures use locally administered MACs (02:*).

Section 2: MAC addressing and switching

• A switch operates at layer 2: it reads the destination MAC of each frame and forwards the frame to the correct port
• The switch builds a MAC address table by noting which port each source MAC address arrives on
• Unicast, broadcast, multicast:
  • Unicast: specific destination MAC (02:00:00:aa:bb:cc)
  • Broadcast: ff:ff:ff:ff:ff:ff -- delivered to every device on the local segment
  • Multicast: first byte has bit 0 set; delivered to a group of devices subscribed to that multicast address
• Before a switch knows where a destination MAC lives, it floods the frame to all ports. After the first exchange, it forwards only to the correct port.

Section 3: ARP -- Address Resolution Protocol

• ARP answers: "I have an IP address. What is the MAC address of the device with this IP?"
• ARP request: broadcast frame (destination ff:ff:ff:ff:ff:ff); asks "Who has X.X.X.X?"
• ARP reply: unicast frame back to the requester; says "I have X.X.X.X; my MAC is AA:BB:CC:DD:EE:FF"
• ARP cache: each device keeps a table of IP-to-MAC mappings it has learned; entries expire after a timeout (typically 2-20 minutes)
• Gratuitous ARP: a device sends an ARP reply without being asked, announcing its own IP-to-MAC mapping. Used when a device joins the network or after failover.

Section 4: ARP fields in a capture

Display filter: arp.opcode == 1 for requests; arp.opcode == 2 for replies.

Section 5: ARP anomalies -- the storm

• Normal ARP: a device asks for a MAC once; the answer is cached; subsequent traffic uses the cached MAC
• ARP storm: many ARP requests in a short time; can indicate a misconfigured device, a broadcast loop, or a scanning tool
• In arp-storm.pcap: 622 packets; rapid ARP requests from a single source. This looks abnormal because the request rate is far higher than any normal host needs.
• An analyst who knows what a normal ARP exchange looks like (two packets, then silence) can immediately recognize the storm as anomalous.

Labs (~90 minutes)

Lab 2-1: Ethernet and ARP (labs/lab-2-1-ethernet-arp.md)

Independent practice (~7 hours)

1. Read Stevens Ch 4 in full; work through the ARP cache examples
2. On your own machine: run arp -n (Linux/macOS) or arp -a (Windows) to see your ARP cache. Which IP addresses are listed? Which MAC addresses correspond to which devices on your network?
3. Load fundamentals-arp-request-reply.pcap in pcap-tools. Expand the ARP header. Verify every field matches the table above. What is the EtherType in the Ethernet header?
4. Load arp-storm.pcap. Apply the display filter arp.opcode == 1. How many requests are there? Apply arp.opcode == 2. How many replies? What does the ratio tell you?
5. Look up "Proxy ARP" and explain in one paragraph why it exists and when it is used.

Reflection prompts (~30 minutes)

1. ARP replies are not authenticated. Any device on the network can reply to any ARP request with any MAC address. What is the attack that this enables? (Look up "ARP spoofing.")
2. The ARP cache has a timeout. Why does the cache expire? What would go wrong if ARP entries never expired?
3. A switch learns MAC addresses by watching traffic. What happens when the switch's MAC address table is full? (Look up "MAC flooding attack.")
4. The Ethernet frame has a minimum payload size of 46 bytes. Why does a minimum size exist? What happens to a payload smaller than 46 bytes?
5. Wi-Fi uses a different frame format at the physical layer but your operating system presents it to software as if it were Ethernet. Why does that abstraction matter?

What comes next

Week 3 moves to the network layer: the IPv4 header, IP addressing, subnets, and how a packet gets routed from your laptop to a server in another country.