Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re: tftp for bootstrap
Message-ID: <8879@ucbvax.ARPA>
Date: Mon, 8-Jul-85 16:25:49 EDT
Article-I.D.: ucbvax.8879
Posted: Mon Jul  8 16:25:49 1985
Date-Received: Tue, 9-Jul-85 06:49:49 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 121

From: imagen!geof@su-shasta.arpa


I must confess that my comments should really be in conjunction with
Noel Chiappa's, since we are referring to the same set of TFTP
implementations.  I worked on some of the TFTP implementations while I
was at MIT.

My last message should only be read in context -- I agree that TFTP is
no better a protocol than most others for bootloading, except insofar as
it is possible to use other server implementations of TFTP.

It is not necessary to modify a TFTP server from its "vanilla" state to
make it useable for bootloading.  The modifications that were done at
MIT mostly were because some machines had TFTP has their only file
transfer protocol (specifically, the UPDATE mode).

The MIT implementations of TFTP all met spec (I presume they all still
do), and few had hidden features.  All ran on port 69.  Some efforts
were occasionally made to make sure that the implementations at MIT and
ISI were able to interconnect.  File names which were received were
handed by the server to the operating system, and interpreted in the
security and naming contexts of the server.  As additional security
measures:
	- all servers refused to overwrite existing files
	- the servers on Tops-20 and Multics were sufficiently isolated
	  from a security point of view that the server had (by default)
	  very little access to most user's files and directories.  On
	  multics, the server had to be explicitly permitted to access
	  a portion of the directory tree.
	- on berkeley Unix, the server explicitly tested protections to
	  verify that global read (or write) access existed where it 
	  was needed. This was necessary because the server had to run
	  as root to be able to access socket 69, so our initial
	  attempts to just have the server attempt to open the file and
	  let the OS apply some default set of protections wouldn't work
	  (interesting how in this case a security feature turned out
	  to be a security bug).
On most of the machines, the server would also reject any file transfer
for which no directory was specified (the exception was the alto
implementation, because there were no directories to speak of).  On
Tops-20, a device or directory spec had to be specified, but it was not
necessary to specify both.

For purposes of bootloading, a special directory was set up on each
machine.  The name of the directory was configured into the
gateways, as was each machine's internet address.  For reasons of code
size, the bootloader was typically only able to use one interface. 
However, the gateways were able to boot through each other, so
bootloading was possible from a wide variety of machines.

Since gateway code was different for each gateway, the boot files for
each gateway were named by concatenating the address of the gateway
together.  As Noel pointed out, this is easy to keep track of if you
assign three letters to each byte for decimal or octal number
(alternately, use hex).  When booting, the gateway sent a read request
to each host for a file whose name was the concatenation of the prefix
for that host and the internet address of the gateway, unparsed as an
octal string with three digits for each byte.  The transfer mode was
mode "image." The intent of mode "image" is that a file which is
transferred to a host using it and then transferred back ends up with
the same bits in it (perhaps a few more tacked onto the end); it is
perfect for bootloading.  We simply distributed the boot-code using
TFTP mode image (with a little telnet fudging to delete the original
first, see below) from the source, and were confident that it would be
read back correctly.  This worked on Alto's, Unices, Tops-20, and
Multics (the latter two used different ways of storing the Image files
- Tops-20 used 8-bit bytes with 4 bits of each 36 bit word wasted, and
multics stored the bits sequentially in 36-bit words, ignoring word
boundaries).

The obvious way to use TFTP for bootloading is to have the gateway send
a read request to every host in the list at once, and to accept the
first response (and eventually reject any other responses).  This is
analogous to a broadcast request for booting.  I'm not sure if the
gateway did this in practise, or just tried the hosts in sequence.

So, in summary, TFTP is a good bootloading protocol, without
modification:
	- It supports a pseudo-broadcast mode of booting request.
	- It has a transfer mode that works.
	- It is fast enough.
	- It is simple (the original TFTP bootloader fit into 2Kb of
	  ROM).
	- It is an internet protocol (you can boot through gateways -
	  for a while at MIT we had two gateways booting off a network
	  which had no other hosts on it.  Each booted through the
	  other.  Worked for weeks until the power flickered one day...
	  then we had to get out the old serial-line downloader).
Problems:
	- You have to derive an Internet address for the host to be
	  able to use an internet protocol to boot it.  On an ethernet
	  this is more of a problem.

	- You have to store both the names of the boot directories on
	  each boot-host and the internet addresses of the boot hosts
	  (in practise, there was only one boot rom that
	  had all the hosts and directories in it; each gateway could
	  not access some of the hosts in its table).
	  This problem is minimized in a homogeneous environment, since
	  the name of the directory can be the same everywhere.

	- It is an Internet protocol, so that broadcast is not a
	  "native" mode of using it.  If your nodes implement internet
	  broadcast (I guess sun's still use host number 0 for
	  broadcast, like the vaxen do...) you could theoretically use
	  it, although as Noel points out, there are advantages to being
	  able to boot through a gateway when necessary.

One compromise position might be to use a broadcast scheme to get the
booting information into the host, then use TFTP to boot the host. 
This would have the effect of compartmentalizing the nonstandard code 
in the system, and would add a more minor restriction to booting a
host.  Or use a "breath of life" scheme.  Have a host periodically
broadcast the booting information on the network in question, and have
the bootloader just wait for the promiscuous packet to arrive.  The
advantage of this scheme is that you don't have to have any broadcasting
booters on the local net -- they can use directed broadcast to send
the breath of life packets.

- Geof