Reverse Address Resolution Protocol is a legacy network protocol that helps a device discover its own IP address when it already knows its hardware address. It maps a MAC address to an IP address on the local network, a function later replaced by more flexible protocols such as BOOTP and DHCP.
What RARP Does
Reverse Address Resolution Protocol was a legacy way for a device to learn its own IP address from a local network after it already knew its hardware, or MAC, address. It solved a bootstrapping problem that later became the job of more flexible address assignment protocols.
RARP sits in the early history of network identity on a LAN: the device presents a link-layer identifier, and the network returns an IP mapping. That makes it useful for understanding how address configuration evolved, but it also explains why it disappeared from modern deployments once BOOTP and DHCP took over the role.
Why RARP Mattered in Early Networks
RARP was important when diskless workstations and similar hosts needed a way to start networking before they had a full local configuration. The protocol depended on a trusted local broadcast environment and on a server that knew the mapping between hardware and network addresses.
Because it only worked on the local segment, RARP was tightly bound to a simple LAN model. That constraint made it easy to understand, but it also limited scalability, flexibility, and centralized configuration compared with later address-assignment systems.
How RARP Worked on the Wire
The device that needed an address sent a request using its MAC address, and a RARP server replied with the IP address associated with that hardware address. The exchange was narrow in scope and purpose, with no broader lease negotiation, option handling, or richer bootstrapping support.
That simplicity is why RARP is often described as a mapping protocol rather than a full configuration service. It answered one question only, “what is my IP address?”, and left most other startup settings to other mechanisms or to later protocols.
Why RARP Was Replaced
RARP was eventually displaced because networks needed more than a one-to-one address lookup. BOOTP and then DHCP added centralized configuration, more deployment flexibility, and support for richer host initialization tasks.
For modern readers, the main value of RARP is conceptual: it shows the origin of automated address assignment and highlights the difference between a minimal mapping service and a full dynamic configuration protocol. In practice, contemporary environments rely on DHCP-style services and treat RARP as a historical protocol.
Risk and Threat Considerations
RARP’s security value today is mostly historical, but the design pattern it represents is still instructive: a host that trusts local network responses to learn critical configuration can be exposed if the local segment is hostile or poorly controlled. The limited scope of the protocol also means there is little built-in resilience if the address-mapping source is unavailable or manipulated.
Failure mechanism: A device can receive the wrong IP configuration, fail to boot into the expected network identity, or be forced to rely on an incorrect mapping if the local environment is not trusted.
Impact: Misaddressing can lead to loss of connectivity, traffic misdelivery, service disruption, or unintended exposure if a host comes up on the wrong segment or under the wrong address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | RARP shows why minimal legacy services should be removed from modern networks. |
| SC-7 — Boundary Protection | RARP depends on local-segment trust, which boundary controls help constrain. | |
| IA-3 — Device Identification and Authentication | RARP maps a hardware address to an IP identity, linking directly to device identity concerns. | |
| Recommendation — Remove legacy address-assignment protocols and retain only the network services that are required. Segment networks so local broadcast-based configuration cannot be abused outside the intended scope. Bind device identity to controlled network enrollment rather than relying on unauthenticated address discovery. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | Modern address configuration depends on governed identity and access relationships, unlike legacy RARP. |
| Recommendation — Use governed configuration services and maintain authoritative records for network-joined devices. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Legacy bootstrap protocols like RARP are part of secure configuration hygiene. |
| Recommendation — Eliminate obsolete network services and standardize host configuration through approved management paths. | ||
Practitioner Guidance
Common misunderstanding: RARP is not a modern operational control for address management. If you encounter it in documentation, legacy firmware, or lab material, treat it as a sign that the environment is using an outdated bootstrap model rather than a current network design.
Practitioner note: For real deployments, the important decision is not whether to preserve RARP, but whether the network uses a contemporary address-assignment mechanism, has authoritative configuration sources, and can be monitored for unexpected legacy dependencies.