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: <8883@ucbvax.ARPA>
Date: Mon, 8-Jul-85 20:48:08 EDT
Article-I.D.: ucbvax.8883
Posted: Mon Jul  8 20:48:08 1985
Date-Received: Tue, 9-Jul-85 07:02:17 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 83

From: Bill Croft 

John,

I guess what I would like to see in your new SUN Microsystems boot
proms (and adopted as an internet standard) is a TWO PHASE boot:

	(1) The 'server location / address assignment' phase could use a
	simple UDP broadcast packet exchange.  This exchange allows the
	booting client to locate boot servers by name.  The same protocol
	can also be used to assign an IP address to the client, given
	his ethernet address.  A sample packet exchange of such a protocol is
	shown below.

	(2) The second phase corresponds to the TFTP file transfer of
	the load image, given that the client knows his IP address,
	the servers IP address, and the file name.   Optionally the
	client may also load through gateways if he knows a default
	gateway address.

The boot is split into these two phases because the first is more volitile
and likely to change than the second.  Given that there are many TFTP
'boot/load servers' already running in the internet, it would be 
great to be able to utilize this resource.  I could imagine that your
boot code would have several entry points.  The default 'power up' boot
might go through both phases.  However a manual entry point would allow
the user to begin just the second phase, by supplying the IP addresses
and pathname string mentioned above.  Further, if the hardware had an
EAPROM capability, a 'default' second phase boot could be completed
automatically, if the person wished to make that setup option.

Note that both phases of this booting use ONLY INTERNET protocols.  This
is in contrast to the proposed RFC903 "A Reverse Address Resolution
Protocol".  RFC903 proposes that we use a new ethernet link type (not ARP,
but RARP) to allow a client to find his own IP address, given his ethernet
address.  But RFC903 can only be implemented with kernel modifications;  e.g.
by using the 'CMU packet filter' kernel code, or some new (as yet
unwritten and unstandardized) IOCTL interface to the kernel to load this
RARP information from the boot servers.

Instead what you can do is have the first phase server BROADCAST his
reply to the requesting client.  This is only one more broadcast than
the RFC903 case, but it now allows all the boot server processes to
be simple UDP servers at user level with no kernel changes.  Even if
you did find a way to modify the kernel for RFC903, how are you going
to get these mods out to all the different UNIX box companies?  What
about booting from TOPS20?  Etc.  I think the advantages are overwhelming
for restricting the boot protocol to use only IP/UDP.


EXAMPLE PACKET EXCHANGE OF FIRST PHASE BOOT

BOOTREQUEST packet from diskless client to server:

	IP DST: 255.255.255.255
	IP SRC: 0.0.0.0			[i.e. I don't know it yet]
	PROTO: UDP
	PORT: bootport
	----- packet data is:
	OPCODE: BOOTREQUEST
	MY ETHERADDR: xx xx xx xx xx xx
	FILENAME: xxxxxx
	SERVERNAME: yyyyyy		[optional]

Then the boot server answers back, with a broadcast [only to this first
exchange] so that we neatly bypass all the ARP bootstraping problems.
After the client has his real IP address (and that of the server),
a normal TFTP file read occurs.  The client only accepts a BOOTACK with
a CLIENT'S ETHERADDR that matches his own.

BOOTACK packet from server to client:

	IP DST: 255.255.255.255
	IP SRC: server IP address
	PROTO: UDP
	PORT: bootport
	----- packet data is:
	OPCODE: BOOTACK
	CLIENT'S ETHERADDR: xx xx xx xx xx xx
	CLIENT'S IP ADDR: xx xx xx xx
	DEFAULT GATE ADDR: xx xx xx xx
	FILEVERSION: xx
	FILEDATE: xx