DHCP is designed with lazy network administrators in mind. Ideally, the administrator just configures a DHCP server, starts it up, and forgets about it. Users plug into the network and unplug, and the network administrator never hears a peep out of them - indeed, never even knows that they exist.
The less lazy the network administrator is, the less true this is. Network administrators that require that the DHCP server know a client's MAC address before assigning it an address create a lot of work for themselves: whenever a new computer is to be attached to a network, the network administrator must determine that computers's network MAC address and configure it into the DHCP server.
Network administrators may also choose to statically allocate IP addresses for some or all DHCP clients. One reason to do this is to allow DHCP clients to act as network servers - the DHCP server is configured with the DHCP client's well-known address, and every time that client boots, it gets the same well-known address. Of course, if all clients are given statically allocated IP addresses, this creates even more work for the network administrator.
Network administrators, lazy or otherwise, can learn a lot about network usage by watching the DHCP server. Because the DHCP server needs to keep a persistent record of what IP addresses are in use and by whom, the system administrator can examine that record to learn how many DHCP clients are using the network and potentially what DHCP clients are using the network. A wise network administrator will track this information so as to anticipate future demands on the network.
Unfortunately, DHCP server administration is not as easy as we'd like, even for the lazy system administrator. The DHCP protocol is somewhat complex, and a lot of clients and servers do a poor job of implementing it. The most frequently-asked sort of question on the DHCP server mailing list is ``when I try to boot my Acme DHCP client, it does the following weird thing - can you tell me why?'' Embedded devices (e.g., printers and ethernet switches) tend to be the worst offenders. The latest version of most O.S. vendors' DHCP clients work pretty well. In fact, the standard answer to this question is, "are you running the latest version of your client?"
The second most common complication that DHCP server administrators run into is getting over the h**p in the learning curve where they realize that the DHCP server really does need to know the network topology, and can't be told convenient lies about it. If you have a 20-bit subnet mask, the server needs to know that. If you are running two IP subnets on the same physical wire, the server needs to know that. Even if you're not serving IP addresses on the local subnets to which the server is attached, the server still needs to know the network number and subnet mask of those subnets, so that it can be sure that addresses is receives are not on that subnet.
The third complication is that although I make light of it above, DHCP server configuration is not completely trivial. In addition to having to describe the network's topology to the server, the system administrator must also choose what options to send to the client. Options are the parameters that the server sends to the client that tell it how to use the network - everything from obvious things like the subnet mask, default router, domain name and name server to more specialized things like NetBIOS configuration parameters for Windows machines, boot filenames and root partitions for network computers (a.k.a diskless clients), and so on.
Clients are allowed to request that specific options be sent, and if they do, the server won't send them any other options. Sadly, some clients do not request any specific options, but do freak out if they get options they aren't expecting. Windows NT 4.0 doesn't know what the broadcast address option does, for example.
The protocol also allows the client to declare itself to be part of a "Vendor Class", and in that case ideally the server should be able to send specialized options to that client. This can allow a clever network administrator to configure the DHCP server so that if a particular kind of network computer or diskless client is plugged in, it will boot up and operate without the user ever having to consult the network administrator to register the client.
The Actual Protocol
The Naive State
A DHCP client that is starting for the first time knows nothing about the network to which it is connected, and can't even make a guess about it. Such clients start up in the INIT state of the DHCP protocol, and try to find a DHCP server by broadcasting a DHCPDISCOVER message. If there are DHCP servers listening, and they choose to answer, they will send the client DHCPOFFER messages. These messages identify the server to the client, and also offer the client an IP address and a set of options. If more than one server responds, the client must choose which server to listen to. Often, clients do this by simply choosing the first server to respond.
The DHCPOFFER message doesn't actually mean that the client has an IP address. Because more than one server can respond, the client needs to communicate its choice to the servers. It does this by broadcasting a DHCPREQUEST packet, requesting the IP address it chose. The server that offered that address knows it has been chosen, and all other servers know that the addresses they offered can now be offered to other clients.
The server that was chosen responds to the client with a DHCPACK packet. Once the client recieves this packet (and no sooner!), it owns the address for a certain period of time, and can therfore start using it.
DHCP servers generally provide addresses to clients with a lease - that is, a time period in which the client is allowed to use the address. After that time period has elapsed, the client may no longer use the IP address. This allows IP addresses to be reclaimed when clients are permanently disconnected from the network. In order to avoid having the lease expire while the client still needs it, the client sends a DHCPREQUEST to the server (unicast, this time, since the client has a valid IP address) asking that the address be renewed. Normally, the server will comply, and the process will repeat indefinitely.
The Usual State
Usually, when a client starts up, it will remember the last IP address it had. It will therefore start in the INIT-REBOOT state, and immediately try to revive the lease it had before. It does this by broadcasting a DHCPREQUEST packet listing its old address as the one it would like to have again. If it gets no response, and the lease hasn't yet timed out, it can just go ahead and use it. In the most common case, where it's on the same network and the IP address it had before is still available, the server will send it a DHCPACK, and it'll be configured. By eliminating the DHCPDISCOVER phase, we save a packet exchange and cut the broadcast traffic on the network in half. This also decreases the load on the DHCP server.
Starting Up on a New Network
A client that is powered down and moved to a new network will have no knowledge of this change, so it'll follow the protocol described above and try to configure itself with a single packet exchange. The DHCP server on the new network will notice that the client is asking for an address on the network other than the one to which it is connected, and send it a DHCPNAK packet - basically, "you can't use that address!" At this point, the client reverts to the INIT state, described above, and presumably gets a new IP address on the new network.
Detecting Address Conflicts
One of the worst things that can happen in the DHCP protocol is for two computers to be assigned the same address. This can happen if the server forgets which addresses it has assigned. It can also happen when a user manually configures an address belonging to the DHCP server into a computer without going through the DHCP protocol so that the server knows the address is in use. It has even been known to happen because a DHCP client fails to follow the protocol, and thus continues to use an address after its lease has expired, or uses the address while it's in a state where it's not allowed to.
In order to minimize the consequences of such an error, both the DHCP client and the DHCP server are expected to test an IP address that's about to be leased before using it. The DHCP server does this by sending an ICMP Echo request to the address and waiting for a reply. The DHCP client does this by sending an ARP for the address.
If the DHCP server sends an ICMP echo reply for an address that it thinks is free, and it gets a response, it marks that address as in use and allocates a different address.
If a client sends an ARP request for an address that has been offered to it and gets a reply, it informs the server that the offered address is in use by sending a DHCPDECLINE message to the server. As in the ICMP Echo reply case, the server marks the address in use and allocates a different address for the client.
Getting Network Information When You Already Have an IP Address
The DHCP protocol was originally designed to dynamically assign IP addresses to clients. However, it turns out that over the years the list of DHCP options that can be sent to the client has grown to the point where a DHCP server can be considered a legitimate source for locating network services, independant of the address assignment problem.
In order to serve that need, the DHCPINFORM message was added to the protocol. A client may unicast the DHCPINFORM message if it knows the DHCP server's IP address, or it may broadcast it to the all-ones broadcast address. The server then unicasts its response to the client, which includes whatever options the client requested for which the server knows the value.
Weaknesses in the DHCP Protocol
The DHCP protocol has been very successful, for the most part, but it does have some weaknesses. There are a variety of Denial of Service attacks which can be used against it. There is as yet no standard protocol for having two DHCP servers which can back each other up. There is no real authentication. Client identification is typically specific to the network interface card.
Weaknesses in the DHCP Protocol
The DHCP protocol has been quite successful at accomplishing its purpose, but there are a few things that are missing, each of which causes a certain amount of pain under some circumstances. The obvious weaknesses are: susceptibility to denial of service attacks, lack of authentication, no good protocol for producing unique client identifiers, and no solution to the problem of providing transparent backup service in case the primary server fails.
Denial of Service Attacks
DHCP is theoretically very susceptible to Denial of Service attacks, although they don't seem to be all that common in practice. An attacker can broadcast a DHCPDISCOVER, wait for a response, send a DHCPNAK, and repeat until the server is out of addresses. A more clever attacker can pretend to be a DHCP server and provide a false address to a client so that it finds itself unable to actually use the network. A really clever attacker can provide the client with mostly correct network information, but tell the client that it is the local subnet router, so that the client sends all of its off-subnet traffic through the attacker.
In an environment where network users are generally trustworthy, it's possible to limit the likelihood of some of these attacks through the use of firewall filtering rules - don't allow DHCP packets to be sent into your network from the outside, and you can be sure that no outsiders will be able to perpetrate DoS attacks against you. Sites that have to be concerned about internal attackers have a much harder time. It's possible to come up with ways to combat relatively trivial attacks, but a really sophisticated attacker is likely to be able to overcome these obstacles. Even if the site is successful in preventing attackers from completing some of the attacks described above, there's always the incredibly trivial attack of just repeatedly sending DHCPDISCOVER packets to the server in hopes of chewing up so much computing power that the server is unable to respond to legitimate users. The good news is that attacks like this are relatively easy to isolate, since the the attacker must be present on the network for a long period of time in order for the attack to have any useful effect. A clever network administrator should be able to quickly track down the attacker and apply an appropriate LART.
It should be pointed out that a DHCP authentication protocol would not solve all Denial of Service attack problems. It does make it much harder for an attacker to exhaust the address space. What it does not do is to prevent an attacker from doing a resource exhaustion attack - in fact, it makes it easier. Cryptographically signing a message takes time - a lot of time. Verifying a signature likewise takes a lot of time. So an underpowered server that's perfectly adequate to the task of serving regular DHCP clients could well be brought to its knees by a clever attacker that just sends it huge numbers of signed messages for which the signature is not valid. The server has to verify the signature before it can discard the message, so a steady stream of these messages can prevent the server from properly serving legitimate clients, as well as causing resource starvation for other services that may be running on the same server machine.
No Interserver Protocol
One important aspect of network servers is the ability for them not to be single points of failure. Ideally, you'd like it to be the case that if your primary DHCP server fails, your secondary DHCP server can take over and keep things going with no interruption of service that is apparent to the client. Unfortunately, there is currently no standard protocol for doing this.
The closest we can currently come to this is to use a lease time that's long enough that a server is unlikely to remain inoperative for that long. The standard sendmail timeout is five days - a similarly long lease is likely to be enough to allow a DHCP client that already has a lease to continue operating until the network administrator comes back from a long weekend of skiing or SCAing. Unfortunately, this fails with clients that need to configure themselves for the first time or that are moved to a new network during the outage.
A second, complimentary strategy is to set up two servers. Each server is given its own set of addresses to dole out. When one server fails, clients that have already been configured continue using their addresses. New clients, or clients that have moved, are configured by the backup server. The only real problem with this strategy is that if a client moves away from Net X, is reconfigured with a new address, the server for its Net X address crashes, and then it moves back to Net X, it will get a different address on Net X than it had last time. How big a problem this is will depend on the client.
A third strategy is possible for those sites that choose to do only static IP address allocation. If the network administrator has to allocate IP addresses, and the server is not allowed to pick addresses on its own, then the network administrator can configure as many servers as are needed, all with the same list of static addresses. Because the servers don't have any autonomy, there is no chance of an address conflict occurring.
The IETF Dynamic Host Configuration working group is currently working on what is being called a failover protocol. This protocol is intended to allow one server to take over for another in the event of a server failure. Progress is being made on this, so I am hopeful that at some point something will be agreed upon and some actual implementations will happen.
Depending on who you talk to, this is either a burning issue or not an issue at all. The sad fact is that for most networks, if an unauthorized user wants to connect to the network, all that he or she needs to do is listen on the wire (or, if you have smart ethernet hubs, go look at another machine's configuration), guess an IP address that's not in use, and manually configure that address into his or her computer.
However, authentication could be helpful in preventing certain kinds of denial of service attacks. It could also be used to do a better job of accounting for legitimate network users in environments where users are generally considered trustworthy. Some users have proposed that the identification proved through authentication be used to allocate addresses based on access control mechanisms, so that IP address allocation on "Virtual LANs" could be done intelligently.
Another fine use for authentication that has been proposed, but for which I have yet to see any implementation, is an intelligent hub that speaks a private protocol with the DHCP server in order to really control a client's access to a network. With such a setup, a client coulkd actually be contained on its own little virtual subnet until it had authenticated. I have heard many requests for this feature, and DHCP authentication would definitely make it more useful.
The IETF Dynamic Host Configuration working group is currently working on a DHCP authentication protocol. At a meeting in early June of 1998, a great deal of progress was made. At the time of this writing, no formal protocol draft exists, but it appears to be closer to becoming a reality than it has ever been before.
Poor Client Identification
The DHCP protocol says that clients must identify themselves with a Client Identifier. This identifier is required to be unique to a particular subnet. If this identifier were well-chosen, it could be extremely useful. Unfortunately, the usual identifier that is chosen is the MAC address of the network interface card on the client. This is a big problem for mobile clients that can plug into arbitrary docking stations - the IP address will follow the docking station rather than the user. Likewise, when a network interface card is swapped out of a computer, the computer's IP address changes. This is not the behaviour most network administrators and users would like to see.
Unfortunately, coming up with a unique identifier is hard. The DHCP protocol doesn't provide a mechanism for doing so. Allowing the user to choose an identifier provides no guarantee of uniqueness. Failure to choose a genuinely unique identifier can be catastrophic, since the identifier is used to distinguish between clients - if two clients choose the same identifier, they will get the same IP address.
At this time, nobody appears to be working on this problem. Some folks working on a Network Computer have proposed and unilaterally implemented a new option called the Universally Unique Identifier, but the semantics for this option are really not meaningfully different from those of the client - the difference is that they have a seperate, out-of-band protocol for branding Network Computers with identifiers that are guaranteed to be unique and are (presumably) associated with the machine rather than the network card. This would have been a big win if they had chosen to use the existing client identifier field rather than declaring a new field, but as it stands it's not clear what will happen with it. In any case, this doesn't really solve the problem for non-NC devices.
The ISC DHCP Distribution
The ISC DHCP Distribution tries to be (and mostly succeeds in being) a complete reference implementation of the DHCP protocol. The most recent distribution includes a server, a relay agent and a client. There are three major versions of the distribution in existance. Release 1 is the oldest, least featureful and most stable. Release 2, currently in beta but soon to be finalized, is very stable and more featureful. Release 3 is still under development, with the first snapshot due out soon. The distribution is currently available as source code, with a very liberal license.
The Distribution uses a common code base to support the client, server and relay agent. This code base has been designed in such a way as to minimize operating system dependencies. It should be possible without too much work to port the server to non-Unix operating systems. Indeed, I know of one implementation that runs on a Tandem mainframe, which is not running Unix.
The ISC DHCP server provides support for dynamic and static configuration of DHCP clients. For backward compatibility, it also provides support for the BOOTP protocol. It even supports dynamic address assignment for BOOTP clients, which can be handy for bootstrapping a network boot PROM with BOOTP and then allowing the more modern operating system to use DHCP once it's been loaded.
The server is configured using a free-form flat file that is parsed with a recursive-descent parser. When changes are made to the file, the server must be killed and restarted. One area of future work on the server will be to provide a configuration mechanism, probably though HTTP, that allows a user to configure a newly installed server completely through a menu-driven web interface. The old configuration method will still be allowed, of course, and the configuration file generated through the web interface will be in the same human-readable format.
The server retains its persistent state in a lease database, which is also a flat file, and is parsed using the same parser that is used for the configuration file.. When an update is made to a lease, the new lease information is written to the end of the file. Since this could cause the lease file to grow without bound, the server periodically recreates the lease file from its internal database, eliminating duplicate entries.
All versions of the server have the ability to support so-called VLAN configurations, where more than one IP subnet is run on the same network wire, possibly with some traffic isolation performed in the switch. It is also possible to list client identifications in the configuration file and then prevent the server from interacting with clients that have not been so identified.
The ISC DHCP Client is based on a protocol engine submitted by Elliot Poger, who was working on the Stanford Mosquitonet project at the time.
The client can be configured using a file very similar to the DHCP server configuration file. This file can be used to specify what options the client asks for, what options it sends, what servers it will ignore, and what timing to use when running the protocol. It can also usefully be run using the default configuration, so it theoretically requires no user adjustment.
In order to configure the network, the DHCP client uses a system-specific shell script which knows how to prepare the network interface to run the DHCP protocol, how to configure the interface once the protocol has succeeded, and a variety of other things. Although the DHCP client compiles and runs on all platforms supported by the DHCP server, client network configuration scripts are not available for all such platforms, so effective support for the client is limited. The solution to this problem is for people who want to use the client on various platforms to start submitting scripts.
Probably the thing that is most different between the client and the server is that the client is supposed to be used by relatively naive users. As such, I would argue that it should be installed and run by default, out of the operating system's startup scripts. To date, none of the O.S. vendors that ship the ISC DHCP server by default do this, or even make this easy to do.
The Relay Agent
The ISC DHCP Relay Agent implements the complete relay agent portion of the protocol. Like the server, its ability to function on a system with more than one network interface is dependent on the network API provided by the operating system. The relay agent is configured with command-line arguments.
Release 1 of the DHCP Distribution includes just the DHCP server. It does not have some significant features and bug fixes that are present in the most recent release. However, it has been out for almost two years now, and can be considered very stable. It is being used in production at many sites with great success.
Release 2 of the DHCP Distribution includes a DHCP server, a DHCP client and a DHCP relay agent. The server supports pinging of addresses prior to assignment, and is more aggressive in disciplining misconfigured clients. It supports the ability to deny certain clients booting. The only important lack in the Release 2 server that is preventing it from coming out of beta is that certain poorly-behaved clients can cycle through the address pool. This problem has been reported at several sites. A partial fix to this problem has been implemented. As soon as this fix has been deployed and tested for a while, Release 2 will be finalized.
Release 3 will contain some significant new features. Features that are expected to be in the initial snapshot include conditional behaviour, client classing, the Relay Agent Information option and seperate allocation pools. We are expecting to have support for Dynamic DNS updates and DHCP authentication in the release before it is final. We do not expect to have an implementation of an Interserver Protocol in Release 3.
The first snapshot will contain the new conditional expression evaluator, which will allow options and addresses to be assigned conditionally based on what information the client sends. This expression evaluator is present in both the server and the client.
In the server, the expression evaluator can be used to send different options to different clients. For example, if a client says it's a diskless sun workstation, the server can give it parameters appropriate to allow such a workstation to boot. If it's an HP JetDirect card, the server can send it only the options a JetDirect card needs. This determination can be made in a variety of ways, including looking at the vendor prefix in the client's MAC address.
In the client, the expression evaluator can be used to provide default values or override values for options provided by the server. For example, a laptop with a local caching name server may normally want to do all DNS lookups through that name server. But if it is plugged into a network that's behind a firewall that blocks queries to foreign name servers, there's no way the local caching server can work. In order to use the local caching name server, the client would normally be told to prepend 127.0.0.1 (the IP loopback address) to the list of name servers provided by the DHCP server. Now it can do this conditionally, perhaps based on the domain name provided by the DHCP server - if the domain name doesn't match the domain behind the firewall, 127.0.0.1 is prepended - otherwise, it's not.
The server can now classify clients based on information they send in their requests. The most obvious example are options like the vendor class option - rather than writing a conditional rule, the system administrator can simply define a class based on the Vendor Class option and send a specific set of options to clients in that class.
It's also possible to set a per-class lease limit. If a client falls into a class with such a limit, then the server checks to see how many other clients that fall into that class currently hold valid leases. If the limit has been reached, the server will not interact with the client. The most obvious use for this feature is for cable modem vendors, who typically have all customers on one large, flat Virtual LAN, but have the cable modems send circuit identifiers in each DHCP request they relay. Each circuit ID gets its own class, with a per-class address limit. As many machines can received addresses at the client site as the limitations on that particular class allow. Classes can be allocated dynamically from a template, so that the network administrator need only write class rules for those classes that should not receive the default treatment.
Seperate Allocation Pools
Some network administrators have asked for the ability to provide more than one address allocation pool on a particular LAN, and to allow clients to be grouped into those pools. This can allow clients on a VLAN to be assigned addresses on different subnets based on what class they're in, for example. It can also be used to assign addresses in one range to clients whose MAC addresses are recognized, and addresses in a different range to clients whose MAC addresses are unknown.
Client Reinitialization Control
In Release 3, it is possible for a user program on a machine that is running the ISC DHCP client to cause the DHCP client to immediately go into the INIT-REBOOT state. The most obvious use for this is to allow a laptop that has just awakened from sleep to check to see if it is still connected to the same network. This could also be used by a client of a network service to recheck the client's IP address if network service suddenly seems to go away.
Dynamic DNS Updates
For about the past two years, an IETF draft has been in circulation that defines a method for allowing DHCP servers and clients to update the DNS using Dynamic DNS updates. There is little agreement on how this should work. There are actually two updates that need to occur. The A record, which maps the hostname (e.g., foo.bar.com) to an IP address, and the PTR record, which maps the IP address to the hostname. The disagreement is over which DHCP agent should update which record or records.
One way to look at this is from a security standpoint: who owns what record? It makes sense that the DHCP client owns the A record - its name. The server is responsible for doling out addresses, so it makes sense that the server own the PTR record. Also, if the client is roaming out of its own domain, it may not be possible for the server to update its A record - the server may not have any sort of security association in common with the client's home DNS server. So from this perspective, the client updates the A record, and the server updates the PTR record. Another argument in favour of this approach is that clients don't prove their identities to servers, so it makes little sense for servers to do secure updates to the DNS based on information from the client that has not been authenticated. So Chances are that when the dust has settled, this is what the final RFC on DHCP interactions with DNS will recommend.
There's a problem with this, though. First of all, nobody's really deployed secure DNS, although some vendors have sample implementations. Furthermore, no popular and widely-deployed DHCP client has any real chance of supporting Dynamic DNS updates in the near future. So even if having the client update the A record is The Right Thing To Do, in the short term, this is not going to happen.
So the alternative is to provide some mechanism for the client to tell the server what its name is, and for the server to evaluate the name and figure out whether or not to let the client use it. This is complicated, and will probably involve some kind of pattern matching against well-known names, as well as keeping track of what DNS names we've update for clients and not allowing clients to change names in the DNS other than those that the DHCP server has added to the DNS on behalf of clients. This still allows for some DoS attacks, but there's probably no helping that.
We plan to have support for Dynamic DNS updates in Release 3, but it won't be in the initial snapshot. Some folks at Rose-Hulman University have implemented Dynamic DNS updates for the ISC DHCP Server. Their code seems (based on my code review) to be pretty solid, but it's a bit too specific to their particular application, so I haven't yet integrated it. This is my fault, not the fault of the contributors - I just haven't had time.
We are also hoping to have a DHCP authentication protocol in Release 3. This assumes that we have a draft protocol prior to Release 3, which seems likely, but is by no means certain.
The server source currently builds on a fairly wide variety of platforms. Currently, these are all unix-like operating systems. The level of support varies from platform to platform, though. Because of the protocol requirement that the server be able to figure out on which network interface a packet arrived, ports of the DHCP server to some platforms do not support the use of multiple network interfaces.
An additional complication is that some DHCP clients are quite picky about the form of responses from the DHCP server. If a response is sent to the wrong broadcast address, the client may not be able to receive it. On various operating systems, the system administrator must go through some significant contortions to make sure that the right broadcast address is used.
The Development Process
Implementation of the ISC DHCP client began as the result of a grant to ISC many years ago. At the time, there was no free reference implementation of DHCP. Armed with funding and the free time that that created, I sat down, read the protocol spec and started figuring out data structures and writing a protocol engine. I had originally intended to use a BOOTP-like configuration file, but when I started trying to figure out how to map the data structures required by my implementation onto that file format, it quickly became clear to me that it was a bad idea. Because I wanted the software to be portable, I wound up writing my own lexer and parser.
The first time my DHCP server saw any real use was to boot my Significant Other's Win95 machine at home. I got this working pretty well, and was also able to test the BOOTP using my Mac running MacTCP. When I brought the DHCP server to Connectathon for the first time, though, I found a few problems in my implementation and wound up making some major improvements to it.
During connectathon, I managed to implement the persistent database, so that the DHCP server could actually be useful for dynamic address assignment. Shortly after that, I made the first public release.
Once the DHCP server was out there in the real world, I started to learn what interoperability really meant. It was truly amazing how many little edge conditions and problems were detected at customers sites that I'd never thought of and that we'd never seen at Connectathon. The quality of the server today, such as it is, is the result of many email debugging sessions with helpful users who took the time not only to complain about the problem they were having, but also to act as my hands in order to debug it. A number of users have actually spent quite a bit of time on their own debugging problems at their site and sending me fixes. During periods where I wasn't able to spend much time debugging the server myself, these folks have made it possible to do things like get out a final 1.0 release and fix some subtle bugs in the 2.0 server.
Quite a few improvements in the server came as a result of code submitted by users - for example, the initial BPF driver was contributed by Archie Cobbs. I rewrote parts of it, but having a working implementation that I could play with made all the difference. That original BPF driver has since spawned several similar drivers for the Ultrix Packet Filter, the Sun Network Interface Tap, and just recently a Solaris DLPI driver, contributed by Eric Negaard.
After a while, the protocol part of the server had fairly well stabilized. At that point, I started porting it to more platforms, and quickly came to know and love my favourite porting platform, Linux, and my second favourite, Solaris. I feel somewhat guilty for all the flaming I did about Linux early on in the development process - it seemed that every Linux user had a different set of header files and libraries, and that what compiled on one machine would fail utterly on another, even though both machines were running 1.0. I ran into similar problems on other operating systems, but not to that degree. Around the time the Linux 2.0 started reach a majority of Linux users of the DHCP server, I started to notice that these problems were somewhat diminished, and indeed I started to suffer more from the h***s I'd put in to make the server compile on older versions of Linux. Things do improve over time.
In version 2.0.33 of the Linux kernel, thanks to Elliot Poger, I finally got a feature I'd really been hoping for - the ability to distinguish on which network interface a packet had arrived. I'd had this ability on quite a few operating systems right from the beginning, but Linux had been one of the important platforms that didn't support multiple interfaces, and I received quite a few complaints about that.
Unfortunately, that progress has to some extent been erased recently - Linux 2.1 kernels no longer correctly support DHCP/BOOTP clients. On the other hand, Linux 2.1 provides the Berkeley Packet filter, which is another way to solve the multiple interface problem, and is in fact how I solve the problem on other platforms. BPF is exactly what I've been asking for since the beginning, so I'm pretty happy that it's now available. However, it's unfortunate that I have to implement to a different API on each version of Linux - it would be nice of some attempt were made to preserve common network APIs across releases. The DHCP protocol places unusual requirements on the network API that seem to hit on these incompatibilities quite frequently.
ISC doesn't specifically track users of our software. However, I can give some statistics based on mailing list subscriptions. There are about 1850 users who are subscribed to the DHCP announcements mailing list. There are 1150 who subscribe to the server mailing list. 850 subscribe to the client mailing list. In total, 2370 users are subscribed to one list or another.
I know of at least three universities that run the DHCP server and have an installed base on the order of 5000 workstations. I know of two users who have an installed base of 23,000 clients, one of whom is expecting this to grow to 100,000. His impression based on current performance is that this will not be a major problem. Quite a few sites have client bases in the 3,000 to 10,000 range, according to a recent survey one person did on the DHCP server mailing list.
I know of two commercial products that are based on the ISC DHCP server. The ISC DHCP Server is also the standard DHCP server for the NetBSD operating system and I believe it is what you get when you install the DHCP server on RedHat Linux.
I am less sure about what kind of use the DHCP client is getting. I occasionally receive enthusiastic testimonials from users, but I think I only know personally of ten such users. It's quite possible, though, that there are more, and that they just aren't talking.
I am aware of several users who have chosen to use the ISC DHCP Distribution because it provides a good basis from which to do research on the protocol or from which to develop new implementations of the protocol.
At the beginning of the project, I was fortunate to be able to operate on a grant specifically intended to support the ISC DHCP server. As time has passed, unfortunately, funding has dropped off. Paul Vixie, who got me started on this project and continues to employ me in other ways, has been kind enough to provide funding from time, but I have been operating with little or no funding for about a year now. The result has been a major slowdown in work on the DHCP server. I am doing my best to keep making progress, but things aren't moving very fast anymore.
Through most of the development process, I have maintained fairly tight control on the server and probably taken less help from the others than I should have. One of the ways I am hoping to speed up development is to try to open the development process a bit more. It will soon be possible to access the ISC DHCP source repository using anonymous cvs. I am hoping to slowly build a pool of experieneced developers who will have commit access to the source pool and be able to make progress on their own.
Answered By: Rank - 4/1/2006