Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!apple!bionet!agate!saturn!eshop From: eshop@saturn.ucsc.edu (Jim Warner) Newsgroups: comp.protocols.tcp-ip Subject: Re: Dynamic IP address assignment Keywords: arp bootp Message-ID: <5587@saturn.ucsc.edu> Date: 26 Nov 88 18:08:40 GMT References: <8811221804.AA20970@TOTO.MIT.EDU> Reply-To: eshop@saturn.ucsc.edu (Jim Warner) Organization: University of California, Santa Cruz Lines: 73 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