At 02:54 PM 6/24/2004, Fred Wright wrote:

>On Thu, 24 Jun 2004, Adam Nellemann wrote:
> >
> > I'm not quite following the other discussion in this thread. What is
> > the need for a lease/mapping that survives a reboot (or more
> > correctly, a crash)? And isn't this what the static mappings are for
> > (they should certainly survive any kind of crash, altough the lease
> > would still have to be renewed I guess, but again I don't see the harm
> > in that?)
>
>It insures that existing access isn't killed by the loss of the lease.
>Without persistent mappings, the reincarnated server may reassign an
>address to a different client, resulting in two clients with the same
>address.
>
>Sure you can get around this with static mappings, but if you need to make
>all mappings static to make them reliable, then what good are dynamic
>mappings?  The intent is that you should only need static mappings for
>machines that need to be accessed as servers (and hence at known IP
>addresses).  Of course for maximum reliability you shouldn't use DHCP for
>servers at all, but sometimes the convenience of managing addresses
>centrally outweighs the reliability issue.
>
>                                         Fred Wright

I could be mistaken, but I believe I read somewhere that at least some 
implementations of DHCP the server would attempt to determine if anyone was 
using a specific IP address before assigning it from the pool, even though 
it should already know this.  That prevents things from happening like your 
pool being x.x.x.2 - x.x.x.254, the server is .1.  All available addresses 
in the subnet are allocated although they might not be in use.  Assume 
someone decides to do a static assignment to x.x.x.100.  Now there is a 
request for an IP from a client, and the server thinks .100 is free, but 
just to be sure it checks for a response from .100 and finds it in use.  It 
won't issue that IP.  I'm pretty sure that m0n0 doesn't react this way, and 
I'm not sure which of the MANY implementations I was dealing with at the 
time, but it's a rather simple means of allowing for example 2 DHCP servers 
on the same subnet serving the same addresses.  If one of them goes down, 
the other can and will continue to serve the entire subnet.  Most of the 
implementations I'm aware of don't handle this, they simply can't deal with 
overlap, and justifiably so.  The others I've worked with however don't 
restrict you from assigning a reserved address in the middle of the scope 
though.  If your scope is 1-200 and you assign 100 it simply skips 
it.  Part of the protocol as I recall is also for the client to normally 
request the address it last had.  I don't know that is a requirement or 
just common practice or possibly even a side effect of the way the server 
tracks things.

Sorry for the length, but that said, I was for some reason of the opinion 
that the original poster (sorry, I've totally lost track of who that was) 
really just wanted to assign a pool of addresses the size of the number of 
machines and be able to insure that once the address had been assigned it 
would never be reassigned to another MAC address.  Assuming that was the 
case, I see some reasonable scenarios for doing this.  For one, it provides 
the basic benefits of static IP assignments (the reason many of the DSL and 
cable ISPs use this method) without the headaches when network 
reconfiguration is required.  It isn't truly static, it is in fact long 
term non-changing.  As an added benefit it allow you to leave the IP alone 
but change things like default gateways, DNS servers, WINS servers, etc., 
on the fly without having to touch the client machines.  Simply shorten the 
lease times, make the changes, allow them to propogate, then reset your 
lease times to normal.  For another, this would prevent the case where 
someone brings in a foreign machine from the outside, plugs into the 
network, and promptly infects the entire network with some virus they 
either didn't know they had or failed to clean up before hand.  On the 
higher end of things that's normally handled by switches that include MAC 
level filtering.  No MAC entry in the switch? No access to the network 
since no packets get routed from your MAC address.  If someone really wants 
on yes they can spoof a MAC, etc., but this isn't really an attempt to 
provide security from the malicious attack, only prevent accidents from the 
normal Luser who doesn't understand or care about what the considerations 
of maintaining the network can be.

I agree, this whole issue has probably generated way more traffic than 
justified, but I guess it just peeked the interest of several folks, myself 
included, to see if there really was an elegant solution to the 
matter.  For whatever part I may have played in prolonging that condition 
(this post probably the worst offender to date) I offer my apologies to any 
who were inconvenienced or upset by it.   No offense was intended.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Whom computers would destroy, they must first drive mad.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Melvin Backus
Principal Wizard
Sleepy Dragon Enterprises
www.sleepydragon.net