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 CroftJohn, 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