Translating IP Addresses into MAC Addresses

The second of our two original translation requirements was translating IP addresses into MAC addresses. Network devices really communicate via physical addresses. Physical addresses, although they are typically globally unique, are valid only for communications within a single Layer 2 domain. In the world of Ethernet and other networks standardized via the IEEE's 802 family of network protocols, physical addresses are known as MAC addresses.

Previous chapters of this book have conveniently overlooked that point in order to focus on IP addresses and their function in a network. Now it's time to complete that picture. Networked devices really communicate locally using local mechanisms. Let's assume, for the sake of example, that our local mechanism is an Ethernet network. Figure 10-12 shows a few devices connected via an Ethernet. Two of these devices are hosts that, ostensibly, originate the majority of communications sessions. The other is a server that, at least in theory, is the intended destination of most communications sessions on this LAN.

Figure 10-12. Although Networked Devices Are Uniquely Identified Via an IP Address, a Physical Address Is Required for Successful Communications

Each endpoint has a unique IP address assigned to it, so this shouldn't be a problem. At least, that's how it looks. In reality, Ethernet (as is every other LAN protocol) is not IP-based. The reason has everything to do with the concept of logically separated functions. You have probably heard all about the OSI Reference Model and its seven layers. The concept embodied in the reference model is what has enabled open communications and cross-vendor interoperability of networking products.

Ethernet and other LAN protocols operate at Layers 1 and 2 of this model. IP and other routed protocols operate at Layer 3. This well-defined separation of functions enables interoperability of IP and Ethernet. But this interoperability takes the form of Ethernet encapsulating IP packets within Ethernet frames for transport through the LAN. Upon reaching its intended destination, the Ethernet frame is stripped off, thereby revealing the IP packet that was embedded in its data field.

This might seem logical enough, but a step is missing. Ethernet and IP are dissimilar protocols. Each has its own addressing system, and those systems are incompatible. Thus, it is necessary to translate IP addresses into MAC addresses for the layered communications session shown in Figure 10-12 to work. This is where ARP comes into the picture.

Address Resolution Protocol

ARP is one of those network protocols you use every day without realizing it. That's because it operates invisibly, without requiring initiative, input, or intervention from individual users. Its function is quite simple: It tracks the correlation between physical MAC addresses and IP addresses for every device attached to the same LAN. So, the step that was missing from the previous example is that ARP "reads" each packet's destination IP address. It then looks in its cache to see if it already knows that IP address. If that IP address appears in the ARP cache, ARP grabs the corresponding MAC address, and that gets used as the destination address in the Ethernet frame.

NOTE

Due to its function as an intermediary between a LAN and the IP suite of protocols, you might be hard-pressed to figure out whether ARP is a LAN protocol or one of the IP protocols. In fact, ARP was originally stipulated in November 1982 in RFC 826. Thus, it is distinctly a native component of IP. RFC 826 positioned ARP as an IP-to-Ethernet mechanism, but it was subsequently extended to all the IEEE's 802 LANs, as well as to FDDI.

Given this role, it becomes clear that ARP must track the correlation between MAC addresses and IP addresses for all devices that lie within the same LAN broadcast domain. This correlation is maintained in a table by each network-attached host. This table is called the ARP cache. How that table gets built and is maintained is important in understanding the dynamic and active role that IP plays in a network.

Building the Table

Each host on a LAN builds a table of MAC addresses on its network and maps those addresses to Layer 3 (in this case, IP) addresses. ARP relies on LAN broadcast mechanisms to do this. As you learned in Chapter 9, "IP Multicasting," broadcasting is a technique that lets you transmit a single stream of data for delivery to all the other hosts on your network. Although that chapter dealt with multicasting based on IP addresses, broadcasting is also a native function of every LAN. LAN broadcasting is the capability that forms the foundation of ARP.

Upon startup, each host on a network must begin the arduous task of populating its ARP cache table. To do this, the host uses the LAN's broadcast message to transmit an ARP request packet. Such request packets are generated as needed. In other words, when a host needs to communicate with another host on behalf of one of its applications, it ultimately needs to convert that destination machine's IP address to a MAC address. An ARP request is generated to look for that specific IP address and is broadcast throughout the LAN. Only the machine whose IP address matches the query is compelled to respond to the request packet.

The responseknown as an ARP replycontains the responder's IP address and MAC address. This information lets the querying device build a comprehensive table of devices known to be operating on the same LAN by both their MAC and IP addresses, as needed.

Figures 10-13 and 10-14 better demonstrate this request-and-reply process. Figure 10-13 shows a desktop computer on a LAN broadcasting an ARP request throughout that LAN in an effort to find a MAC address that correlates with IP address 10.125.109.3. Notice that the request is even accepted by the router interface. The router does not forward this broadcast. But inasmuch as one of its interfaces is connected to the LAN, it is obligated to accept the MAC broadcasts of that environment just like any other device.

Figure 10-13. A Desktop Computer Transmits an ARP Request Throughout the LAN to Find a MAC Address for Host 10.125.109.3

Figure 10-14. Other Devices in the LAN Reply to the ARP Request, Supplying the Requesting Device with Their IP and MAC Address

Figure 10-14 shows the device on that LAN with that IP address replying to the ARP request. This reply lets the requesting desktop computer build its ARP cache. Using this approach, the requesting desktop can obtain all the MAC addresses it needs to communicate with its local peers.

NOTE

