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 disguise 

    Date:  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