John Gilmore should be familiar to most of us involved in networking; he is one of the principals behind a series of current IETF drafts on releasing the historically reserved 240.0.0.0/4, 0.0.0.0/8 and the upper parts of 127.0.0.0/8 as globally routable addresses.
But his involvement in the Internet goes back further than this story. He is a major contributor to the GNU project of free software, and a founder of the Electronic Freedom Foundation (EFF). As his biography on Wikipedia notes, he was the fifth employee of Sun Microsystems, and this places him at the heart of a precious juncture in the history of Internet Protocols.
Let’s examine why by reflecting on John’s discussion on the origins of the Address Resolution Protocol (ARP) and Bootstrap Protocol (BOOTP), via the NANOG mailing list.
ARP
Many networking problems come down to discovery — how do you find the other thing you want to talk to? The Domain Name System (DNS) can be used to look up the IP address with a name — that’s one kind of ‘finding’.
Then there’s routing — how you ‘find’ that IP address in the global Internet to make packets flow between origin and destination. That’s the second major kind of ‘discovery’.
ARP is designed to do the ‘bootstrapping’— solving the initial problem of finding which host on a local network segment, a level down the stack, is reachable in that network technology. There are no ‘names to addresses’ in this problem, so it’s not a DNS problem. And there’s no routing in this problem because you will be talking directly to the host in question on the shared network. This isn’t a problem when you build a network out of point-to-point links, because the link is a strong metaphor for a ‘bit of wire’ with two ends. You need to know there is something with an IP address on the other end of the wire, but how to find it is not a problem because there are only two ends!
The problem emerged when networks were invented that had more than one device connected, like ring networks (such as IBM’s token-ring) or the original Ethernet. Here is something that is a lot like a radio broadcast (in so many ways, Ethernet is just a special kind of waveguide carried inside the cable) because when something is sent down this network, everything attached to it can (in principle) see it.
So, how do you specify one receiver, and no other?
The answer is to have a form of address for this medium, which is called a link layer address, because in the model of networking used at the time, the ‘link’ level is the one that has devices connected directly to you on some (shared or point-to-point) local link. Link local addresses are still referred to in IPv6, defined as being restricted to the immediate local network with no routing expected. So, the problem in this space is finding how to take an IP address and find the link address that the computer with that IP address uses. That’s the job of ARP.
ARP was developed in 1982, very early on in the life of both Ethernet and IP version 4 (IPv4). Before ARP, the mechanism was to co-opt some bytes at the bottom of your prefix. At this stage, everyone who could afford to run experimental 1- and 3-megabit Ethernet had a lot of IPv4 addresses, which meant a lot of bits were available.
But, as John points out in the mailing list, this was not a good fit with the 10-megabit industry standard Ethernet, which chose a 48-bit link address.
Before Ethernet, the address on the link was small enough to ‘fit’ in the bottom bits of the IPv4 address. After Ethernet was developed, the individual device address was in a number space bigger than the IP address, so it had to be mapped. Managing this mapping meant finding out which MAC address to use for sending an IP packet on the local medium. ARP was used to ask ‘what is the MAC address of this IP address’, which then used a special MAC address that was ‘broadcast’ — every station, host, and entity on the Ethernet was meant to see this broadcast and decide if they had to answer. ARP meant that you could discover the address of every ‘live’ host, by asking a device to tell you what it was, as a MAC address.
Asking by broadcast introduces the concept of a ‘storm’ of requests, which all devices see and potentially respond. ARP and Reverse ARP (RARP) storms are a scaling problem of IPv4 that can wreak havoc by jamming the network with broadcast packet flows and removing the opportunity to use the network for real work. That is, broadcasts ‘jam’ the radio-space and prevent others from speaking.
RARP: Solving a bootstrap problem
Sun Microsystems was one of the first explosively successful workstation manufacturers of the time and, alongside others, had the problem of how to make lower-cost workstations viable for deployment in a low-overhead world. Cheap at this time meant ‘no disk’ because in the 1980s, hard drives were both small and expensive, and static memory like SSD only existed as very small programmable read-only memory (PROM), which were used for the (tiny) bootstrap code.
Before this, you had to have a heavyweight systems administration cost to preconfigure the Internet address of your workstation and preconfigure everything about it into a known server to run as the provider of services.
Sun wanted a way to do this for less configuration and setup overhead and invented a ‘reverse’ protocol. It did ARP, but the other way around.
If ARP asks ‘what is the local MAC address of this IP address?’, then RARP asks ‘what is my IP address, given all I know is my MAC address?’ And it worked, within limits. A broadcast packet was used to ask ‘Who am I’ and somebody out there on the network replied ‘here is your IP address’. The configuration burden was in the ‘centre’ — to assign the IP to the MAC. But you didn’t have to tell the client this, it found out online. If you add the consequence of using the IP address, which replies as your configuration and bootstrapping host, then all subsequent work happens with that host. You don’t have to say ‘here’s where to boot from, here’s what to do next, and here is your router’ in RARP. It did just one thing, simply. RARP even reused part of the ARP packet structure to avoid reinventing the wheel.
RARP to BOOTP: Doing bootstrap better
John discusses how, as a ‘less hack-like’ solution, they also designed a better protocol to tell the client extra information so that the bootstrapping server could only do configuration management, and pass the heavy lifting work of network filestore, and the like, to another host. This is what became BOOTP.
“We got the BOOTP protocol working in prototype. Bill [Croft] understood the RFC submission process, and we got it published as an experimental RFC.
Sun didn’t care. Their products shipped using RARP. Bill and I had lots of other things to do, so we ignored BOOTP for years.”
BOOTP continues to be used to this day, alongside its sister-protocol Dynamic Host Configuration Protocol (DHCP). The primary role of BOOTP and RARP was to help a diskless workstation learn where to load its operating system and network file system from, which leads to other protocols like Trivial File Transfer Protocol (TFTP) to load the code, and Network File System (NFS) to access the file store. Both are used to this day, alongside other protocols like Preboot Execution Environment (PXE) for initial system loading that’s built into many Intel-based computer systems.
BOOTP to DHCP: Configuration above the bootstrap
DHCP is a much more complex protocol but continues to use BOOTP for the initial phases. BOOTP is kept simple so it can be implemented easily in the bootstrap firmware of machines. DHCP, on the other hand, is implemented to run continuously on live services and can manage IP address and routing across changes of interface, the underlying network, and changes to the address pool.
It provides for address persistence (getting the same address if it’s still available) and has significant investment in vendor-specific and vendor-neutral options. DHCP is under management in the IETF but with declining change.
DHCP helped define DHCPv6, which is the equivalent for IPv6 protocols, although this also confronts a divergence in the model of how networks operate. In the ARP-BOOTP-DHCP work, a binding between a MAC address and an IPv4 address is a strong centrally-managed assertion, and DHCPv6 maintains this model.
An alternative model is ‘stateless autoconfiguration’, which does not presuppose a specific IPv6 address should be assigned, or that it should even come from a server, but that a prefix can be assigned, and then identity within that space can be self-assigned and managed.
This is a major divergence in the model and introduced new protocols alongside DHCPv6 such as the Neighbor Discovery (ND) protocol (which, in turn, uses concepts similar to ARP and ICMP to do its job) and router solicitation, which diverges from the DHCP model. In DHCP, identity on the network is allocated, as is which edge router to use. In ND and ICMv6, you ask, ‘what is your local prefix assignment’ and self-assign a unique identity. And you can use ICMPv6 to ask what routers are available to you and choose among them.
This introduces new forms of risk and attack: ND has its own versions of the RARP/ARP storm, and router solicitation invites being ‘lied to’ as opposed to a DHCP server being a single point of trust. This, in turn, has led to the development of new protocols for IPv6 such as Secure Neighbor Discovery (SEND), which has been upgraded to include reference to the RPKI system administered by the Regional Internet Registries in address distribution.
So why were they ‘slapped on’ to IP? As John said in his NANOG mailing list thread: “What started as experiments eventually became expected parts of the IP standards … The rest is history.”
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.