static IP allocations in dynamic ranges -why not?

[Simon Hobson]

Dorsey, Chris wrote:

>My question:
>What is the technical reason why dhcpd cannot mix static addresses 
>within dynamic ranges?

I think a better question might be to ask "what is the design 
decision behind the restriction".

The issue comes up from time to time, and often from people migrating 
from a Microsoft server. To a certain extent, it's just a different 
design philosophy - Microsoft chose to use a system where you define 
a range and then exclude addresses from it*, ISC decided to let you 
just define the range you want to use.

* Complicated by the fact that on early versions (ie NT), once you'd 
defined a range you could not alter it - I've no idea if this is 
still the case. As a result of that restriction, it because common 
practice to define a range covering the entire subnet and then 
exclude the bits you didn't want to use for dynamic leases.

When defining the interface, the ISC team took the approach that it's 
a technical tool used by network admins who really should know their 
own network. On this basis, the interface assumes the admin knows 
what he is doing (ie won't use an address twice - dynamically and 
also for a fixed address host), but conversely doesn't constrain the 
more complex setups behind all the safety features.

Anyone who has worked with both will recognise the difference.
The ISC server offers a rich configuration environment, but is 
technically more complex to configure.
The Microsoft server provides a relatively easy to use GUI, but 
significantly restricts the capabilities to those supported by the 
GUI.


As to the way fixed addresses don't get automatically excluded, well 
it may help to step back quite a few years. In computing terms, a lot 
of years ! Unfortunately, the ISC page on the history of their DHCP 
server doesnt' actually cover it's history - only going back as far 
as version 3 which it states went alpha in March 1999. Prior to that, 
version 2 had been around for "quite some time", and I don't have any 
idea at all when version 1 first appeared. I see that RFC1541 goes 
back to October 1993 - when I was first finding out about this 
complicated thing called TCP/IP when I got dial-up access to this new 
fangled Internet thingy.

The (IIRC, it's at work so I can't look it up) first chapter of Ralph 
Droms and Ted Lemon's book "The DHCP Handbook" gives an overview of 
network configuration techniques when DHCP was first conceived. Back 
then, you either manually configured stuff, or you used reverse ARP 
(only gives an address, you still have to manually configure 
everything else), or you used BOOTP (still limited in config 
abilities, and address assignment was still static).

The ISC set out to build not just a production usable piece of 
software, but a reference implementation of the standards. I'd say 
the fact that it's almost the de-facto standard DCHP server on Linux 
distributions suggests they got something right ! Applying a bit of 
speculation, I'd think that their priorities were on getting the 
dynamic allocation/handling side of things right - and that's harder 
than you might thing once you start considering some of the obscure 
corner cases that can crop up. So it's easy to see why they made 
fixed-address host assignments something of an ugly duckling - as 
others have said, these go through a different and much simplified 
code path.

Although it's caused various issues over the years, there has never 
been a compelling reason to justify the effort involved in going back 
and changing this.

As an aside, some of the current limitations/problems stem from 
adherence to the standards - so it's really that the standards were 
'wrong'. That's easy to say with hindsight, you try predicting what 
computing will do in the next 17 years ! A good example of that is 
the difficulty faced by people wanting to use Option 82 (relay agent 
link identifier) as the key for address allocation - ie allocate an 
address to <whatever> is attached to a specific port on a piece of 
network gear. A proposal requiring a sponsor is to add a config 
option to override the default (and standards compliant) selection of 
database key - that would allow an admin to use Option 82 as the key 
and may fix a lot of issues for a lot of people.

17 years ago, switched networks were the exception - ethernet was 
still commonly that chunk of 1/2" yellow "hosepipe" draped around the 
building - or it's cheaper cousin the thinner version with more 
limited length restriction. The upstart twisted pair cabling was only 
just appearing on the scene, and was struggling with the cost of the 
hubs (not switches which were even more costly) it required.


Getting back to your other question ...
You may well want to look into Reserved Leases. So new that they 
aren't documented and don't have a user interface to configure them !
A reserved lease is just like any other lease except for two details :
1) It includes the statement (I think) "reserved;" in the lease - and 
editing the lease file is the only way to set/unset this.
2) Once set, the address will be bound to that client and never 
re-assigned to another client.

But being otherwise a standard lease, it goes through the normal 
lease lifecycle - including Dynamic DNS updates if configured.

That means, if you want to toggle a client onto a fixed address, you 
can do it by setting it's lease to reserved. And when you no longer 
want it to be fixed, you can unset that.

In due course, it's been expressed that they'd like to have a user 
friendly way of administering this - but at the moment development 
effort is going into IPv6 support.


I hope that answers your question - effectively it comes down to "yes 
it's ugly in places, and with the benefit of 17 years of hindsight it 
might have been done differently".

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.