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.

For 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?

This 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.

Why Diskless Workstations?

Diskless workstations emerged for several compelling reasons:

The Boot Chicken-and-Egg Problem:

When a diskless workstation powers on, it faces a fundamental bootstrapping challenge:

1. It needs an IP address to communicate on the network
2. It needs to download its operating system from a server
3. But it has no local storage where IP configuration could be saved
4. The IP configuration itself must come from the network

This creates a chicken-and-egg problem: The machine needs network connectivity to get its configuration, but it needs configuration to achieve network connectivity.

What the Workstation Knows:

• Its MAC address (burned into the NIC ROM)
• How to send and receive Ethernet frames
• A small boot ROM program (typically only a few KB)

What the Workstation Doesn't Know:

• Its IP address
• The subnet mask
• The default gateway
• 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.

The Fundamental Inversion:

This 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:

Critical Design Decision: Layer 2 Operation

RARP operates at Layer 2 (Data Link Layer), not Layer 3. This has profound implications:

1. No routing required: Requests and replies are Ethernet frames, not IP packets
2. Broadcast-based: The request goes to all machines on the local segment
3. Local segment limitation: RARP cannot cross routers or reach remote networks
4. No IP dependency: Works before the client has any IP configuration

The RARP Request/Reply Exchange:

The protocol follows a simple request-reply pattern:

Step 1: Client Broadcasts RARP Request

• Source MAC: Client's hardware address
• Destination MAC: Broadcast (FF:FF:FF:FF:FF:FF)
• Sender Hardware Address: Client's MAC
• Sender Protocol Address: Empty (zeros)
• Target Hardware Address: Client's MAC (querying about itself)
• Target Protocol Address: Empty (this is what we need)

Step 2: RARP Server Unicasts Reply

• Source MAC: Server's hardware address
• Destination MAC: Client's MAC (unicast)
• Sender Hardware Address: Server's MAC
• Sender Protocol Address: Server's IP
• Target Hardware Address: Client's MAC
• 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.

Complete RARP Packet Structure:

Operation Codes Comparison:

The operation code is the key differentiator between ARP and RARP:

EtherType Distinction:

• ARP EtherType: 0x0806
• RARP EtherType: 0x8035

The different EtherType values allow network interfaces and switches to distinguish between ARP and RARP traffic, enabling proper handling and filtering.

Example RARP Exchange (Hexadecimal):

RARP Request from client 00:1A:2B:3C:4D:5E:

Destination: FF:FF:FF:FF:FF:FF (broadcast)
Source:      00:1A:2B:3C:4D:5E
EtherType:   80:35 (RARP)

Hardware:    00:01 (Ethernet)
Protocol:    08:00 (IPv4)
HW Length:   06
Proto Len:   04
Operation:   00:03 (RARP Request)
Sender HW:   00:1A:2B:3C:4D:5E
Sender IP:   00:00:00:00 (unknown)
Target HW:   00:1A:2B:3C:4D:5E (self)
Target IP:   00:00:00:00 (requesting this!)

RARP Reply granting IP 192.168.1.100 (0xC0A80164):

Destination: 00:1A:2B:3C:4D:5E (unicast to client)
Source:      00:AA:BB:CC:DD:EE (RARP server)
EtherType:   80:35 (RARP)

Hardware:    00:01 (Ethernet)
Protocol:    08:00 (IPv4)
HW Length:   06
Proto Len:   04
Operation:   00:04 (RARP Reply)
Sender HW:   00:AA:BB:CC:DD:EE (server)
Sender IP:   C0:A8:01:01 (192.168.1.1 - server)
Target HW:   00:1A:2B:3C:4D:5E (client)
Target IP:   C0:A8:01:64 (192.168.1.100 - answer!)

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.

RARP Server Responsibilities:

1. Listen for RARP broadcast requests on the local network segment
2. Look up the requesting MAC address in the configuration database
3. Respond with the assigned IP address if found
4. Ignore requests for unknown MAC addresses (let other servers respond)

Server Configuration Database:

The RARP server maintains a static mapping file, traditionally /etc/ethers on Unix systems:

