Summary

  • RFC 906 proposed TFTP over IP as a common way to fetch a diskless computer’s first code, after installations had accumulated different manufacturers’ boot methods and server implementations.
  • In its reported Motorola 68000/Ethernet example, an ERROR did not close the search for a server: the first valid DATA packet fixed the transfer partner. The ROM code took less than 4K bytes excluding the Ethernet driver; that is evidence of one implementation, not industry-wide adoption.

A workstation could speak the same Internet protocols as its neighbors after it started, yet still need a special path to become that kind of machine. Its operating system was not there to make a request. A small program in read-only memory had to bring up enough networking to fetch the next code file.

Ross Finlayson’s June 1984 RFC 906 describes the practical friction at that boundary. Different manufacturers had used different methods to load the initial files. An installation supporting several kinds of computer might therefore need several boot-server implementations, even when the machines could communicate freely once running. RFC 906 proposed a common protocol for that first transfer: TFTP carried over IP. The memo is explicit about its status. It proposes a protocol for the ARPA Internet community and asks for discussion and improvements; it does not report that the proposal had already become a universal practice.

The choice of TFTP was deliberately modest. The booting program sent a read request naming a file, then received DATA packets and returned acknowledgements or errors. RFC 906 argued that a slow transfer was acceptable for the primary bootstrap because a later stage could use a faster protocol. It required the client to receive IP datagrams up to 524 octets, excluding the IP header: a TFTP DATA packet of up to 516 octets plus UDP’s 8-octet header. The booting machine did not need to answer incoming TFTP read or write requests. This was a narrow retrieval client, not a general file server.

The memo also stopped short of standardizing the whole boot experience. It described only the network protocols. It did not prescribe how someone started the machine or what console command they typed, and it did not require Ethernet or any other particular data-link architecture. A common packet exchange could sit beneath different local ways of invoking a boot and choosing a file.

The implementation gives the proposal a more concrete edge. Finlayson reported a ROM implementation for a Motorola 68000 workstation on Ethernet. The user entered a file name and could supply the workstation’s and server’s Internet addresses. If the server address was missing, the example could send a request that more than one TFTP server might receive. The important question was then not simply whether a server replied, but which reply changed the client’s state.

The answer was precise. A TFTP ERROR from one server did not make the client abort, because another server could still send the requested file. The first valid DATA packet established the Internet and Ethernet source addresses to which the client sent later ACKs. If a different server later sent DATA, the client answered it with an ERROR. The initial request could be heard by several servers, but one valid first response became the partner for that transfer.

That rule is easy to mistake for authentication. It was not. TFTP Revision 2 describes TFTP as a small file-transfer protocol and says it has no provisions for user authentication. RFC 906’s first-valid-packet rule selects a responder; it does not prove that responder is the operator’s intended server or that a boot image has an independently verified origin. The record does not establish an attack or a deployment incident. It shows where the proposal placed a decision: in the client’s response handling and in the local environment that determined who could answer.

The code-size report is equally bounded. The example implementation used less than 4K bytes of code, not counting the Ethernet device driver. This is evidence that one author had fitted the described client into a constrained ROM design. It is not a measurement for other processors, a count of installations, or a claim that all manufacturer-specific boot methods disappeared.

Later documents clarify the broader architecture without proving a direct adoption chain. RFC 951, published in 1985, describes BOOTP as one phase for address determination and boot-file selection, after which file transfer would typically use TFTP. RFC 1123 in 1989 describes diskless network boot as a boot-ROM program performing two distinct phases: configuring IP, then loading the host system code. These later descriptions make a separation between preparation and transfer explicit. They do not turn RFC 906’s single reported implementation into a deployment statistic.

The proposal’s historical value is therefore a boundary, not a victory lap. A small ROM program could use ordinary IP transport to request the next file, while console invocation and parts of server selection remained local. The first valid DATA packet supplied a clear point at which one responder became the transfer partner. That kept the protocol small, but left operators responsible for the code source that answered first.

Heng Lu’s later Note 65 offers a useful editorial discipline: running code, validation, deployment and use are different evidence from a published proposal. That note is not evidence of Finlayson’s intent. Applied here, it keeps the claim proportional: RFC 906 records a proposed interface and one implementation. Its text does not establish how many sites adopted it or whether it removed the support burden it identified.

Sources