		     Internet Software Consortium
	   Dynamic Host Configuration Protocol Distribution
		      Version 3, Alpha Snapshot
			     May 6, 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, as well as being more compliant with the protocol specification.

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
May of 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 and at some other
sites.  A beta release of 3.0 is expected by June.  At this point, the
3.0 release is reasonably stable, but is really only recommended for
sites that are in a position to experiment, or for sites that need the
new features.  Bug reports are enthusiastically solicited.

		     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.
