Cover V09, I10
Article
Figure 1
Figure 2

oct2000.tar


The World According to ARP

Ron McCarty

Address Resolution Protocol (ARP) happens daily millions of times on the networks we manage often without issues or problems. However, network design challenges and support issues with ARP do arise, and unfortunately, many administrators must attend the certification seminar school of hard knocks and quickly get up to speed on the protocol under poor circumstances. This month's column covers ARP fundamentals, design issues, and shows ARP requests with tcpdump. (Note: While writing this article, I discovered that version 3.4 of tcpdump distributed with RedHat 6.1 incorrectly reported Ethernet broadcast addresses with 00:00:00:00:00:00 as opposed to the correct FF:FF:FF:FF:FF:FF. An upgrade to tcpdump version 3.5 available at http://www.tcpdump.org/ fixed the problem.)

ARP is defined in RFC 826, “An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48-bit Ethernet Address for Transmission on Ethernet Hardware”. ARP is the mechanisum used to determine the layer 2 media access control address for a directly connected layer 3 IP address. This resolution is required whether the IP host is directly connected to the network or not. But, in those cases where the destination host is not connected, the source host will attempt to resolve (or “ARP”) the gateway's address. In addition to RFC 826, RFC 1122, “Requirements for Internet Hosts -- Communications Layers” also adds some new requirements concerning caching of addresses.

Whenever a host needs to communicate with a particular host, it will try to resolve the address by sending an ARP who-has request, and assuming the IP address exists on the local network, the host will respond. Let's examine a request and reply with tcpdump:

tcpdump -n arp
Kernel filter, protocol ALL, raw packet socket
tcpdump: listening on eth0
21:58:48.894202 arp who-has 10.1.1.1 tell \
   10.1.1.2
21:58:48.937925 arp reply 10.1.1.1 is-at \
   0:10:67:0:3c:3c
2 packets received by filter
0 packets dropped by kernel
To avoid unnecessary traffic, systems cache the learned entries for future use. Besides avoiding unnecessary traffic, this also drastically reduces the load on hosts, because each host will examine each ARP request since it is destined to the Ethernet broadcast address: FF:FF:FF:FF:FF:FF as shown with tcpdump below. The -e option is used to see the layer two (data link) layer information and the n option is used to not resolve addresses to names:

tcpdump -en arp
Kernel filter, protocol ALL, raw packet socket
tcpdump: listening on eth0
22:00:01.272362 0:10:a4:e6:3b:c0 \
   ff:ff:ff:ff:ff:ff 0806 42: arp \
   who-has 10.1.1.1 tell 10.1.1.2
22:00:01.315486 0:10:67:0:3c:3c \
   0:10:a4:e6:3b:c0 0806 60: arp \
  reply 10.1.1.1 is-at 0:10:67:0:3c:3c
2 packets received by filter
0 packets dropped by kernel
ARP Troubles

Since ARP is a relatively simple protocol and has a very specific purpose, the types of problems associated with ARP are also limited.

Duplicate addresses can cause problems on a network because workstations may be communicating with the wrong hosts. Duplicate MAC addresses are unlikely since vendors typically burn their MAC adresseses into the Ethernet card; however, there are exceptions with vendors that store the MAC address in battery-backed up RAM. Additionally, some Ethernet switches do not support the same MAC address on multiple ports or VLANs as is the case with SUN quad cards, so manual configuration may be needed to allow interoperability with such switches.

Duplicated IP addresses on the other hand are possible, and not uncommon in larger environments with a large number of static IP addresses. Undocumented use of IP addresses for temporary use often become permanent, and problems arise later when a new host is deployed with that IP address. In DHCP environments, static addresses can also be assigned, so a DHPC daemon such as ISC's dhcpd (http://www.isc.org/products/DHCP/) will actually ping the host to ensure that the address is not being used.

Network planning and documentation are the best cures for these problems. Active monitoring with scripts using ping or nmap can be used to ensure that unassigned addresses are not replying to network traffic. The ARP command can also be used to display the ARP table.

