Browse Prior Art Database

Reverse Address Resolution Protocol (RFC0903)

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

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Finlayson: AUTHOR [+4]

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 30% 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.

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