RFC 906

Bootstrap Loading using TFTP 🎀

Okay bestie, here's the header info first. It's from the Network Working Group, written by Ross Finlayson at Stanford University, dated June 1984. It's a proposed protocol for the ARPA Internet community. The header doesn't list anything it obsoletes or updates. 💖

---

Status of This Memo ✨

It's often super convenient to be able to bootstrap a computer system from a communications network 🌐. This RFC proposes using the IP TFTP protocol for bootstrap loading in that case.

This RFC specifies a proposed protocol for the ARPA Internet community, and requests discussion and suggestions for improvements. So bestie, if you have ideas, the authors want to hear them 🫶.

Introduction 🦋

So many computer systems, like diskless workstations, get bootstrapped by loading one or more code files across a network. The sad part is that the protocol used to load those first files was never standardized, and different computer manufacturers have all tried their own methods 😭. That makes life really hard for an installation that wants to support several kinds of systems on a local-area network. Every different booting mechanism has to be supported, for example by running a bunch of servers on one or more host machines. And the wild thing is that these heterogeneous systems can talk to each other freely (all using the same protocol) once they've been booted 💅.

We propose that TFTP (Trivial File Transfer Protocol) [6] be used as a standard protocol for bootstrap loading. It's a great fit, since it's based on the standard Internet Protocol (IP) [4] 🧚. It's easy to implement, both in the machines being booted and in bootstrap servers elsewhere on the net. (Also, lots of popular operating systems already support TFTP servers 🌈.) TFTP is a fairly slow protocol, but that's not a big deal, because it only needs to be used for the primary bootstrap. A secondary bootstrap could use a faster protocol ⭐.

This RFC describes how the system being booted (called the "booter" below) would use TFTP to load a desired code file. It also describes an existing implementation (in ROM) for Ethernet 🍓.

Note that we're only specifying the network protocols the booting system would use. We're not trying to mandate how a user actually boots a system (like the format of a command typed at the console) 🙈. Also, this proposal doesn't assume any particular data-link level network architecture, even though the example we describe below uses Ethernet.

Network Protocols used by the Booting System 🔥

To load a file, the booter sends a standard TFTP read request (RRQ) packet that contains the name of the file to be loaded. The file name should not assume any operating system dependent naming conventions (file names containing only alphanumeric characters should suffice) 💜. After that, the system receives TFTP DATA packets, and sends TFTP ACK and/or ERROR packets, following the TFTP specification [6].

TFTP runs on the User Datagram Protocol (UDP) [5], and UDP runs on IP. So the booter has to be able to receive IP datagrams containing up to 524 octets (not counting the IP header). That's because TFTP DATA packets can be up to 516 octets long, and UDP headers are 8 octets long 🧮. The booting machine is not required to respond to incoming TFTP read or write requests, so no pressure 😌.

We allow for two additional protocols: ARP (Address Resolution Protocol) [3] and RARP (Reverse Address Resolution Protocol) [1]. How these might be used is described below. The booter could also use other protocols (such as for name lookup), but they should be IP-based and an internet standard 👑.

The IP datagram that holds the initial TFTP RRQ (and every other IP datagram the booter sends) must of course contain both a source internet address and a destination internet address in its IP header. Here's the tricky part: it's pretty common for the booter to not know its own internet address at first, only a lower-level (e.g. Ethernet) address 🙃. The booter can use the Reverse Address Resolution Protocol (RARP) [1] to find its internet address before sending the TFTP RRQ. RARP was inspired by Plummer's Address Resolution Protocol (ARP) [3]. Unlike ARP, which finds the 'hardware' address for a known higher-level protocol (e.g. internet) address, RARP works the other way around: it figures out a higher-level protocol address when you already know the hardware address 🔁. RARP uses the same packet format as ARP, and just like ARP, it can be used with a wide variety of data-link protocols 💖.

ARP can also be used. If the destination internet address is known, an ARP request containing that address can be broadcast to find the matching hardware address to send the subsequent TFTP RRQ to. It may not matter if this request fails, because the RRQ can also be broadcast at the data-link level 🤷‍♀️. Also, since an ARP request contains the sender's (that is, the booter's) internet and hardware addresses, that info gets shared with the rest of the local subnet, which could be useful for routing, for instance 🗺️.

If a single destination internet address isn't known, a special 'broadcast' internet address can be used as the destination address in the TFTP RRQ, so that all 'local' internet hosts receive it 📣. Honestly though, no standard for internet broadcasting has been officially adopted yet. [**] 😬

An Example Implementation 💅

The author has implemented TFTP booting as specified above. The resulting code lives in ROM. (This implementation is for a Motorola 68000 based workstation, booting over an Ethernet 🖥️.) A user who wants to boot one of these machines types a file name and (optionally) the internet address of the workstation, and/or the internet address of a server machine that the file should be loaded from. Then the bootstrap code goes like this:

(1) The workstation's Ethernet address is found (by querying the Ethernet interface).

(2) If the internet address of the workstation wasn't given, a RARP request is broadcast to find it. If this request fails (that is, times out), the bootstrap fails 😱.

(3) If the internet address of a server host was given, broadcast an ARP request to try to find a corresponding Ethernet address. If this fails, or if a server internet address wasn't given, the Ethernet broadcast address is used 📡.

(4) If the internet address of a server host wasn't given, we use a special internet address that represents a broadcast on the "local subnet", as described in [2]. (This is not an internet standard.) 🧃

(5) A TFTP RRQ for the requested file is sent to the Ethernet address found in step (3). The source internet address is the one found in step (2), and the destination internet address is the one found in step (4) 🚀.

Here's a juicy detail: because several TFTP servers may reply to the RRQ, we don't abort if a TFTP ERROR packet comes in. That's because it doesn't rule out some other server replying later with the first data packet of the requested file 👀. When the first valid TFTP DATA packet arrives in response to the RRQ, the source internet and Ethernet addresses of that packet get used as the destination addresses in the subsequent TFTP ACK packets. If another server later responds with a DATA packet, an ERROR packet is sent back in response 🙅‍♀️.

An implementation of TFTP booting can take up a lot of space if you're not careful 🫠. That can be a big problem if the code has to fit in a limited amount of ROM. But the implementation described above is less than 4K bytes of code (not counting the Ethernet device driver) 🏆. Slay.

Acknowledgements 🫶

The ideas here came out of discussions with several other people, especially Jeff Mogul 💜.

References 📚

[1] Finlayson, R., Mann, T., Mogul, J. & Theimer, M., "A Reverse Address Resolution Protocol", RFC 903 Stanford University, June 1984.

[2] Mogul, J., "Internet Broadcasting", Proposed RFC, January 1984.

[3] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826, MIT-LCS, November 1982.

[4] Postel, J., ed., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, USC/Information Sciences Institute, September 1981.

[5] Postel, J., "User Datagram Protocol", RFC 768 USC/Information Sciences Institute, August 1980.

[6] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, MIT/LCS, June 1981.

---

[**] Editor's Note: While there is no standard for an Internet wide broadcast or multicast address, it is strongly recommended that the "all ones" local part of the Internet address be used to indicate a broadcast in a particular network. 🌸 That means that in class A network 1, the broadcast address would be 1.255.255.255. In class B network 128.1, the broadcast address would be 128.1.255.255. And in class C network 192.1.1, the broadcast address would be 192.1.1.255. ✨