# /etc/ethers - MAC to hostname mapping
00:1A:2B:3C:4D:5E  workstation01
00:1A:2B:3C:4D:5F  workstation02
00:1A:2B:3C:4D:60  workstation03
00:AA:BB:CC:DD:01  printer-floor3
00:AA:BB:CC:DD:02  thin-client-lobby

This file maps MAC addresses to hostnames. The actual IP addresses are resolved via /etc/hosts or DNS:

# /etc/hosts - hostname to IP mapping
192.168.1.100  workstation01
192.168.1.101  workstation02
192.168.1.102  workstation03
192.168.1.200  printer-floor3
192.168.1.201  thin-client-lobby

Server Redundancy Considerations:

Because RARP is critical for booting diskless workstations, server redundancy is essential. Multiple RARP servers on the same segment provide fault tolerance:

Handling Multiple Servers:

When multiple RARP servers exist on a segment:

1. All servers receive the broadcast request
2. Each server that knows the MAC address responds
3. The client accepts the first response received
4. Subsequent responses are ignored

This race condition is intentional—it provides both redundancy and automatic failover without complex coordination protocols.

Server Implementation Details:

The RARP server daemon (typically rarpd on Unix) operates in a tight loop:

while (true) {
    1. Receive Ethernet frame with EtherType 0x8035
    2. Verify operation code = 3 (RARP Request)
    3. Extract Target Hardware Address from frame
    4. Look up Target HW Address in /etc/ethers
    5. If found:
       a. Resolve hostname to IP via /etc/hosts
       b. Construct RARP Reply with assigned IP
       c. Send unicast reply to requester's MAC
    6. If not found:
       a. Log (optionally)
       b. Ignore (let another server handle it)
}

Implementation Challenges:

• Raw socket access: Server must access Ethernet frames directly, requiring elevated privileges
• Promiscuous mode: Server must capture all frames, not just those addressed to it
• Database consistency: All servers must have identical, synchronized databases
• 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.

Boot ROM RARP Client Algorithm:

1. Initialize network interface
2. Read own MAC address from NIC
3. Construct RARP Request frame
4. Set retry_count = 0
5. While (retry_count < MAX_RETRIES) {
      a. Broadcast RARP Request
      b. Start timer (e.g., 4 seconds)
      c. Wait for RARP Reply
      d. If reply received:
         - Extract assigned IP address
         - Configure local IP stack
         - Proceed to next boot phase (TFTP)
         - EXIT
      e. If timeout:
         - retry_count++
         - Optionally double wait time (exponential backoff)
   }
6. If no reply after MAX_RETRIES:
   - Display error
   - Halt or retry indefinitely

Timeout and Retry Strategy:

The RARP protocol specification (RFC 903) does not mandate specific timeout values, leaving implementation details to vendors. Common strategies include:

Client Implementation Challenges:

1. No storage for logs: Any errors or debug information must be displayed immediately
2. Minimal memory: Can't buffer multiple responses or perform complex operations
3. No clock: Some systems don't have a real-time clock, making timeout measurement difficult
4. Single-threaded: Boot ROM executes sequentially with no multitasking

Post-RARP Boot Process:

Once the client obtains its IP address via RARP, the boot process continues with additional steps that RARP cannot provide:

1. RARP: Obtain IP address (✓ completed)
2. Next step: Download boot image
3. Problem: Where is the boot server? What file to download?

RARP provides only the IP address—it doesn't supply:

• Subnet mask
• Default gateway
• Boot server address
• Boot file name
• DNS server
• Any other configuration

This 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.

Fundamental Limitations of RARP:

Scalability Analysis:

Consider a large organization with 100 network segments:

This administrative burden made RARP impractical for large deployments, driving the development of more sophisticated solutions.

The Layer 2 Constraint:

Perhaps RARP's most significant limitation is its Layer 2 operation. By working at the Ethernet level:

Advantages:

• Works without IP stack initialization
• Simple implementation in boot ROMs
• No complex protocol handling required

Disadvantages:

• Cannot leverage IP routing infrastructure
• Servers must be on every local segment
• Cannot be centralized in a data center
• Doesn't benefit from IP-based redundancy

This 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:

In 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.