Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!houxm!ihnp4!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re: tftp for bootstrap
Message-ID: <8758@ucbvax.ARPA>
Date: Wed, 3-Jul-85 21:26:21 EDT
Article-I.D.: ucbvax.8758
Posted: Wed Jul  3 21:26:21 1985
Date-Received: Fri, 5-Jul-85 06:40:39 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 42

From: Jeff Mogul 

One thing you might want to consider is a multi-stage bootstrap, where
TFTP is used to load a small program that then determines (via NFS
or whatever you prefer) what the host's configuration should be.

For example, we have Suns here that run the V-system (instead of
Sun Unix.)  They load a short program called Vload, using whatever
protocol Suns bootload with.  Vload then reads a configuration
file (located using the hardware ethernet address as an identifier)
which says what programs should really be loaded.  Vload uses
the V protocols (which is unfortunate but that's another story)
to read the config file and load the real program; all that is
needed from the original bootstrap protocol is the ability to
load the second-phase bootstrap program.

The point here is that the non-volatile storage need not reside
on the workstation or whatever; as long as the first-phase boot
program can find a database on some server, either by broadcast
or by wiring the server address into the code, the rest is
just a matter of chasing pointers.

I think TFTP is preferable to ND or NFS or FTP or whatever because
it's extremely simple, which is important when it has to be squeezed
into a ROM, and because it's widely available, unlike certain
manufacturers' proprietary protocols.  If you only care about
loading Suns as Suns, then using NFS might make sense because
of efficiency or convenience; if you care about loading a variety
of hosts with a variety of operating systems, then TFTP makes
more sense because it's simpler and more available.

As to the problem of default directories:  perhaps what we
need is to separate the TFTP protocol from the intended use.
TFTP is currently expected to listen on port 69, but there
is no reason why a TFTP-based boot server couldn't listen on
some other port; the port-69 server would not need a default
directory, while the behaviour of the port-XX server would be
defined so that alphanumeri-only file names would refer to a
default directory.  Alternatively (this is what our pseudo-ND
server does), the TFTP-boot server might be allowed to look
at the requesting host address to look up in a database which
file to download.