GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1931

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-
           ferent network segment than expected; users will be able to
           remedy the problem by connecting the system to the correct
           network segment.
      DRARPERR_FAILURE (5)
           For some reason, no address could be returned.  No defined
           status code known to the server explained the reason.
 More opcodes for the Address Resolution Protocol (ARP) family could
 be defined in the future, so unrecognized opcodes (and error codes)
 should be ignored rather than treated as errors.

2.3 Protocol Exchanges

 This section describes typical protocol exchanges using RARP and
 Dynamic RARP, and common fault modes of each exchange.

2.3.1. RARP Address Lookup

 To determine a previously published ("persistent") protocol address
 for itself or another system, a system may issue a REVARP_REQUEST
 packet.  If a REVARP_REPLY packet arrives in response, then the
 target protocol address listed there should be used.

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

 If no REVARP_REPLY response packet arrives within some time interval,
 a number of errors may have occurred.  The simplest one is that the
 request or reply packet may never have arrived:  most RARP client
 implementations retransmit requests to partially account for this
 error.  There is no clear point at which to stop retransmitting a
 request, so many implementations apply an exponential backoff to the
 retransmit interval, to reduce what is typically broadcast traffic.
 Otherwise there are many different errors which all have the same
 failure mode, including: the system might not have a published
 protocol address; it might be on the wrong network segment, so its
 published address is invalid; the RARP servers which can supply the
 published address may be unavailable; it might even be on a network
 without any RARP servers at all.

2.3.2 Dynamic RARP Address Lookup

 Dynamic RARP may be used to determine previously published protocol
 addresses by clients who issue DRARP_REQUEST packets.  If the client
 has a published protocol address on the network segment on which the
 DRARP_REQUEST packet was issued, it is returned in a REVARP_REPLY
 packet.
 If the client has a published protocol address only on some other
 network segment, then two basic responses are possible.  In the case
 where dynamic address reallocation is enabled, a temporary protocol
 address may be allocated and returned in a DRARP_REPLY packet.
 Otherwise if dynamic address reallocation is disabled, a DRARP_ERROR
 packet is returned with the status DRARPERR_MOVED.  Detection of host
 movement can be provided only with link level addresses that are
 unique over the catenet, such as are provided with IEEE 802 48 bit
 addresses.  Without such uniqueness guarantees, this case looks like
 a request for a new address as described in the next section.

2.3.3 Dynamic RARP Address Allocation

 Dynamic RARP clients who issue DRARP_REQUEST packets may acquire
 newly allocated protocol addresses.  If the client has no published
 protocol address, there are three responses:
 (a)  When dynamic address allocation is enabled, a temporary protocol
      address is allocated and returned in a DRARP_REPLY packet.
 (b)  Errors or delays in the allocation process (with dynamic address
      allocation enabled) are reported in DRARP_ERROR packets with
      error codes such as DRARPERR_SERVERDOWN, DRARPERR_NOADDRESSES,
      DRARPERR_MOVED, or even DRARPERR_FAILURE.

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

 (c)  When dynamic address allocation is disabled (or "restricted"), a
      DRARP_ERROR packet with status DRARPERR_RESTRICTED is returned.
      DRARP_REQUESTS are normally retransmitted until an address is
      returned, using backoff-style algorithms to minimize needless
      network traffic.  When DRARP_ERROR responses are received, they
      should be reported to the user.  For example, knowing that the
      server is busy could indicate it's time for a cup of Java, but
      if the network is restricted then it might be time to contact a
      network administrator for help instead.

2.3.4 Discovering Other DRARP Servers

      The existence of a DRARP server can be discovered by the fact
      that it puts its addressing information in all DRARP_REPLY
      packets that it sends.  DRARP servers can listen for such
      packets, as well as announcing themselves by sending such a
      packet to themselves.
      It can be important to discover other DRARP servers.  Users make
      mistakes, and can inappropriately set up DRARP servers that do
      not coordinate their address allocation with that done by the
      other DRARP servers on their network segment.  That causes
      significant administrative problems, which can all but be
      eliminated by DRARP servers which politely announce themselves,
      and when they detect an apparently spurious server, report this
      fact before entering a "restricted" mode to avoid creating any
      problems themselves.
      As no further server-to-server protocol is defined here, some
      out-of-band mechanism, such as communication through the address
      authority, must be used to help determine which servers are in
      fact spurious.

2.4 Network Setup Concerns

      Some internetwork environments connect multiple network segments
      using link level bridges or routers.  In such environments, a
      given broadcast accessible "local" area network will have two
      problems worth noting.
      First, it will extend over several cable segments, and be
      subject to partitioning faults.  Assigning one DRARP server to
      each segment (perhaps on systems acting as routers or bridges,
      to serve multiple segments) can reduce the cost of such faults.
      Assigning more than one such server can help reduce the cost of
      failure to any single network segment; these cooperate in the
      assignment of addresses through the address authority.

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

      Second, those networks are sometimes shared by organizations
      which don't cooperate much on the management of protocol
      addresses, or perhaps aren't even collocated.  A DRARP server
      might need help from link level bridges/routers in order to
      ensure that local clients are tied to local servers (rather
      than, for example, to servers across the country where they are
      prone to availability problems).  Or the server might need to
      run in "restricted" mode so that a network administrator
      manually assigns address and other resources to each system.

