ISC Dynamic Host Configuration Protocol
DHCP Distribution Version 1
Current release: Version 1.0 Patchlevel 2
Version 1 of the ISC DHCP Distribution provides a reliable
version of the ISC DHCP server for sites which wish to deploy
it in a production environment. This release has been in a feature freeze
since November of 1996.
The source to the ISC DHCP Server is freely available at http://ftp.isc.org/isc/dhcp/dhcp-1.0-history/dhcp-1.0pl2.tar.gz.
Version 1 of the ISC DHCP Distribution includes just a DHCP Server.
It should be noted that version 2.0 contains many bug fixes and
changes that make it far more compliant with the DHCP protocol, so it
is not recommended that even conservative site administrators consider
1.0 for any new installations.
For more details, see the README file.
- NetBSD: Full functionality
- FreeBSD: Full functionality
- BSDI BSD/OS: Full functionality.
- DEC Alpha OSF/1: Full functionality.
- SunOS 4.1.4: Full functionality.
- Ultrix: Full functionality.
- Solaris 2.5: Partial functionality: only systems with a
single network interface are supported.
- Linux: Partial functionality: only systems with a single
network interface are supported.
- HPUX: Partial functionality: only systems with a single
network interface are supported.
Changes in Version 1.0 Patchlevel 2
- This Patchlevel contains two significant security bug fixes.
- Fix two more potential buffer overflow problems.
- Disable certain warnings on Solaris.
- Include different headers on Linux 1.x and 2.x.
- Fix stupid typo in cons_option call in dhcp.c which caused long dhcp
packets to be sent incorrectly.
- Fix ancient typo in memory.c.
Changes in version 1.0 beta 1 patchlevel 1
- Fix two potential buffer overflow problems.
- Clarify socket API error message on multiple interfaces.
- Fix broken comparison that was setting IP source address to zero.
- Only return 64 bytes of options to BOOTP clients, as specified in
- Documentation fixes.
Changes in Version 1.0 Patchlevel 0
- Minor adjustment to dhcpd.8 documentation.
Changes in Beta 5 Patchlevel 17
- Added a man page for dhcpd.leases.
- Updated README to answer some frequently asked questions.
- Fixed a compile problem on Solaris 2.6.
- Support interface aliases on Solaris.
- Print day and month with leading zero in lease files if less than ten,
for easier parsing by perl/sed/awk scripts.
- Never make the lease database world writable, even if dhcpd is invoked
with a bogus umask.
- Fix DHCPRELEASE handling (before, addressed would never be released.)
- If there is more than one lease for a particular client on a particular
network, find the lease the client is asking for so as to avoid a cycle
- If a BOOTP request is received from a particular client and that client
has previously received a DHCP address, make sure that we still find a
valid BOOTP lease so that we don't cycle through addresses.
- Remove server-identifier option from documentation, other than to document
that it has been deprecated.
- Don't give up if we get an EINTR or EAGAIN while polling or selecting
- these return statuses can occur spuriously without indicating a fatal
- Do not select for exceptions, since we don't handle them. This was
causing massive CPU consumption on some systems.
- When a DHCP client has been assigned a fixed address but had previously
had a lease, it will request the old leased address. In such an event,
send a DHCPNAK so that it will discover its new static binding.
Bugs fixed in Beta 5 Patchlevel 16
- When the DHCP server is restarted, it rewrites the lease database.
In Patchlevel 15, however, it added one day to each date it read out of
the lease file and then wrote this new date back into the lease file, so
that each time dhcpd was restarted, it would increment the start end end
times of each recorded lease by one day.
- The DHCP server would fail to acknowledge unicast DHCPREQUEST messages,
which meant that the client had to get to the point where the lease had
almost expired before it could successfully renew. This caused some clients
(notably Win95) major problems.
Bugs fixed in Beta 5 Patchlevel 15
- When the server saw a DHCPREQUEST for a client that it knew had a lease
on a different network, it would release that lease. This behaviour is
incorrect according to the protocol - there is nothing in the protocol
that says that a client can't simultaneously hold a lease on two addresses
on two different networks.
- On little-endian machines (e.g., intel machines and DEC machines),
if a client requested that responses to it be broadcast rather than unicast,
this request would not be honored because of a byte-swapping error.
- The server would print a banner on startup and then go into a background
(daemon) mode. If there was a parse error in the dhcpd.conf file, this
was not detected until the server had gone into the background, and thus
there was no immediate notification. This caused service failures for some
users which were difficult to diagnose. Dhcpd now continues to log messages
to the console until after it has successfully parsed the config file and
lease file. Also, if dhcpd runs into a problem which causes it to exit,
it now logs the message ``exited'' at CRITICAL priority, which should show
up on the system console.
- On Linux, spurious Host Unreachable and Connection Refused errors could
delay or foil the DHCP protocol by preventing the transmission of some
packets. This is because of a Linux kernel bug whereby bogus ICMP errors
can be communicated to the user program.
- DHCPNAK behaviour wasn't correct. In some cases, the server would not
NAK DHCPREQUEST messages if they were on the wrong network. This has now
- DHCPACK behaviour was incorrect. If a client sent a DHCPREQUEST for
an address that the server was not willing to provide, the server could
respond with a DHCPACK for a different address, when it should have ignored
- DHCPDECLINE processing wasn't being done correctly, with the result
that DHCPDECLINEs were effectively being ignored. DHCPDECLINEs are now
processed correctly - leases which have been DECLINEed are abandoned and
never again offered to clients, at lease until the administrator intervenes.
Warning: this bug fix does open up the DHCP server to a denial of service
attack that was formerly not possible - a client can successively request
and DECLINE every lease in the server's database.
- The lease file was being rewritten twice whenever it was time to rewrite
it. This no longer happens.
- BOOTP clients for which there was a host entry with no fixed-address
would not be allowed to boot if the dynamic-bootp flag and the boot-unknown-clients
flags were set.
- If an address range specified within a subnet declaration was on the
wrong network, dhcpd would silently mask off the erroneous network number
and mask in the network number from the subnet declaration, resulting in
incorrect and potentially harmful behaviour. Dhcpd now flags this as an
- The vendor-encapsulated-options option was specified as a text string,
which was incorrect. It is now specified as an arbitrary string of hexadecimal
values, so that a user may mock up vendor tags. This behaviour will eventually
be superseded by correct vendor option support.
- On Ultrix, the executable was not being installed in the correct directory.
- Got rid of change warnings in the configure script - these warnings
were instituted in August of 1996, and probably anybody who would be affected
by them is already aware of them.