Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!ames!ucbcad!ucbvax!BITSY.MIT.EDU!jis
From: jis@BITSY.MIT.EDU (Jeffrey I. Schiller)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Automatic IP address assignment
Message-ID: <8706092130.AA06295@BITSY.MIT.EDU>
Date: Tue, 9-Jun-87 17:30:39 EDT
Article-I.D.: BITSY.8706092130.AA06295
Posted: Tue Jun  9 17:30:39 1987
Date-Received: Fri, 12-Jun-87 04:49:55 EDT
References: <[A.ISI.EDU].9-Jun-87.14:54:34.CERF>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 28


	My approach is hybrid. The idea is that one host (in our
environment the gateway that connects the Ethernet to the rest of the
world) would maintain a RARP table. A booting machine will transmit an
Ethernet level broadcast requesting information about the
configuration of the Ethernet. This information serving host would
respond immediately with necessary info (network number, subnet mask,
range of assignable addresses etc.) and iff it has a RARP entry, the
IP address to use. Other hosts would respond after a random delay, but
without the IP address to use (in the event the information server is
down).

	If this doesn't get it an address to use, it chooses one in
the allowed range based on some hashing (algorithm yet to be designed)
function. The information server would then note this address (which
it would learn from ARPs) and remember it. However because the
information server might fail, it is necessary that before attempting
to use an IP address, that you ARP to see if it is in use, and yes you
must respond to ARPs in order to DEFEND your address (sigh...).

	The design goal is for a reliable (no single point of
failure), maintenance free system which tends to keep a given IP
address with a given host, but doesn't guarantee this. Ie. the rate at
which a given machine gets assigned a different address is minimized
(so if it was registering its address with a nameserver, the update
traffic would be reduced).

			-Jeff