RARP and BOOTP: Bootstrap Protocols

Imagine you are a computer that has just been powered on. You have a network interface with a unique hardware address (MAC address) burned into your network interface card. You know who you are at the data link layer. But here's the problem: you have no idea what your IP address is.\n\nFor a computer with a hard disk, this is trivial—the IP configuration is stored locally and loaded during boot. But what if you have no disk? What if you are a diskless workstation, a thin client, or an embedded device with no persistent storage? How do you discover your network identity?\n\nThis is the fundamental problem that Reverse ARP (RARP) was designed to solve. While the Address Resolution Protocol (ARP) answers the question 'I know the IP address; what is the MAC address?', RARP inverts this question: 'I know my MAC address; what is my IP address?'

To fully appreciate RARP, we must first understand the historical context and technical challenges that necessitated its creation. The early 1980s saw the rise of diskless workstations—computers that relied entirely on the network for storage and boot images.\n\nWhy Diskless Workstations?\n\nDiskless workstations emerged for several compelling reasons:\n\n| Motivation | Description |\n|------------|-------------|\n| Cost Reduction | Hard disks were extremely expensive in the early 1980s. A diskless workstation could save hundreds or thousands of dollars per unit. |\n| Central Management | All software and data resided on central servers, making administration and updates trivial. |\n| Security | No local storage meant no local data theft; all sensitive information stayed on secured servers. |\n| Reliability | Fewer mechanical parts (no disk) meant fewer hardware failures at the workstation. |\n| Noise Reduction | Diskless workstations ran silently—ideal for office environments. |

The Boot Chicken-and-Egg Problem:\n\nWhen a diskless workstation powers on, it faces a fundamental bootstrapping challenge:\n\n1. It needs an IP address to communicate on the network\n2. It needs to download its operating system from a server\n3. But it has no local storage where IP configuration could be saved\n4. The IP configuration itself must come from the network\n\nThis creates a chicken-and-egg problem: The machine needs network connectivity to get its configuration, but it needs configuration to achieve network connectivity.\n\nWhat the Workstation Knows:\n\n- Its MAC address (burned into the NIC ROM)\n- How to send and receive Ethernet frames\n- A small boot ROM program (typically only a few KB)\n\nWhat the Workstation Doesn't Know:\n\n- Its IP address\n- The subnet mask\n- The default gateway\n- Where to find its boot image

RARP was defined in RFC 903 (1984) by Ross Finlayson, Timothy Mann, Jeffrey Mogul, and Marvin Theimer at Stanford University. The protocol's elegance lies in its simplicity: it reuses the ARP frame format almost entirely, merely inverting the query semantics.\n\nThe Fundamental Inversion:\n\n| Protocol | Input (Known) | Output (Requested) | Direction |\n|----------|---------------|--------------------|-----------:|\n| ARP | IP Address | MAC Address | IP → MAC |\n| RARP | MAC Address | IP Address | MAC → IP |\n\nThis symmetry was intentional. By reusing the ARP frame structure, RARP could leverage existing network infrastructure and required minimal new code in network stacks.

Protocol Characteristics:\n\n| Characteristic | Value | Significance |\n|----------------|-------|--------------|\n| Layer | Data Link Layer | Works below IP; uses Ethernet directly |\n| Transport | None | Direct Ethernet encapsulation |\n| Delivery | Broadcast (request) / Unicast (reply) | Requests reach all local machines |\n| Reliability | Unreliable | Client must implement retransmission |\n| EtherType | 0x8035 | Different from ARP's 0x0806 |\n| Scope | Local segment only | Cannot cross routers |\n\nCritical Design Decision: Layer 2 Operation\n\nRARP operates at Layer 2 (Data Link Layer), not Layer 3. This has profound implications:\n\n1. No routing required: Requests and replies are Ethernet frames, not IP packets\n2. Broadcast-based: The request goes to all machines on the local segment\n3. Local segment limitation: RARP cannot cross routers or reach remote networks\n4. No IP dependency: Works before the client has any IP configuration

The RARP Request/Reply Exchange:\n\nThe protocol follows a simple request-reply pattern:\n\nStep 1: Client Broadcasts RARP Request\n- Source MAC: Client's hardware address\n- Destination MAC: Broadcast (FF:FF:FF:FF:FF:FF)\n- Sender Hardware Address: Client's MAC\n- Sender Protocol Address: Empty (zeros)\n- Target Hardware Address: Client's MAC (querying about itself)\n- Target Protocol Address: Empty (this is what we need)\n\nStep 2: RARP Server Unicasts Reply\n- Source MAC: Server's hardware address\n- Destination MAC: Client's MAC (unicast)\n- Sender Hardware Address: Server's MAC\n- Sender Protocol Address: Server's IP\n- Target Hardware Address: Client's MAC\n- Target Protocol Address: Client's IP (the answer!)

