Re: Automatic IP address assignment (long)

R.H. coast near the top (decvax!eagle_snax!geoff@ucbvax.Berkeley.EDU)
11 Jun 87 02:37:31 GMT

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 ( feel free to pick up a copy.
> -Jeff
>From: Raman Khanna <decvax!ucbvax!!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
>raman khanna
>From: decvax!ucbvax!UDEL.EDU!Mills
>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.
>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...

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

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:

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:38:19 GMT