~/ linuxnetwork.net

Reverse Address Resolution Protocol (RARP)

In the world of networking, the Reverse Address Resolution Protocol (RARP) was one of the earliest solutions for dynamic IP address assignment. While it has been superseded by more capable protocols like BOOTP and DHCP, understanding RARP remains valuable for a comprehensive knowledge of network communication and the evolution of address resolution. This blog will delve into what RARP is, how it works, its common and best practices, along with example usage.

Note: RARP is considered obsolete. It was replaced first by the Bootstrap Protocol (BOOTP) and then by the Dynamic Host Configuration Protocol (DHCP), which offer far greater flexibility. RARP is no longer included in the Linux kernel (removed since version 2.3) and is rarely deployed in modern networks.

Table of Contents#

  1. What is RARP?
  2. How RARP Works
  3. Limitations of RARP
  4. RARP vs ARP
  5. Common Practices with RARP
  6. Best Practices for RARP
  7. Example Usage of RARP
  8. Modern Alternatives: BOOTP and DHCP
  9. References

What is RARP?#

RARP is a network protocol that enables a device (usually a diskless workstation or an embedded device) to obtain its IP address when it only knows its Media Access Control (MAC) address. In traditional networking, ARP is used to map an IP address to a MAC address. RARP does the reverse — it helps a device find its IP address based on its MAC address.

RARP was specified in RFC 903, published in June 1984 by Ross Finlayson, Timothy Mann, Jeffrey Mogul, and Marvin Theimer at Stanford University. It reused ARP's message structure but reversed its function, operating at the data-link layer (Layer 2) using broadcast frames.

How RARP Works#

  1. Request Phase
    • A device with only a known MAC address sends out a RARP request. This request is a broadcast message on the local network. The message contains the device's MAC address.
    • For example, in a local area network (LAN), a diskless workstation boots up. It has a pre-configured MAC address (usually burned into its network interface card), but no IP address. It sends a RARP request packet with the opcode field set to 3 (request reverse).
  2. Server Response
    • A RARP server on the network listens for these requests. The RARP server has a database that maps MAC addresses to IP addresses. When it receives a RARP request, it looks up the MAC address in its database.
    • If the MAC address is found, the RARP server sends a RARP reply with the opcode field set to 4 (reply reverse). The reply contains the corresponding IP address for that MAC address.
    • The device that sent the request then configures its network interface with the received IP address.

RARP packets use the same frame format as ARP but are distinguished by a separate Ethertype, so existing ARP implementations are not confused by RARP traffic.

Limitations of RARP#

RARP had several significant drawbacks that led to its replacement:

  • IP address only: RARP could only provide an IP address. It could not deliver additional configuration such as subnet mask, default gateway, or DNS server addresses.
  • Layer 2 only: RARP operates at the data-link layer using broadcast frames, meaning it cannot traverse routers or work across subnets.
  • Static mappings required: Each MAC-to-IP mapping had to be manually configured on the RARP server. There was no dynamic allocation.
  • No security: RARP had no authentication or authorization mechanisms, making it vulnerable to spoofing.
  • Server dependency: A dedicated RARP server was needed on every network segment, and the server had to be maintained with up-to-date mappings.

RARP vs ARP#

FeatureARPRARP
PurposeMaps IP address → MAC addressMaps MAC address → IP address
Opcode (request/reply)1 / 23 / 4
RFCRFC 826RFC 903
StatusWidely used todayObsolete
Typical useResolving known IP to unknown MACDiskless workstation bootstrapping

Common Practices with RARP#

  • Diskless Workstations: One of the most common historical use cases is in diskless workstations. These workstations often rely on a network server for their operating system and other resources. Since they don't have a local disk to store configuration information (including IP addresses), RARP was used to obtain the IP address at boot-up.
  • Embedded Systems: Some embedded systems, especially those in simple networked devices (e.g., certain types of sensors in a local network setup), used RARP. These devices may have limited storage and rely on a central server (acting as a RARP server) to configure their network settings.
  • Virtual machine migration: In modern networks, RARP packets are sometimes used by virtualization platforms (e.g., Cisco Overlay Transport Virtualization and VMware vMotion) to update Layer 2 forwarding tables when a virtual machine's MAC address moves between hosts or data centers.

Best Practices for RARP#

These practices apply to legacy environments where RARP is still in use. For new deployments, DHCP is strongly recommended.

  • Secure Database Management: If you are running a RARP server, it is crucial to manage the MAC-IP mapping database securely. Unauthorized access to this database could lead to IP address spoofing. For example, use access controls on the server where the database is stored.
  • Redundancy: In larger networks where RARP is used, consider having redundant RARP servers. If one server fails, another can take over the task of responding to RARP requests. This ensures that devices can still obtain their IP addresses.
  • Regular Updates: Keep the MAC-IP mapping database up-to-date. As new devices are added to the network or existing devices' MAC addresses change (due to hardware replacement, for example), update the database accordingly.

Example Usage of RARP#

Let's assume we have a simple LAN with a RARP server and a diskless workstation.

Server-side (RARP Server)#

  • Database Setup:
    • The RARP server has a text-based database (e.g., /etc/ethers in some Unix-like systems). The database entries look like this:
    00:0c:29:ab:cd:ef 192.168.1.100
    • Here, 00:0c:29:ab:cd:ef is the MAC address of the diskless workstation, and 192.168.1.100 is the corresponding IP address.
  • Server Software:
    • On a Linux system, you can use software like rarpd (a RARP daemon). You would start the daemon with the appropriate configuration (specifying the database file). For example:
    rarpd -f /etc/ethers
    • Note: The rarpd daemon is no longer included in most modern Linux distributions. The Linux kernel removed native RARP support starting with version 2.3. If you need similar functionality today, use DHCP instead.

Client-side (Diskless Workstation)#

  • Boot-up Process:
    • When the diskless workstation boots up, its network interface controller (NIC) knows its MAC address (e.g., 00:0c:29:ab:cd:ef).
    • The workstation's bootloader initiates the RARP process. It sends a RARP request packet (using the NIC's MAC address) over the network.
    • The RARP server (running rarpd in our example) receives the request, looks up the MAC address in its database (/etc/ethers), and sends back a RARP reply with the IP address 192.168.1.100.
    • The workstation then configures its network interface with the received IP address and can start communicating on the network (e.g., by mounting a network-based file system if it's a diskless workstation).

Modern Alternatives: BOOTP and DHCP#

RARP's limitations led to the development of two successor protocols:

  • BOOTP (Bootstrap Protocol): Defined in RFC 951 (1985), BOOTP improved on RARP by operating at the application layer (Layer 7), which allowed it to work across routers via relay agents. BOOTP could provide additional configuration beyond just an IP address, including the default gateway, subnet mask, and boot file information.
  • DHCP (Dynamic Host Configuration Protocol): Defined in RFC 2131 (1997), DHCP extended BOOTP with dynamic address leasing, automatic pool management, and a much richer set of configuration options. DHCP is the standard protocol for IP address assignment in virtually all modern networks.

Both BOOTP and DHCP solved RARP's core problem — they can deliver complete network configuration, work across subnets, and support dynamic address allocation without per-device manual configuration on the server.

References#

2026-06