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: <8941@ucbvax.ARPA> Date: Wed, 10-Jul-85 12:22:05 EDT Article-I.D.: ucbvax.8941 Posted: Wed Jul 10 12:22:05 1985 Date-Received: Fri, 12-Jul-85 00:59:26 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 60 From: David C. Plummer in disguiseDate: 8 Jul 1985 1633-PDT (Monday) 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. 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; with a full backup in the file system). That is, instead of saying "What's your Ethernet address" it says "What's my protocol address." We almost did this at MIT, but the need didn't come up. If anybody is really interested I can try to find the full description (it's pretty trivial; just take ARP and rearrange a few fields). 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 Why 255.255.255.255. Shouldn't this be "CLIENT'S IP ADDR"? 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