This article was accepted into the corpus but its outbound wikilinks were never NER-processed — typical at the deepest BFS hop or when the run's entity cap was reached. No expansion funnel to show.
| RARP | |
|---|---|
| Name | RARP |
| Full name | Reverse Address Resolution Protocol |
| Origin | Xerox PARC |
| Initial release | 1984 |
| Developers | Digital Equipment Corporation, Xerox Corporation, Bolt Beranek and Newman |
| Standardized by | Internet Engineering Task Force |
| Related | ARP, BOOTP, DHCP |
| Status | Obsolete |
RARP RARP is a network protocol developed in the 1980s to allow a device to discover its Internet Protocol address from a known hardware address. It was designed in environments using Ethernet, DECnet, VAX, and early Unix workstations, and it predates and influenced later protocols such as BOOTP and DHCP. RARP saw adoption in commercial products from Digital Equipment Corporation and integration into stacks for Sun Microsystems systems and Berkeley Software Distribution derivatives.
RARP was created to map a physical network interface identifier to an Internet Protocol address for diskless clients, enabling boot-time configuration on networks like Ethernet and LocalTalk. It addressed a practical need in installations at sites such as Xerox PARC, Stanford University, Massachusetts Institute of Technology, and Bell Labs where devices from DEC and Sun Microsystems lacked local storage. RARP messages were carried in IPv4-adjacent frameworks and operated at the intersection of link-layer and TCP/IP stacks implemented in systems like BSD and System V.
RARP emerged during the early expansion of ARP research and deployments in networks run by organizations including Xerox, Digital Equipment Corporation, and Bolt Beranek and Newman laboratories. Early specifications were discussed in venues such as IETF working groups and at conferences attended by engineers from Stanford Research Institute, MIT, and UCLA who were also active in the development of TCP/IP and ARPANET technologies. Commercial implementations appeared in products from VAX vendors and in SunOS releases, while academic implementations were present in Berkeley Software Distribution kernels and experimental stacks at Carnegie Mellon University.
RARP operates by having a client broadcast a request containing a hardware address such as a MAC address and awaiting a unicast reply with an IPv4 address. The protocol was specified to work on link layers like Ethernet and required a RARP server configured with a mapping table maintained by administrators at sites such as Stanford, UC Berkeley, MIT, and Bell Labs. Its design is related to address resolution mechanisms discussed alongside ARP, NetBIOS, and early XNS protocols in engineering documents circulated among DEC, Xerox, and HP engineers.
A RARP message uses a frame structure similar to ARP frames, with fields for hardware type, protocol type, hardware length, protocol length, opcode, sender hardware address, sender protocol address, target hardware address, and target protocol address; these fields were interoperable with stacks in BSD, SunOS, Ultrix, and HP-UX. Typical opcodes included request and reply, and messages were encapsulated directly on Ethernet II frames or within media-specific envelopes for LocalTalk adapters used in Apple environments. Administration of mapping tables was often performed through utilities in 4.3BSD, proprietary configuration tools from Digital Equipment Corporation, or scripts used at institutions like NASA and CERN.
RARP server and client implementations were shipped in operating systems and network appliances from Sun Microsystems, Digital Equipment Corporation, HP, IBM, and in open-source projects like FreeBSD, NetBSD, and OpenBSD through their ifconfig and kernel network stacks. Academic sites such as MIT, Stanford, and UC Berkeley used RARP to support diskless workstations in classrooms and labs, while commercial installations at Bell Labs and Hewlett-Packard facilities used RARP for thin client bootstrapping. Network firmware on devices from Intel and National Semiconductor included RARP capabilities for early network interface cards and embedded controllers.
RARP lacked mechanisms for conveying additional configuration data beyond the IP address, could not cross router boundaries, and required manual mapping maintenance on servers from vendors like Sun Microsystems and Digital Equipment Corporation. These limitations, coupled with the emergence of protocols capable of providing richer boot-time configuration such as BOOTP and the more automated DHCP specified by the IETF, led to RARP's rapid deprecation in enterprise networks managed by organizations like Cisco Systems, Juniper Networks, and large research sites including CERN and NASA.
RARP is historically connected to ARP and influenced the design of BOOTP, DHCP, and other bootstrapping protocols used in environments managed by IETF working groups and deployed across networks run by Sun Microsystems, IBM, HP, and Digital Equipment Corporation. Alternative address discovery mechanisms such as Inverse ARP used in Frame Relay and ATM contexts, and later service discovery protocols like PXE and iSCSI boot, superseded RARP for many applications in enterprise and research networks.
Category:Network protocols