isc-dhcp/RELNOTES

		     Internet Software Consortium
	   Dynamic Host Configuration Protocol Distribution
		      Version 3, Alpha Snapshot
			    April 12, 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 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.