isc-dhcp/RELNOTES

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

			    Release Notes

This is the final development snapshot before Version 2 of the
Internet Software Consortium DHCP Distribution goes to beta.
Development snapshots after this one will be for Version 3 of the ISC
DHCP Server.

This snapshot is being released in the hopes that a fair number of
DHCP sites will download it, try it out, and submit bug reports and
critique the new manual pages.  Please do not hold back - the plan is
to cut the first Beta release in about two weeks - at the beginning of
December.

				PLANS

Version 1 of the ISC DHCP Distribution included just a DHCP Server.
As of this writing, the most recent Version 1 distribution is Beta 5
Patchlevel 16.  One more patchlevel is planned before Version 1.0 is
finalized.  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.

This version is fairly stable at this time, and will soon be
moved to the "stable" track.   It has a number of new features, and is
the release that we would expect sites that want some stability but
need the new pinging feature, or need a client or relay agent (but
note that you can run the Version 1 server alongside the Version 2
client and relay agent).

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.

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