Before dynamic IP address allocation became standard, early networked computers faced a major challenge: how to determine their own IP address upon boot when they only knew their hardware address. The Reverse Address Resolution Protocol (RARP) emerged in the early 1980s as a solution to this problem. Though obsolete today, RARP played a pivotal role in the evolution of network booting and dynamic address assignment.
RARP was first described in RFC 903, published in June 1984 by David C. Plummer, who also contributed to the original ARP protocol (RFC 826). The protocol was designed during a time when networks were becoming increasingly decentralized and more reliant on remote booting.
In traditional IP networks, a device requires an IP address to communicate. But diskless workstations—common in the 1980s, especially in academic and research settings—didn’t have local storage to store a static IP address. These machines could identify themselves only via their MAC (hardware) address.
RARP was designed to let such a device send a request to a RARP server, asking: “What is my IP address?” The server would look up a pre-configured table mapping MAC addresses to IP addresses and respond accordingly.
RARP was built as an extension of Ethernet and ARP, not as a standalone protocol layer. It reused ARP’s message format but modified the operation code and logic to support reverse mapping.
The protocol was developed during a time when:
While innovative, RARP was limited:
These constraints led to the adoption of more flexible protocols like BOOTP (RFC 951) and eventually DHCP (RFC 2131).
Although RARP is no longer in use, it laid the groundwork for network boot protocols. Concepts from RARP reappear in technologies like PXE (Preboot Execution Environment) and continue to influence embedded systems that rely on MAC-based addressing during startup.