geoff@eagle_snax.UUCP ( R.H. coast near the top) (06/09/87)
Does anyone have any experience with either on-the-fly IP
address assignment or automated IP host installation?
Since we started shipping PC-NFS, several people have
expressed concern about using PCs as IP nodes and have asked if there
was any standard way of automating IP address assignment,
either per-session or once-only at first connection. Now
I know that there's nothing in the RFCs, but I seem to remember
some talk at the December '85 PC/IP - MAC/IP Workshop at the
Univ. of Maryland. Can anyone help jog my memory?
--
"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.comjis@BITSY.MIT.EDU (Jeffrey I. Schiller) (06/09/87)
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. It is a "configurationless" protocol. Ie. you don't preassign an IP address to some Ethernet address in advance of first use. Instead the first time a new machine (actually new ethernet address) shows up on the network it is assigned a semi-permanent IP address WHICH IT HAS TO DEFEND by responding to ARPS for its address. The biggest problem with using it on PCs is that (at least with PC/IP) when a PC isn't using a network application, it is deaf to the network. Is this still true with PC-NFS, or is the network software always active? Ifso then this protocol might work for you. I actually have a draft of this document but have been hesitant to give it much distribution until I test it. However if there is sufficient interest I can make it available (provided people respect its draft status). -Jeff
Mills@UDEL.EDU (06/09/87)
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
CERF@A.ISI.EDU (06/09/87)
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
jis@BITSY.MIT.EDU (Jeffrey I. Schiller) (06/10/87)
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
jis@BITSY.MIT.EDU (Jeffrey I. Schiller) (06/10/87)
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
deering@PESCADERO.STANFORD.EDU (Steve Deering) (06/10/87)
The other problem with "defended addresses", besides the issue of PCs not always running their networking software, is that the owner of an address may not hear a challenge if the network is partitioned. A local-area network can be partitioned by failure of a MAC-level bridge, temporary disconnection of a host-to-network cable, etc. Steve Deering
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (06/11/87)
We've had a great deal of success using Bill Croft's BOOTP (RFC 951). As currently implemented, a network node's IP address is permanently assigned to a particular ethernet address and put in a configuration file read by the bootp server. Address assignment is done once when the machine is booted, via a UDP broadcast. We've extended the protocol to also announce the subnet mask and default gateway along with a number of server addresses. There is really no reason why the BOOTP server could not be extended to dynamically create new addresses for unknown ethernet addresses. A scheme similiar to Jeff's could be used to defend them afterwards, or the server could try to maintain some sort of database. Dynamic address assignment is also done for Macintoshes. I'm not quite sure how it works (I'm sure someone else can fill in the details), but the Kinetics gateways are given a range of addresses which they dynamically assign to new Appletalk nodes. I think it uses NBP to request an address and later defend it. Drew
geoff@eagle_snax.UUCP (06/11/87)
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 <decvax!ucbvax!BITSY.MIT.EDU!jis> > > 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 <decvax!ucbvax!argus.stanford.edu!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
lazear@GATEWAY.MITRE.ORG (06/12/87)
Geoff, I am surprised nobody has mentioned the issue of how does someone off-net ever address anything to the PC-host? There has been no notion of updating a name server to be able to tell remote systems the PC's address (what if the remote system caches it?). I think this impacts the duration of the IP/PC binding, since re- using an IP address means former associations are now void implicitly. Maybe I don't understand the environment enough. I guess the highly transient association of PC and IP address is OK if the PC always initiates the communication. Perhaps this is to download files for local work, perhaps just to act as a terminal emulator (where the user logs in at the mainframe across the net). The issue of positively identifying that this PC is who it says it is gets lost if IP address is floating each time the PC is turned on. Perhaps the mainframe (as I characterize non-PC hosts) has no need to contact the PC or try to deliver datagrams to it until the PC comes up and announces itself? Walt Lazear
ravi@ubc.CSNET.UUCP (06/14/87)
Hi, Dynamic address assignment has been employed in some experimental distributed operating systems. Though the host addresses thus assigned are not IP addresses, the techniques may be adapted to assigning IP addresses dynamically. For example, the V distributed operating system developed at the Stanford University uses a dynamic address assignment protocol similar to that of your "defended addresses". The system has a large pool of assignable addresses from which a booting machine picks up one (based on random number generation) and solicits any objections to its usage of the address. A machine that may already use the address "defends" the address by raising an objection. If no objection is received by the booting machine, it starts using the address. Otherwise, it picks up another one and tries again. We at the University of British Columbia have designed a variant of the protocol to make sure that the addresses are non-reusable in the "near future". Both schemes are distributed and do not suffer from single-point failures. Our protocol additionally guarantees non-reusability of addresses if reliability is a concern. We have a technical report which describes the implications of such dynamic bindings between host and network addresses, how cached bindings are invalidated/corrected in a dynamic environment such as when machines fail and come up later, resolving multiply assigned addresses (because of network failures), etc. The report is awaiting publication in "Computer Networks and the ISDN" journal. If any one wants the report, send me an e-mail. Ravindran Dept. of Computer Science, Univ. of British Columbia, Vancouver B.C. V6T 1W5, Canada. Ph: (604) 228-5485
geoff@eagle_snax.UUCP ( R.H. coast near the top) (06/22/87)
In article <8706121831.AA05760@saturn.mitre.org>, lazear@GATEWAY.MITRE.ORG writes: > Geoff, > I am surprised nobody has mentioned the issue of how does > someone off-net ever address anything to the PC-host? There has > been no notion of updating a name server to be able to tell remote > systems the PC's address (what if the remote system caches it?). > I think this impacts the duration of the IP/PC binding, since re- > using an IP address means former associations are now void implicitly. Quite apart from the (not unreasonable) idea of off-net nodes addressing the PC, an off-net server system may well need to map the client PC's IP address into a hostname or vice versa. For example, the Sun NFS mount daemon performs a consistency check on the mount request by taking the hostname passed in the RPC arguments, doing a 'gethostbyname' on it, and verifying that the RPC did indeed originate from that address. It can then confidently use the name to check the 'netgroups' access control list. As you say, a completely dynamic address assignment scheme would require that the name-address mapping be propagated to all servers which might have cached a previous mapping. > .... Perhaps the mainframe (as > I characterize non-PC hosts) has no need to contact the PC or try to > deliver datagrams to it until the PC comes up and announces itself? > Walt Lazear As I've indicated, I think this is unduly restrictive. But again, it all depends which problem you're trying to solve: sharing scarce resources (IP addresses) or making the installation of network nodes simpler and less error-prone. -- "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
gnu@hoptoad.uucp (John Gilmore) (06/23/87)
I think a lot of the discussion on this is not relevant to the original
request. People are trying to solve the problems that arise when a
host wants to move around to various networks and "plug in" and just
work. That's not what was asked for, as far as I recall.
The problem is how to take a new machine and get it on the net. Not
move it around, just get it on the net in ONE place. This should not
require superusers to mumble incantations to files in obscure places;
it should not require sending email to Jon Postel; ideally you should
plug in e.g. a diskless workstation and it should tell the net it wants
to boot. If it is an unknown host, some friendly local site can assign
it a temporary internet address (via a name server with online update),
tell it its address, and offer to boot it with an initialization
program. This program would display a pretty picture on the screen
(Thanks for buying me, see how easy I am to operate!) and ask what
hostname, username, and password you want, and which file server if
there are several. These would update the appropriate entries in the
name server database, the system would boot, and you'd be up and
running without following 50 pages of detailed directions in an obscure
manual.
The original question from SunEast seemed to be for the PC world,
so you can substitute "dumb host with generic software on a floppy"
for "diskless workstation" if you like.
I have never understood why we on Unix and/or the Internet seem
content to administer things with humans editing ASCII files and then
converting them to database format with little utility programs, while
commercial systems have been able to apply hundreds of transactions a
second to big online databases for many years.
So to get back to [what I think is] the question, are there any defined
protocols for assigning a new Internet address for a new machine ONLINE
and in REAL TIME? Note that the boot ROMs (running RARP or BOOTP or
whatever) would not do this; the SERVER which is talking to the new
machine would use this protocol to assign the new address.
--
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu gnu@ingres.berkeley.edu
Kudos to Stargate for permitting redistribution. May the Source be with you!