RFC 1931

Dynamic RARP Extensions for Automatic Network Address Acquisition

📅 published April 1996, from ietf

RFC 1931: Dynamic RARP Extensions for Automatic Network Address Acquisition 💖

  • Request For Comments: 1931
  • Network Working Group 🎀
  • Author: D. Brownell, Sun Microsystems, Inc. 🧚
  • Category: Informational
  • Date: April 1996
  • Obsoletes / Updates: Nothing is listed. This document doesn't obsolete or update any other RFC.

Status of This Memo

okay bestie, first things first 🫶 this memo is just information for the Internet community. It does not define an Internet standard of any kind 🙅‍♀️ and distribution of it is unlimited ✨

1. Introduction ✨

so this doc is about extensions to the Reverse Address Resolution Protocol (RARP [2]). the glow-up is called Dynamic RARP (DRARP, pronounced D-RARP) 🦋 DRARP's whole job got taken over later by the DHCP protocol [9], so this memo is getting published now just to write it down for the record 📜

DRARP is how a host gets a protocol level address when all you have is its fixed hardware address 💅 The clients are systems that are being installed or reconfigured, and the servers are plugged into other network administration services. This protocol, along with its adjunct protocols, supports several common styles of "Intranet" administration 🌸 including networks that choose not to use the simplified installation and reconfiguration features DRARP enables.

the rest of this intro gives you the big-picture system design that DRARP was a key part of 👑 Section 2 covers the DRARP protocol itself, and Section 3 talks about the requirements for an "Address Authority" that manages addresses alongside one or more cooperating DRARP servers 🎀

1.1. Automatic System Installation

