- Internet Software Consortium
- Dynamic Host Configuration Protocol Distribution
- Version 3, Beta 2, Patchlevel 0
- January 21, 2000
+ Internet Software Consortium DHCP Distribution
+ Version 3, Beta 2, Patchlevel 1
+ September 1, 2000
README FILE
3.3 BUILDING IT
4 INSTALLING THE DHCP DISTRIBUTION
5 USING THE DHCP DISTRIBUTION
- 5.1 LINUX
- 5.1.1 IF_TR.H NOT FOUND
- 5.1.2 SO_ATTACH_FILTER UNDECLARED
- 5.1.3 PROTOCOL NOT CONFIGURED
- 5.1.4 BROADCAST
- 5.1.5 FIREWALL RULES
- 5.1.6 IP BOOTP AGENT
- 5.1.7 MULTIPLE INTERFACES
- 5.2 SCO
- 5.3 HP-UX
- 5.4 ULTRIX
- 5.5 FreeBSD
- 5.6 NeXTSTEP
- 5.7 SOLARIS
+ 5.1 FIREWALL RULES
+ 5.2 LINUX
+ 5.2.1 IF_TR.H NOT FOUND
+ 5.2.2 SO_ATTACH_FILTER UNDECLARED
+ 5.2.3 PROTOCOL NOT CONFIGURED
+ 5.2.4 BROADCAST
+ 5.2.6 IP BOOTP AGENT
+ 5.2.7 MULTIPLE INTERFACES
+ 5.3 SCO
+ 5.4 HP-UX
+ 5.5 ULTRIX
+ 5.6 FreeBSD
+ 5.7 NeXTSTEP
+ 5.8 SOLARIS
6 SUPPORT
6.1 HOW TO REPORT BUGS
- 7 KNOWN BUGS
WHERE TO FIND DOCUMENTATION
Documentation for this software includes this README file, the
RELNOTES file, and the manual pages, which are in the server, common,
-client and relay subdirectories. Internet standards relating to the
-DHCP protocol are stored in the doc subdirectory. You will have the
-best luck reading the manual pages if you build this software and then
-install it, although you can read them directly out of the
-distribution if you need to.
+client and relay subdirectories. The README file (this file) includes
+late-breaking operational and system-specific information that you
+should read even if you don't want to read the manual pages, and that
+you should *certainly* read if you run into trouble. Internet
+standards relating to the DHCP protocol are stored in the doc
+subdirectory. You will have the best luck reading the manual pages if
+you build this software and then install it, although you can read
+them directly out of the distribution if you need to.
DHCP server documentation is in the dhcpd man page. Information about
the DHCP server lease database is in the dhcpd.leases man page.
RELEASE STATUS
-This is the first beta release of version 3.0 of the ISC DHCP
-Distribution. Development of this release is approaching the point
-at which it will be frozen, and no significant new features will be
+This is the second beta release of version 3.0 of the ISC DHCP
+Distribution. Development of this release is approaching the point at
+which it will be frozen, and no significant new features will be
added.
-In this release, the server and relay agent currently work well on
-NetBSD, Linux after kernel version 2.0.30, FreeBSD, BSD/OS, Ultrix,
-Digital Alpha OSF/1, Solaris and SunOS 4.1.4. They run on AIX, HPUX,
-IRIX and Linux 2.0.30 and earlier kernels but support only a single
-broadcast network interface. They also runs on QNX as long as only
-one broadcast network interface is configured and a host route is
-added from that interface to the 255.255.255.255 broadcast address.
+In this release, the server and relay agent are currently fully
+functional on NetBSD, Linux systems with kernel version 2.2 or later,
+FreeBSD, OpenBSD, BSD/OS, Digital Tru64 Unix and Solaris. The
+software will also run on HP-UX, but only supports a single network
+interface. Ports also exist for QNX, SCO, NeXTStep, and MacOS X, but
+are not in wide use, with all that implies. We are not aware of an
+easy way to get this software running on HP-UX.
The DHCP client currently only knows how to configure the network on
-NetBSD, FreeBSD, BSD/os, Linux, Solaris and NextStep. The client
-depends on a system-dependent shell script to do network
+NetBSD, FreeBSD, OpenBSD, BSD/os, Linux, Solaris and NextStep. The
+client depends on a system-dependent shell script to do network
configuration - support for other operating systems is simply a matter
of porting this shell script to the new platform.
+If you are running the DHCP distribution on a machine which is a
+firewall, or if there is a firewall between your DHCP server(s) and
+DHCP clients, please read the section on firewalls which appears later
+in this document.
+
If you wish to run the DHCP Distribution on Linux, please see the
Linux-specific notes later in this document. If you wish to run on an
SCO release, please see the SCO-specific notes later in this document.
You particularly need to read these notes if you intend to support
Windows 95 clients. If you are running a version of FreeBSD prior to
2.2, please read the note on FreeBSD. If you are running HP-UX or
-Ultrix, please read the notes for those operating systems below.
-If you are running NeXTSTEP, please see the notes on NeXTSTEP below.
+Ultrix, please read the notes for those operating systems below. If
+you are running NeXTSTEP, please see the notes on NeXTSTEP below.
If you start dhcpd and get a message, "no free bpf", that means you
need to configure the Berkeley Packet Filter into your operating
To build the DHCP Distribution, unpack the compressed tar file using
the tar utility and the gzip command - type something like:
- zcat dhcp-3.0b2pl0.tar.gz |tar xvf -
+ zcat dhcp-3.0b2pl1.tar.gz |tar xvf -
On BSD/OS, you have to type gzcat, not zcat, and you may run into
similar problems on other operating systems.
CONFIGURING IT
-Now, cd to the dhcp-3.0b2pl0 subdirectory that you've just
+Now, cd to the dhcp-3.0b2pl1 subdirectory that you've just
created and configure the source tree by typing:
./configure
DYNAMIC DNS UPDATES
-An interim implementation of dynamic DNS updates is included in this
-release. This implementation is not built by default. To use this
-implementation, you must have installed the latest version of bind 8.2
-(see http://www.isc.org for more information about BIND). The
-configuration utility assumes that the BIND 8.2 distribution libraries
-and includes are under the /usr/local/bind directory, except on
-FreeBSD, where it assumes they are in /usr/local. If you have
-installed them elsewhere, you should set the BINDLIB and BINDINC
-variables in site.conf to override the values that will be set by the
-configure script from Makefile.conf.
-
-Assuming that you have BIND 8.2.2-P3 or later installed, you can build
-dynamic DNS update support using:
-
- ./configure --with-nsupdate
+A fully-featured implementation of dynamic DNS updates is included in
+this release. There are no build dependencies with any BIND version
+- this version can and should just use the resolver in your C library.
There is documentation for the DDNS support in the dhcpd.conf manual
page - see the beginning of this document for information on finding
USING THE DHCP DISTRIBUTION
+ FIREWALL RULES
+
+If you are running the DHCP server or client on a computer that's also
+acting as a firewall, you must be sure to allow DHCP packets through
+the firewall. In particular, your firewall rules _must_ allow packets
+from IP address 0.0.0.0 to IP address 255.255.255.255 from UDP port 68
+to UDP port 67 through. They must also allow packets from your local
+firewall's IP address and UDP port 67 through to any address your DHCP
+server might serve on UDP port 68. Finally, packets from relay agents
+on port 67 to the DHCP server on port 67, and vice versa, must be
+permitted.
+
+We have noticed that on some systems where we are using a packet
+filter, if you set up a firewall that blocks UDP port 67 and 68
+entirely, packets sent through the packet filter will not be blocked.
+However, unicast packets will be blocked. This can result in strange
+behaviour, particularly on DHCP clients, where the initial packet
+exchange is broadcast, but renewals are unicast - the client will
+appear to be unable to renew until it starts broadcasting its
+renewals, and then suddenly it'll work. The fix is to fix the
+firewall rules as described above.
+
+ PARTIAL SERVERS
+
+If you have a server that is connected to two networks, and you only
+want to provide DHCP service on one of those networks (e.g., you are
+using a cable modem and have set up a NAT router), if you don't write
+any subnet declaration for the network you aren't supporting, the DHCP
+server will ignore input on that network interface if it can. If it
+can't, it will refuse to run - some operating systems do not have the
+capability of supporting DHCP on machines with more than one
+interface, and ironically this is the case even if you don't want to
+provide DHCP service on one of those interfaces.
+
LINUX
There are three big LINUX issues: the all-ones broadcast address,
LINUX: BROADCAST
-On older versions of Linux (versions prior to 2.2), there is a
-potential problem with the broadcast address being sent incorrectly.
+If you are running a recent version of Linux, this won't be a problem,
+but on older versions of Linux (kernel versions prior to 2.2), there
+is a potential problem with the broadcast address being sent
+incorrectly.
+
In order for dhcpd to work correctly with picky DHCP clients (e.g.,
Windows 95), it must be able to send packets with an IP destination
address of 255.255.255.255. Unfortunately, Linux changes an IP
destination of 255.255.255.255 into the local subnet broadcast address
-(here, that's 192.5.5.223). This isn't a problem on Linux 2.2 and
-later kernels, since we completely bypass the Linux IP stack, but on
-old versions of Linux 2.1 and all versions of Linux prior to 2.1, it
-is a problem - pickier DHCP clients connected to the same network as
-the ISC DHCP server or ISC relay agent will not see messages from the
-DHCP server.
+(here, that's 192.5.5.223).
+
+This isn't generally a problem on Linux 2.2 and later kernels, since
+we completely bypass the Linux IP stack, but on old versions of Linux
+2.1 and all versions of Linux prior to 2.1, it is a problem - pickier
+DHCP clients connected to the same network as the ISC DHCP server or
+ISC relay agent will not see messages from the DHCP server. It *is*
+possible to run into trouble with this on Linux 2.2 and later if you
+are running a verson of the DHCP server that was compiled on a Linux
+2.0 system, though.
It is possible to work around this problem on some versions of Linux
by creating a host route from your network interface address to
If you are not using eth0 as your network interface, you should
specify the network interface you *are* using in your route command.
- LINUX: FIREWALL RULES
-
-If you are running the DHCP server or client on a Linux system that's
-also acting as a firewall, you must be sure to allow DHCP packets
-through the firewall - Linux firewalls make filtering decisions before
-they make the forwarding decision, so they will filter packets that
-are intended for the firewall itself, as well as packets intended to
-be forwarded. In particular, your firewall rules _must_ allow
-packets from IP address 0.0.0.0 to IP address 255.255.255.255 from UDP
-port 68 to UDP port 67 through. They must also allow packets from
-your local firewall's IP address and UDP port 67 through to any
-address your DHCP server might serve on UDP port 68. Finally,
-packets from relay agents on port 67 to the DHCP server on port 67,
-and vice versa, must be permitted.
-
LINUX: IP BOOTP AGENT
Some versions of the Linux 2.1 kernel apparently prevent dhcpd from
SUPPORT
The Internet Software Consortium DHCP server is not a commercial
-product, and is not supported in that sense. However, it has
-attracted a fairly sizable following on the Internet, which means that
-there are a lot of knowledgable users who may be able to help you if
-you get stuck. These people generally read the dhcp-server@fugue.com
-mailing list.
+product, and is not supported by the ISC. However, it has attracted a
+fairly sizable following on the Internet, which means that there are a
+lot of knowledgable users who may be able to help you if you get
+stuck. These people generally read the dhcp-server@isc.org mailing
+list.
If you are going to use dhcpd, you should probably subscribe to the
dhcp-server and dhcp-announce mailing lists. If you will be using
dhclient, you should subscribe to the dhcp-client mailing list.
If you need help, you should ask on the dhcp-server or dhcp-client
-mailing list (or both) - whichever is appropriate to your
-application. This includes reporting bugs. Please do not report
-bugs in old software releases - fetch the latest release and see if
-the bug is still in that copy of the software, and if it's not, _then_
-report it. It's okay to report bugs in the latest patchlevel of a
-major version that's not the most recent major version, though - for
-example, if you're running 2.0, you don't have to upgrade to 3.0
-before you can report bugs.
+mailing list - whichever is appropriate to your application. Support
+requests for the ISC DHCP client should go to dhcp-client@isc.org.
+Support requests for the DHCP server should go to dhcp-server@isc.org.
+If you are having trouble with a combination of the client and server,
+send the request to dhcp-server@isc.org. Please do not cross-post to
+both lists under any circumstances.
+
+PLEASE DO NOT REPORT BUGS IN OLD SOFTWARE RELEASES! Fetch the latest
+release and see if the bug is still in that version of the software,
+and if it's not, _then_ report it. It's okay to report bugs in the
+latest patchlevel of a major version that's not the most recent major
+version, though - for example, if you're running 2.0, you don't have
+to upgrade to 3.0 before you can report bugs.
+
+PLEASE DO NOT REPORT BUGS IF YOU ARE NOT RUNNING A VERSION OF THE ISC
+DHCP DISTRIBUTION THAT YOU DIDN'T GET FROM THE ISC! Free operating
+system distributions are notorious for including outdated versions of
+software, and also versions of software that were not compiled on your
+particular version of the operating system. These versions
+frequently do not work. Getting a source distribution from the ISC
+and installing it frequently *does* work. Please try this *before*
+asking for help.
PLEASE READ THIS README FILE CAREFULLY BEFORE REPORTING BUGS!
- HOW TO REPORT BUGS
+ HOW TO REPORT BUGS OR REQUEST SUPPORT
-When you report bugs, please provide us complete information. A list
-of information we need follows. Please read it carefully, and put
-all the information you can into your initial bug report, so that we
-don't have to ask you any questions in order to figure out your
-problem.
+When you report bugs or ask for help, please provide us complete
+information. A list of information we need follows. Please read it
+carefully, and put all the information you can into your initial bug
+report, so that we don't have to ask you any questions in order to
+figure out your problem. If you need handholding support, please
+consider contacting a commercial provider of the ISC DHCP
+Distribution.
- The specific operating system name and version of the
machine on which the DHCP server or client is running.
something about your situation that we don't know.
- Include your dhcpd.conf and dhcpd.leases file if they're not
huge (if they are huge, we may need them anyway, but don't
- send them until you're asked).
+ send them until you're asked). Huge means more than 100
+ kilobytes each.
- Include a log of your server or client running until it
encounters the problem - for example, if you are having
trouble getting some client to get an address, restart the
dhcpcd, this is _not_ the ISC DHCP client, and we probably can't help
you with it.
-Please see http://www.fugue.com/dhcp/lists for details on how to
-subscribe. If you don't have WorldWide Web access, you can send mail
-to dhcp-request@fugue.com and tell me which lists you want to
-subscribe to, but please use the web interface if you can, since I
-have to handle the -request mailing list manually, and I will give you
-the third degree if you make me do your subscription manually.
-
-PLEASE DO NOT SEND REQUESTS FOR SUPPORT DIRECTLY TO ME! The number of
-people using the DHCP Distribution is sufficiently large that if I
-take an interrupt every time any one of those people runs into
-trouble, I will never get any more coding done.
-
-PLEASE DO NOT CALL ME ON THE PHONE FOR SUPPORT! Answering the phone
-takes a lot more of my time and attention than answering email. If you
-do call me on the phone, I will tell you to send email to the mailing
-list, and I won't answer your question, so there's no point in doing
-it.
+Please see http://www.isc.org/services/public/lists/dhcp-lists.html
+for details on how to subscribe to the ISC DHCP mailing lists.
+
+PLEASE DO NOT SEND REQUESTS FOR SUPPORT DIRECTLY TO THE ENGINEERS WHO
+WORK ON THE ISC DHCP DISTRIBUTION! Do not even Cc: us - we do read
+the public mailing lists! The number of people using the DHCP
+Distribution is sufficiently large that if we take interrupts every
+time any one of those people runs into trouble, we will never get any
+more coding done. If you send a support request directly to any ISC
+or Nominum engineer, we will forward it to the mailing list, or
+possibly ignore it, depending on how much stress we are under at the
+time. If your question can only be answered by one of us, we will
+answer it on the public mailing list. When we have time.
+
+PLEASE DO NOT CALL US ON THE PHONE FOR SUPPORT! Answering the phone
+takes a lot more of our time and attention than answering email. If
+you do call us on the phone, we will tell you to send email to the
+mailing list or buy a support contract, so please don't waste your
+time or ours. If you have a support contract, please use the support
+channel mentioned in the support contract - otherwise you probably
+won't get timely support unless you happen to ask an interesting
+question and we happen to have some time to kill, because we can't
+tell you're a support customer if you send mail to the public mailing
+lists.
+
- Internet Software Consortium
- Dynamic Host Configuration Protocol Distribution
- Version 3, Beta 2, Patchlevel 0
- January 21, 2000
+ Internet Software Consortium DHCP Distribution
+ Version 3, Beta 2, Patchlevel 1
+ September 1, 2000
Release Notes
This is a development snapshot of Version 3 of the Internet Software
Consortium DHCP Distribution.
- PLANS
+ NEW FEATURES
-Version 3 of the ISC DHCP Distribution adds conditional behaviour,
-address pools with access control, and client classing. An interim
-implementation of dynamic DNS updates for the server only is included,
-but is not supported. The README file contains information about how
-to enable this - it is not compiled into the DHCP server by default.
+Version 3, Beta 2 of the ISC DHCP Distribution includes the following
+features that are new since version 2.0:
-Features in upcoming releases, starting with 3.1, will include
-Dynamic DNS Support, DHCPv4 16-bit option codes, asynchronous DNS
-query resolution, DHCP Authentication, and support for a DHCP
-Interserver Protocol and live querying and update of the DHCP
-database. Not all of this is done yet (see below).
+ - DHCP Failover Protocol support
+ - OMAPI, an API for accessing and modifying the DHCP server and
+ client state.
+ - Conditional behaviour
+ - Storing arbitrary information on leases
+ - Address pools with access control
+ - Client classing
+ - Address allocation restriction by class
+ - Relay agent information option support
+ - Dynamic DNS updates
+ - Many bug fixes, performance enhancements, and minor new DHCP
+ protocol features.
This release is running in production at the ISC and at quite a few
other sites. At this point, the 3.0 release is reasonably stable, but
as well as how to find documentation and report bugs, please consult
the README file.
-The interim Dynamic DNS Update support is the result of work by Lans
-Carstensen and Brian Dols at Rose-Hulman Institute of Technology, Jim
-Watt at Perkin-Elmer, Irina Goble at Integrated Measurement Systems,
-and Brian Murrell at BC Tel Advanced Communications. I'd like to
-express my thanks to all of these good people here.
-
- Changes since June 6, 1999
-
-- Integrated Irina Goble's Dynamic DNS update patches, with some
- changes, thanks to Brian Murrell of BC Tel. These changes are only
- enabled if you explicitly specify it with the configure script, and
- we currently have no documentation.
-
-- Heavily updated README file.
-
-- Updated dhclient man page to document all current command-line
- arguments.
-
-- Added a -s flag to both the client and server, for debugging only,
- so that the client and server can both be run using the socket API
- on a single machine that has no network interfaces (e.g., with lo0).
-
-- Added support for three new subexpressions that return data:
- leased-address, reverse and binary-to-ascii.
-
-- Fixed a problem where TOKEN_NOT and NOT were both kinds of tokens,
- which prevented "not authoritative" from working.
-
-- Updated the pretty-printer for the 'X' type so that it will output
- ASCII text if the buffer being output contains all printable
- characters. This is useful, e.g., for using the host-name option
- in the client.
-
-- Add support for an always-broadcast flag, which, when enabled,
- causes the DHCP server to broadcast responses to all clients in the
- scope in which it is enabled, even if the client didn't request that
- the response be broadcast. This is useful for working around
- clients that have buggy support for the protocol.
-
-- Fix (I hope!) a compilation problem with the declaration of the
- fallback_discard function on some versions of Linux.
-
-- Fix a bug that caused the offered lease time to be zero (or possibly
- some random value from the stack) if the client did not request a
- specific lease duration.
-
-- Add support for a one-lease-per-client flag, which if enabled in the
- scope in which a client appears, causes any leases the client holds
- to be freed as soon as a DHCPREQUEST is received from the client for
- some other IP address. This will only work if the client has only
- one network interface, so caution is urged in the use of this
- feature.
-
-- Fix a mistake in the example in the dhcpd.conf manual page that
- talks about the "spawn with" statement.
-
- Changes since May 27, 1999
-
-- Fix some typos in the token ring code that I made while
- incorporating Andrew's changes.
-
-- Fix some problems with scope evaluation related to BOOTP clients.
-
- Changes since May 7, 1999
-
-- Add LPF token ring support, contributed by Andrew Chittenden.
-
-- Fix a serious bug in some server option evaluations, where it was
- looking for the values in the DHCP option space instead of the
- server option space.
-
-- Prevent the server from failing to configure a client that retries
- its initial DHCPDISCOVER too quickly.
-
-- Tweak semantics of lease limits so that if any class a client is in
- has a limit, then the client can't get a lease just because it's
- also in a class with no limits.
-
-- Correct an operator precedence bug in abandoned lease handling.
-
-- Provide more complete documentation for classes and correct errors
- in existing documentation.
-
-- Fix some pointer non-debug code paths.
-
-- Add support for encode_int() operand
-
-- Fix documentation for concat operator.
-
-- Edit dhcp options manual page for consistency.
-
- Changes since May 6, 1999
-
-- Reverse precedence of user-supplied parameter request list so that
- user can override client's preferences.
-
-- Do not call abort () when uninitialized pointers are passed to
- allocation functions unless POINTER_DEBUG is defined.
-
-- Fix a bug in parsing colon-seperated hex octet lists in data
- expressions.
-
-- Fix a number of cases where the server would dump core in
- evaluate_*_expression if the options buffer was a NULL pointer.
-
-- Fix incorrect handling of exists subexpression.
-
- Changes since April 24, 1999
-
-- In DHCPINFORM, allow for buggy clients that do not set ciaddr by
- using the IP source address from the IP header if ciaddr is zero.
-
-- Fix some memory allocation botches in the DHCP server.
-
-- Use parameter request list option from scope if it is present and
- client didn't send one.
-
-- Allow for RFC1541 clients that set ciaddr when REQUESTING by
- checking server-identifier option as well as ciaddr before
- unicasting.
-
-- Add support for concat data subexpression.
-
-- Add support for specifying option data as a data expression instead
- of in the option's specified format.
-
-- Fix a compile error on some Linux 2.0-based distributions.
-
- Changes since April 23, 1999
-
-- Fix a duplicate declaration of the object file copyright in dlpi.c. Sigh.
-
- Changes since April 12, 1999
-
-- Fix a bug that would cause a core dump in DHCPINFORM.
-
-- Document DHCP server lease allocation algorithm in dhcpd.conf manual
- page. Also document pool access control lists.
-
-- Add support for site-defined option spaces.
-
-- Do not respond with NAK if ciaddr is set and giaddr/interface origin
- network segment doesn't match, since ciaddr means client is
- unicasting using IP routing.
-
-- Support DHCPINFORM even on unknown networks.
-
-- Make pool scope less specific than class scope.
-
-- Enforce maximum lease length after applying default lease time.
-
-- Add support for a bunch of options that were added in RFC2132.
-
-- Undo a mistaken change in the interface discovery code that caused
- (e.g.) lo0 to be recognized as a broadcast interface.
-
-- Tweak (hopefully fix) UDP/IP checksum algorithm.
-
-- Support compilation on MacOS X.
-
-
- Changes since April 8, 1999
-
-- Support DHCPINFORM.
-
-- Fix up some references to error() which I didn't notice earlier
- because I don't do compilation testing on Linux.
-
-- Add a boolean expression, "known", which returns true if the client
- whose request is currently being processed has a host declaration.
-
-- Do path keyword substitution on unformatted manual pages before
- installing them.
-
-- Use length from UDP header to compute UDP checksum, because some
- buggy relay agents send UDP header lengths that disagree with IP
- header length and actual bytes sent.
-
-- Make error logging when packets with bad checksums or lengths are
- received work more correctly.
-
-- Fix a null pointer dereference that would occur when processing
- bootp packets from networks to which the server was not directly
- connected.
-
- Changes since March 30, 1999
-
-- Install unformatted manual pages on Linux
-
-- SGI Irix support
-
-- Generalize option support and add parser support for defining new
- option spaces.
-
-- Support for generating vendor-encapsulated-options option from
- user-specified option space, rather than having to encode it as
- hex.
-
-- Fix hash table code to do the right thing with nul-terminated
- strings - before they'd all get hashed into the same bucket.
-
-- Fix a parser bug caused by dereferencing an uninitialized variable
- that prevented the parser from working correctly on some systems but
- allowed it to work on others.
-
-- Document how to define new options, as well as how to set up
- vendor-encapsulated-options option.
-
-- When responding to bootp clients, use the subnet mask from the
- subnet declaration as we do for DHCP clients if no explicit subnet
- mask option was defined.
-
-- Add always-send-rfc1048 option to force the server to send
- rfc1048-style options (what everybody uses now) even if the client
- doesn't send the right magic cookie.
-
-- Fix some bugs in class support that became obvious when I tried to
- use the vendor-encapsulated-option support in a reasonable way.
-
-- Fix some memory leaks.
-
- Changes since March 29, 1999 (second snapshot)
-
-- Fix a memory allocation bug
-
-- Move support for allow and deny keywords (WRT to server option
- space) into common code so that they can be used within
- conditionals.
-
- Changes since March 29, 1999 (first snapshot)
-
-- Build two new manual pages.
-
-- Undo IFF_POINTOPOINT change from March 26.
-
-- Add entry, exit and resolv.conf building hooks to dhclient-script.
-
- Changes since March 26, 1999
-
-- Set broadcast flag in DHCPDISCOVER packet if appropriate.
-
-- Fix parsing of pool permits and address range statements.
-
-- Account for tabs in parse_warn().
-
- Changes since March 15, 1999
-
-- Only use min-secs parameter on DHCPDISCOVER packets.
-
-- Restore support for server-identifier keyword.
-
-- Fix dhcp-class-identifier name to be vendor-class-identifier.
-
-- Add support for defining new DHCP options, e.g.:
-
- option new-option-name code 198 = array of ip-address;
- option new-option-name 10.20.30.1, 10.20.30.2;
-
-- Support added for AIX 4.1.5.0 (and hopefully other versions).
-
-- Use /var/run instead of /etc on Digital Unix.
-
-- Change DHCP client exponential backoff code to back off more slowly,
- so that it is more robust in lossy environments, at the expense of
- being a bit less polite to the server.
-
-- Don't request a specific lease interval in the client unless the
- user says to do so.
-
-- Don't print DHCPXXX in wrong xxx messages unless DEBUG is defined.
-
-- Fix handling of secs field.
-
-- Fix handling of append statement.
-
-- Fix documentation for append and prepend statements.
-
-- Fix server support for parameter request list and maximum message
- size.
-
-- Parameterize more hardware types in discover_interfaces. Check for
- IFF_BROADCAST instead of !IFF_POINTOPOINT
-
-- Print kernel configuration warning message if we get EINVAL when
- opening or configuring the Linux packet filter.
-
-- Fix a bug in UDP checksum code (thanks to John Nemeth for figuring
- this out) and re-enable UDP checksumming. This allows the client
- to work with some buggy DHCP servers that can't handle zero
- checksums in the UDP header - in particular, the one John's cable
- modem ISP is using.
-
-- Don't report packet header checksum errors unless we see a lot of
- them. It's perfectly normal for some number of checksum errors to
- occur.
-
-- Refer to the dhcpd.leases man page when printing an error message
- prior to exiting because there's no lease database.
-
-- Add information to the README telling the reader how to get to the
- manual pages.
-
-- Fix the server packet transmission code to unicast when it can.
-
-- Fix a typo in the dhcpd.conf manual page.
-
-
-
- CHANGES SINCE VERSION 2.0
-
-- Support for conditional behaviour - i.e., what the client sends can
- be used to determine what response the client gets, in a very
- general way.
-
-- Support for client classing - that is, clients can be assigned to
- classes based on what they send, and then address assignments can be
- made based on the client's class. A per-class limit on the number
- of addresses assignable can be made. It is possible to spawn new
- classes on the fly based on a template, so that address limitations
- can be done on a per-customer basis - e.g., when using relay agent
- options, a particular customer's circuit ID can be used to classify
- all hosts at the customer site as part of a class which is generated
- on the fly the first time the circuit ID is seen. The class
- template from which this class is created can specify a limit of,
- say, four leases. This would have the effect of limiting all
- customer sites behind relay agents that attach circuit IDs to the
- packets they forward to a maximum of four leases each.
-
-- Memory allocation behaviour has been completely redone.
-
-- Support for more than one pool of addresses per network segment.
- This permits clients to be allocated addresses out of different
- ranges, even within a subnet, based on what classes they're in,
- whether or not they are known (have host declarations), whether or
- not they have authenticated, and that sort of thing. Parameters,
- including things like lease times and also things like options to be
- sent to the client, can vary from address pool to address pool.
-
- UPCOMING WORK
-
-I have a bunch of unintegrated code to do authentication. The only
-reason it's not integrated is that I've decided it's incorrect, and
-I'm going to have to hack the in-memory database to make it correct.
-So expect the lease data structure to change, and probably expect the
-host data structure to change as well, in order to fully support
-authentication. Some bits of authentication support are already
-scattered here and there. You may see references in the code to the
-failover protocol. I was testing some theories, but this code isn't
-functional in any sense, although it will be in the future.
-
-Integration between DHCP and Dynamic DNS is the most-requested
-feature, and you can expect work on this to occur in the near future.
-Irina Goble has some code that several people are running with 2.0
-with some success right now, and while I don't promise to integrate
-this particular code, something will certainly be happening in April
-or May.
-
-There's already some support for DHCPv4NG 16-bit option codes, but it's
-not complete, and won't be very interesting until we have a DHCP
-futures draft out and Microsoft implements it in their clients. When
-this draft is a bit closer to completion, the ISC will release a
-sample implementation - it's not too hard, and it'll be cool to be
-able to say at the IETF that there's something available, even if it
-won't be deployable for a while yet. You will be able to run the
-DHCPv4NG server with existing DHCPv4 clients, because the protocol
-provides for interoperability between new servers and old clients, as
-well as new clients and old servers.
-
-The all-singing, all-dancing Interserver Protocol has been put on the
-back burner in favor of the DHCP Failover Protocol, which solves the
-problem of providing redundant DHCP service with no more than two DHCP
-servers. This protocol is coming along quite nicely - we had a
-meeting in February at Cisco, and lots of progress was made. Cisco
-and Process Software both have implementations of an older version of
-the protocol, and will presumably have support for the new protocol in
-the not-too-distant future. The ISC will go straight to the new
-protocol, once the next draft comes out and as time allows.
-
-Live querying and update of the DHCP database will involve creating a
-unix domain or secure (peer-to-peer IPSEC or TLS) TCP socket to the
-DHCP server, sending requests for information, receiving responses,
-and sending updates. Most of the read-only DHCP status information
-will be available through SNMP, but the private query/update socket
-will allow, for example, registration of clients without restarting
-the server, and adjusting parameters on classes - e.g., reducing or
-increasing the number of leases clients in a particular spawned class
-may hold.
-
-We will be providing anonymous CVS support as soon as we can.
+The Dynamic DNS Update support is a descendent of an implementation
+done by Lans Carstensen and Brian Dols at Rose-Hulman Institute of
+Technology, Jim Watt at Perkin-Elmer, Irina Goble at Integrated
+Measurement Systems, and Brian Murrell at BC Tel Advanced
+Communications. I'd like to express my thanks to all of these good
+people here, both for working on the code and for prodding me into
+improving it.
projects / thirdparty / dhcp.git / commitdiff