The RARP frame format is virtually identical to ARP, sharing the same structure with only the operation code differing. This design decision enabled code reuse and simplified implementation.\n\nComplete RARP Packet Structure:

Operation Codes Comparison:\n\nThe operation code is the key differentiator between ARP and RARP:\n\n| Operation Code | Value | Protocol | Purpose |\n|----------------|-------|----------|---------|\n| ARP Request | 1 | ARP | Who has this IP? Tell me your MAC |\n| ARP Reply | 2 | ARP | I have that IP. Here's my MAC |\n| RARP Request | 3 | RARP | I have this MAC. What's my IP? |\n| RARP Reply | 4 | RARP | That MAC maps to this IP |\n\nEtherType Distinction:\n\n- ARP EtherType: 0x0806\n- RARP EtherType: 0x8035\n\nThe different EtherType values allow network interfaces and switches to distinguish between ARP and RARP traffic, enabling proper handling and filtering.

Example RARP Exchange (Hexadecimal):\n\nRARP Request from client 00:1A:2B:3C:4D:5E:\n\nDestination: FF:FF:FF:FF:FF:FF (broadcast)\nSource: 00:1A:2B:3C:4D:5E\nEtherType: 80:35 (RARP)\n\nHardware: 00:01 (Ethernet)\nProtocol: 08:00 (IPv4)\nHW Length: 06\nProto Len: 04\nOperation: 00:03 (RARP Request)\nSender HW: 00:1A:2B:3C:4D:5E\nSender IP: 00:00:00:00 (unknown)\nTarget HW: 00:1A:2B:3C:4D:5E (self)\nTarget IP: 00:00:00:00 (requesting this!)\n\n\nRARP Reply granting IP 192.168.1.100 (0xC0A80164):\n\nDestination: 00:1A:2B:3C:4D:5E (unicast to client)\nSource: 00:AA:BB:CC:DD:EE (RARP server)\nEtherType: 80:35 (RARP)\n\nHardware: 00:01 (Ethernet)\nProtocol: 08:00 (IPv4)\nHW Length: 06\nProto Len: 04\nOperation: 00:04 (RARP Reply)\nSender HW: 00:AA:BB:CC:DD:EE (server)\nSender IP: C0:A8:01:01 (192.168.1.1 - server)\nTarget HW: 00:1A:2B:3C:4D:5E (client)\nTarget IP: C0:A8:01:64 (192.168.1.100 - answer!)\n

Unlike ARP, which can be handled by any host maintaining its own cache, RARP requires dedicated RARP servers that maintain the authoritative MAC-to-IP mapping database. The server architecture and implementation details significantly impact network reliability and scalability.\n\nRARP Server Responsibilities:\n\n1. Listen for RARP broadcast requests on the local network segment\n2. Look up the requesting MAC address in the configuration database\n3. Respond with the assigned IP address if found\n4. Ignore requests for unknown MAC addresses (let other servers respond)\n\nServer Configuration Database:\n\nThe RARP server maintains a static mapping file, traditionally /etc/ethers on Unix systems:\n\n\n# /etc/ethers - MAC to hostname mapping\n00:1A:2B:3C:4D:5E workstation01\n00:1A:2B:3C:4D:5F workstation02\n00:1A:2B:3C:4D:60 workstation03\n00:AA:BB:CC:DD:01 printer-floor3\n00:AA:BB:CC:DD:02 thin-client-lobby\n\n\nThis file maps MAC addresses to hostnames. The actual IP addresses are resolved via /etc/hosts or DNS:\n\n\n# /etc/hosts - hostname to IP mapping\n192.168.1.100 workstation01\n192.168.1.101 workstation02\n192.168.1.102 workstation03\n192.168.1.200 printer-floor3\n192.168.1.201 thin-client-lobby\n

Server Redundancy Considerations:\n\nBecause RARP is critical for booting diskless workstations, server redundancy is essential. Multiple RARP servers on the same segment provide fault tolerance:\n\n| Scenario | Single Server | Multiple Servers |\n|----------|---------------|------------------|\n| Server failure | All clients cannot boot | Other servers respond |\n| Server overload | Slow responses, timeouts | Load distributed |\n| Database update | All clients affected | Staged rollout possible |\n| Network segment | One server per segment | Redundancy per segment |\n\nHandling Multiple Servers:\n\nWhen multiple RARP servers exist on a segment:\n\n1. All servers receive the broadcast request\n2. Each server that knows the MAC address responds\n3. The client accepts the first response received\n4. Subsequent responses are ignored\n\nThis race condition is intentional—it provides both redundancy and automatic failover without complex coordination protocols.

