A Reverse Address Resolution Protocol
also
- std-38
Extracted elements (15)
RARP defines no 'not found' or error reply packets because many RARP servers may be present and any is free to respond. The client detects failure via timeout rather than an explicit negative response.
RARP deliberately reuses the ARP packet format to enable code sharing with existing ARP implementations, minimizing development overhead and avoiding modifications to hosts that do not participate in RARP.
RARP is specified as a separate protocol at the data-link level with its own Ethertype, rather than piggybacking on ARP, because ARP and RARP are fundamentally different operations not supported equally by all hosts. This prevents existing ARP servers from being confused by RARP packets and makes RARP a general hardware-to-protocol address mapping facility.
The RARP server database is intentionally maintained outside the operating system kernel, because maintaining such large databases inside the kernel is undesirable or impossible on many hosts. Implementations require out-of-kernel interaction (e.g., a user-space daemon).
The requirement that ar$spa be filled with the responder's protocol address in opcode 4 replies is purely for convenience: it provides a valid (hardware, protocol) pair that may allow the requester to skip a subsequent forward ARP lookup for the server.
Unlike ARP, where all hosts are peers maintaining small local caches, RARP requires dedicated server hosts to maintain a full database mapping hardware addresses to protocol addresses. This client/server asymmetry is a core design distinction from ARP.
Because RARP is assigned a distinct Ethertype separate from ARP, existing ARP server implementations will not receive or be confused by RARP packets, requiring no changes to ARP hosts that do not implement RARP.
RARP packets with opcodes 1 or 2 carry the same semantics as in ARP and may be passed directly to existing ARP processing code, preserving backward compatibility.
The sender of a RARP request packet should timeout if it does not receive a reply within a reasonable amount of time, since there are no negative-acknowledgement or error packets defined.
For Ethernet-to-IP resolution, the fixed field values are: ar$hrd=1 (Ethernet), ar$pro=2048 decimal (IP Ethertype), ar$hln=6 (48-bit Ethernet address), ar$pln=4 (32-bit Internet address).
In a RARP reply (opcode 4): ar$sha is the responder's hardware address, ar$spa is the responder's protocol address, ar$tha is the target hardware address (echoed from the request), and ar$tpa is the resolved protocol address of the target.
In a RARP request (opcode 3): ar$sha contains the sender's hardware address; ar$tha contains the target hardware address (equal to ar$sha when a host seeks its own protocol address); ar$spa and ar$tpa are undefined.
RARP defines two new opcodes: 3 ('request reverse') and 4 ('reply reverse'). Opcodes 1 and 2 retain their ARP meanings; any other opcode is undefined.
RFC 903 defines no authentication or authorization mechanism for RARP. Any host on the broadcast medium may respond to a RARP request with an arbitrary protocol address, making the protocol inherently vulnerable to spoofing by a malicious or misconfigured server on the same network segment.
RARP reuses the ARP packet format verbatim: ar$hrd (16 bits), ar$pro (16 bits), ar$hln (8 bits), ar$pln (8 bits), ar$op (16 bits), ar$sha (n bytes), ar$spa (m bytes), ar$tha (n bytes), ar$tpa (m bytes), where n and m are given by ar$hln and ar$pln respectively.