Dynamic RARP Extensions for Automatic Network Address Acquisition
RFC 1931

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

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                      [Page 1]
RFC 1931                      Dynamic RARP                    April 1996

   which extended BOOTP.

   The "hands-off" installation of all kinds of systems (including
   diskless workstations, and servers) was required, as supported by
   LocalTalk networks [8].  However, Internet administrative models are
   not set up to allow that: there is no way to set up a completely
   functional IP network by just plugging machines into a cable and
   powering them up.  That procedure doesn't have a way to input the
   network number (and class) that must be used, or to bootstrap the
   host naming system.  An approach based on administered servers was
   needed for IP-based "Intranet" systems, even though that
   unfortunately called for networks to be initially set up by
   knowledgeable staff before any "hands-off" installations could be
   performed.

1.2  System Overview

   DRARP was used by systems in the first phase of joining a network, to
   acquire a network address without personal intervention by a network
   administrator.  Once a system was given a network address, it would
   perform whatever network operations it desired, subject to a site's
   access control policies.  During system installation, those network
   operations involved a (re)configuration protocol ("Plug'n'Play", or
   PNP).  Diskless sytems used TFTP to download code which could speak
   the PNP protocol.

   The PNP protocol would register the names of newly installed hosts in
   the naming service, using the address which was acquired using DRARP.
   These names could be chosen by users installing the system, but could
   also be assigned automatically.  Diskless systems used the PNP
   protocol to assign booting resources (e.g. filesystem space) on
   servers.  All systems were assigned public and private keys, also
   initial (quasi-secret) "root" passwords, so that they could use what
   was then the strongest available ONC RPC authentication system.

   Servers for DRARP and for the configuration protocol (as well as
   other administrative tools) needed to consult an authoritative
   database of which Internet addresses which were allocated to which
   hosts (as identified by hardware addresses).  This "address
   authority" role was implemented using a name service (NIS) and an
   RPC-based centralized IP address allocation protocol ("IPalloc").
   Address allocation could be performed only by authorized users,
   including network administrators and DRARP servers.

   Most systems used DRARP and PNP each time they started, to