At the risk of restating the obvious, machines communicate across a LAN using MAC addresses. IP addresses are required only when machines communicate between two or more networks, or if the application requires that protocol. Given the near-complete dominance of IP, many applications require IP. This can create the misperception that IP is required to communicate on a LAN.

Keeping the Table Current

Having seen how an ARP cache gets built, you might be wondering how long such a table can stay current. The answer is "not long." Think about it: Not everyone shows up at work at the same time. Nor does everyone leave at the same time. Consequently, desktop and laptop computers are powered up and powered down at staggered intervals in the morning. If a machine isn't plugged into the network or isn't powered up, it can't respond to a neighbor's ARP request. So, some means of keeping an ARP cache current is required. Of course, the notion of desktops and laptops coming online and offline, obsoleting an ARP cache, implies that peer-to-peer communication is actually used. This might or might not be the case, but at least you can see why a cache can become outdated.

One common mechanism for maintaining an ARP cache's currency is a simple timer. System and network administrators alike enjoy the opportunity to establish thresholds for a timed update of their device's ARP cache. It isn't uncommon to find 4 hours as the time interval. At the end of that interval, the device flushes its ARP cache and generates a request that lets it build a new, more up-to-date table.

Although timers provide a nice, automatic means of maintaining the currency of the table's data, they are far from perfect. The basic ARP mechanisms described up to this point adequately provide a host with a means of building a table. But what happens when a host ceases functioning, powers down, or otherwise becomes unreachable via the LAN? Given enough time, the timer of each host would count down to 0 and force an ARP request. But that would create a period of time in which the contents of the ARP cache could be obsolete. The net effect would be that a machine would believe that it is reachable locally when it really isn't.

Furthermore, it is highly unlikely that all the timers of all the hosts would elapse simultaneously. Thus, the symptoms of ARP cache obsolescence probably will not be experienced uniformly throughout a network. This tends to make troubleshooting more interesting. In cases where, for whatever reason, an ARP cache becomes corrupted or painfully out-of-date, your best bet is to simply rebuild it.

NOTE

The first time you use ping to test connectivity to an IP address, you will likely see that the first reply in the sequence of attempts will fail. Subsequent replies will be successful. That's normal. It demonstrates that the first time around there was no mapping between the IP and MAC addresses for that destination.

Handling Unknown IP Addresses

Another interesting aspect of ARP is how it handles unknown IP addresses. An IP address can be unknown to ARP for many reasons. For example, it might not be a valid IP address. Excluding that obvious reason, there are at least two other main reasons why ARP wouldn't know about a particular IP address. First, perhaps the IP address belongs to a locally connected device that hasn't connected to the network yet. Alternatively, the IP address could be assigned to a machine that is not on the same LAN. Of course, myriad other possibilities exist too, including that the IP address is invalid, but we'll focus on just those two main reasons.

The process begins when an application passes data to the TCP/IP protocol stack for forwarding to a specific destination (as identified by the destination's IP address). IP engages ARP's services to see if that IP address is known to exist locally. Remember: ARP builds a table that tracks only locally connected machines by their MAC and IP addresses. If the IP address can't be found in the ARP cache, you just can't jump to the conclusion that the device is on a different network.

The next step in figuring out what to do is to poll the local hosts again. Remember, at this point the application has already handed off its data to TCP/IP for encapsulation in an IP packet. That packet must be encapsulated in an Ethernet frame for transmission on the Ethernet LAN. An ARP request packet is generated with its IP address and is broadcast throughout the LAN. The local hosts again check to see if they are the IP address in the request packet. If they are, a reply packet is generated and is sent back to the requesting machine. That requesting machine must do two things: update its ARP cache, and then wrap the IP packet that started this whole process with an Ethernet frame and send it on its way.

However, if no local host replies to the ARP request, it is safe to assume that either

• The host is not local

• The host is local but is not on the network at this time

Either way, the source machine is not off the hook. It still is obligated to find a way to deliver the packet. Let's revisit the previous example of an HTTP session between two desktop computers to see how ARP handles these two scenarios. The way it does this is through the use of a default gateway. A default gateway IP address should be configured every time you configure networked communications on a computer. The LAN's population must use that router interface's IP address (the default gateway) to reach the outside world. ARP correlates that IP address with that router interface's MAC address.

The way this works is relatively simple. The source machine takes the IP packet with its encapsulated application data and places it in an Ethernet frame bearing the destination MAC address of the router's interface. The router accepts that frame (after all, that frame is addressed to it, even if the IP packet contained therein is not) and strips away the frame to reveal the embedded IP packet. This is where the router, functioning as the LAN's default gateway, must make a decision. If the packet bears a destination IP address that belongs to the network from which it was received, it discards the packet as undeliverable. The logic at work here is that it is seldom useful to send a packet out the same interface from which it was received.

NOTE

There was a time when it was never useful to send a packet out the same router interface from which it was received. The introduction of subnetting has changed this. Today, it is not uncommon to find a single router interface that supports two separate IP subnets on the same Ethernet LAN. In such cases, the router may have no choice but to send IP packets (embedded in Ethernet frames, of course) back through the same interface on which they came in.

However, if the destination IP address of that packet is from a different network address, the router sends the packet on its way. This is illustrated in Figure 10-15.

Figure 10-15. The Router Acts as a Default Gateway and Accepts Ethernet Frames Addressed to Its Interface. Those Frames Contain an Embedded IP Packet Addressed to a Foreign Host.