The Reverse Address Resolution Protocol (RARP) is an obsolete computer communication protocol used by a client computer to request its Internet Protocol (IPv4) address from a computer network, when all it has available is its link-layer or hardware address, such as a MAC address.[1] The client broadcasts the request and does not need prior knowledge of the network topology or the identities of servers capable of fulfilling its request.

RARP has been rendered obsolete by the Bootstrap Protocol (BOOTP) and the modern Dynamic Host Configuration Protocol (DHCP), which have much greater feature sets than RARP.

RARP requires one or more server hosts to maintain a database of mappings of link-layer addresses to their respective protocol addresses. MAC addresses need to be individually configured on the servers by an administrator. RARP is limited to serving only IP addresses.

Reverse ARP differs from the Inverse Address Resolution Protocol (InARP), which is designed to obtain the IP address associated with a local Frame Relay data link connection identifier.[2] InARP is not used in Ethernet.

History

edit

The Reverse Address Resolution Protocol (RARP) was introduced in the early 1980s to help devices, especially diskless workstations, determine their IP addresses using only their hardware (MAC) addresses.[3] This was a common need in early network environments where local storage was unavailable for IP configuration.

RARP was specified in RFC 903, published in June 1984 by David C. Plummer.[4] Building on the original Address Resolution Protocol (ARP), RARP reused ARP’s message structure but reversed its function, allowing a device to query a RARP server for its corresponding IP address.[4] The protocol was widely adopted in UNIX-based systems for network booting.[4]

Despite its utility, RARP had major limitations: It required static mappings, lacked support for additional configuration data, and could not operate across subnets. These drawbacks led to its replacement by more robust protocols like BOOTP and DHCP.[4] Nonetheless, RARP laid the groundwork for later network boot technologies.

Modern day uses

edit

Although the original uses for RARP have been superseded by different protocols, some modern-day protocols use RARP to handle MAC migration, particularly in virtual machines, using a technique originating in QEMU.

Examples include:

See also

edit

References

edit
  1. ^ R. Finlayson; T. Mann; J. Mogul; M. Theimer (June 1984). A Reverse Address Resolution Protocol. Network Working Group. doi:10.17487/RFC0903. STD 38. RFC 903. Internet Standard 38.
  2. ^ T. Bradley; C. Brown; A. Malis (September 1998). Inverse Address Resolution Protocol. Network Working Group. doi:10.17487/RFC2390. RFC 2390. Draft Standard. Obsoletes RFC 1293.
  3. ^ "The Origins of RARP: How and Why the Reverse Address Resolution Protocol Was Developed". usa-ip.com. Retrieved 19 June 2025.
  4. ^ a b c d Plummer, David C,"RFC 903: A Reverse Address Resolution Protocol". datatracker.ietf.org. 1 June 1984. Retrieved 19 June 2025.
  5. ^ Deshpande, Venky (22 July 2013). "VXLAN Series – How vMotion impacts the forwarding table – Part 6". vmware. Retrieved 15 March 2023.[dead link]

📚 Artikel Terkait di Wikipedia

Address Resolution Protocol

another node, whereas RARP is used to obtain the layer-3 address of the requesting station itself for address configuration purposes. RARP is obsolete; it was

Dynamic Host Configuration Protocol

protocol is commonly called DHCPv6. The Reverse Address Resolution Protocol (RARP) was defined in 1984 for the configuration of simple devices, such as diskless

Bootstrap Protocol

Address Resolution Protocol (RARP), published in June 1984. The primary motivation for replacing RARP with BOOTP is that RARP was a link layer protocol.

Management of prostate cancer

hands of an experienced surgeon, robotic-assisted radical prostatectomy (RARP) may reduce positive surgical margins when compared to radical retropubic

Construct (Python library)

Bytes(6), "source" / Bytes(6), "type" / Enum(Int16ub, IPv4=0x0800, ARP=0x0806, RARP=0x8035, X25=0x0805, IPX=0x8137, IPv6=0x86DD, ), ) Next, the IP header (layer

IPTraf

IPTtraf supports multiple protocols: IP TCP UDP ICMP IGP IGMP IGRP OSPF ARP RARP IPTraf supports a wide range of network interfaces: Local loopback All Ethernet

ThreadX

Auto IP, DHCP, DNS, DNS-SD, FTP, HTTP, ICMP, IGMP, mDNS, POP3, PPP, PPPoE, RARP, TFTP, SNTP, SMTP, SNMP, and Telnet. IoT Cloud protocol support includes

Das U-Boot

transfer) Kermit S-Record YMODEM Network boot (optionally using DHCP, BOOTP, or RARP) TFTP NFS On some embedded device implementations, the CPU or SoC will locate