Address Resolution: ARP and RARP

ARP, due to its apparent simplicity, is a rather overlooked concept, and sometimes its effect
on the well being of network infrastructures is underestimated. ARP-related issues are fairly
common in complex scenarios and often poorly understood by non-networking folks.
Therefore, this section offers an overview of several manifestations of the ARP protocol itself
and related aspects.
For a good understanding of network dynamics, it is also mandatory to understand the timers
involved with regard to ARP and switch table entries and their lifetime. ARP table entries
have a lifetime in the range of minutes up to tens of minutes, depending on the operating
system under discussion.
Politely behaving implementations such as Cisco IOS Software display ARP cache timers
within the ARP output. This information will hopefully assist in tracking and resolving
problems such as incomplete ARP entries, duplicate IP addresses, and security issues such as
spoofing and sniffing. Ethernet MAC addresses can be spoofed easily given physical access to
the network segment or VLAN under consideration. Example 7-1 presents an overview of the
capabilities of the Linux and BSD arp commands (essentially show, add, and delete). Static
ARP entries can as well be deployed via a configuration file. You will read more about the
temp/pub flags of the arp command in the following sections.
Example 7-1. Linux and BSD ARP Utility Features

[root@callisto:~#] arp -?

Usage:

arp [-vn] [<HW>] [-i <if>] [-a] [<hostname>] <-Display ARP
cache

arp [-v] [-i <if>] -d <hostname> [pub][nopub] <-Delete ARP
entry

arp [-vnD] [<HW>] [-i <if>] -f [<filename>] <-Add entry
from file

arp [-v] [<HW>] [-i <if>] -s <hostname> <hwaddr> [temp][nopub] <-Add
entry

arp [-v] [<HW>] [-i <if>] -s <hostname> <hwaddr> [netmask <nm>] pub
<-''-

arp [-v] [<HW>] [-i <if>] -Ds <hostname> <if> [netmask <nm>] pub
<-''-



-a display (all) hosts in alternative (BSD)
style

-e display (all) hosts in default (Linux)
style

-s, --set set a new ARP entry

-d, --delete delete a specified entry

-v, --verbose be verbose

-n, --numeric don't resolve names

-i, --device specify network interface (e.g. eth0)

-D, --use-device read <hwaddr> from given device

-A, -p, --protocol specify protocol family

-f, --file read new entries from file or from
/etc/ethers



<HW>=Use '-H <hw>' to specify hardware address type. Default: ether

List of possible hardware types (which support ARP):

strip (Metricom Starmode IP) ash (Ash) ether (Ethernet)

tr (16/4 Mbps Token Ring) tr (16/4 Mbps Token Ring (New)) ax25 (AMPR
AX.25)

netrom (AMPR NET/ROM) rose (AMPR ROSE) arcnet (ARCnet)

dlci (Frame Relay DLCI) fddi (Fiber Distributed Data Interface) hippi
(HIPPI)

irda (IrLAP) x25 (generic X.25)



[root@castor:~#] arp

usage: arp [-n] hostname

arp [-n] -a

arp -d hostname [pub]

arp -d -a

arp -s hostname ether_addr [temp] [pub]

arp -S hostname ether_addr [temp] [pub]

arp -f filename



[root@callisto:~#] rarp -?

rarp: invalid option -- ?

Usage: rarp -a list entries in cache.

rarp -d <hostname> delete entry from cache.

rarp [<HW>] -s <hostname> <hwaddr> add entry to cache.

rarp -f add entries from /etc/ethers.

rarp -V display program version.



<HW>=Use '-H <hw>' to specify hardware address type. Default: ether

List of possible hardware types (which support ARP):

strip (Metricom Starmode IP) ash (Ash) ether (Ethernet)

tr (16/4 Mbps Token Ring) tr (16/4 Mbps Token Ring (New)) ax25 (AMPR
AX.25)

netrom (AMPR NET/ROM) rose (AMPR ROSE) arcnet (ARCnet)

dlci (Frame Relay DLCI) fddi (Fiber Distributed Data Interface) hippi
(HIPPI)

irda (IrLAP) x25 (generic X.25)



[root@callisto:~#] rarp -a

This kernel does not support RARP.



##### My LAB kernel does not support netboot such as RARP/BOOTP ######

##### This has to be configured at compile time ######################


Proxy ARP
Proxy almost always means "to act on someone's behalf"; this is exactly what happens when a
manual ARP entry is configured with the publish tag on BSD. This is explained perfectly in
the BSD arp(8) manual page.
In the particular case of proxy ARP, the system responds to ARP requests for that entry as if it
were the target of the request with its own MAC address, thereby impersonating an ARP
server. This is essentially relevant only for hosts without a default gateway or routing table
configured or certain boot or transitional situations. The use of proxy ARP in modern routed
and subnet-aware networks is discouraged but occasionally found in context with failover
protocols. Regarding this issue, I found an interesting quote from the Linux arp(7) man page:
Linux will automatically add a non-permanent proxy arp entry when it receives a request for
an address it forwards to and proxy arp is enabled on the receiving interface. When there is a
reject route for the target no proxy arp entry is added . . . Support for proxy arp entries for
networks (netmask not equal 0xffffffff) was dropped in Linux 2.2. It is replaced by automatic
proxy arp setup by the kernel for all reachable hosts on other interfaces (when forwarding and
proxy arp is enabled for the interface).
[1]

Example 7-2 shows the sysctl parameters that affect proxy ARP behavior and ARP filtering
on Linux systems.
ARP_filter
For a better understanding of the ARP_filter, consider this quote from the Linux
kernel documentation (ip-sysctl.txt):
arp_filter - BOOLEAN
1 - Allows you to have multiple network interfaces on the same subnet, and have the
ARPs for each interface be answered based on whether or not the kernel would route
a packet from the ARP'd IP out that interface (therefore you must use source based
routing for this to work). In other words it allows control of which cards (usually 1)
will respond to an arp request.
0 - (default) The kernel can respond to arp requests with addresses from other
interfaces. This may seem wrong but it usually makes sense, because it increases the
chance of successful communication. IP addresses are owned by the complete host
on Linux, not by particular interfaces. Only for more complex setups like load-
balancing does this behaviour cause problems.

Example 7-2. Proxy ARP Parameters for Linux Interfaces

[root@callisto:~#] sysctl -a | grep arp

net.ipv4.conf.eth1.arp_ignore = 0

net.ipv4.conf.eth1.arp_announce = 0

net.ipv4.conf.eth1.arp_filter = 0

net.ipv4.conf.eth1.proxy_arp = 0

net.ipv4.conf.eth0.arp_ignore = 0

net.ipv4.conf.eth0.arp_announce = 0

net.ipv4.conf.eth0.arp_filter = 0

net.ipv4.conf.eth0.proxy_arp = 0

net.ipv4.conf.lo.arp_ignore = 0

net.ipv4.conf.lo.arp_announce = 0

net.ipv4.conf.lo.arp_filter = 0

net.ipv4.conf.lo.proxy_arp = 0

net.ipv4.conf.default.arp_ignore = 0

net.ipv4.conf.default.arp_announce = 0

net.ipv4.conf.default.arp_filter = 0

net.ipv4.conf.default.proxy_arp = 0

net.ipv4.conf.all.arp_ignore = 0

net.ipv4.conf.all.arp_announce = 0

net.ipv4.conf.all.arp_filter = 0

net.ipv4.conf.all.proxy_arp = 0


ARP Cache
The route and ARP cache are intimately related via MAC resolution or data-link identifiers,
or, to be more general, by "next-hop" addresses and directly attached physical and logical
interfaces. Example 7-3 shows an example of the Linux ARP table. "Incomplete" entries
(shaded text) would mean that no ARP replies were received for that particular MAC address
resolution attempt.
Example 7-3. Linux ARP Table

[root@callisto:~#] arp

Address HWtype HWaddress Flags Mask
Iface

pollux ether 08:00:46:64:74:1B C
eth1

ganymed ether 48:54:E8:8C:0A:3F C
eth1

192.168.14.254 ether 00:00:0C:1A:A9:AB C
eth0



[root@callisto:~#] arp -a

pollux (192.168.1.250) at 08:00:46:64:74:1B [ether] on eth1

europa (192.168.1.254) at 48:54:E8:8C:0A:3F [ether] on eth1

scar (192.168.14.254) at <incomplete> on eth0


Static ARP Entries
Static ARP entries serve different purposes: They make smaller network setups more
predictable, enhance security, and can be required in context with static Network Address
Translation (NAT) entries of firewall gateways. Example 7-4 shows two examples for static
ARP entries on Linux and BSD systems. Note that these are examples for temporary manual
entries (in contrast to permanent). The OpenBSD example temp flag results in proxy ARP
behavior (as demonstrated in the highlighted text).
Example 7-4. Two Examples of Static ARP Entries

[root@callisto:~#] arp -s 192.168.1.55 A3:A3:A3:A3:A3:A3 temp

[root@callisto:~#] arp

Address HWtype HWaddress Flags Mask
Iface

pollux ether 08:00:46:64:74:1B C
eth1

ganymed ether 48:54:E8:8C:0A:3F C
eth1

192.168.14.254 ether 00:00:0C:1A:A9:AB C
eth0

192.168.1.55 ether A3:A3:A3:A3:A3:A3 C
eth1



[root@ganymed:~#] arp -s 192.168.1.55 A3:A3:A3:A3:A3:A3 pub temp

[root@ganymed:~#] arp -an

? (192.168.1.1) at 52:54:05:e3:51:87

? (192.168.1.2) at 08:00:46:64:74:1b

? (192.168.1.55) at a3:a3:a3:a3:a3:a3 published

? (192.168.2.7) at 00:10:5a:c4:2c:04

? (111.11.117.1) at 00:05:9a:5b:23:fc


Gratuitous ARP
Gratuitous ARP resembles emission of an unsolicited ARP reply to which no request was sent
or received. This is quite common behavior during bootstrap or boot procedures of several
operating systems when they initialize their IP stacks. When a computer receives a new
interface or another change occurs, it can update all neighboring ARP caches with one
gratuitous ARP packet to FF:FF:FF:FF:FF:FF.
A second important application is checking for duplicate IP addresses. The initializing IP
stack would not complete its initialization sequence upon detection of such a situation. There
exist security and performance implications when accepting gratuitous ARP packets;
therefore, routers and switches can be configured to ignore them. This feature can be used to
maliciously take over IP addresses.
Gratuitous ARP plays an important role in modern Hot Standby Routing Protocol (HSRP) and
heartbeat failover configurations, and sometimes in context of static NAT. Example 7-5
shows a sniffing example of a booting operating system, and Example 7-6 shows relevant
Cisco IOS commands to influence proxy ARP and gratuitous ARP behavior. I would not
recommend touching the default settings unless you know well what you want to accomplish.
Example 7-5. Gratuitous ARP at BSD IP Stack Initialization

[root@ganymed:~#] tethereal -i ne4

Capturing on ne4

0.000000 castor.nerdzone.org -> ff:ff:ff:ff:ff:ff ARP Who has
192.168.2.7?

Tell 192.168.2.7


Example 7-6. Improving Cisco Security and Performance

scar(config-if)# no ip proxy-arp



scar(config)# no ip gratuitous-arps



scar# show arp

Protocol Address Age (min) Hardware Addr Type Interface

Internet 192.168.13.1 - 0000.3058.9555 SNAP TokenRing0

Internet 192.168.14.1 0 0010.5ad7.9360 ARPA Ethernet1

Internet 192.168.7.7 11 5254.05e3.e488 ARPA Ethernet0

Internet 192.168.17.1 - 0000.3058.95b5 SNAP TokenRing1

Internet 192.168.7.254 - 0000.0c1a.a9a8 ARPA Ethernet0

Internet 192.168.14.254 - 0000.0c1a.a9ab ARPA Ethernet1


NOTE
UNIX workstations also send out gratuitous ARP when initializing alias or VLAN interfaces.

Reverse ARP (RARP), the Bootstrap Protocol (BOOTP), and Dynamic Host
Configuration Protocol (DHCP)
UNIX workstations can run a rarpd to respond to RARP requests of diskless or client
workstations. It can return an IP address for a requesting MAC address as well as a bootable
image via Trivial File Transfer Protocol (TFTP). There also exists a bootpd in the BSD world.
BOOTP, Preboot Execution Environment (PXE), and DHCP approaches have largely
superseded RARP. Because network-bootable client issues go beyond the scope of this book,
no examples are provided. Consult the man pages for rarpd, bootpd, and the links provided in
the "Recommended Reading" section for further information. Example 7-7 shows the relevant
sysctl parameters to influence BOOTP behavior on Linux systems.
NOTE
The ISC-DHCP server discussed in Chapter 6, "The Analyzer Toolbox, DHCP, and CDP,"
can answer both DHCP and BOOTP requests.

Example 7-7. Linux Can Relay BOOTP Requests

[root@callisto:~#] sysctl -a | grep bootp

net.ipv4.conf.eth1.bootp_relay = 0

net.ipv4.conf.eth0.bootp_relay = 0

net.ipv4.conf.lo.bootp_relay = 0

net.ipv4.conf.default.bootp_relay = 0

net.ipv4.conf.all.bootp_relay = 0


TFTP
TFTP is a lightweight protocol without any security that allows storage, retrieval, and creation
of files in a particular directory. On UNIX systems, it is usually started via the (x)inetd super
server. UNIX operating systems usually provide a native TFTP service out of the box. It is a
broadcast protocol commonly used in network-boot environments together with DHCP,
BOOTP, PXE, and RARP. In addition, it is often used to store and retrieve configurations for
network elements. Recently there was interest in multicast TFTP servers to efficiently and
simultaneously boot multiple clients.
There essentially exist several improved versions of TFTP server implementations:
utftpd Represents my TFTP UNIX implementation of choice. It consists of a client
and a server. According to its creator, it offers "fine-grained access control, support for
blksize (RFC 2348) and timeout options, and support for revision control"
(http://www.ohse.de/uwe/software/utftpd.html).
tftpd-hpa An enhanced version of the BSD tftpd called tftp-hpa that has TCP
wrapper support as well (http://www.kernel.org/pub/software/network/tftp/).
atftp Advanced TFTP client and server is multithreaded, supports libwrap (the TCP
wrapper library), and is fully compliant with all relevant standards. You can
downloaded it from ftp://ftp.mamalinux.com/pub/atftp/.
The Solarwinds TFTP server If you require a TFTP server for Windows, you can
use the free tool from Solarwinds (http://www.solarwinds.net).
NOTE
TFTP is an inherently insecure protocol without a password facility. Therefore, it is strongly
advised to compile your TFTP server of choice with TCP wrapper support to protect the
server or place it behind a packet filter or firewall. utftp and Solarwinds TFTP provide an
internal security mechanism that can filter based on source IP address.

Inverse ARP (InARP), UNARP, and DirectedARP
Inverse ARP is a feature used in ATM and Frame Relay dynamic address mapping. It is used
to request the next-hop protocol address given a data-link connection identifier (DLCI) or
ATM virtual path identifier/virtual circuit identifier (VPI/VCI) pair. The result is an address-
to-DLCI or -VPI/VCI mapping table. In addition, static mappings can be configured. Inverse
ARP is a multiprotocol mechanism on Cisco routers and turned on per default for Frame
Relay (all protocols). Go to Cisco.com for example configurations.
Examples 7-8 and 7-9 show a brief hub-and-spoke Frame Relay configuration example to
emphasize this point. Keep in mind that this setup requires an intermediate Frame Relay
switch; hence the name "Frame Relay" or "cell relay" for ATM networks. This will not work
in a crossover fashion. Every Layer 2 WAN protocol deals with ARP issues in its own way.
Example 7-8. Cisco Frame Relay Point-to-Multipoint Example (Hub Configuration Fragment)

scar# show running-config

...

!

interface Serial1

no ip address

encapsulation frame-relay

!

interface Serial1.1 multipoint

ip address 10.1.1.3 255.255.255.0

frame-relay map ip 10.1.1.1 160 broadcast

!

...


Example 7-9. Cisco Frame Relay Point-to-Multipoint Example (Spoke Configuration Fragment)

simba# show running-config

...

!

interface Serial0

ip address 4.0.1.1 255.255.255.0

encapsulation frame-relay

frame-relay map ip 10.1.1.2 140 broadcast

!

...


Interesting future developments (quoted from the RFCs) include the following:
UNARP (RFC 1868):
The Address Resolution Protocol allows an IP node to determine the hardware (datalink)
address of a neighboring node on a broadcast network. The protocol depends on timers to age
away old ARP entries. This document specifies a trivial modification to the ARP mechanism,
not the packet format, which allows a node to announce that it is leaving the network and that
all other nodes should modify their ARP tables accordingly.
DirectedARP (RFC 1433):
Directed ARP is a dynamic address resolution procedure that enables hosts and routers to
resolve advertised potential next-hop IP addresses on foreign IP networks to their associated
link level addresses.