Browse Prior Art Database

A Reverse Address Resolution Protocol (RFC0903)

IP.com Disclosure Number: IPCOM000003953D
Original Publication Date: 1984-Jun-01
Included in the Prior Art Database: 2019-Feb-13
Document File: 4 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Finlayson: AUTHOR [+3]

Related Documents

10.17487/RFC0903: DOI

Abstract

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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 37% of the total text.

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...

Processing...
Loading...