Address Resolution (TCP/IP Network Administration, 3rd Edition)

2.5. Address Resolution

The IP address and the routing table direct a datagram to a specific physical network, but when data travels across a network, it must obey the physical layer protocols used by that network. The physical networks underlying the TCP/IP network do not understand IP addressing. Physical networks have their own addressing schemes, and there are as many different addressing schemes as there are different types of physical networks. One task of the network access protocols is to map IP addresses to physical network addresses.

The most common example of this Network Access Layer function is the translation of IP addresses to Ethernet addresses. The protocol that performs this function is Address Resolution Protocol (ARP), which is defined in RFC 826.

The ARP software maintains a table of translations between IP addresses and Ethernet addresses. This table is built dynamically. When ARP receives a request to translate an IP address, it checks for the address in its table. If the address is found, it returns the Ethernet address to the requesting software. If the address is not found, ARP broadcasts a packet to every host on the Ethernet. The packet contains the IP address for which an Ethernet address is sought. If a receiving host identifies the IP address as its own, it responds by sending its Ethernet address back to the requesting host. The response is then cached in the ARP table.

The arp command displays the contents of the ARP table. To display the entire ARP table, use the arp -a command. Individual entries can be displayed by specifying a hostname on the arp command line. For example, to check the entry for rodent in the ARP table on crab, enter:

% arp rodent
rodent (172.16.12.2) at 0:50:ba:3f:c2:5e

Checking all entries in the table with the -a option produces the following output:

% arp -a

Net to Media Table: IPv4
Device   IP Address               Mask      Flags   Phys Addr
------ -------------------- --------------- ----- ---------------
dnet0  rodent               255.255.255.255       00:50:ba:3f:c2:5e
dnet0  crab                 255.255.255.255 SP    00:00:c0:dd:d4:da
dnet0  224.0.0.0            240.0.0.0       SM    01:00:5e:00:00:00

This table tells you that when crab forwards datagrams addressed to rodent, it puts those datagrams into Ethernet frames and sends them to Ethernet address 00:50:ba:3f:c2:5e.

One of the entries in the sample table (rodent) was added dynamically as a result of queries by crab. Two of the entries (crab and 224.0.0.0) are static entries added as a result of the configuration of crab. We know this because both these entries have an S, for "static," in the Flags field. The special 224.0.0.0 entry is for all multicast addresses. The M flag means "mapping" and is used only for the multicast entry. On a broadcast medium like Ethernet, the Ethernet broadcast address is used to make final delivery to a multicast group.

The P flag on the crab entry means that this entry will be "published." The "publish" flag indicates that when an ARP query is received for the IP address of crab, this system answers it with the Ethernet address 00:00:c0:dd:d4:da. This is logical because this is the ARP table on crab. However, it is also possible to publish Ethernet addresses for other hosts, not just for the local host. Answering ARP queries for other computers is called proxy ARP.

For example, assume that 24seven is the server for a remote system named clock connected via a dial-up telephone line. Instead of setting up routing to the remote system, the administrator of 24seven could place a static, published entry in the ARP table with the IP address of clock and the Ethernet address of 24seven. Now when 24seven hears an ARP query for the IP address of clock, it answers with its own Ethernet address. The other systems on the network therefore send packets destined for clock to 24seven. 24seven then forwards the packets on to clock over the telephone line. Proxy ARP is used to answer queries for systems that can't answer for themselves.

ARP tables normally don't require any attention because they are built automatically by the ARP protocol, which is very stable. However, if things go wrong, the ARP table can be manually adjusted. See Section 13.4.2, "Troubleshooting with the arp Command " in Chapter 13, " Troubleshooting TCP/IP".