MAC to IP addresses can also be statically mapped using the ARP command; however, this use should be restricted to a temporary fix when a host is broken and as described in the Security and ARP section.

Denial of service attacks can often be seen with the tcpdump. Additionally, the -t option with tcpdump will print a timestamp to determine how often ARP requests are being sent.

Legacy Networks

Proxy ARP can also be used to provide subnetting on equipment that does not properly support subnetting or variable length subnet masks; however, this particular application must be avoided on modern network deployments.

Proxy ARP works by listening for specific requests on an interface and replies to the sender with its own MAC address. The sender then directs the traffic to the MAC address (which is the ARP proxy server), which then routes the packet using routing. The ultimate destination can be connected to the router, meaning it will then send an ARP request on the connected network to determine the destination, or route it out the interface on the destination's path.

Although originally designed for subnetting that would assume proxy ARP would be used in both directions (but not necessarily use the same path), this is by no means required. One portion of the network might require the proxy ARP, but the other portion of the network can reach the network through normal routing based upon the network mask.

Figure 1 gives a good overview of using proxy ARP. In the figure, the network was originally 10.0.0.0/8, but 10.10.10.0/24, for whatever reason (address depletion, reorganization, etc.), will now be used in another area of the network, which happens to not properly support subnetting or variable length subnet masks. Proxy ARP can be activated on the 10.1.1.1 router for 10.10.10.0/24. Any hosts from the legacy network 10.0.0.0 will send ARP requests for the complete network including the new 10.10.10.0/24. The router 10.1.1.1 will then answer the ARP requests and route the packets on their way. In this particular example, the router for 10.10.10.0/24 supports VLSM routing, and the hosts are configured with the proper netmask of 255.255.255.0 (/24); therefore, proxy ARP is not required in the other direction in this example.

An additional use of proxy ARP is for remote access services provided by network access servers (NAS). When a NAS is configured for proxy ARP, it will respond with its MAC address when a host queries for a dialed-in user that it believes is on the same network based upon the address and netmask. Typically, NAS servers can be configured to always answer the ARP request or to only reply when the address is in use (i.e., the user is online). The use of proxy ARP for remote access services is shown in Figure 2. With this configuration only one network (192.168.1.0/24) is required -- the LAN and dial-in users are on the same IP network.

Security and ARP

Based upon the information presented, the first security issue that comes to mind is likely denial of service attacks based upon a purposefully misconfigured IP address, or worse yet, a tool that answers requests with false MAC addresses. Additionally, the original ARP specification does not require that a request to be sent to receive an ARP reply; therefore, these system can be spoofed and effectively brought down by filling the ARP cache with wrong entries for the complete network.

The arpwatch (ftp://ftp.ee.lbl.gov/ \
arpwatch.tar.gz
) tool can be used to monitor ARP requests as well as the MAC to IP mappings. Additionally, scripting tcpdump to perform the same feature is also a good possibility for watching the mappings.

Good network design with separation of servers and workstations will also help quickly localize the problem and limit the number of hosts that can affect important services. ARP requests and replies are local requests, so routers will not forward the requests to other networks except for proxy ARP.

Static mappings of IP addresses can also be used in environments requiring the extra security, such as on a firewall, Internet router, and public servers. This should just be an additional measure of security to an already strong security model, since affecting ARP within a security zone should be tough considering limited physical and network access to the hosts. ARP -s can be used on most versions of UNIX to create static entries.

Summary

ARP, a simple yet fundamental protocol for the TCP/IP protocols over Ethernet and other media, should be understood and cleanly implemented. I hope I've covered ARP here in enough detail to help you quickly identify any ARP-related problems.

About the Author

Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ronald McCarty started his network career as network administrator at the Schwaebisch Gmuend campus. Ronald McCarty works for Lucent Technologies as a senior systems engineer on a customer team responsible for a major telecommunications carrier. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia. Ron can be reached at: ronald.mccarty@gte.net.