DRARP was used by certain Sun Microsystems platforms starting in 1988. (Those platforms aren't sold by Sun anymore, btw 😭) Together with other administrative protocols, which we'll recap in the next subsection, it was part of a simplified network and domain administration framework for SunOS 4.0 🍓 So there was a product requirement to extend the RARP/TFTP two phase booting model [3] instead of replacing it, so everything already in the system infrastructure could be reused 🔥 Later on, DHCP [9] came along and extended BOOTP instead, which is the contrast 🧚

The "hands-off" installation of all kinds of systems (diskless workstations and servers included) was REQUIRED, as supported by LocalTalk networks [8]. Here's the tea though: Internet administrative models aren't set up to allow that 😭 There's no way to get a fully working IP network by just plugging machines into a cable and powering them up. That procedure has no way to input the network number (and class) that MUST be used, and no way to bootstrap the host naming system either 💀 So for IP-based "Intranet" systems, an approach based on administered servers was needed, even though that unfortunately meant knowledgeable staff had to set up the networks first before any "hands-off" installations could happen 🙈

1.2. System Overview

DRARP was used by systems in the first phase of joining a network. Its job was to get a network address without a network administrator having to personally step in 🦋 Once a system had a network address, it could do whatever network operations it wanted, as long as it followed the site's access control policies. During system installation, those operations involved a (re)configuration protocol, which was called "Plug'n'Play", or PNP ✨ Diskless systems used TFTP to download code that could speak the PNP protocol 💖

The PNP protocol registered the names of newly installed hosts in the naming service, using the address that DRARP had acquired. The people installing the system could pick the names themselves, or the names could be assigned automatically 🎀 Diskless systems also used PNP to assign booting resources (e.g. filesystem space) on servers 🧚 Every system was assigned public and private keys, plus initial (quasi-secret) "root" passwords, so they could use what was then the strongest available ONC RPC authentication system 🔐

The servers for DRARP and for the configuration protocol (plus other administrative tools) needed to check an authoritative database of which Internet addresses were allocated to which hosts, identified by their hardware addresses 📒 This "address authority" role was implemented with a name service (NIS) and an RPC-based centralized IP address allocation protocol called "IPalloc" 🌈 Only authorized users could perform address allocation, and that included network administrators and DRARP servers 👑

Most systems used DRARP and PNP every time they started up, so applicable system and network policies got automatically reconfigured 🔄 For example, network addresses and numbers changed using these protocols, while host names changed less often 🍓 The naming service (NIS) held most of the info, like where the printers were and where users' home directories lived 🏠

2. Dynamic RARP Extensions 🦋

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

DRARP benefits from link layer addresses that are scoped more widely than just the local network segment ✨ It takes advantage of that scoping to detect hosts that move between network segments 🧚 That kind of 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, DRARP can't detect the case of systems roaming between networks 😭

2.1. Mixing RARP and DRARP Servers

DRARP is an extension to RARP, so every Dynamic RARP server is also a RARP server 💜 That said, DRARP gives you a more manageable service model than RARP does 🍓 RARP lets multiple servers respond to RARP requests, but it doesn't expect all of 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 might have a different answer 💀

DRARP fixes 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 of which addresses are in use 📒

So in effect, there may be a number of independent RARP services offered alongside a single DRARP service 🌈 DRARP service may well be offered through multiple servers, and the persistent address bindings it serves will be accessible as if from a set of coordinated RARP servers 👑

Not every network wants to support dynamic address allocation services 🙅‍♀️ Even the ones that do will need control over how the address authority gets implemented 🎀 So DRARP servers need policy controls, like "restricting" them from assigning addresses (applied to an entire network segment), as well as disabling DRARP entirely ✨ (One may need to disable servers that would otherwise allocate new addresses, so that ones able to talk to the "correct" address authority can be enabled. Standards do not exist for the 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]. So a DRARP packet looks like a RARP packet, but it uses opcodes that RARP servers ignore 🦋 DRARP servers MUST also support RARP requests, and hence ARP requests [1] 💅

2.2.1. RARP Packets

Here we're going over the two RARP opcodes, just so the rest of the presentation makes sense 🧚 The name "REVARP", used in the opcode descriptions, is just 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). The response goes back 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, which is the address of the system sending the packet 🌸 RARP servers check their name and address databases, and they send back a REVARP_REPLY packet if they can do 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) gets filled in as requested, and the source hardware and protocol addresses (sha, spa) match the RARP server. The target hardware address (tha) comes 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, but only if the protocol address returned was not a temporary one. It has to be the address that would have been returned for an otherwise identical REVARP_REQUEST packet 👑🦋

2.2.2. Dynamic RARP Packets 💖

okay so DRARP adds three new opcodes on top of the two RARP already has 🦋 here's the lineup:

  • DRARP_REQUEST (5): these packets have the same format as REVARP_REQUEST packets, just with a different operation code. The vibe is similar, except when a REVARP_REQUEST would get no REVARP_REPLY (because there's no persistent address mapping stored in an addressing database), a DRARP_REQUEST will usually get a temporary address allocation in a DRARP_REPLY packet ✨. A DRARP_ERROR packet can also come back, and a Dynamic RARP server will always respond, unlike a REVARP server 🫶
  • DRARP_REPLY (6): same format as REVARP_REPLY, opcode excepted, and the fields are interpreted the same way 💅. The big differences are these: first, the protocol address bindings in a DRARP_REPLY are temporary, and they get recycled after some period (like an hour, for example) 🕐. The ones in a REVARP_REPLY are "persistent" addresses that usually change way more slowly 🐢. Second, it's explicitly a protocol error to send DRARP_REPLY packets that differ in anything except the sender address fields 🙈. Also, DRARP_REPLY packets are only generated in response to DRARP_REQUEST packets.

These temporary addresses can get reallocated to another system after some time, so a configuration protocol is normally used to make sure that reallocation doesn't happen 🧚

  • DRARP_ERROR (7): these can also be sent in response to DRARP_REQUESTs. The format is identical to REVARP_REPLY, except for the opcode, and the target protocol address (tpa) field gets swapped out for 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 that explains why no tpa is being returned 😭. The status values are:
    • DRARPERR_RESTRICTED (1): this network doesn't 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 allocation changes, or until the client is otherwise given a persistent address binding. A REVARP_REQUEST might get a REVARP_REPLY though, because non-cooperating RARP servers could be the very reason dynamic allocation got turned off 👀
    • DRARPERR_NOADDRESSES (2): this network supports dynamic address allocation, but every available protocol address on the local segment is taken, so none can be allocated right now 🥲
    • DRARPERR_SERVERDOWN (3): the service that gives access to the address authority is temporarily unavailable 🛠️. This can also come back if an address allocation was needed and the required response took a "long time" to generate. It's how you tell apart a network that doesn't support DRARP from one that does but is just slow 🐌
    • DRARPERR_MOVED (4): this is kind of like DRARPERR_RESTRICTED, since no address got dynamically allocated 🙅‍♀️. The extra info here is that the administration software for the domain recognized this client as being on a different network segment than expected. Users can fix it by plugging the system into the correct segment 🔌
    • DRARPERR_FAILURE (5): for some reason, no address could be returned, and no defined status code known to the server explained why 🤷‍♀️

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 walks through the typical protocol exchanges using RARP and Dynamic RARP, plus the common ways each exchange can fault 🫧

2.3.1. RARP Address Lookup 🔍

if a system wants to find a previously published ("persistent") protocol address for itself or for another system, it may send a REVARP_REQUEST packet 📨. If a REVARP_REPLY shows up in response, then the target protocol address listed there should be used ✅

if no REVARP_REPLY shows up within some time interval, a bunch of errors could have happened 😵‍💫. The simplest one is that the request or reply packet never arrived, and most RARP client implementations retransmit requests to partially cover for this 🔁. There's no clear point where you should stop retransmitting, so lots of implementations use exponential backoff on the retransmit interval, which cuts down on the broadcast traffic 📉

otherwise there are lots of different errors that all look the same from the outside, 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 that could supply the published address might be unavailable 💤; or it might even be on a network with no RARP servers at all 🏝️

2.3.2. Dynamic RARP Address Lookup 🕵️‍♀️

Dynamic RARP can be used to figure out previously published protocol addresses for clients that send DRARP_REQUEST packets 💌. If the client has a published protocol address on the network segment where the DRARP_REQUEST was sent, that address comes back in a REVARP_REPLY packet 🎉

but if the client only has a published protocol address on some other network segment, there are two basic responses possible 🧐. If 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 comes back with the status DRARPERR_MOVED 🚚. Detecting host movement only works with link level addresses that are unique over the catenet, like the IEEE 802 48 bit addresses 🔢. Without that uniqueness guarantee, 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 that send DRARP_REQUEST packets may get brand new allocated protocol addresses 💖. If the client has no published protocol address, there are three possible 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) get reported in DRARP_ERROR packets, with error codes like DRARPERR_SERVERDOWN, DRARPERR_NOADDRESSES, DRARPERR_MOVED, or even DRARPERR_FAILURE 😬.
  • (c) When dynamic address allocation is disabled (or "restricted"), a DRARP_ERROR packet with the status DRARPERR_RESTRICTED comes back 🚫.

DRARP_REQUESTs are normally retransmitted until an address comes back, using backoff-style algorithms so there isn't needless network traffic 🔁. When DRARP_ERROR responses come in, they should be reported to the user 📣. For example, knowing that the server is busy could mean 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 🔭

a DRARP server can be spotted by the fact that it puts its addressing information in all the DRARP_REPLY packets it sends 📬. DRARP servers can listen for those packets, and they can also announce themselves by sending such a packet to themselves 📣

it's really important to discover other DRARP servers 😤. Users make mistakes, and they can accidentally set up DRARP servers that don't coordinate their address allocation with the other DRARP servers on their network segment. That causes serious administrative problems, which can almost completely be avoided by DRARP servers that politely announce themselves 🫶. And when they detect an apparently spurious server, they report it before entering a "restricted" mode, so they don't create problems of their own 🛡️

no further server-to-server protocol is defined here, so some out-of-band mechanism, like communicating through the address authority, must be used to help figure out which servers are actually spurious 🕵️‍♀️

2.4. Network Setup Concerns 🌐

some internetwork environments connect multiple network segments using link level bridges or routers 🌉. In those environments, a given broadcast-accessible "local" area network has two problems worth noting 👀

First, it will stretch across several cable segments, and it's subject to partitioning faults 🪢. Assigning one DRARP server to each segment (maybe on systems acting as routers or bridges that serve multiple segments) can reduce the cost of those faults 💸. Assigning more than one such server can help reduce the cost of failure to any single network segment, and these servers cooperate in assigning addresses through the address authority 🤝

Second, these networks are sometimes shared by organizations that don't cooperate much on managing protocol addresses, or that might not even be in the same place 🏢. A DRARP server might need help from link level bridges or routers to make sure local clients are tied to local servers, rather than (for example) servers across the country that are prone to availability problems 🌎. Or the server might need to run in "restricted" mode, so a network administrator manually assigns addresses and other resources to each system 🧑‍💻

3. The Address Authority 👑

while it's not part of the DRARP protocol itself, 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 that service, which is required for more than just dynamic address allocation tools ✨. This section is here to record one set of requirements for such an authority, and it ignores implementation issues like whether protocol support for replication or partitioning is needed 🧩

3.1. Basic Requirements 🎀

okay bestie, so for every network segment under its control, the Address Authority has to keep at least these three things 💅

  • persistent bindings between hardware and protocol addresses (for at least those hosts which are DRARP clients);
  • temporary bindings between such addresses;
  • protocol addresses available for temporary bindings;

The Address Authority is also responsible for presenting and managing those bindings ✨. DRARP clients need it to support:

  • creating temporary bindings initially,
  • looking up bindings (the distinction between temporary and persistent bindings is not usually significant here),
  • deleting temporary or persistent bindings on request,
  • purging them automatically by noticing that a binding is now persistent or that the temporary address is available for reuse.

Those clients will frequently make concurrent requests 🔥, and they 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 move 🕵️‍♀️. 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. This is a serious one bestie, so please don't skip it 🚨.

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
📦 where this page comes from