Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!decvax!eagle_snax!geoff From: geoff@eagle_snax.UUCP Newsgroups: comp.protocols.tcp-ip Subject: Re: Automatic IP address assignment (long) Message-ID: <121@eagle_snax.UUCP> Date: Wed, 10-Jun-87 22:37:31 EDT Article-I.D.: eagle_sn.121 Posted: Wed Jun 10 22:37:31 1987 Date-Received: Sat, 13-Jun-87 07:08:28 EDT References: <117@eagle_snax.UUCP> Lines: 174 Keywords: IP address installation automation PC Summary: Let me focus in a bit... Thank you to all to replied on this subject. Most copied their comments to "tcp-ip@SRI-NIC.ARPA"; let me quote a couple, for selfish reasons (see below): >From: Jeffrey I. Schiller > > I have been working on and off on a protocol to assign IP >addresses on the fly. The idea being based on a combination of ARP and >an RARP mechanism. I am putting together a document that I will >submit as an RFC after I have done some coding and made sure it is a >"sane" approach. > [...I'll let Jeff speak for himself...] > >I have placed a *DRAFT* copy of this document in /pub/dyn.doc >on BITSY.MIT.EDU (18.72.0.3) feel free to pick up a copy. > > -Jeff ----------------------------------------------------------------------- > >From: Raman Khanna > >We were using RARP for this purpose - RARP server had a static ethernet >address to IP address translation table and PCs were assigned IP address >on connection. Problem with RARP was that it did not propagate through >our routers and, therefore, we had to use a RARP server per subnet. > >Recently we made a switch to Bootp that overcomes the problem stated >above. > >raman khanna >Stanford ----------------------------------------------------------------------- >From: decvax!ucbvax!UDEL.EDU!Mills > >Geoff, > >See RFC-891, which among other things describes the scheme used by the >so-called fuzzballs. The idea is that a newcomer squawks his IP address >in a hello packet and then the local-net routing algorithm bumps and >grinds to match. The scheme allows virtual hosts to pop up anywhere >touched by the algorithm, even if a different network. The scheme is >used for many permanently attached hosts, as well as dial-up hosts. > >Dave ----------------------------------------------------------------------- >From: decvax!ucbvax!A.ISI.EDU!CERF > >This sounds like the IP equivalent of NETBIOS which suffers from the >need for the acquirer of a (name) (IP address) to DEFEND it whenever >someone else tries to take that (name) (address). > >Maybe an improvement would be to have a server which does the >assignment? A bit like a name server... > >Vint > All of which suggests that the problem of on-the-fly IP address assignment is in good hands. However, the once-only case didn't get addressed, and I guess that's where my primary focus lies. Most of those who replied were clearly concerned with sharing a limited set of IP addresses among a large but transient population of clients. This is clearly a major problem, particularly in Universities, and I don't want to belittle the problem or the proposed solutions. In contrast, I had been focussing on an ease-of-use question: how best to help a network-naive user "plug'n'play" a system into a network in which it will operate for some time. For good ergonomic reasons it makes sense to focus on making the initial contact with a system simple and relatively foolproof. If I can get this one right, I am prepared to accept the overhead of human involvement in resolving some types of situations which typically occur further up the user's learning curve: for example, changing the Ethernet controller (and thus the Ethernet address) of a system, or changing its name. (For anyone who wonders about the extent of this passion for ease-of-use, come over to Sun ECD and I'll show you the "pizza movie".) Although at first sight this problem may seem to be solvable using the "resource-sharing" techniques described by others, I think there's a fairly major difference. I believe that for many users the most important attribute of the system the work with is consistency; once a system has been installed they want it to work forever(!). The idea that one day they power it up and it reports that it can't join the network because all addresses are in use is alien - a network address is like a phone number, right? [If IP addresses had no user visibility this would be less painful, but.... well, just take a look at the last line of Jeff's mail above.] Since I'm mainly concerned with automating the process of making a (relatively) permanent name-address binding rather than something more transient, many issues (such as "address defense") are irrelevant. Let me now describe the kind of model I was thinking of: (1) The (client) system RARP's as usual. This is a new node, nobody knows about it, so nobody replies. (2) The client broadcasts an IARP (Initial Address Resolution Protocol) request including its Ethernet address, a suggested hostname and a descriptive string (see below). (3) If there is an IARP server on the net, it can return any of the following responses: OK - This is the first time the node has been connected to the net. An Internet address is assigned, the name is registered, and the Ethernet-IP address mapping is stored for RARP purposes. The client should start over by RARPing for its IP address, etc. OK-MOVED- the client's Ethernet address was already recorded in the RARP tables with an IP address which mapped to the required hostname, but the IP address corresponded to another network (or subnet). The system assumes that the client has been physically moved and connected to a new net. The IARP server assigns a new IP address, deassigns the old one, and updates all the maps. DUPNAME - the hostname was in use, and there's either no Ethernet address associated with the corresponding IP address OR the Ethernet address is different from that of the client. BADNAME - the client's Ethernet address was recorded in the RARP tables, but the IP address was not on this network AND the hostname was wrong. (Assumption: this node has already been configured under a different name.) NOADDR - the server was unable to assign an address; a message may be provided to further explain the failure (e.g. site policy, no addresses available) (3) Subsequently the client RARPs, and can then use an inverse name lookup to verify that it is who it thinks it is... (Note that this requires a fix to most versions of RARP, which will happily return an Internet address even if the network number does not correspond to the network from which the request originated. I have seen people's hair go gray overnight with this one.....) The idea of passing over a string of descriptive information about the client is that it may help an IARP server in setting up the environment for the client. For example, if the string read "SUN 3/50 DISKLESS" a suitable IARP server might construct the necessary network boot files before replying. This is a slippery slope: imagine having IARP servers from several competing vendors each of which knows how to (and is prepared to) set up only its "family" clients..... There are three obvious problem areas. First, and probably the least serious, is one of implementation: for Unix we're probably looking at one more chunk to hack into the kernel, since we're not using IP at this point. (Raw sockets tend to have rather undesirable performance side-effects unless some low-level filtering can be specified.) Second, the IARP server may need some significant amount of time to set up the environment before it can send an OK or OK-MOVED; to avoid client time-outs the server may need to send some kind of keepalive (e.g. a WORKING packet) to prevent the client from giving up. Thirdly we must address the problem of how we cope with multiple IARP servers on a single Ethernet. (Just another implementation detail.:-) Finally I should emphasize that all of this represents my personal thoughts on how we can get the guru out of the loop for the average user of these systems, and doesn't reflect the policies, plans or products of Sun Microsystems Inc. -- "You want a disclaimer form? Next window, please..." Geoff Arnold, Sun Microsystems East Coast Division (home of PC-NFS) UUCP: {ihnp4,decwrl,...}!sun!garnold ARPA: garnold@sun.com