Dynamic RARP Extensions for Automatic Network Address Acquisition
RFC 1931
Document | Type |
RFC - Informational
(April 1996; No errata)
Was draft-rfced-info-sun (individual)
|
|
---|---|---|---|
Author | David Brownell | ||
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 1931 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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, toShow full document text