Server Implementation Details:\n\nThe RARP server daemon (typically rarpd on Unix) operates in a tight loop:\n\n\nwhile (true) {\n 1. Receive Ethernet frame with EtherType 0x8035\n 2. Verify operation code = 3 (RARP Request)\n 3. Extract Target Hardware Address from frame\n 4. Look up Target HW Address in /etc/ethers\n 5. If found:\n a. Resolve hostname to IP via /etc/hosts\n b. Construct RARP Reply with assigned IP\n c. Send unicast reply to requester's MAC\n 6. If not found:\n a. Log (optionally)\n b. Ignore (let another server handle it)\n}\n\n\nImplementation Challenges:\n\n- Raw socket access: Server must access Ethernet frames directly, requiring elevated privileges\n- Promiscuous mode: Server must capture all frames, not just those addressed to it\n- Database consistency: All servers must have identical, synchronized databases\n- Update coordination: Database changes must propagate to all servers simultaneously

The RARP client behavior is implemented in the boot ROM of diskless workstations. Given the extremely limited space in these ROMs (often just a few kilobytes), the client implementation must be minimal yet robust.\n\nBoot ROM RARP Client Algorithm:\n\n\n1. Initialize network interface\n2. Read own MAC address from NIC\n3. Construct RARP Request frame\n4. Set retry_count = 0\n5. While (retry_count < MAX_RETRIES) {\n a. Broadcast RARP Request\n b. Start timer (e.g., 4 seconds)\n c. Wait for RARP Reply\n d. If reply received:\n - Extract assigned IP address\n - Configure local IP stack\n - Proceed to next boot phase (TFTP)\n - EXIT\n e. If timeout:\n - retry_count++\n - Optionally double wait time (exponential backoff)\n }\n6. If no reply after MAX_RETRIES:\n - Display error\n - Halt or retry indefinitely\n

Timeout and Retry Strategy:\n\nThe RARP protocol specification (RFC 903) does not mandate specific timeout values, leaving implementation details to vendors. Common strategies include:\n\n| Strategy | Parameters | Behavior |\n|----------|------------|----------|\n| Fixed timeout | 4 seconds, 5 retries | Simple but may be too aggressive |\n| Exponential backoff | 2s, 4s, 8s, 16s | Reduces network load under congestion |\n| Random jitter | ±500ms variation | Prevents synchronized retries |\n| Infinite retry | No maximum | Never gives up (common for critical systems) |\n\nClient Implementation Challenges:\n\n1. No storage for logs: Any errors or debug information must be displayed immediately\n2. Minimal memory: Can't buffer multiple responses or perform complex operations\n3. No clock: Some systems don't have a real-time clock, making timeout measurement difficult\n4. Single-threaded: Boot ROM executes sequentially with no multitasking

Post-RARP Boot Process:\n\nOnce the client obtains its IP address via RARP, the boot process continues with additional steps that RARP cannot provide:\n\n1. RARP: Obtain IP address (✓ completed)\n2. Next step: Download boot image\n3. Problem: Where is the boot server? What file to download?\n\nRARP provides only the IP address—it doesn't supply:\n- Subnet mask\n- Default gateway\n- Boot server address\n- Boot file name\n- DNS server\n- Any other configuration\n\nThis limitation led diskless workstation vendors to combine RARP with other mechanisms, typically TFTP (Trivial File Transfer Protocol) for downloading boot images, with hard-coded or conventionally-derived server addresses.

While RARP elegantly solved the immediate problem of IP address discovery, it suffered from significant limitations that became increasingly problematic as networks grew in size and complexity. Understanding these limitations explains why RARP was superseded by BOOTP and eventually DHCP.\n\nFundamental Limitations of RARP:

Scalability Analysis:\n\nConsider a large organization with 100 network segments:\n\n| With RARP | Requirement |\n|-----------|-------------|\n| RARP Servers | At least 100 (one per segment), 200+ for redundancy |\n| Configuration Files | 100+ copies of /etc/ethers to maintain |\n| Database Sync | Manual synchronization across all servers |\n| New Client Setup | Update every relevant server manually |\n| IP Reclamation | Manual removal of stale entries |\n| Audit Trail | None built-in |\n\nThis administrative burden made RARP impractical for large deployments, driving the development of more sophisticated solutions.

The Layer 2 Constraint:\n\nPerhaps RARP's most significant limitation is its Layer 2 operation. By working at the Ethernet level:\n\nAdvantages:\n- Works without IP stack initialization\n- Simple implementation in boot ROMs\n- No complex protocol handling required\n\nDisadvantages:\n- Cannot leverage IP routing infrastructure\n- Servers must be on every local segment\n- Cannot be centralized in a data center\n- Doesn't benefit from IP-based redundancy\n\nThis trade-off was acceptable in small networks but became untenable as organizations consolidated servers into central locations while users remained distributed across many segments.

We have covered the complete architecture and operation of Reverse ARP. Let's consolidate the key concepts before moving on to explore RARP's operational details:

What's Next:\n\nIn the next page, we will dive deep into RARP's operational mechanics. You will learn the precise sequence of events during a RARP transaction, timing considerations, error handling, and how RARP integrates with the complete diskless boot process. Understanding these operational details is essential for troubleshooting and for appreciating how BOOTP improved upon RARP's foundation.