RFC 903 (rfc903) - Page 1 of 4
Reverse Address Resolution Protocol
Alternative Format: Original Text Document
Network Working Group Finlayson, Mann, Mogul, Theimer
Request for Comments: 903 Stanford University
June 1984
A Reverse Address Resolution Protocol
Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer
Computer Science Department
Stanford University
June 1984
Status of this Memo
This RFC suggests a method for workstations to dynamically find their
protocol address (e.g., their Internet Address), when they know only
their hardware address (e.g., their attached physical network
address).
This RFC specifies a proposed protocol for the ARPA Internet
community, and requests discussion and suggestions for improvements.
I. Introduction
Network hosts such as diskless workstations frequently do not know
their protocol addresses when booted; they often know only their
hardware interface addresses. To communicate using higher-level
protocols like IP, they must discover their protocol address from
some external source. Our problem is that there is no standard
mechanism for doing so.
Plummer's "Address Resolution Protocol" (ARP) [1] is designed to
solve a complementary problem, resolving a host's hardware address
given its protocol address. This RFC proposes a "Reverse Address
Resolution Protocol" (RARP). As with ARP, we assume a broadcast
medium, such as Ethernet.
II. Design Considerations
The following considerations guided our design of the RARP protocol.
A. ARP and RARP are different operations. ARP assumes that every
host knows the mapping between its own hardware address and protocol
address(es). Information gathered about other hosts is accumulated
in a small cache. All hosts are equal in status; there is no
distinction between clients and servers.
On the other hand, RARP requires one or more server hosts to maintain
a database of mappings from hardware address to protocol address and
respond to requests from client hosts.
Finlayson, Mann, Mogul, Theimer