RFC 1931 (rfc1931) - Page 1 of 11

Dynamic RARP Extensions for Automatic Network Address Acquisition

Alternative Format: Original Text Document
Next >
Network Working Group                                        D. Brownell
Request For Comments: 1931                        Sun Microsystems, Inc.
Category: Informational                                       April 1996


                      Dynamic RARP Extensions for
                 Automatic Network Address Acquisition

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not define an Internet standard of any kind.  Distribution of
   this memo is unlimited.

1.  Introduction

   This memo describes extensions to the Reverse Address Resolution
   Protocol (RARP [2]) and called Dynamic RARP (DRARP, pronounced D-
   RARP).  The role of DRARP, and to some extent the configuration
   protocol used in conjunction with it, has subsequently been addressed
   by the DHCP protocol [9].  This memo is being published now to
   document this protocol for the record.

   DRARP is used to acquire (or allocate) a protocol level address given
   the fixed hardware address for a host.  Its clients are systems being
   installed or reconfigured, and its servers are integrated with other
   network administration services.  The protocol, along with adjunct
   protocols as briefly described here, supports several common styles
   of "Intranet" administration including networks which choose not to
   support the simplified installation and reconfiguration features
   enabled by DRARP.

   The rest of this introductory section summarizes the system design of
   which the DRARP protocol was a key part.  The second section presents
   the DRARP protocol, and the third section discusses requirements
   noted for an "Address Authority" managing addresses in conjunction
   with one or more cooperating DRARP servers.

1.1  Automatic System Installation

   Dynamic RARP was used by certain Sun Microsystems platforms beginning
   in 1988.  (These platforms are no longer sold by Sun.) In conjunction
   with other administrative protocols, as summarized in the next
   subsection, it was part of a simplified network and domain
   administration framework for SunOS 4.0.  Accordingly, there was a
   product requirement to extend (rather than replace) the RARP/TFTP two
   phase booting model [3], in order to leverage the existing system
   infrastructure.  This is in contrast to the subsequent DHCP [9] work,



Brownell                     Informational
Next >