Will@cup.portal.com (Will E Estes) (04/16/91)
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). Thanks, Will Estes Internet: Will@cup.portal.com UUCP: apple!cup.portal.com!Will
erick@sunee.waterloo.edu (Erick Engelke) (04/17/91)
In article <41315@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >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). > I do this for my 500+ PCs because I could not be botherred doing an installa- tion for each. You need some method of getting ip numbers, I have something running similar to BOOTP which gets run in the batch file immediately after the packet drivers is loaded. My BOOTP-similar program can write the ip address to a file or to an environment variable. With NCSA, Clarkson CUTCP, and Waterloo TCP, you simply insert the line with the correct ip address into the ASCII configuration file using some automatic process such as the one I have described or you select BOOTP for the TCP stacks which support it. Beame&Whiteside's system includes an automated IP generation scheme which, if memory serves me correctly, uses the lowest n bits of the Ethernet address where n is (32 - the number of bits in the network mask). B&W also supports the normal methods listed below. For PCIP based products such as FTP, Wollongong, Beame&Whiteside, etc., you can: 1. Use BOOTP (I think they all support it) 2. Use the configure program with a batch file 3. figure out the data structure and write to it yourself Since you ask about research, the following is a description of what is being done, but not commercially available. The Waterloo TCP system when running on Watstar (a proprietary DOS network) need not be configured with an IP address. It uses one if so supplied, but otherwise requests the address from the the Watstar network. The Watstar system responds with the computers IP address, or generates a new one if the computer is new. Addresses are managed by the subnet's gateway, meaning the gateway never needs to arp a station because it is the authority. Erick -- ---------------------------------------------------------------------------- Erick Engelke Watstar Computer Network Watstar Network Guy University of Waterloo Erick@Development.Watstar.UWaterloo.ca (519) 885-1211 Ext. 2965
jbvb@FTP.COM (James B. Van Bokkelen) (04/19/91)
PC/TCP for DOS has included a BOOTP (RFC 951) client since 10/89. It helps a lot, but because of the limit on the BOOTP packet's size and the amount of space reserved for other items, it isn't the be-all and end-all for automatic configuration. The IETF Dynamic Host Configuration working group was chartered sometime in 1990 to figure out what to do next, but I don't know how much progress they've made since. Originally they were considering BOOTP extensions, but they may have swung over to developing a new protocol. One hard problem they're faced with is short-term dynamic IP address assignment, where a PC picks a new address on each boot, and uses it for the life of that bootload.... James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
db@argon.Eng.Sun.COM (David Brownell) (04/29/91)
> 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
jbvb@FTP.COM (James B. Van Bokkelen) (05/01/91)
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! .... We own a single 386i, but not a 'co-operating' net, and never before or since have we had such a vale of tears for the systems people. If you limit the scope of the problem, you can come up with an essentially proprietary solution. General solutions aren't so easy, as anyone who's ever installed a MAC-layer bridge connecting two previously happy Appletalk user communities can tell you. 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. There is lots of customer demand, but defining an interoperable, scalable solution to Dynamic Host Configuration is still at least partly a research issue (yes, I know of the broadcast name-claim schemes, but they don't scale, and all-knowing servers have to be duplicated, and the duplicates have to be kept in synchronization...). James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901