A Reverse Address Resolution Protocol
RFC 903
Document | Type |
RFC - Internet Standard
(June 1984; No errata)
Also known as STD 38
|
|
---|---|---|---|
Authors | |||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 903 (Internet Standard) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 [Page 1]
RFC 903 June 1984
B. As mentioned, RARP requires that server hosts maintain large
databases. It is undesirable and in some cases impossible to maintain
such a database in the kernel of a host's operating system. Thus,
most implementations will require some form of interaction with a
program outside the kernel.
C. Ease of implementation and minimal impact on existing host
software are important. It would be a mistake to design a protocol
that required modifications to every host's software, whether or not
it intended to participate.
D. It is desirable to allow for the possibility of sharing code with
existing software, to minimize overhead and development costs.
III. The Proposed Protocol
We propose that RARP be specified as a separate protocol at the
data-link level. For example, if the medium used is Ethernet, then
RARP packets will have an Ethertype (still to be assigned) different
from that of ARP. This recognizes that ARP and RARP are two
fundamentally different operations, not supported equally by all
hosts. The impact on existing systems is minimized; existing ARP
servers will not be confused by RARP packets. It makes RARP a general
facility that can be used for mapping hardware addresses to any
higher level protocol address.
This approach provides the simplest implementation for RARP client
hosts, but also provides the most difficulties for RARP server hosts.
However, these difficulties should not be insurmountable, as is shown
in Appendix A, where we sketch two possible implementations for
4.2BSD Unix.
RARP uses the same packet format that is used by ARP, namely:
ar$hrd (hardware address space) - 16 bits
ar$pro (protocol address space) - 16 bits
ar$hln (hardware address length) - 8 bits
ar$pln (protocol address length) - 8 bits
ar$op (opcode) - 16 bits
ar$sha (source hardware address) - n bytes,
where n is from the ar$hln field.
ar$spa (source protocol address) - m bytes,
where m is from the ar$pln field.
ar$tha (target hardware address) - n bytes
ar$tpa (target protocol address) - m bytes
ar$hrd, ar$pro, ar$hln and ar$pln are the same as in regular ARP
(see [1]).
Finlayson, Mann, Mogul, Theimer [Page 2]
RFC 903 June 1984
Suppose, for example, that 'hardware' addresses are 48-bit Ethernet
addresses, and 'protocol' addresses are 32-bit Internet Addresses.
That is, we wish to determine Internet Addresses corresponding to
Show full document text