isc-dhcp/RELNOTES

		     Internet Software Consortium
	   Dynamic Host Configuration Protocol Distribution
		      Version 3, Alpha Snapshot
			  March 26, 1999

			    Release Notes

This is a development snapshot of Version 3 of the Internet Software
Consortium DHCP Distribution.

				PLANS

Version 1 of the ISC DHCP Distribution includes just a DHCP Server.
Version 1 has been in feature freeze since late 1996, and is quite
stable.  This is the release that we would expect very conservative
sites to run in production, but it is no longer recommended.

Version 2 of the ISC DHCP Distribution adds a DHCP Client and a
DHCP/BOOTP Relay Agent to the DHCP Server that was offered in version
1.0.   In addition, some new capabilities have been added to the
server:

	- IP addresses are now tested before they are assigned to
	  clients.   This allows the DHCP server to detect rogue
	  machines that may have hijacked IP addresses before an IP
	  address conflict can occur.

	- The server may be configured so that some DHCP clients can
	  be excluded from booting.

	- Improved NAKing behaviour, so that clients that are using
	  addresses other than the one the server knows they should be
	  using are disciplined quickly.

This version has been in a near feature freeze since January of 1998,
has been in Beta test since then, and is planned for final release in
mid-1999.  It has a number of important features, and is the release
that we would expect most sites to run.  It is possible to run the
Version 1 server with the Version 2 client at sites that want to be
really conservative.

Version 3 of the ISC DHCP Distribution will add conditional behaviour,
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 March 15, 1999

- 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.