Internet Software Consortium
Dynamic Host Configuration Protocol Distribution
Version 3, Alpha Snapshot
- February 25, 1999
+ March 15, 1999
Release Notes
really conservative.
Version 3 of the ISC DHCP Distribution will add conditional behaviour,
-client classing, Dynamic DNS Support, DHCPv4 16-bit option codes,
-asynchronous DNS query resolution, DHCP Authentication, and possibly
-support for a DHCP Interserver Protocol and live querying of the DHCP
-database. Currently, only client classing and conditional behaviour
-have been implemented - the DNS code is waiting for an enhanced DNS
-resolver. The code has gone through a major internal restructuring
-which will help to support wider option codes, and possibly IPv6, as
-well as a more sensible memory allocation strategy. This release is
-running in producion at the ISC, but is not expected to be stable in
-the near future, and is intended for sites that are in a position to
-experiment, or for sites that desperately need the new features.
+address pools with access control, client classing, 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).
+
+This release is running in producion at the ISC, but is not expected
+to be stable in the near future, and is intended for sites that are in
+a position to experiment, or for sites that desperately need the new
+features. In particular, while the code compiles on my development
+system and does all the stuff that I have thought to test, there's a
+pretty decent chance it will do something other than what you expect
+when you try to use it. Pointing out inconsistencies between the
+documentation and the source code will always be appreciated.
CHANGES SINCE VERSION 2.0
- 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 create new
+ 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
customer sites behind relay agents that attach circuit IDs to the
packets they forward to a maximum of four leases each.
-- Support for DHCP authentication. This is based on code contributed
- by the University of Pennsylvania, written by XXX
-
- Memory allocation behaviour has been completely redone.
- Support for more than one pool of addresses per network segment.
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.
projects / thirdparty / dhcp.git / commitdiff
