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 MogulOne 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.