Both logical and physical addresses are used for communication on a network. The use of logical addresses allows for communication between multiple networks and indirectly connected devices. The use of physical addresses facilitates communication on a single network segment for devices that are directly connected to each other with a switch. In most cases, these two types of addressing must work together in order for communication to occur.
Consider a scenario where you wish to communicate with a device on your network. This device may be a server of some sort or just another workstation you need to share files with. The application you are using to initiate the communication is already aware of the IP address of the remote host (via DNS, covered in Chapter 7), meaning the system should have all it needs to build the layer 3 through 7 information of the packet it wants to transmit. The only piece of information it needs at this point is the layer 2 data link data containing the MAC address of the target host.
MAC addresses are needed because a switch that interconnects devices on a network uses a Content Addressable Memory (CAM) table, which lists the MAC addresses of all devices plugged into each of its ports. When the switch
receives traffic destined for a particular MAC address, it uses this table to know through which port to send the traffic. If the destination MAC address is unknown, the transmitting device will first check for the address in its cache; if it is not there, then it must be resolved through additional communication on the network.
The resolution process that TCP/IP networking (with IPv4) uses to resolve an IP address to a MAC address is called the Address Resolution Protocol (ARP), which is defined in RFC 826. The ARP resolution process uses only two packets: an ARP request and an ARP response (see Figure 6-1).
TIPS: An RFC, or Request for Comments, is the official document that defines the implementation standards for protocols. You can search for RFC documentation at the RFC Editor home page, http://www.rfc-editor.org/.
The transmitting computer sends out an ARP request that basically asks, “Howdy everybody, my IP address is XX.XX.XX.XX, and my MAC address is XX:XX:XX:XX:XX:XX. I need to send something to whoever has the IP address
XX.XX.XX.XX, but I don’t know its hardware address. Will whoever has this IP address please respond back with your MAC address?”
This packet is broadcast to every device on the network segment. Any device that does not have this IP address simply discards the packet. The device that does have this IP address sends an ARP reply with an answer like, “Hey, transmitting device, I’m who you are looking for with the IP address of XX.XX.XX.XX. My MAC address is XX:XX:XX:XX:XX:XX.”
Once this resolution process is completed, the transmitting device updates its cache with the MAC-to-IP address association of this device, and it can begin sending data.
TIPS: You can view the ARP table of a Windows host by typing arp –a from a command prompt.
Seeing this process in action will help you to understand how it works. But before we look at some examples, let’s examine the ARP packet header.
The ARP Header
As shown in Figure 6-2, the ARP header includes the following fields:
Hardware Type The layer 2 type used. In most cases, this is Ethernet (type 1).
Protocol Type The higher-layer protocol for which the ARP request is being used.
Hardware Address Length The length (in octets/bytes) of the hardware address in use (6 for Ethernet).
Protocol Address Length The length (in octets/bytes) of the logical address of the specified protocol type.
Operation The function of the ARP packet: either 1 for a request or 2 for a reply.
Sender Hardware Address The hardware address of the sender.
Sender Protocol Address The sender’s upper-layer protocol address.
Target Hardware Address The intended receiver’s hardware address (zeroed in ARP requests).
Target Protocol Address The intended receiver’s upper-layer protocol address.
Figure 6-2: The ARP packet structure
Now lunch the Unicorn and set filter to only capture ARP packets, then start a new project. We’ll focus on each packet individually as we walk through this resolution process.
ARP Request
The packet 23527 is the ARP request, as shown in Figure 6-3. We can confirm that this packet is a true broadcast packet by examining the Ethernet header in Unicorn’s Packet Details pane. The packet’s destination address is ff:ff:ff:ff:ff:ff . This is the Ethernet broadcast address, and anything sent to it will be broadcast to all devices on the current network segment. The source address of this packet in the Ethernet header is listed as our MAC address .
Figure 6-3: An ARP request packet
Given this structure, we can discern that this is indeed an ARP request on an Ethernet network using IP. The sender’s IP address (192.168.1.114) and MAC address (00:23:CD:2A:ED:52) are listed , as is the IP address of the target (192.168.1.124) . The MAC address of the target—the information we are trying to get—is unknown, so the target MAC is listed as 00:00:00:00:00:00
ARP Response
In our response to the initial request (see Figure 6-4), the Ethernet header now has a destination address of the source MAC address from the first packet.
The ARP header looks similar to that of the ARP request, with a few changes:
1. The packet’s operation code (Type) is now 0x0002 , indicating a reply rather than a request.
2. The addressing information is reversed—the sender MAC address and IP address are now the target MAC address and IP address .
3. Most important, all of the information is present, meaning we now have the MAC address (A0:93:47:14:FF:FA) of our host at 192.168.1.124.
An ARP reply packet
Gratuitous ARP
Where I come from, when something is done “gratuitously,” that usually carries a negative connotation. A gratuitous ARP, however, is actually a good thing.
In many cases, a device’s IP address can change. When this happens, the IP-to-MAC address mappings that hosts on the network have in their caches will be invalid. To prevent this from causing communication errors, a gratuitous ARP packet is transmitted on the network to force any device that receives it to update its cache with the new IP-to-MAC address mapping (see Figure 6-5).
Figure 6-5: The gratuitous ARP process
A few different scenarios can spawn a gratuitous ARP packet. One of the most common is the changing of an IP address. Open the capture file arp_gratuitous.pcap, and you’ll see this in action. This file contains only a single packet (see Figure 6-6) because that’s all that’s involved in gratuitous ARP.
Figure 6-6: A gratuitous ARP packet
Examining the Ethernet header, you can see that this packet is sent as a broadcast so that all hosts on the network receive it . The ARP header looks like an ARP request, except that the sender IP address and the target IP address are the same. When received by other hosts on the network, this packet will cause them to update their ARP tables with the new IP-to-MAC address association. Because this ARP packet is unsolicited but results in a client updating its ARP cache, the packet is considered gratuitous.
You will notice gratuitous ARP packets in a few different situations. As mentioned, changing a device’s IP address will generate one. Also, some operating systems will perform a gratuitous ARP on startup. Additionally, you may notice gratuitous ARP packets on systems that use them for load-balancing of incoming traffic.