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.

Ah, I can see how that could be a problem (a rather big one actually), 
I just assumed that the DHCP server, when comming up again, would 
start some kind of "discovery" (for want of better a word?) Whereby 
all DHCP clients would get a new lease, or some similar way of 
resolving this particular issue (which could hardly have gone 
unnoticed when the DHCP protocol was standardised?)

But of course, that might be exactly what was hinted at when there was 
talk about how a DHCP (according to the RFC) ought to behave (ie. it 
should try to maintain persistent mappings).

A possible solution (I'm shooting from the hip here):

What if m0n0wall were to treat ALL DHCP leases as (semi-)static, in 
that once a given host (MAC) was assigned an IP from the dynamic pool, 
m0n0wall would create a (semi-permanent) static mapping for it, and 
save this to the CF. Then, whenever that host requests an IP, the same 
one would be used (regardless of any crashes in the meantime). In case 
no more dynamic IPs (that haven't previously been made 
"semi-permanent") are available, the oldest, unused, of these 
semi-static mappings could be erased. In addition (if at all 
necessary) m0n0wall might once in a while (say once a day) "prune" any 
semi-static mappings that have not been in use for the period (or some 
other reasonable interval).

While not entirely eliminating occasional CF writes (ie. whenever an 
unknown/new host requests an IP and, if needed, that one time each day 
when "pruning" is done), it should still keep these to a bare minimum 
(at least in a great many network configurations, the exception being 
one where a lot of "foreign" hosts are continually connected to the 
network).

> 
> 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.
> 

This sounds quite reasonable, personally I do things in a three-fold 
manner, trying to get the best of both (all?) worlds:

- "Real" (as opposed to smaller, monolithic) servers and hosts needing 
a static IP don't use DHCP at all, just plain old static IPs.

- Those "smaller, monolithic" boxen (such as my printserver and my 
accesspoint) get a static DHCP mapping.

- The remainding "normal" hosts, without any need for a particular IP, 
get a dynamic IP via DHCP. (Although, currently I have no boxen 
falling into this category.)

I find this to be a good compromise between easy (central) managing of 
IPs (in this case limited to those less important small boxen and the, 
so far non-existent, "plain" hosts), and the stability gained with 
static IPs for the more important servers (ie. they don't need the 
DHCP server, aka. m0n0wall, to be running in order to function on the 
LAN), which should of course be kept to a minimum (as they will need 
manual reconfiguration in case of changes a subnet change or such).

But then again, what do I know, I'm just running my home network 
(albeit a rather complex one at that). I'm sure quite different 
considerations are needed for larger, cooporate, networks?


Adam.