wdw@aucs.UUCP (Bill Wilder) (11/20/88)
At our site, we have a number of PC's attached to an Ethernet and
this number will no doubt continue to grow. At the moment each PC picks
up it's IP address from a RARP daemon on a UNIX host (Sun-4/280 SUN-OS
4.0). It seems to me a shame to dedicate an IP address to each PC when
at any given time only a fraction of the PC's would be in use at the
same time.
Does anyone know of an RARP implementation that dynamically assigns
IP addresses from a pool? Obviously this would be appropriate only for
machines such as PC's in a public location where the current user may
care less what his IP address is.
--
UUCP: {uunet|watmath|utai|garfield}!dalcs!aucs!wdw
BITNET: WDW@Acadia
Internet: WDW%Acadia.BITNET@CUNYVM.CUNY.EDUlear@NET.BIO.NET (Eliot Lear) (11/21/88)
Wouldn't you run into a problem with ARP caches if you dynamically assign internet addresses to ethernet based machines? Eliot -- Eliot Lear [lear@net.bio.net]
morgan@polya.Stanford.EDU (Robert L. Morgan) (11/21/88)
wdw@aucs writes: > Does anyone know of an RARP implementation that dynamically assigns IP > addresses from a pool? Obviously this would be appropriate only for > machines such as PC's in a public location where the current user may > care less what his IP address is. There's much gnashing of teeth about this issue going on at several sites, including ours. There are, as far as I know, no distributable implementations yet. There are a variety of problems that need to be addressed with such a mechanism, including how the address is chosen, when it is OK to reuse it, ARP caches in other hosts and gateways on the LAN, robustness in the face of server crashes, etc. Stay tuned. - RL "Bob" Morgan Networking Systems Stanford
mar@ATHENA.MIT.EDU (11/23/88)
From: agate!bionet!lear@ucbvax.Berkeley.EDU (Eliot Lear) Organization: Natl Computer Resource for Mol. Biology Wouldn't you run into a problem with ARP caches if you dynamically assign internet addresses to ethernet based machines? Eliot Possibly, but probably not. If you dyanically assign a machine to an address that either hasn't been used before, or hasn't been used in a long enough time that everyone's ARP cache has timed out, you have no problem. If a machine is assigned an IP address for which ARP cache entries do exist on the local ethernet pointing to a different ethernet address, you still might not lose. Since you've just assigned this dynamic address, this new machine probably has an empty ARP cache which it will need entries in before it can talk to any other hosts. In the process of sending ARP requests for other hosts, those other hosts will get the new mapping for this host. So the only problem is if a machine which has a stale ARP entry attempts to contact this new machine, rather than the new machine contacting it. A way to avoid this entirely is to have the new machine broadcast an ARP reply when it starts up. This gratuitous ARP reply will prime everyone's cache with its information. Some operating systems do this (broadcast) already, and every ARP implementation following the RFC will get its cache primed. -Mark
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (11/23/88)
In article <Nov.20.13.30.19.1988.26043@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes: >Wouldn't you run into a problem with ARP caches if you dynamically >assign internet addresses to ethernet based machines? Age the arp cache. Then set a "re-use" timer on the IP address to be, say 3x, the arp cache time-out. Of course, how do you know when an IP address is released? There oughta be a protocol.
bzs@pinocchio.UUCP (Barry Shein) (11/23/88)
From: kwe@bu-cs.bu.edu (kwe@bu-it.bu.edu (Kent W. England)) > Age the arp cache. Then set a "re-use" timer on the IP >address to be, say 3x, the arp cache time-out. > Of course, how do you know when an IP address is released? >There oughta be a protocol. The arp cache in Unix is already aged, other O/S's might handle it differently although that's the obvious approach. The question is at what rate to age, there's a real thrash issue there. Another approach might be to re-arp on failure or just compare incoming packets with the current table (eg. I get a packet from host foo I already have the IP and ether address for, if I have a different pair in my table I flush them and either just use the new one directly or re-arp.) Unix currently considers a new hardware address a security breach ("Duplicate IP address for xxxxx!"). I don't think an IP release protocol in general would work since hitting the power switch on the machine will probably release the IP address in a dynamic environment, at least eventually. Just as well to just have a way to replace any stale address when needed rather than remove ones when they're not, storage issues are usually minor and aging occurs anyhow, particularly as caches fill. The other problem of course is security, the more ways I have to manipulate the arp cache with external packets the more ways I have to spoof or disrupt the system. Then again the current mechanisms are quite vulnerable to this already, but if it's being reworked one might think about these issues as it's made more complicated. Some sort of challenge might help (eg. I just received a packet which says that IPx is at a different hardware address, before updating my table send a packet to the old address and if it responds do something like alert the console.) No new protocol would be needed, just a ping or something. It still leaves open the problem of my jumping in and being an imposter for your system if I notice you down, an easy thing to do with a program and no manual intervention. -Barry Shein, ||Encore||
craig@NNSC.NSF.NET (Craig Partridge) (11/24/88)
> In article <Nov.20.13.30.19.1988.26043@NET.BIO.NET> lear@NET.BIO.NET (Eliot Lear) writes: > >Wouldn't you run into a problem with ARP caches if you dynamically > >assign internet addresses to ethernet based machines? > > Age the arp cache. Then set a "re-use" timer on the IP > address to be, say 3x, the arp cache time-out. > Of course, how do you know when an IP address is released? > There oughta be a protocol. A protocol won't help with the release of IP addresses -- what happens if the machine goes down, or its owner disconnects his portable PC and walks away, before the machine gets a chance to release its address? I think any system one develops for reclaiming addresses has to assume the system might silently go away. Note that this is one reason why I feel that there is a difference between transient assignment (IP addresses dynamically assigned for short term use, and thus addresses that must be reclaimed) and one-time configuration assignment (unpack the box and have it learn its IP address once and for all -- you may want to reclaim addresses once every few years, but that can probably be done by hand). Craig
morgan@Jessica.stanford.edu (RL "Bob" Morgan) (11/24/88)
Kent England replies: > In article <Nov.20.13.30.19.1988.26043@NET.BIO.NET> lear@NET.BIO.NET > (Eliot Lear) writes: > > >Wouldn't you run into a problem with ARP caches if you dynamically > >assign internet addresses to ethernet based machines? > > Age the arp cache. Then set a "re-use" timer on the IP > address to be, say 3x, the arp cache time-out. > Of course, how do you know when an IP address is released? > There oughta be a protocol. Some people have allowed as how a broadcast ARP Reply containing an IP-address/Ethernet-address mapping will cause "most" hosts that hear it to enter the info into their ARP cache. This would allow a new assignment to be "set", presumably after confirming with ARP Requests that the previous assignment had been released. (It would also allow a nasty program to thoroughly mess with everybody's ARP caches, but we've had enough of nasty programs for the moment, I think.) So the question is, "most", or "all"? Does the ever-forthcoming Host Requirements RFC make reference to this behavior? - RL "Bob" Morgan Networking Systems Stanford
hedrick@geneva.rutgers.edu (Charles Hedrick) (11/24/88)
The Arp cache in BSD (at least 4.2) is aged, but not quite the way you need if you're going to be changing things around a lot. Entries stay in the cache as long as they're being used. So if you have some process retrying a connection to a given address with a retry time less than the cache timeout, it will never time out, even if the entry no longer points anywhere useful. Entries should time out eventually whether they're being used or not.
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (11/24/88)
Perhaps the right thing to do is to reset the ARP age timer on receipt of a packet from that (IP? Ethernet? both?) address; that will deal with persistent attempts to reach a host which has gone away.
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (11/24/88)
In article <8811231554.AA05701@pinocchio.UUCP> > bzs@pinocchio.UUCP (Barry Shein) writes: > > >I don't think an IP release protocol in general would work since >hitting the power switch on the machine will probably release the IP >address in a dynamic environment, at least eventually. Just as well >to just have a way to replace any stale address when needed rather >than remove ones when they're not, storage issues are usually minor >and aging occurs anyhow, particularly as caches fill. > >Some sort of challenge might help (eg. I just received a packet which >says that IPx is at a different hardware address, before updating my >table send a packet to the old address and if it responds do something >like alert the console.) No new protocol would be needed, just a ping >or something. It still leaves open the problem of my jumping in and >being an imposter for your system if I notice you down, an easy thing >to do with a program and no manual intervention. > > -Barry Shein, ||Encore|| Anyone working on dynamic IP address assignment ought to have a look at AppleTalk dynamic address assignment. See "Inside AppleTalk". Of course, AppleTalk takes dynamic assignment to services, names, and addresses which is one of the reasons it doesn't scale up well. But, no need to reinvent the wheel for internet address assignment.
eshop@saturn.ucsc.edu (Jim Warner) (11/27/88)
In article <8811221804.AA20970@TOTO.MIT.EDU> mar@ATHENA.MIT.EDU writes: > >A way to avoid this entirely is to have the new machine broadcast an >ARP reply when it starts up. This gratuitous ARP reply will prime >everyone's cache with its information. Some operating systems do this >(broadcast) already, and every ARP implementation following the RFC >will get its cache primed. > -Mark I'm not sure which RFC you're reading. If it's RFC826 I think you misunderstand some details. The last field of an ARP packet (request or reply) is the protocol destination address of the target. What do you propose to put in this field for a broadcast ARP reply? The IP broadcast address? This will not "prime everyone's cache." It will not prime anyone's cache. A match with the local IP address is required in this field to add a new entry (if that's what "prime" means). Now things aren't all that bad. RFC826 calls for all hosts on the wire to update an existing ARP entry on receipt of a broadcast ARP packet. A new entry will not be created unless the protocol destination address matches that of the recipient. It doesn't matter whether it is a request or a reply. I hauled out my Ethernet analyzer and checked this behavior for 4.3BSD, Sun OS3.5 and Cisco routers and they work the way they're supposed to. So the good news is that inventing a broadcast ARP reply isn't necessary. The first (normal) broadcast ARP request will have the same effect (updating old info) and doesn't require anything new. I think that the original direction of this thread was, "can we make some changes to a bootp server so that it can serve a large pool of PC-type clients by dynamicly assigning their IP addresses out of a (smaller) piece of the address space. I see three problems: 1. The bootp protocol works through subnet gateways so that one (or a small number of) bootp servers can service an entire network. Helpful subnet gateways forward these requests along staticly defined paths so that clients that don't have servers on their local wire can get service. But information is not carried in the request to indicate the originating subnet. Unless the bootp.tab data base contains entries binding Ethernet addresses to subnets, the bootp server won't know on which subnet to assign an address. 2. I presently run two bootp servers on separate computers. They work off identical static bootp.tab files. It doesn't matter which one responds first to a request because they provide the same responses. PCs have a reputation for rebooting frequently. How do I insure that when a user does cntrl-alt-delete that he will be reassigned to the same address he was using a few minutes prior? If I don't get him back with the same address, he can reboot ten times and tie up the entire dynamic address pool. Along the same lines, what happens to the pool if the bootp server reboots and can't remember the current dynamic assignments? 3. My boss. The last thing he does just before he goes home is pull up a Sidekick window on his PC to look up a phone number. He leaves for the day with his PC frozen in Sidekick -- with interrupts disabled. When he comes in the next morning and exits Sidekick, his PC still thinks it "owns" an IP address that was assigned 18 hours prior but that it hasn't been using or defending. Please *don't* suggest I get a new boss. I view the last problem as, by far, the more difficult. How can a bootp server determine that a dynamicly assigned IP address is free for reassignment in the face of clients as ill-behaved as MS-DOS PCs? jim warner U.C. Santa Cruz
db@eagle_snax.UUCP ( Sun ECD Software) (11/28/88)
In article <1378@aucs.UUCP> wdw@aucs.UUCP (Bill Wilder) writes: > Does anyone know of an RARP implementation that dynamically assigns > IP addresses from a pool? We ship one standard as part of the Sun386i workstation. We don't encourage use of RARP for this, but the option is supported. By default we use extensions to RARP that we call "Dynamic RARP". (An RFC on that is in progress.) A network policy option can be changed to also allow use of RARP, if the network administrator is convinced that this won't affect operation of an existing network. It usually requires some conversion, and in any case clients have to know how to deal with temporary IP addresses they've been handed. We use it as part of an automated system and network installation application. When diskful or diskless systems are set up on a network supporting automated installation, they first get an IP address using Dynamic RARP. Then they install themselves on the network, keeping that IP address, using an RPC protocol. The requirement is that any user can safely install a workstation (or PC) on the network just by plugging it in and powering it on, except in cases where a network administrator has decided that they should not be doing this (and set the relevant policy to control this). > Obviously this would be appropriate only for > machines such as PC's in a public location where the current user may > care less what his IP address is. There are a lot of ways to use such a feature. "Obvious" is not a phrase I'd apply to this decision! It really depends on the application you're constructing using dynamic address assignment. The way we use it is to set up a network of machines where all the system names (and addresses) have to be persistent, since each workstation will as a rule be serving data to others. We aren't focussing on sites with money to spend on dedicated servers, or which have any kind of expertise in networking. After that address is assigned, it's made permanent unless it times out first due to some kind of error (after 1 hour). Another way that dynamic address assignment might be used is to let a bunch of what I call "transient hosts" access the network. Not unlike Kinetics does with Macintoshes -- the address is bound for the duration of a session, and the clients of the address server advertise no network services and need no names. (But how to enforce that?) I especially like the example of contacting a commercial TCP/IP service provider over a dialup IP link: you don't know, or care, the IP network address in use at either end, but you want to be able to use the service knowing only its phone number and your own VISA/MC information. We've also discussed allowing automatic reconfiguration of networks. Imagine moving a workstation from one cable to another, and having all the naming databases (YP, BIND, etc) automatically updated with the new addressing information. Right now, the reconfiguration requires manual steps at a central server, but in principle it needn't. These last two get tricky when the system has substantial "identity", because the IP address no longer is part of that identity. How many of the Internet security models presume that IP addresses remain constant over very long periods? How many applications have that hidden assumption? And how many applications can really address the security problems of whether or not to trust their client (or server) ? Also, hosts make lots of assumptions about their "local" environment, ones which probably won't be valid in a different environment. I'm curious who is working on models that don't assume centralized administration, as with a BIND or YP server. Dynamic address assignment without a central control site would seem to be a requirement for small (potentially isolated) IP networks which can't afford a dedicated server. David Brownell dbrownell@sun.com Sun Entry Systems Software sun!suneast!db Billerica, MA -- David Brownell, Sun Microsystems East Coast Division {ihnp4,decwrl,hplabs,ucbvax}!sun!dbrownell "There is a time and a place for spontaneity."
braden@VENERA.ISI.EDU (11/29/88)
So the question is, "most", or "all"? Does the ever-forthcoming Host Requirements RFC make reference to this behavior? I believe that the ARP algorithm presented on (unnumbered!) page 5 of RFC-826 will cause all ARP entries to be updated with the mapping (Sender Protocol Address -> Sender Hardware Address) [i.e., (IP addr -> Ethernet address)] contained in any broadcast ARP request, either Request or Reply. Of course, you can thoroughly mess up everyone's cache this way; after all, such insidious subversion in a benigh cause is the essence of proxy ARP. The Host Requirements RFC does not comment upon this, assuming it is already part of every ARP implemenentation. It does discuss the need to cache validation, with timeouts one of the possible methods that is listed. Bob Braden
mar@ATHENA.MIT.EDU (11/29/88)
I was a little ambiguous with my wording. By "broadcasting an ARP
reply", I didn't mean for this broadcast to claim anything about the
broadcast address. If a machine broadcasts an ARP packet with it's
own IP and hardware addresses as both the requestor and the target,
then this will have the desired effect of updating the ARP caches of
every machine implementing ARP according to RFC826:
The suggested algorithm for receiving address resolution packets
tries to lessen the time it takes for recovery if a host does
move. Recall that if the <protocol type, sender protocol
address> is already in the translation table, then the sender
hardware address supersedes the existing entry. Therefore, on a
perfect Ethernet where a broadcast REQUEST reaches all stations
on the cable, each station will be get the new hardware address.
It turns out that it doesn't matter if you use a request or a reply
for this to work. I prefer to use a reply for asthetic reasons, since
I'm not requesting a response. The algorithm in the RFC to be
followed when receiving an ARP packet of any kind specifies that the
sender's information should be updated in your cache before you ever
look at the opcode or target addresses.
-Mark