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