Harping on ARP

ARP, the Address Resolution Protocol, is the means by which IP addresses are translated to physical layer MAC (usually ethernet) addresses. ARP makes local area networks work by enabling systems to find each other. When one system has a packet to transmit to another on the local network, it broadcasts an ARP request packet seeking a MAC address for a given IP address. Some machine (usually the intended recipient) hopefully responds with the corresponding MAC address, and the packet gets sent.

If a Linux system (with a default configuration) receives an ARP request on one of its interfaces, and that request is looking for an IP address assigned to any of the systems interfaces, the system will respond to the ARP request through the interface that received it. This response happens even if the interface involved is not the one to which the requested address has been assigned. Mr. Bloemsaat's problems came about because his system has two interfaces plugged into the same network. Both interfaces receive - and respond to - ARP requests sent on that network. Depending on the order in which the responses are sent, traffic could be directed to the wrong interface.

Mr. Bloemsaat included a patch which restricts ARP responses to the interface actually implementing the requested address. But, over almost a month of discussion, the networking hackers have made it clear that they do not intend to change the way Linux behaves. Their reasoning follows, more or less, these lines:

• Blocking ARP responses in this way is putting filtering decisions at the wrong layer of the networking code. This sort of action belongs at the netfilter level, rather than down at the device level.

• Linux's approach to ARP responses is fully compliant with all applicable RFCs.

• In some situations, responding out of all interfaces is the only way to successfully get communication established.

• For situations where the default ARP behavior causes problems, the arp_filter sysctl knob can be used to change things. This knob is described in networking/ip-sysctl.txt in the kernel documentation directory. For those who do not want to do this sort of tweaking directly, the ebtables package presents an easier interface.

A lot of the confusion, it seems, comes down to a subtle difference in how systems handle IP addresses. Many (perhaps most) networking implementations treat addresses as "belonging" to the interfaces they are assigned to. With that view of the world, no network interface has any business responding to an ARP request for an address which is assigned elsewhere. Linux, instead, sees IP addresses as a property of the system as a whole. So it makes sense for an interface to respond to a request for one of the system's addresses, even if that address is normally associated with a different interface.

The networking RFCs make it clear that either view of IP addresses is legitimate. Armed with that, and their sense of how things should work, the networking hackers are determined to keep Linux's ARP behavior as it is.