Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!exodus!argon.Eng.Sun.COM!db
From: db@argon.Eng.Sun.COM (David Brownell)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Request For Info On Dynamically Acquiring IP Addresses At Boot
Message-ID: <12397@exodus.Eng.Sun.COM>
Date: 28 Apr 91 21:22:23 GMT
References: <9104182024.AA09941@ftp.com>
Sender: news@exodus.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 51

> Can someone give me a reference to any research or commercial products
> that attempt to solve the problems of 1) allowing a PC or workstation
> to dynamically acquire an IP address at boot time, and 2) making it
> easier to install IP on a PC or workstation (i.e., an attempt to make
> things in general more dynamic so that each client doesn't have so
> much static information hard-coded into it at install time).

Well, the Sun386i is the first commercial product that I heard of that
did this.  That was back in 1988; I think they're off the price list
now.  A design requirement for the product was that, on cooperating
networks, unsophisticated users be able to unbox the workstation and be
reading their mail, on a new user account, 15 minutes after it was
physically cabled together ... and it worked!  Clearly, one of the big
parts of that process was setting up IP addressing and naming.  (Though
the marketing said otherwise, this part was independant of the rest.)

There were three phases.  First was characterizing the network to figure
out what kind of installation procedure was required.  (For those of you
that know the 386i, it wasn't an engineer that decided to require using
YP on all networks!!)  Second  (if dynamic installation was required) was
acquisition of a "transient" IP address.  These were unnamed, and were
liable to be reallocated after a longish time period; just what you get
if you pick an address manually, but guaranteed to be on the right subnet
and not otherwise in use.  The third step of dynamic installation was
persistent allocation of resources such as a hostname, configuration of
any diskless boot resources, and so on.

That process couldn't really be done without new protocols.  There are
lookup protocols, such as RARP/TFTP/BOOTPARAMS and BOOTP/TFTP, which
distribute configuration information that's already been manually set up,
but no standard protocols to reject installation or generate/select and
store configuration information.  (Such protocols might be used either
by an administrator with a GUI tool, or by a new workstation seeking to
install itself ... the difference could be purely what kind of policy the
site put in place.)  There is an IETF working group (DHCWG) to address some
of these problems, but I don't know their status.

It's sort of perplexing to me to see that nothing else along those lines
has become available.  I don't think the problem is really technical;
there are no unsolved problems beyond protocols getting defined and used.
I suspect that IP networking just hasn't (yet?) reached the kind of mass
market where real simplicity of operation is obligatory.  For now, most
sites seem to be happy with solutions requiring administrative involvment
on every aspect of network (re)configuration.

- Dave Brownell

--
"The traffic started getting rough; the chicken had to cross.  If not
for the plumage of its peerless tail the chicken would be lost.  The
chicken would be lost!" -- Gilligan