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: <9015@ucbvax.ARPA> Date: Fri, 12-Jul-85 16:46:41 EDT Article-I.D.: ucbvax.9015 Posted: Fri Jul 12 16:46:41 1985 Date-Received: Sat, 13-Jul-85 12:48:06 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 58 From: Bill Croft---- >Date: 09 Jul 85 13:30:31 EST (Tue) >From: Christopher A Kent > >Your protocol sounds really nice, except that IP broadcasting doesn't exist. > Well it is implemented (perhaps non-standardly) in many Berkeley UNIXes. I hope that 4.3BSD implements the recommendations made by Jeff Mogul in RFC919/922. Those RFCs use various forms of an IP address consisting of 'all ones' or mostly ones to represent the broadcast address. ---- >Date: Wed, 10 Jul 85 08:45 EDT >From: David C. Plummer in disguise > >A more general scheme for this (actually, getting the IP address), which >unfortunately requires implementing a slightly new protocol set is to >implement inverse ARP (most servers can use existing forward ARP tables; > Dave, my argument was that it would be best to implement the first phase protocol as ONLY an IP/UDP protocol. This way the server can be a user-level process (on UNIX, Multics, TOPS20, etc.) without requiring kernel/operating system mods necessary for the "reverse ARP solution". The authors of RFC903 DID implement 'reverse ARP' here at Stanford, but it required using the 'CMU packet filter' kernel code to allow a user-level server process to access arbitrary ethernet link level packet types. Any 'reverse ARP' scheme is going to require kernel mods; given that there are many different kernels out there now, with each source maintained by different organizations, a boot protocol that does not require kernel modifications I think is an overwhelming advantage. In addition, the protocol I illustrated provided several other pieces of information that "reverse ARP" lacks: (1) it allows server specification by name, instead of just address; (2) it returns IP addresses of both the client and of gateways on the cable, to allow cross-net booting; (3) it returns 'qualified' filename / version / date information. Item #3 allows the client to specify a generic name in the bootrequest (e.g. 'unix') and then the bootreply from the server could contain a qualified name based upon database lookups at the server, indexed by the client's hardware address. For example, the person performing the boot may ask to 'boot unix'; the bootreply returned from the server may contain the qualified pathname '/usr/boot/vmunix123'; the second phase boot (TFTP) then does a transfer of this new name. >Why 255.255.255.255. Shouldn't this be "CLIENT'S IP ADDR"? > In the first phase, since the client DOESNT KNOW his IP address yet, if the server sent the reply to the client's (new) IP address, the server's ARP module would be unable to discover the client's hardware address. That is why the server must broadcast this bootreply packet. I claim the slight extra overhead of this extra broadcast is well worth it, since it allows our first phase server to use only existing IP/UDP transmission (instead of implementing new ethernet link types in the kernel).