3. The Address Authority

      While not part of the DRARP protocol, the Address Authority used
      by the DRARP servers on a network segment is critical to
      providing the address allocation functionality.  It manages the
      data needed to implement such service, which is required not
      just for dynamic address allocation tools.  This section is
      provided to record one set of requirements for such an
      authority, ignoring implementation isssues such as whether
      protocol support for replication or partitioning is needed.

3.1 Basic Requirements

      For each network segment under its control, an Address Authority
      maintains at least:
  1. persistent bindings between hardware and protocol addresses

(for at least those hosts which are DRARP clients);

  1. temporary bindings between such addresses;
  1. protocol addresses available for temporary bindings;
 The Address Authority is also responsible for presenting and managing
 those bindings.  DRARP clients need it to support:
  1. creating temporary bindings initially,
  1. looking up bindings (the distinction between temporary and

persistent bindings is not usually significant here),

  1. deleting temporary or persistent bindings on request,
  1. purging them automatically by noticing that a binding is

now persistent or that the temporary address is available

           for reuse.

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

 Those clients will frequently make concurrent requests, and should be
 required to pass some kind of authorization check before they create
 or change any bindings.  They may also need to know about other
 clients, in order to determine (for example) if a given DRARP server
 is spurious.

3.2 Multiple Authorities and Segments

 Note there is only a single address authority on a given network
 segment.  It may be desirable to partition that authority, though
 that complicates implementation and administration of the authority
 substantially.
 If detection of systems moving between network segments is to be
 provided, then the authorities for those two network segments must
 either be the same or (equivalently) must communicate with one
 another.  Also, as noted earlier, hardware addresses must be scoped
 widely enough that the two segments do not assign the same link level
 address to different hosts.

3.3 Quality of Service

 The records of temporary address bindings must be persistent for at
 least long enough to install a system and propagate its records
 through the site's administrative databases, even in the case of
 server or network faults.  A timeout mechanism could be used to
 ensure that the limited address space was not used up too quickly.
 The initial implementation found that an hour's worth of caching,
 before deleting temporary bindings, was sufficient.
 Experience has shown that many networks have addresses in use which
 are not listed in their name services (or other administrative
 databases).  On such networks, the Address Authority should have a
 way to learn when an address which it thinks is available for
 allocation is instead being actively used.  Probing the network for
 "the truth" before handing out what turns out to be a duplicate IP
 address is a worthwhile.  Both ARPing for the address and ICMP echo
 request have been used for this.

4. Security Considerations

 Security concerns are not addressed in this memo.  They are
 recognized as significant, but they also interact with site-specific
 network administration policies.  Those policies need to be addressed
 at higher levels before ramifications at this level can be
 understood.

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

5. References

 [1]  Plummer, D., "An Ethernet Address Resolution Protocol", STD 37,
      RFC 826, MIT, November 1982.
 [2]  Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
      Address Resolution Protocol", STD 38, RFC 903, Stanford, June
      1984.
 [3]  Finlayson, R., "Bootstrap Loading using TFTP", RFC 906,
      Stanford, June 1984.
 [4]  Postel, J., "Multi-LAN Address Resolution", RFC 925,
      USC/Information Sciences Institute, October 1984.
 [5]  Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
      13, RFC 1034, USC/Information Sciences Institute, November 1987.
 [6]  Postel, J., and J. Reynolds, "A Standard for the Transmission of
      IP Datagrams over IEEE802 Networks", STD 43, RFC 1042,
      USC/Information Sciences Institute, February 1988.
 [7]  IEEE; "IEEE Standards for Local Area Networks:  Logical Link
      Control" (IEEE 802.2); IEEE, New York, NY; 1985.
 [8]  United States Patent No. 4,689,786; "Local Area Network with
      Self Assigned Address Method"; Issued August 25, 1987;
      Inventors:  Sidhu, et al.; Assignee:  Apple Computer, Inc.
 [9]  Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
      Bucknell University, October 1993.
 [10] Srinivasan, R., "RPC:  Remote Procedure Call Protocol
      Specification, Version 2", RFC 1831, Sun Microsystems, August
      1995.

Author's Address:

 David Brownell
 SunSoft, Inc
 2550 Garcia Way, MS 19-215
 Mountain View, CA  94043
 Phone:  +1-415-336-1615
 EMail:  dbrownell@sun.com

Brownell Informational [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1931.txt · Last modified: 1996/04/01 20:51 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki