isc-dhcp/RELNOTES

		     Internet Software Consortium
	   Dynamic Host Configuration Protocol Distribution
			 Development Snapshot
			   December 2, 1997

			    Release Notes

This is the first 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 most sites to run in
production.

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 is now in Beta testing, and is planned for release in
mid-1998.  It has a number of new features, and is the release that we
would expect sites that want some stability but need the new lease
testing feature, better NAKing, or need a client or relay agent.  Note
that it is possible to run the Version 1 server with the Version 2
client.

Version 3 of the ISC DHCP Distribution will add Dynamic DNS Support,
asynchronous DNS query resolution, DHCP Authentication, and possibly
support for a DHCP Interserver Protocol and live querying of the DHCP
database.   This release 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.

			       CHANGES

- Use %ld to print pid_t and cast pid_t values to long to avoid
  inconsistent declarations between different POSIX flavours.

- Add support for ARPHRD_IEEE802 (token ring) hardware type.

- If we own an address and a client requests it, but we can't assign
  it to that client, we now NAK it so that the client doesn't try to
  reuse it.

		    CHANGES FROM THE JUNE SNAPSHOT

- Support for NeXTstep 3.x and 4.x

- Added man pages for dhcpd.leases, dhclient-script, dhclient.leases
  and dhclient.conf.   Move general documentation of DHCP options into
  a seperate man page which is referred to by the dhclient.conf and
  dhcpd.conf man pages.

- Updated README to answer some frequently asked questions.

- Fixed a bug in command-line interface specification in dhclient - it
  was formerly not possible to specify that only certain interfaces be
  configured.

- Do not leave client scripts lying around in /tmp after they've been
  used unless the -D flag is specified.

- Add a new, non-standard, not-guaranteed-to-stay-the-same system
  configuration status message server which can be used to trigger the
  client to recheck its address, e.g., after a laptop has been put to
  sleep and then awakened (this has yet to be documented).

- Fix handling of media selection in the REBOOT phase - previously the
  media type would not be remembered, which could cause severe delays
  in reacquiring an address if the default media type was wrong.

- Allocate space for a NUL terminator on the end of client options -
  this was previously overlooked, and could cause garbage characters
  to be written to the temporary client script files.

- Use mkstemp if it's available.

- Supply network number and broadcast address to the client script so
  that on systems that need these values, they don't need to be
  computed with an awk script.

- Keep a PID file for the client and the relay agent, and have the
  relay agent background itself by default.

- Add client script for bsd/os, fix many niggling bugs in existing
  client scripts and add support for static routing tables to all bsd
  scripts.

- Add a -q option to the client, server and relay agent so that they
  can be started from /etc/rc scripts without spewing a bunch of
  garbage on the console.   By default, all three daemons still print
  startup messages, since these are helpful in bug reporting.

- Don't print anything to stderr or stdout after going into
  background.

- Fix bug where hostname keyword was not being recognized in
  dhcpd.leases file, resulting in the loss of lease database entries.

- Fix problem on some operating systems where zero-length ifreq
  structures were being offset incorrectly when scanning the interface
  list on startup.

- Unless a BOOTP client requests it, never send more than 64 bytes of
  options.

- Don't ping static leases, since we don't have a lease structure on
  the heap to work with later.

- Fixed a compile problem on Solaris 2.6.

- Support interface aliases on Solaris.

- Print day and month with leading zero in lease files if less than
  ten, for easier parsing by perl/sed/awk scripts.

- Never make the lease database world writable, even if dhcpd is
  invoked with a bogus umask.

- Fix DHCPRELEASE handling (before, addressed would never be
  released.)

- If there is more than one lease for a particular client on a
  particular network, find the lease the client is asking for so as to
  avoid a cycle of NAKs.

- If a BOOTP request is received from a particular client and that
  client has previously received a DHCP address, make sure that we
  still find a valid BOOTP lease so that we don't cycle through
  addresses.

- Remove server-identifier option from documentation, other than to
  document that it has been deprecated.

- Don't give up if we get an EINTR or EAGAIN while polling or
  selecting - these return statuses can occur spuriously without
  indicating a fatal problem.

- Do not select for exceptions, since we don't handle them.   This was
  causing massive CPU consumption on some systems.

- When a DHCP client has been assigned a fixed address but had
  previously had a lease, it will request the old leased address.   In
  such an event, send a DHCPNAK so that it will discover its new
  static binding.