rfc1931.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 620 行 · 第 1/2 页

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
   automatically reconfigure applicable system and network policies.
   For example, network addresses and numbers were changed using these
   protocols; host names changed less often.  The naming service (NIS)



Brownell                     Informational                      [Page 2]

RFC 1931                      Dynamic RARP                    April 1996


   held most information, such as the locations of printers and users'
   home directories.

2.  Dynamic RARP Extensions

   Dynamic RARP (DRARP) service is provided by any of a small active set
   of cooperating server systems on a network segment (network or
   subnetwork).  Those servers are contacted through link level
   procedures, normally a packet broadcast.  One or more servers may
   respond to a given request.  It was intended that network segments
   will be administered together in domains [5] consisting of one or
   more network segments.  Domains sharing a network segment need to
   share information about network addresses, both hardware level and
   protocol level, so an address authority (see section 3) can avoid
   reallocating protocol addresses which are already allocated or in
   use.

   Dynamic RARP benefits from link layer addresses which are scoped more
   widely than just the local network segment.  It takes advantage of
   such scoping to detect hosts which move between network segments.
   Such scoping is provided by IEEE 802 48-bit addresses [7], but not by
   all other kinds of network address.  Without such a widely scoped ID,
   the case of systems roaming between networks can't be detected by
   Dynamic RARP.

2.1  Mixing RARP and DRARP Servers

   DRARP is an extension to RARP, so that all Dynamic RARP servers are
   also RARP servers.  However, DRARP provides a more manageable service
   model than RARP does:  while RARP allows multiple servers to respond
   to RARP requests, it does not expect all those servers to be able to
   respond, or to respond identically.  A given RARP server can not be
   relied upon to know whether a given link level address can be mapped
   into a protocol address, and some other RARP server may have a
   different answer.

   Dynamic RARP addresses this problem by requiring that all Dynamic
   RARP servers on a network segment must communicate with the same
   address authority.  That address authority controls name and address
   bindings, records bindings between host identifiers and addresses,
   makes decisions about how to allocate addresses, and keeps records
   about addresses in use.

   This means that in effect there may be a number of independent RARP
   services offered along with a single DRARP service.  DRARP service
   may well be offered through multiple servers, and the persistent
   address bindings it serves will be accessible as from a set of
   coordinated RARP servers.



Brownell                     Informational                      [Page 3]

RFC 1931                      Dynamic RARP                    April 1996


   Not all networks want to support dynamic address allocation services.
   Even those that do support it will need control over implementation
   of the address authority.  So DRARP servers need policy controls such
   as "restricting" them from assigning addresses (applied to an entire
   network segment) as well as disabling use of DRARP entirely.  (One
   may need to disable servers that would otherwise allocate new
   addresses, in order to enable ones which can speak to the "correct"
   address authority.  Standards do not exist for protocols and security
   options used to talk to address authorities.)

2.2  Packet Format

   The packet format is identical to RARP and is encapsulated using RARP
   frames, with the same Ethernet/SNAP type field.  [1, 2, 6].  That is,
   a DRARP packet looks like a RARP packet, but it uses opcodes which
   are ignored by RARP servers; DRARP servers must also support RARP
   requests, and hence ARP requests [1].

2.2.1  RARP Packets

   The two RARP opcodes are described here, in order to clarify the
   overall presentation.  The name "REVARP", used in the opcode
   descriptions, is a synonym for "RARP".

   REVARP_REQUEST (3)
        REVARP_REQUEST packets are sent to RARP servers as a request to
        map the target hardware address (tha) into the corresponding
        target protocol address (tpa), sending the response to the
        source hardware address (sha) as encoded in the packet.  The
        source hardware address will usually be the same as the target
        hardware address, that of the system sending the packet.  RARP
        servers will consult their name and address databases, and
        return a REVARP_REPLY packet if they can perform the reverse
        address resolution as requested.

   REVARP_REPLY (4)
        This packet is sent by RARP servers in response to
        REVARP_REQUEST packets.  The target protocol address (tpa) is
        filled in as requested, and the source hardware and protocol
        addresses (sha, spa) correspond to the RARP server.  The target
        hardware address (tha) is from the corresponding REVARP_REQUEST
        packet, and the packet is sent to the source hardware address
        (sha) from that packet.

        This packet is also sent by Dynamic RARP servers in response to
        DRARP_REQUEST packets, if the protocol address returned was not
        a temporary one, but was instead what it would have returned
        given an otherwise identical REVARP_REQUEST packet.



Brownell                     Informational                      [Page 4]

RFC 1931                      Dynamic RARP                    April 1996


2.2.2  Dynamic RARP Packets

        There are three opcodes defined for DRARP, in addition to the
        two already defined for RARP:

   DRARP_REQUEST (5)
        DRARP_REQUEST packets have the same format as REVARP_REQUEST
        packets, except for the operation code.  The semantics are simi-
        lar, except that in cases where a REVARP_REQUEST would produce
        no REVARP_REPLY (no persistent address mapping is stored in an
        addressing database) a DRARP_REQUEST will normally return a tem-
        porary address allocation in a DRARP_REPLY packet.  A
        DRARP_ERROR packet may also be returned; a Dynamic RARP server
        will always provide a response, unlike a REVARP server.

   DRARP_REPLY (6)
        DRARP_REPLY packets have the same format, opcode excepted, as
        REVARP_REPLY packets.  The interpretation of the fields is the
        same.

        There are semantic differences between the two packet types.
        First, the protocol address bindings returned in DRARP_REPLY
        packets are temporary ones, which will be recycled after some
        period (e.g. an hour).  Those bindings returned in REVARP_REPLY
        packets are "persistent" addresses which typically change much
        more slowly.  Second, it is explicitly a protocol error for
        DRARP_REPLY packets to be sent which differ except in the sender
        address fields.  Also, DRARP_REPLY packets are generated only in
        response to DRARP_REQUEST packets.

        These temporary addresses may be reallocated to another system
        after some time period.  A configuration protocol is normally
        used to ensure that reallocation does not occur.

   DRARP_ERROR (7)
        DRARP_ERROR packets may also be sent in response to
        DRARP_REQUESTs.  The format is identical to REVARP_REPLY, except
        for the opcode and that the target protocol address (tpa) field
        is replaced by an error code field.  The error code field must
        be at least one byte long, and the first byte is used to encode
        an error status describing why no target protocol address (tpa)
        is being returned.  The status values are:

        DRARPERR_RESTRICTED (1)
             This network does not support dynamic address allocation.
             The response is definitive; the network is controlled so
             that no other DRARP_REPLY (for this hardware address) is
             legal until the network policy on dynamic address



Brownell                     Informational                      [Page 5]

RFC 1931                      Dynamic RARP                    April 1996


             allocation is changed, or until the client is otherwise
             assigned a persistent address binding.  A REVARP_REQUEST
             might yield a REVARP_REPLY, however; non-cooperating RARP
             servers could be the very reason that dynamic address allo-
             cation was disabled.

        DRARPERR_NOADDRESSES (2)
             This network supports dynamic address allocation, but all
             available protocol addresses in the local segment are in
             use, so none can be allocated now.

        DRARPERR_SERVERDOWN (3)
             The service providing access to the address authority is
             temporarily unavailable.  May also be returned if an
             address allocation was required and the required response
             took a "long time" to generate; this distinguishes the case
             of a network that didn't support DRARP from the case of one
             that does, but is slow.

        DRARPERR_MOVED (4)
             Analogous to the DRARPERR_RESTRICTED status in that no
             address was dynamically allocated.  This provides the addi-
             tional status that this client was recognized by the
             administration software for the domain as being on a dif-