--- dhcp-2.0pl5.orig/relay/dhcrelay.man8 +++ dhcp-2.0pl5/relay/dhcrelay.man8 @@ -0,0 +1,145 @@ +.\" dhcrelay.8 +.\" +.\" Copyright (c) 1997 The Internet Software Consortium. +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. Neither the name of The Internet Software Consortium nor the names +.\" of its contributors may be used to endorse or promote products derived +.\" from this software without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE INTERNET SOFTWARE CONSORTIUM AND +.\" CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, +.\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE +.\" DISCLAIMED. IN NO EVENT SHALL THE INTERNET SOFTWARE CONSORTIUM OR +.\" CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +.\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +.\" LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF +.\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND +.\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, +.\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT +.\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" This software has been written for the Internet Software Consortium +.\" by Ted Lemon in cooperation with Vixie +.\" Enterprises. To learn more about the Internet Software Consortium, +.\" see ``http://www.isc.org/isc''. To learn more about Vixie +.\" Enterprises, see ``http://www.vix.com''. +.TH dhcrelay 8 +.SH NAME +dhcrelay - Dynamic Host Configuration Protocol Relay Agent +.SH SYNOPSIS +.B dhcrelay +[ +.B -p +.I port +] +[ +.B -d +] +[ +.B -q +] +[ +.B -i +.I if0 +[ +.B ... +.B -i +.I ifN +] +] +.I server0 +[ +.I ...serverN +] +.SH DESCRIPTION +The Internet Software Consortium DHCP Relay Agent, dhcrelay, provides a +means for relaying DHCP and BOOTP requests from a subnet to which +no DHCP server is directly connected to one or more DHCP servers on other +subnets. +.SH OPERATION +.PP +The DHCP Relay Agent listens for DHCP requests on all interfaces +attached to a host, unless one or more interfaces are specified on the +command line with the +.I -i +flag. +.PP +When a query is received, dhcrelay forwards it to the list of DHCP +servers specified on the command line. When a reply is received, it +is broadcast or unicast on the network from whence the original +request came. +.PP +It is possible to specify a set of interfaces on which dhcrelay will +listen, so that if dhcrelay is connected through one interface to a +network on which there is no DHCP server, but is connected on another +interface to a network on which there is a DHCP server, it will not +relay DHCP and BOOTP requests from the network on which the server +exists to that server. This is an imperfect solution. +.SH COMMAND LINE +.PP +The names of the network interfaces that dhcrelay should attempt to +configure may be specified on the command line using the +.I -i +option. If no interface names +are specified on the command line dhcrelay will identify all network +interfaces, elimininating non-broadcast interfaces if possible, and +attempt to configure each interface. +.PP +If dhcrelay should listen and transmit on a port other than the +standard (port 67), the +.B -p +flag may used. It should be followed by the udp port number that +dhcrelay should use. This is mostly useful for debugging purposes. +If the +.B -p +flag is specified, the relay agent will transmit responses to clients +at a port number that is one greater than the one specified - i.e., if +you specify +.B -p +67, then the relay agent will listen on port 67 and transmit to port +68. Transmissions to servers will be sent to the same port number +that it specified in the +.B -p +flag. +.PP +Dhcrelay will normally run in the foreground until it has configured +an interface, and then will revert to running in the background. +To run force dhcrelay to always run as a foreground process, the +.B -d +flag should be specified. This is useful when running dhcrelay under +a debugger, or when running it out of inittab on System V systems. +.PP +Dhcrelay will normally print its network configuration on startup. +This can be annoying in a system startup script - to disable this +behaviour, specify the +.I -q +flag. +.PP +The name of at least one DHCP server to which DHCP and BOOTP requests +should be relayed must be specified on the command line. +.PP +.SH SEE ALSO +dhclient(8), dhcpd(8), RFC2132, RFC2131. +.SH AUTHOR +.B dhcrelay(8) +has been written for the Internet Software Consortium +by Ted Lemon in cooperation with Vixie +Enterprises. To learn more about the Internet Software Consortium, +see +.B http://www.vix.com/isc. +To learn more about Vixie +Enterprises, see +.B http://www.vix.com. +.PP --- dhcp-2.0pl5.orig/debian/dhcp-relay.postrm +++ dhcp-2.0pl5/debian/dhcp-relay.postrm @@ -0,0 +1,15 @@ +#!/bin/sh -e +# +# $Id: dhcp-relay.postrm,v 1.2.2.3 2004/05/26 17:09:09 peloy Exp $ +# + +if [ "$1" = "purge" ]; then + # Remove init.d configuration file + rm -f /etc/default/dhcp-relay + + update-rc.d dhcp-relay remove >/dev/null +fi + +#DEBHELPER# + +exit 0 --- dhcp-2.0pl5.orig/debian/dhcp-relay.postinst +++ dhcp-2.0pl5/debian/dhcp-relay.postinst @@ -0,0 +1,91 @@ +#!/bin/sh -e +# +# $Id: dhcp-relay.postinst,v 1.3.2.3 2004/05/26 16:45:04 peloy Exp $ +# + +case "$1" in + configure) + # continue below + ;; + + abort-upgrade|abort-remove|abort-deconfigure) + exit 0 + ;; + + *) + echo "postinst called with unknown argument \`$1'" >&2 + exit 0 + ;; +esac + +INITCONFFILE=/etc/default/dhcp-relay + +# Generate configuration file if it does not exist, using default values. +[ -r "${INITCONFFILE}" ] || { + umask 022 + echo Generating ${INITCONFFILE}... >&2 + cat >${INITCONFFILE} <<'EOFMAGICNUMBER1234' +# Defaults for dhcp-relay initscript +# sourced by /etc/init.d/dhcp-relay +# installed at /etc/default/dhcp-relay by the maintainer scripts + +# +# This is a POSIX shell fragment +# + +# On what interfaces should the DHCP relay (dhcrelay) listen? +# Separate multiple interfaces with spaces, e.g. "eth0 eth1". +INTERFACES="eth0" + +# Where should DHCP requests be forwarded to? (what are your DHCP servers?) +# Separate multiple servers with spaces, e.g. "1.2.3.4 5.6.7.8". +# If a server is not specified the init script will not start +# the DHCP relay!!! +DHCP_SERVERS="" + +# Additional options that are passed to the DHCP relay daemon? +OPTIONS="" +EOFMAGICNUMBER1234 +} + +cat </dev/null + # Init script could fail, since dhcp is unconfigured on a new install + if [ -x /usr/sbin/invoke-rc.d ]; then + invoke-rc.d dhcp-relay start || true + else + /etc/init.d/dhcp-relay start || true + fi +fi + +#DEBHELPER# + +exit 0 --- dhcp-2.0pl5.orig/debian/dhcp.postinst +++ dhcp-2.0pl5/debian/dhcp.postinst @@ -0,0 +1,115 @@ +#!/bin/sh -e +# +# $Id: dhcp.postinst,v 1.3.2.4 2004/05/26 16:45:04 peloy Exp $ +# + +case "$1" in + configure) + # continue below + ;; + + abort-upgrade|abort-remove|abort-deconfigure) + exit 0 + ;; + + *) + echo "postinst called with unknown argument \`$1'" >&2 + exit 0 + ;; +esac + +PATH_DHCPD_DB=/var/lib/dhcp/dhcpd.leases + +# --- Begin FHS migration code --- + +# Starting with dhcp-2.0pl5-10 we are FHS-compliant. The following +# code takes care of moving important files in the old, non +# FHS-compliant directory (/var/dhcp/) to their new location +# (/var/lib/dhcp/) +if [ -d /var/dhcp/ ]; then + mv /var/dhcp/dhcp* /var/lib/dhcp/ 2> /dev/null || true + rmdir /var/dhcp/ 2> /dev/null || true +fi + +# --- End FHS migration code --- + +update-inetd --disable bootps + +if [ -f /etc/dhcpd.leases ]; then + echo "Moving leases file to $PATH_DHCPD_DB" + mv /etc/dhcpd.leases* $PATH_DHCPD_DB +fi + +if [ ! -e $PATH_DHCPD_DB ]; then + touch $PATH_DHCPD_DB +fi + +INITCONFFILE=/etc/default/dhcp + +# Generate configuration file if it does not exist, using default values. +[ -r "${INITCONFFILE}" ] || { + umask 022 + echo Generating ${INITCONFFILE}... >&2 + cat >${INITCONFFILE} <<'EOFMAGICNUMBER1234' +# Defaults for dhcp initscript +# sourced by /etc/init.d/dhcp +# installed at /etc/default/dhcp by the maintainer scripts + +# +# This is a POSIX shell fragment +# + +# On what interfaces should the DHCP server (dhcpd) serve DHCP requests? +# Separate multiple interfaces with spaces, e.g. "eth0 eth1". +INTERFACES="" +EOFMAGICNUMBER1234 +} + +cat </dev/null + # Init script could fail, since dhcp is unconfigured on a new install + if [ -x /usr/sbin/invoke-rc.d ]; then + invoke-rc.d dhcp start || true + else + /etc/init.d/dhcp start || true + fi +fi + +#DEBHELPER# + +exit 0 --- dhcp-2.0pl5.orig/debian/dhcp.postrm +++ dhcp-2.0pl5/debian/dhcp.postrm @@ -0,0 +1,32 @@ +#!/bin/sh -e +# +# $Id: dhcp.postrm,v 1.3.2.2 2004/05/26 16:05:53 peloy Exp $ +# + +PATH_DHCPD_DB=/var/lib/dhcp/dhcpd.leases +PATH_DHCPD_DB_DIR=`dirname $PATH_DHCPD_DB` + +case "$1" in + remove) + [ -x /usr/sbin/update-inetd ] && update-inetd --enable bootps + ;; + + purge) + rm -f $PATH_DHCPD_DB + rm -f $PATH_DHCPD_DB~ # backup file left by the daemon + rmdir --ignore-fail-on-non-empty $PATH_DHCPD_DB_DIR + + # Remove init.d configuration file + rm -f /etc/default/dhcp + + update-rc.d dhcp remove >/dev/null + ;; + + upgrade|failed-upgrade|abort-install|abort-upgrade|disappear) + # Nothing to do + ;; +esac + +#DEBHELPER# + +exit 0 --- dhcp-2.0pl5.orig/debian/dhcp.examples +++ dhcp-2.0pl5/debian/dhcp.examples @@ -0,0 +1 @@ +server/dhcpd.conf --- dhcp-2.0pl5.orig/debian/dhcp.docs +++ dhcp-2.0pl5/debian/dhcp.docs @@ -0,0 +1 @@ +README RELNOTES doc/ debian/dhcp-on-linux.txt --- dhcp-2.0pl5.orig/debian/dhcp.init.d +++ dhcp-2.0pl5/debian/dhcp.init.d @@ -0,0 +1,44 @@ +#!/bin/sh +# +# $Id: dhcp.init.d,v 1.3.2.2 2002/08/11 22:11:54 peloy Exp $ +# + +test -x /usr/sbin/dhcpd || exit 0 + +# Defaults +INTERFACES="eth0" + +# Reads config file (will override defaults above) +[ -r /etc/default/dhcp ] && . /etc/default/dhcp + +DHCPDPID=/var/run/dhcpd.pid + +case "$1" in + start) + echo -n "Starting DHCP server: " + start-stop-daemon --start --quiet --pidfile $DHCPDPID \ + --exec /usr/sbin/dhcpd -- -q $INTERFACES + sleep 2 + + if [ -f "$DHCPDPID" ] && ps h `cat "$DHCPDPID"` >/dev/null; then + echo "dhcpd." + else + echo "dhcpd failed to start - check syslog for diagnostics." + fi + ;; + stop) + echo -n "Stopping DHCP server: dhcp" + start-stop-daemon --stop --quiet --pidfile $DHCPDPID + echo "." + ;; + restart | force-reload) + $0 stop + sleep 2 + $0 start + ;; + *) + echo "Usage: /etc/init.d/dhcp {start|stop|restart|force-reload}" + exit 1 +esac + +exit 0 --- dhcp-2.0pl5.orig/debian/dhcp-client.postrm +++ dhcp-2.0pl5/debian/dhcp-client.postrm @@ -0,0 +1,20 @@ +#!/bin/sh -e +# +# $Id: dhcp-client.postrm,v 1.3.2.2 2004/05/26 16:45:04 peloy Exp $ +# + +PATH_DHCLIENT_DB=/var/lib/dhcp/dhclient.leases +PATH_DHCLIENT_DB_DIR=`dirname $PATH_DHCLIENT_DB` + +if [ "$1" = "purge" ]; then + rm -f /etc/init.d/dhcp-client + update-rc.d dhcp-client remove >/dev/null + + rm -f $PATH_DHCLIENT_DB + rm -f $PATH_DHCLIENT_DB~ # backup file left by the daemon + rmdir --ignore-fail-on-non-empty $PATH_DHCLIENT_DB_DIR +fi + +#DEBHELPER# + +exit 0 --- dhcp-2.0pl5.orig/debian/dhcp-relay.prerm +++ dhcp-2.0pl5/debian/dhcp-relay.prerm @@ -0,0 +1,21 @@ +#!/bin/sh -e +# +# $Id: dhcp-relay.prerm,v 1.2.2.2 2004/05/26 16:45:04 peloy Exp $ +# + +if [ "$1" != upgrade ]; then + update-alternatives --remove dhcp-options.5.gz \ + /usr/share/man/man5/dhcp-options-dhcrelay.5.gz +fi + +if [ -x /etc/init.d/dhcp-relay ]; then + if [ -x /usr/sbin/invoke-rc.d ]; then + invoke-rc.d dhcp-relay stop + else + /etc/init.d/dhcp-relay stop + fi +fi + +#DEBHELPER# + +exit 0 --- dhcp-2.0pl5.orig/debian/rules +++ dhcp-2.0pl5/debian/rules @@ -0,0 +1,133 @@ +#!/usr/bin/make -f +# Made with the iad of dh_make, by Craig Small +# Sample debian/rules that uses debhelper. GNU copyright 1997 by Joey Hess. +# Also some stuff taken from debmake scripts, by Cristopt Lameter. + +# Uncomment this to turn on verbose mode. +#export DH_VERBOSE=1 + +DESTDIR = `pwd`/debian/tmp + +IVARS = DESTDIR=$(DESTDIR) \ + VARDB=/var/lib/dhcp \ + FFMANDIR=/usr/share/man/man5 \ + ADMMANDIR=/usr/share/man/man8 +# MANINSTALL="install -c -m644" + +BVARS = PREDEFINES='-D_PATH_DHCPD_DB=\"/var/lib/dhcp/dhcpd.leases\" \ + -D_PATH_DHCLIENT_DB=\"/var/lib/dhcp/dhclient.leases\"' \ + VARDB=/var/lib/dhcp + +patch: patch-stamp +patch-stamp: + dh_testdir + if [ ! -f patch-stamp ]; then /bin/sh debian/scripts/patch-source; fi + touch patch-stamp + +unpatch: + dh_testdir + if [ -f patch-stamp ]; then /bin/sh debian/scripts/unpatch-source; fi + rm -f patch-stamp + +build: patch-stamp build-stamp +build-stamp: + dh_testdir + + ./configure + $(MAKE) $(BVARS) + + touch build-stamp + +clean: unpatch + dh_testdir + rm -f build-stamp install-stamp + + # Add here commands to clean up after the build process. + -$(MAKE) distclean + + # Remove files left around by a build but that are not removed + # by 'make distclean' +# rm -f client/dhclient-script.cat8 client/dhclient.cat8 \ +# client/dhclient.conf.cat5 client/dhclient.leases.cat5 \ +# common/dhcp-options.cat5 common/dhcp-options.man5 \ +# relay/dhcrelay.cat8 relay/dhcrelay.man8 server/dhcpd.cat8 \ +# server/dhcpd.conf.cat5 server/dhcpd.leases.cat5 + + dh_clean + +install: install-stamp +install-stamp: build-stamp + dh_testdir + dh_testroot + dh_clean -k + dh_installdirs + + # Add here commands to install the package into debian/tmp. + $(MAKE) install $(IVARS) + + # Install dhcp's conffile. + install -m 644 debian/dhcpd.conf $(DESTDIR)/etc/ + + # Install dhcp's conffile. + install -m 644 debian/dhclient.conf $(DESTDIR)/etc/ + + # Install some man pages that are installed by default only in the + # dhcp package (and we want them in dhcp-relay and + # dhcp-client as well.) + cp -f $(DESTDIR)/usr/share/man/man5/dhcp-options.5 \ + debian/dhcp-relay/usr/share/man/man5/dhcp-options-dhcrelay.5 + cp -f $(DESTDIR)/usr/share/man/man5/dhcp-options.5 \ + debian/dhcp-client/usr/share/man/man5/dhcp-options-dhclient.5 + mv $(DESTDIR)/usr/share/man/man5/dhcp-options.5 \ + $(DESTDIR)/usr/share/man/man5/dhcp-options-dhcpd.5 + + # install the udeb binary (no need to install dhclient-script + # since it is provided by another udeb package. See #249373) + install -m 755 $(DESTDIR)/sbin/dhclient \ + `pwd`/debian/dhcp-client-udeb/sbin/dhclient + + dh_install --list-missing --sourcedir=$(DESTDIR) + + touch install-stamp + +UDEBPACKAGE=dhcp-client-udeb +VERSION=$(shell dpkg-parsechangelog | grep ^Version:.* | cut -d ' ' -f 2) +ARCH=$(shell dpkg --print-architecture) +UDEBFILENAME=$(UDEBPACKAGE)_$(VERSION)_$(ARCH).udeb +PRIORITY=$(shell grep ^Priority: debian/control | cut -d ' ' -f 2) + +# Build architecture-dependent files here (this package does not contain +# architecture-independent files). +binary-arch: build install +# dh_testversion + dh_testdir -a + dh_testroot -a + dh_installdocs -a --no-package=dhcp-client-udeb + dh_installexamples -a +# dh_installmenu -a +# dh_installemacsen -a + dh_installinit -a -n +# dh_installcron -a +# dh_installmanpages -a +# dh_undocumented + dh_installchangelogs -a --no-package=dhcp-client-udeb CHANGES + dh_strip -a + dh_compress -a + dh_fixperms -a + dh_installdeb -a + dh_shlibdeps -a + dh_gencontrol -a --no-package=dhcp-client-udeb + # Don't write your stupid guesses to debian/files. + dh_gencontrol --package=dhcp-client-udeb -- -fdebian/files~ + # Register file manually. + dpkg-distaddfile $(UDEBFILENAME) debian-installer $(PRIORITY) +# dh_makeshlibs -a + dh_md5sums -a --no-package=dhcp-client-udeb + dh_builddeb -a --no-package=dhcp-client-udeb + dh_builddeb --package=dhcp-client-udeb --filename=$(UDEBFILENAME) + +source diff: + @echo >&2 'source and diff are obsolete - use dpkg-source -b'; false + +binary: binary-arch +.PHONY: build clean binary-indep binary-arch binary --- dhcp-2.0pl5.orig/debian/control +++ dhcp-2.0pl5/debian/control @@ -0,0 +1,79 @@ +Source: dhcp +Section: net +Priority: optional +Maintainer: Ubuntu Core Developers +XSBC-Original-Maintainer: Eloy A. Paris +Uploaders: Matt Zimmerman +Build-Depends: debhelper (>= 4.0), dpkg-dev (>= 1.7.0), groff +Standards-Version: 3.6.2.1 + +Package: dhcp +Architecture: any +Depends: ${shlibs:Depends}, update-inetd +Replaces: dhcpd, dhcp-beta +Conflicts: dhcpd, dhcp-beta, dhcp-relay, dhcp-relay-beta +Provides: dhcpd, dhcp +Description: DHCP server for automatic IP address assignment + DHCP is a protocol like BOOTP (actually dhcpd includes much of + the functionality of BOOTPD!). It assigns IP addresses to clients + based on lease times. DHCP is used extensively by Microsoft and more + recently also by Apple. It is probably essential in any multi-platform + environment. + . + Multiple Ethernet Interfaces are supported by this DHCP package. + . + Note: This package _requires_ a 2.2.x or later Linux kernel. 2.0.x + kernels are _not_ supported. + . + This is the DHCP server from version 2 of the Internet Software + Consortium DHCP package. For more information visit the ISC web site + at http://www.isc.org. + +Package: dhcp-client +Architecture: any +Depends: ${shlibs:Depends} +Replaces: dhcp-client-beta +Conflicts: dhcp-client-beta, dhcpcd +Description: DHCP Client + This is a split off from the dhcp package and contains the DHCP client + tools. + . + Cable modem users likely need this or another dhcp client to successfully + connect to the network. + . + Documentation (apart from manpages) can be found in the dhcp package. + . + Note: This package _requires_ a 2.2.x or later Linux kernel. 2.0.x + kernels are _not_ supported. + . + This is the DHCP client from version 2 of the Internet Software + Consortium DHCP package. For more information visit the ISC web site + at http://www.isc.org. + +Package: dhcp-client-udeb +Architecture: any +Section: debian-installer +Depends: ${shlibs:Depends} +Replaces: dhcp-client-beta +Conflicts: dhcp-client-beta, dhcpcd +Description: DHCP Client for debian-installer + dhcp-client-udeb is a minimal dhcp package used by the debian-installer. + +Package: dhcp-relay +Architecture: any +Depends: ${shlibs:Depends}, ed +Replaces: dhcpd, dhcp-relay-beta +Conflicts: dhcp-relay-beta +Description: DHCP Relay + Installing this package will make the machine it is installed on to + a dhcp relay. You need to have a DHCP or BOOTP server reachable in order + to use the relay. + . + Documentation (apart from manpages) can be found in the dhcp package. + . + Note: This package _requires_ a 2.2.x or later Linux kernel. 2.0.x + kernels are _not_ supported. + . + This is the DHCP relay from version 2 of the Internet Software + Consortium DHCP package. For more information visit the ISC web site + at http://www.isc.org. --- dhcp-2.0pl5.orig/debian/README.debian +++ dhcp-2.0pl5/debian/README.debian @@ -0,0 +1,33 @@ +DHCP for Debian +--------------- + +This is the Internet Software Consortium (ISC) DHCP version 2 package. +If you are looking for the latest version of the ISC DHCP package you +should try the dhcp3-* packages, which are for version 3 of the ISC +DHCP package. + +This release has full support for operation on multiple interfaces and +needs a 2.2.x or later kernel; the 2.0.x kernels are _not_ supported. + +The sources of the ISC DHCP package produce the following Debian packages: + +dhcp: A DHCP Server +dhcp-client: A DHCP Client +dhcp-relay: A DHCP Relay +dhcp-client-udeb: Small DHCP client for debian-installer + + +If you get the following error when trying to run dhclient, dhcpd or +dhcrelay: + + Can't install packet filter program: Protocol not available + exiting. + +then you need to edit your linux kernel .config file, set CONFIG_FILTER=y, +and rebuild your kernel. See /usr/share/doc/dhcp/README for more +information. + +Eloy A. Paris +Matt Zimmerman + +$Id: README.debian,v 1.5.2.3 2003/03/17 02:21:19 peloy Exp $ --- dhcp-2.0pl5.orig/debian/changelog +++ dhcp-2.0pl5/debian/changelog @@ -0,0 +1,824 @@ +dhcp (2.0pl5-19.5ubuntu2.1) feisty-security; urgency=low + + * SECURITY UPDATE: DHCP client could execute arbitrary code via malicious + replies. + * Add debian/patches/305_CVE-2007-5365.patch: upstream fixes, thanks to + Debian. + * References + CVE-2007-5365 + + -- Kees Cook Thu, 18 Oct 2007 11:00:24 -0700 + +dhcp (2.0pl5-19.5ubuntu2) feisty; urgency=low + + * Change dependency on netbase to dependency on update-inetd since it's + in its own package now. + + -- Tollef Fog Heen Thu, 14 Dec 2006 11:34:55 +0100 + +dhcp (2.0pl5-19.5ubuntu1) feisty; urgency=low + + * Merge from debian unstable, remaining changes: + - fix FTBFS by adding missing asm/types.h + + -- Michael Vogt Mon, 11 Dec 2006 10:20:01 +0100 + +dhcp (2.0pl5-19.5) unstable; urgency=low + + * Non-maintainer upload. + * Add 117_fix_CVE-2006-3122 to fix remote DOS, CVE-2006-3122. + Thanks to Andrew Steets for detecting and the patch. Closes: #380273 + * Update 202_script_resolvconf-support to not break resolv.conf even if + domain_name is empty/undefined. Closes: #322860 + + -- Andreas Barth Mon, 4 Dec 2006 15:15:00 +0000 + +dhcp (2.0pl5-19.4ubuntu1) edgy; urgency=low + + * debian/patches/400_missing_type_h.patch: + - fix FTBFS by adding missing asm/types.h + + -- Michael Vogt Fri, 13 Oct 2006 12:11:01 +0200 + +dhcp (2.0pl5-19.4) unstable; urgency=low + + * Non-maintainer upload. + * Rename 116_aligned_structs.diff to 116_aligned_structs.patch so it will + actually be applied (Closes: #339711, #341757). + + -- Frans Pop Sat, 3 Dec 2005 20:09:53 +0100 + +dhcp (2.0pl5-19.3) unstable; urgency=low + + * Non-maintainer upload. + * 203_script_expr.patch: Fixed an error in the patch for #61441 + (Closes: #339595, #339637, #340106, #340109). + * 116_aligned_structs.diff: New patch fixing alignment issues on Sparc + (Closes: #339711). + + -- Sam Hocevar (Debian packages) Mon, 21 Nov 2005 08:54:40 +0100 + +dhcp (2.0pl5-19.2) unstable; urgency=low + + * Non-maintainer upload. + + * debian/copyright: + + Fixed the link to the changelog. + + Replaced "Author(s)" with "Author". + * debian/control: + + Set policy to 3.6.2.1. + + Build-depend on a newer version of debhelper (>= 4.0). + * debian/compat: + + Set level to 4. + * debian/rules: + + Use dh_install instead of dh_movefiles. It goes along with debhelper + level 4 a bit better. + + Removed now useless rmdir $(DESTDIR)/sbin/. + + Install CHANGES as the upstream changelog. + * debian/*.install: + + Created dhcp.install. + + Renamed dhcp-client.files into dhcp-client.install. + + Renamed dhcp-relay.files into dhcp-relay.install. + * debian/*.conffiles: + + Removed these now unneeded files, as debhelper now automatically tags + files in /etc as conffiles. + * debian/*.docs: + + Do not install CHANGES as a doc file. + * debian/dhcp.dirs: + + Added /var/lib/dhcp to the dhcp package. + * debian/changelog: + + Removed obsolete emacs settings (Closes: #281220). + + Fixed this file's syntax by adding a fake date to the first entry (all + the old dates seem fake anyway). + + Converted this file to UTF-8. + + * Renamed patches to clean up the directory and to make sure they are + applied in the right order: + + dhclient.patch -> 100_dhclient.patch + + extra-nul.patch -> 110_extra-nul.patch + + token-ring.patch -> 111_token-ring.patch + + common.patch -> 112_common.patch + + dhcp.patch -> 113_dhcp.patch + + dispatch.patch -> 114_dispatch.patch + + dhclient-script.patch -> 200_script.patch + + resolvconf-support.patch -> 202_script_resolvconf-support.patch + + documentation.patch -> 300_documentation.patch + + no-rfcs.patch -> 301_no-rfcs.patch + + README.patch -> 302_README.patch + + * 101_dhclient_wait.patch 201_script_arpcheck.patch: + + New patches courtesy of Andrew Suffield. Fix unnecessary wait after a + DHCPOFFER message (Closes: #304097). + * 115_format_string.patch: + + Moved the fix for CAN-2004-1006 in the patch system. + * 200_script.patch: + + Removed the release/relmajor/relminor patch which now stands in a + separate patch. + * 202_script_resolvconf-support.patch: + + Fixed the "[: too many arguments" error (Closes: #279639). + * 203_script_expr.patch: + + New patch courtesy of Andrew Pollock. Replaces the use of expr with sed + to avoid depending on /usr being mounted (Closes: #61441). + * 303_manpage_typos.patch: + + Fix various typos in the manpages, courtesy of A Costa (Closes: #332206, + Closes: #332207, #332208, #332209, #332210). + * 304_manpage_see_also.patch: + + Mention dhclient-script(8) in dhclient(8) (Closes: #170515). + + -- Sam Hocevar (Debian packages) Tue, 15 Nov 2005 12:04:24 +0100 + +dhcp (2.0pl5-19.1) unstable; urgency=high + + * Non-maintainer upload by the Security Team + * Corrected calls to syslog() in order to prevent a remotely triggerable + buffer overflow [common/errwarn.c, CAN-2004-1006] + + -- Steve Kemp Thu, 4 Nov 2004 16:30:11 +0000 + +dhcp (2.0pl5-19) unstable; urgency=low + + * Use invoke-rc.d if available when starting the DHCP server. + (Closes: #250878) + + -- Eloy A. Paris Wed, 26 May 2004 12:00:58 -0400 + +dhcp (2.0pl5-18) unstable; urgency=low + + * Doh! Forgot to commit the removal of dhclient-script so cvs export + did not bring the fixed code. + + -- Eloy A. Paris Tue, 18 May 2004 07:54:14 -0400 + +dhcp (2.0pl5-17) unstable; urgency=low + + * Maintainer upload. (closes: #221537) + * Applied patch from Thomas Hood to add resolvconf + support to dhclient. (closes: #248399, #211569) + * Do not provide dhclient-script in dhcp-client-udeb (closes: #249373) + + -- Eloy A. Paris Mon, 17 May 2004 23:43:41 -0400 + +dhcp (2.0pl5-16.1) unstable; urgency=low + + * NMU from Minnepaolis BSP. + * Applied patch to prevent md5sums file to be created for + dhcp-client-udeb. + + -- Scott M. Dier Sat, 13 Dec 2003 20:58:50 -0600 + +dhcp (2.0pl5-16) unstable; urgency=low + + * This should be the last 2.x release. The plan now is to move the + dhcp3* packages (dhcp3-server, dhcp3-relay, and dhcp3-client) to + the dhcp* packages. The dhcp3 packages will go away and only the + dhcp packages (tracking ISC DHCP 3.x and above) will stay. We need + help working on this migration. If you can help please drop us a + note at dhcp@packages.debian.org. + * Removed "non-free" documentation (RFCs) from the packages. + Thanks Craig P. Steffen . + (closes: #199798, #199801, #199802). + * I failed to handle the /usr/doc transition when I should have + (shame on me; sorry Joey). This is an attempt to fix my oversight: + if /usr/doc/{dhcp,dhcp-client,dhcp-relay} is a symlink we remove it. + (closes: #189855) + * Don't modify conffile (/etc/init.d/dhcp-relay) in the dhcp-relay + postinst script. New configuration mechanism (using + /etc/default/dhcp-relay) makes it clear how to specify multiple + DHCP servers (closes: #80076, #191006). + * Install /etc/rc?.d/ symlinks for /etc/init.d/dhcp-relay (closes: #90221). + + -- Eloy A. Paris Wed, 10 Sep 2003 15:32:02 -0400 + +dhcp (2.0pl5-15) unstable; urgency=low + + * Applied patch from Nicolás Lichtmaier to + fix the infamous off-by-one bug in MS DHCP server reported in + #74960. (closes: #74960) Muchas gracias Nicolás! + * Added verbiage to the package descriptions to make it clear what + the difference between these packages and the dhcp3-* packages is. + + -- Eloy A. Paris Sun, 16 Mar 2003 21:08:52 -0500 + +dhcp (2.0pl5-14) unstable; urgency=low + + * Print an error message in /etc/init.d/dhcp if dhcpd fails to + start. We're doing this already in the dhcp3-server package and this + is just a backport of the code that does this in the dhcp3-server + package. (Closes: #156293) + + -- Eloy A. Paris Sun, 11 Aug 2002 18:03:08 -0400 + +dhcp (2.0pl5-13) unstable; urgency=low + + * Make the default IP time to live compliant with the RFC (it was + 16 and it should be 64 according to Chad Walstrom + ). Thanks Chad. (closes: #154314) + + -- Eloy A. Paris Thu, 25 Jul 2002 21:59:51 -0400 + +dhcp (2.0pl5-12) unstable; urgency=low + + * Close lease database before executing dhclient-script (not need + to have it open, possible security risk.) (Closes: #147582) + * Remove compatibility baggage for supporting 2.0.x Linux kernels. + (Closes: #146042, as a side effect) + * Comment all subnet declarations in the sample dhcpd.conf so dhcpd + doesn't start unless the administrator configures it. + (Closes: #144360) + + -- Eloy A. Paris Tue, 9 Jul 2002 23:33:57 -0400 + +dhcp (2.0pl5-11) unstable; urgency=low + + * Make sure /etc/init.d/dhcp-client does not exist before calling + update-rc.d. We are not providing this script anymore, BTW. + (Closes: #138552) + * Removed output (info. for the user) from maintainer scripts on + package purge. + + -- Eloy A. Paris Sat, 16 Mar 2002 10:40:20 -0500 + +dhcp (2.0pl5-10) unstable; urgency=low + + * Fixes from Wichert: + - Restore rebindsignal patch that apparently has gotten lost. + With this patch you can send a USR1 signal to dhclient and + it will attempt to rebind each interface. + Closes: #93528, #134472. + - Don't do a dh_testroot on 'debian/rules clean'. + * Patch from Mark Glines that allows to supersede the + dhcp-server-identifier option in dhclient.conf. Closes: #126999. + * Applied patch from Francois Gouget to honor the + interface-mtu setting. Closes: #77328. + * Minor fixes to postinst scripts. + * Make the dhcp* packages FHS-compliant by having them store the lease + databases in /var/lib/dhcp/ instead of /var/dhcp/. + Closes: #133211 - dhcp-client: /var/dhcp: FHS compliant? + + -- Eloy A. Paris Thu, 21 Feb 2002 12:08:21 -0500 + +dhcp (2.0pl5-9) unstable; urgency=low + + * Make sure we don't call update-inetd if netbase is not installed. + Thanks to Ryan Murray for the advice and for patiently fielding + my stupid questions. This time, this really closes #59449. + Closes: #59449 postinst uses update-inetd, which might not be available. + * Restructured build system that provides DBS-like separation of + patches + * Removed all HTML tags from README, and formatted everything as + plain old text. This file obviously should have been a pure text file + but some upstream screw up shipped the 2.0pl5 release with the + file as HTML. No more incorrect HTML here. + Closes: #88132: Partial cleanup of HTML in README.html. + + -- Eloy A. Paris Sun, 10 Feb 2002 22:02:59 -0500 + +dhcp (2.0pl5-8) unstable; urgency=low + + * Note: support for 2.0.x kernels is going away soon. modutils + hasn't supported 2.0 kernels for ages now and we don't see + any reasons why dhcp should support them. We asked on + debian-devel and nobody has complained. Speak now or + forever hold your peace. + * Matt Zimmerman has been kind enough to accept my + offer to become co-maintainer of the ISC DHCP packages. Adding + an Uploaders: field with his name on it :-) + * Applied patch from Jochen Hein to make + DHCP work with Token Ring on 2.4.x kernels. + Closes: #128334 - DHCP with Kernel 2.4.17 and Token Ring doesn't work. + Closes: - #128172 - dhcp 2.0pl5-7 fails for token ring on 2.4.x > kernels. + * debian/control: dhcp-relay does not conflict with dhcp. + Closes: #118906 dhcp-relay: Don't conflict with dhcp. + * Got rid of the infamous run_dhcp setting in /etc/init.d/dhcp. + The init script now sources /etc/default/dhcp to get the + names of the interfaces the dhcpd daemon should listen to. + Please note that I am not getting rid of the -q parameter, as some + people have suggested, because I think dhcpd spits too much output + if it is run without this switch. Please do not file a bug report + about this. + Closes: #75365, #37949, #121509, #95154, #121854. + Closes: #129511 - dhcp: Configuration option in init script. + Closes: #95154 - dhcp: move enable line out of init.d script. + Closes: #93500 - dhcp; Make it possible to specify interfaces to use + on multi-homed hosts. + Closes: #79112 - Need to be able to specify interfaces in dhcp + and dhcp-client. (Note: dhcp's interfaces are configured + in /etc/default/dhcp. dhclient's interfaces are + specified in /etc/network/interfaces or in + /etc/pcmcia/network/opts.) + Closes: #47218 - dhcpd: forces use on multiple interfaces. + Closes: #41159 - dhcp: does not properly handle interfaces other + than eth0. + * Fixed dhcp's postinst script so it doesn't do silly things upon + removal. + Closes: #130433 - dhcp: dpkg --purge output. + Closes: #95152 - dhcp: extra output on purge. + * Delete /etc/init.d/dhcp-client during a purge (this script + is not part of the dhcp-client package anymore, but a NMU left + it around just in case and now it is breaking purges.) + Closes: #117480 - /etc/init.d/dhcp-client still exists; + dpkg --purge dhcp-client will fail. + * Including /var/dhcp/ in dhcp-client-udeb. + Closes: #124385 dchp-client-udeb needs to make /var/dhcp. + * Fixed minor typo in dhcpd.conf's man page. + Closes: #114075 dhcpd.conf: references itself. + * dhcp's postinst script writes to STDOUT a note saying where to + look for errors. + Closes: #108757: dhcp install script does not tell where to look + for errors. + * Fixed typo in NTP's RFC number in dhcp-options(5) manpage. + Closes: #107225 - Small error in the dhcp-options(5) manpage. + * dhcp depends on netbase so we can use update-inetd in maintainer + scripts. + Closes: #59449 postinst uses update-inetd, which might not be available. + + -- Eloy A. Paris Fri, 8 Feb 2002 14:10:10 -0500 + +dhcp (2.0pl5-7) unstable; urgency=medium + + * Finally, a maintainer upload. Sorry I have been MIA lately. + I want to mention that there are DHCP ISC 3.0 packages + available. The reason they are not in unstable is that + the boot-floppies team is using the DHCP client in ISC DHCP + 2.0 for the installation. The dhclient in 3.0 is huge and + doesn't fit in the boot-floopies, so the boot-floppies team + asked me to wait until woody is relased. Apparently if I + upload to unstable the packages might end up in frozen/testing + and that would destabilize their work. Any suggestions are + welcome. Meanwhile the 3.0 packages are in the experimental + section. Look in pool/main/d/dhcp/ in your favorite mirror. + The packages have debconf support for specifying the interfaces. + This is a much wanted request from a lot of people. + This maintainer upload closes the NMU bugs. + Closes: #113268: dhcp_2.0pl5-6.1_nmu.diff + Closes: #119032: debootstrap NMU 2.0pl5-6.1 and 2.0pl5-6.2 + * Make the dhcpd.sh and dhclient.sh wrappers work with 2.5.x kernels. + Closes: #122077: dhcp: Fails to start if kernel version >= 2.5.0 + Closes: #120729: dhcp-client: It dumps an error message and won't + start on 2.5.0. + * Cosmetic fixes to /etc/init.d/dhcp (from Mark Brown + ) + * Patch from russell@coker.com.au to fix broken compile when + DEBUG_PACKET is defined. + Closes: #124110: dhcp-client: patch for compiling with -DDEBUG_PACKET. + * Fixed typo in dhclient.conf.5. + Closes: #124109: dhclient.conf(5) documents 70 second minutes ;) + + -- Eloy A. Paris Sat, 15 Dec 2001 21:15:31 -0500 + +dhcp (2.0pl5-6.2) unstable; urgency=medium + + * add an option so the client will exit with an error if + it fails to configure an interface (closes: #109455) + Patch from David Kimdon + * other bugs fixed in last NMU (closes: #89669) + + -- Adam Di Carlo Sat, 10 Nov 2001 14:29:09 -0500 + +dhcp (2.0pl5-6.1) unstable; urgency=high + + * NMU to fix RC bugs; specifically the urgency is high for + boot-floppies; currently, things are breaking for boot-floppies when + the network was configured statically + * remove /etc/init.d/dhcp-client, since we use /etc/network/interfaces + now; hopefully that doesn't break too many people upgrading, but + better to break some upgrades than to break all new installs, IMHO + closes: #66432, #98680 + * not having the init script, but using ifupdown, fixes tons of other + problems too, although one wonders whether perhaps we shouldn't remove + the init script on upgrade as well + closes: #76401, #57917, #75604 + + -- Adam Di Carlo Mon, 17 Sep 2001 00:08:50 -0400 + +dhcp (2.0pl5-6) unstable; urgency=low + + * Applied patch from Aaron Schrab to avoid + following a NULL pointer when trying to read the lease time. + Closes: #103813 dhcp-client segfaults on powerpc. + + -- Eloy A. Paris Sun, 22 Jul 2001 20:23:00 -0400 + +dhcp (2.0pl5-5) unstable; urgency=low + + * Added groff to Build-depends. + Closes: #88711: error in build dependencies. + Closes: #91988: failed autobuild: missing groff build-depends. + * Added force-reload support to /etc/init.d/dhcp. + Closes: #89639: /etc/init.d/dhcp doesn't support force-reload. + * dhclient-exit-hooks does not need to be executable in dhclient's script. + Closes: #91306: dhclient-exit-hooks does not need to be executable. + * Applied patch to dhclient.c from Wichert to force a DHCP refresh. Sorry + it took so long, Wichert. + Closes: #84883: force DHCP refresh. + * Add reference to -d in dhclient's usage message. Reference did exist + in the man page. + Closes: #90702: help output does not mention -d. + + -- Eloy A. Paris Sun, 8 Apr 2001 17:32:16 -0400 + +dhcp (2.0pl5-4) unstable; urgency=low + + * Created a new package: dhcp-client-udeb. dhcp-client-udeb is a minimal + dhcp package used by the debian-installer. dhcp-client-udeb patch + provided by David Whedon . + Closes: #83001 - [PATCH] : dhcp-client-udeb for debian-installer. + * Updated README.Debian. + * Changed "if [ -x /etc/dhclient-enter-hooks ]; then ..." to + [ -f /etc/dhclient-enter-hooks ]; then ..." in client/scripts/linux + (the dhclient configuration script.) The script was checking that + the file was executable but then it was dotting it, and for this it + does not have to be executable. + Closes: Bug#84768: dhcp-client: dhclient-enter-hooks does not need to be + executable. + * Cleaned up README.html. + Closes: Bug#85285: Clean up README.html. + + -- Eloy A. Paris Tue, 27 Feb 2001 19:17:26 -0500 + +dhcp (2.0pl5-3) unstable; urgency=low + + * Transition from suidmanager to dpkg-statoverride. + + -- Eloy A. Paris Fri, 19 Jan 2001 00:13:32 -0500 + +dhcp (2.0pl5-2) unstable; urgency=low + + * Using /bin/sh instead of /bin/bash in scripts. + * Using alternatives to handle the ocurrence of the dhcp-options.5 manual + page in all the dhcp* packages. + Closes: #80034: dhcp-relay: Contains /usr/share/man/man5/dhcp-options.5.gz, + conflicting with dhcp-client. + Closes: #78646: dhcp and dhcp-client packages both provide + dhcp-options.5.gz man page. + Closes: #82106: dhcp-client: dhcp-options.5.gz also in package dhcp. + * Added patch from bug #79578 to allow the dhcp client and server to + work under Debian-ARM. + Closes: #79578: dhcp: NMU: Debian-ARM patches. + Closes: #62940: dhcp: NMU: Debian-ARM changes (alignment fix). + * Removed comment misleading comment in /etc/init.d/dhcp. I plan to move + to debconf soon and then people will be able to specify the interfaces + on which to run DHCP. + Closes: #71310: /etc/init.d/dhcp has misleading comments. + + -- Eloy A. Paris Mon, 15 Jan 2001 11:55:58 -0500 + +dhcp (2.0pl5-1) unstable; urgency=low + + * New upstream version. + Closes: Bug#69684 - Patch to fix dhcp for picky gcc on Alpha. + * Added the -q switch to the invocation of the dhcp* daemons (dhcpd, + dhclient, and dhcrelay) in the corresponding /etc/init.d/dhcp* + script (dhcpd, dhcp-client and dhcp-relay) so programs don't print + a lot of junk when they start. + Closes: Bug#71309 - dhcpd wraper should call with -q. + Closes: Bug#59280 - dhcp: Too verbose. + * Added code to /etc/init.d/dhcp-client to test if the new scheme for + network configuration is being used (the /etc/network/* stuff). If + this is the case then the init.d script just exists without doing + anything. + Closes: Bug#61092 - dhclient loads twice under new interfaces + configuration. + + -- Eloy A. Paris Mon, 11 Sep 2000 23:33:53 -0400 + +dhcp (2.0pl4-2) stable unstable; urgency=low + + * Uploading to stable because the current dhcp* packages in stable do + not contain the recent security fixes. + + -- Eloy A. Paris Tue, 15 Aug 2000 23:14:08 -0400 + +dhcp (2.0pl4-1) unstable; urgency=low + + * New upstream version. + + -- Eloy A. Paris Wed, 9 Aug 2000 21:01:03 -0400 + +dhcp (2.0pl3-3) unstable; urgency=low + + * Call the configure scripts as "/bin/sh debian/configure-xx" instead + of just "debian/configure" so no non-executable scripts are found + during building. + Closes: Bug#68462 - dhcp: non-executable script during building. + + -- Eloy A. Paris Sun, 6 Aug 2000 11:45:57 -0400 + +dhcp (2.0pl3-2) unstable; urgency=low + + * OK, I screwed it up: the fact that it is entirely possible to have + a DHCP server and a DHCP client running at the same time in the same + machine never crossed my mind, so I made each of the dhcp* packages + conflict with each other in 2.0pl3-1. Big mistake! SO I corrected + that and just left dhcp-client to conflict with dhcpcd. I hope that + nobody is using ISC DHCP client and dhcpcd in the same machine and at + the same time because I'm going to be pissed. + Closes: Bug#68445: dhcp: shouldn't conflict with dhcp-client. + + -- Eloy A. Paris Thu, 3 Aug 2000 20:56:21 -0400 + +dhcp (2.0pl3-1) unstable; urgency=low + + * New upstream version (I skipped 2.0pl1 and 2.0pl2.) + * Made /etc/init.d/dhcp-client a conffile to prevent an overwrite at + install time without the user knowing it. In the future I will use + debconf to take care of interface configuration. + Closes: Bug#67873: dhcp-client: init.d script is overwritten on upgrade. + * Applied patch from Jun Hamano to + fix kernel version identification problems in /etc/dhclient-script + (thanks Jun!) + Closes: #66472: dhcp-client: /etc/dhclient-script bugfix. + * Applied patch from steve@nyongwa.montreal.qc.ca to fix problems + reported in bug #66173 (thanks Steve!) Also, fixed dhclient.conf(5) + to reference dhclient.leases(8) instead of dhclient-lease(8) as well + as dhclient-script in the description of the "script" statement. + Closes: #66173: dhcp-client: dhclient-script doesn't do what its + manpage says. + * Added to the control section of the dhcp-client package a conflict + with the dhcpcd package. + Closes: #65524: dhcp-client needs a "conflicts" with dhcpcd. + * Made each of the dhcp* packages (dhcp, dhcp-relay and dhcp-client) + conflict with each other so only one of them can be installed at + the same time. + * Now dhcp-options(5) is installed in each of the dhcp* packages. + Closes: #61716: dhcp-client: dhcp-options(5) man page missing. + + -- Eloy A. Paris Sun, 30 Jul 2000 11:58:17 -0400 + +dhcp (2.0-3) unstable; urgency=low + + * The sample /etc/dhclient.conf is now provided completely commented + out so existing installations are not broken after upgrading + to dhcp-client 2.0-3 and above. + Closes: Bug#50592: default dhclient.conf is a killer. + + -- Eloy A. Paris Thu, 18 Nov 1999 21:34:29 -0500 + +dhcp (2.0-2) unstable; urgency=low + + * Compiled two sets of binaries: one for 2.0.x kernels and another + one for 2.2.x kernels. Created three wrapper scripts (dhcpd, + dhclient, and dhcrelay) that call the appropiate version + depending on the version of the running kernel. I also needed + to tweak dhcp's init.d script to accomodate for the change (now + I am calling "start-stop-daemon --stop" with the --pid-file argument + and not with bot the --pid-file and the --exec arguments. + Closes: Bug#41974 (dhcp requires kernel 2.2??) + * Took care of the /usr/doc/* -> /usr/share/doc/* move (had to + tweak the postinst and prerm scripts to take care of the link since + I am not letting debhelper generate these scripts automatically). + * Man pages now installed in /usr/share/man/. + * Fixed a little the init.d script for dhcp-relay, although this file + was so broken that I believe nobody is using this package. + * Fixed a minor typo in the sample server/dhcpd.conf file + ("domain-name-servers" instead of "name-servers"). + * s/reload/restart/g in /etc/init.d/dhcp. + * Updated README.Debian and descriptions in debian/control. + * Removed Bashism from /etc/dhclient-script. + Closes: Bug#44977 (Bashism in /etc/dhclient-script) + * Included /etc/dhclient.conf and made it a conffile for dhcp-client. + Closes: Bug#45537 (significant error in dhclient man pages) + * Added a /etc/init.d/dhcp-client script. The script won't start + dhclient if /sbin/cardmgr exists (this normally means + that PCMCIA is installed and that dhclient will be started by the + cardmgr daemon). The script is run early in the boot sequence. + Closes: Bug#48952 (missing /etc/init.d/dhcp-client?) + + -- Eloy A. Paris Tue, 2 Nov 1999 23:41:00 -0500 + +dhcp (2.0-1) unstable; urgency=low + + * Final release of dhcp-2.0. + * Removed "-beta" suffix from all the packages. This package now replaces + the old dhcp-1.0 package and the -beta packages no longer exist. + + -- Eloy A. Paris Wed, 23 Jun 1999 12:28:12 -0400 + +dhcp-beta (2.0b1pl27-1) unstable; urgency=low + + * New upstream version (never uploaded to master). + + -- Eloy A. Paris Sun, 25 Apr 1999 14:21:39 -0400 + +dhcp-beta (2.0b1pl26-1) unstable; urgency=low + + * New upstream version. + + -- Eloy A. Paris Fri, 16 Apr 1999 09:21:46 -0400 + +dhcp-beta (2.0b1pl18-1) unstable; urgency=low + + * New upstream version. + + -- Eloy A. Paris Sun, 7 Mar 1999 09:09:59 -0400 + +dhcp-beta (2.0b1pl17-1) unstable; urgency=low + + * New upstream version. + * Fixed dhcp-beta's postinst and prerm scripts to call update-rc.d + to update the rc links to /etc/init.d/dhcp-beta. + + -- Eloy A. Paris Sun, 28 Feb 1999 13:32:13 -0400 + +dhcp-beta (2.0b1pl14-1) unstable; urgency=low + + * New maintainer (temporary, while Rich Sahlender is out of scene). + * New upstream version. + * Moved from debstd to debhelper. + * Modified /etc/init.d/dhcp-beta to start/stop dhcpd by using the + PID file /var/run/dhcpd.pid. + * Re-worked a lot debian/rules (I actually wrote it again from scratch). + * The patches in the last NMU done by Vincent Renardias + are not included since I tested dhclient and it ran just fine. Please + give this new version a shot and let me know of any problems. + + -- Eloy A. Paris Fri, 19 Feb 1999 19:39:20 -0400 + +dhcp-beta (2.0b1pl6-0.2) frozen unstable; urgency=medium + + * NMU: + Fix Grave bug #18322 with the provided patch. + Fix Important bug #19767: dhcp-client-beta did not contain + any /usr/doc/dhcp-client-beta directory. + Fix bug #20532 bad option in /etc/dhcpd.conf. + Close bug #20533 file location prob (Fixed by previous upload). + Close bug #22081 dhcpd-beta (Fixed by previous upload). + Close bug #19768 /etc/dhclient-script is not a conffile + (Already fixed). + Fix bug #28164 by included a new dhclient script. + + -- Vincent Renardias Tue, 5 Jan 1999 23:23:47 +0100 + +dhcp-beta (2.0b1pl6-0.1) frozen unstable; urgency=medium + + * Non-maintainer upload that fixes "important" bugs #24445 ([SECURITY] + dhcp-beta: potential buffer overflow problems) and #24442 + (/etc/init.d/dhcp-beta sources inexistent /etc/init.d/functions). + * New upstream release (this new release is what solves bug #24445). + * Removed from /etc/init.d/dhcp sourcing of /etc/init.d/functions because + this file is obsolete and is not present in newer Debian releases + (>= 2.0). This fixes #24442 and #19654 (/etc/init.d/functions should + not be used). + * Changed _PATH_DHCPD_DB in dhcpd.h to /var/dhcp/dhcpd.leases (it was + /var/lib/dhcpd/dhcpd.leases, which we are not using anymore). So, + now the leases database will be in /var/dhcp/dhcpd.leases. No more + files in /var/dhcpd/ nor /var/lib/dhcpd/. + * Changed VARDB (in the linux-2.0 section of Makefile.dist) to be + /var/dhcp/ instead of /var/dhcpd/ (this was done to support the + change of the leases database to /var/dhcp/). The consequence of this + is that /var/dhcpd/ is not provided in the .deb anymore (which is + fine because this directory is not used). + * Defined PATH_DHCPD_DB as a constant equal to "/var/dhcp/dhcpd.leases" + in the postinst. Used this constant in all references to the leases + database througout the postinst. + * s%ETCDIR%/etc/%g, s%DBDIR%/var/dhcp/%g and s%RUNDIR%/var/run/%g in + dhcpd.8 and dhcpd.leases.5, so the man pages show the correct directory. + * The last 4 changes fix #23089 (/var/lib/dhcpd does not exist so dhcpd + can't start). + * Made the default _not_ to run dhcpd. This was done by setting run_dhcpd + to 0 in the default /etc/init.d/dhcp. + * Change comments that are printed out in the last part of the postinst + to explain that editing of /etc/dhcpd.conf and /etc/init.d/dhcp is + necessary in order to be able to run dhcpd. + * Fixed a small typo in /etc/init.d/dhcp (diasble -> disable). + * Added the word "server" to the short description of dhcp-beta in + the control file. This fixes #17558 (dhcp-beta: unclear description). + + -- Eloy A. Paris Fri, 17 Jul 1998 00:06:50 -0400 + +dhcp-beta (2.0b1pl1-1) frozen unstable; urgency=low + + * New upstream patches fixing security and other bugs. + * New Maintainer. + + -- Rich Sahlender Thu, 28 May 1998 23:02:43 -0400 + +dhcp-beta (2.0b1pl0-2) unstable; urgency=low + + * #17939 dhcplient problem with environment variable. + + -- Christoph Lameter Mon, 16 Feb 1998 19:46:47 -0800 + +dhcp-beta (2.0b1pl0-1) unstable; urgency=low + + * Generate additional binaries dhcp-relay-beta and dhcp-client-beta. + dhcp-client beta is not working. + * New Beta Version with support for multiple interfaces etc. + * debian/config did not support multi-binary targets cleanly. Removed. + * Note: The relay does not properly handle the -i option but scans all + interfaces (upstream issue) + + -- Christoph Lameter Sun, 4 Jan 1998 13:12:05 -0800 + +dhcp (1.0.0-1) debs; urgency=low + + * Upstream non-beta release. Name changed to dhcp. + + -- Christoph Lameter Sun, 4 Jan 1998 09:34:44 -0800 + +dhcpd (0.5.16.1-4) unstable; urgency=low + + * One interface only. If the 2.0.31 feature becomes finally available + also in 2.1.x then I will include the multi interface feature again. + * Customize /etc/dhcpd.conf so that it should work after installation with + some possibly wrong defaults. + * Linux configuration reworked for glibc. Build on hamm. + + -- Christoph Lameter Thu, 4 Sep 1997 16:19:25 -0700 + +dhcpd (0.5.16.1-3) unstable; urgency=low + + * Documentation changes. Linus has included SO_BINDTODEVICE in the latest + pre patches for Kernel 2.0.31 + + -- Christoph Lameter Mon, 4 Aug 1997 20:45:21 -0700 + +dhcpd (0.5.16.1-2) unstable; urgency=low + + * /etc/init.d/dhcpd: Add initializing routes to 255.255.255.255. + * README.debian: Given the correct name and added some more information. + + -- Christoph Lameter Wed, 11 Jun 1997 22:31:36 -0700 + +dhcpd (0.5.16.1-1) unstable; urgency=low + + * Include CHANGES file as upstream changelog + * Update to latest upstream release. Support for multiple interfaces + using Linux 2.0.31-2 and higher now available. This version will not work + with older version of Linux. + * Make dhcpd build using debmake's build command. + * Include dhcp relay agent and dhcp client + * Update messages that appear on the screen + + -- Christoph Lameter Wed, 11 Jun 1997 13:30:00 -0700 + +dhcpd (0.5.14-2) unstable; urgency=low + + * Moved leases file into /var/lib/dhcp/ (#5689). + + -- Joey Hess Tue, 25 Feb 1997 20:27:54 -0500 + +dhcpd (0.5.14-1) unstable; urgency=low + + * New upstream release. + * New maintainer. + * Old version had incorrect name for directory in .orig.tar.gz file; + corrected this. + * Modifications for new debmake. + * This needs some testing. I can't test it becuase the computer on my + network that uses DHCP isn't here right now. + * Remove leases file on purge. + + -- Joey Hess Sun, 9 Feb 1997 20:16:08 -0500 + +dhcpd (0.5.13-4) unstable; urgency=low + + * debmake bug: no scripts installed in -3 + + -- Christoph Lameter Thu, 17 Oct 1996 07:12:44 +0800 + +dhcpd (0.5.13-3) unstable; urgency=low + + * added a touch /etc/dhcpd.leases to postinst on suggestion of Joey Hess. + * Uses debmake: compressed manpages + documentation + + -- Christoph Lameter Wed, 16 Oct 1996 18:21:15 +0800 + +dhcpd (0.5.13-2) unstable; urgency=low + + * Forgot to include conffiles in binary + * Documentation moved around + + -- Christoph Lameter Mon, 16 Sep 1996 14:51:46 +0800 + +dhcpd (0.5.13-1) unstable; urgency=low + + * New upstream version + + -- Christoph Lameter Mon, 16 Sep 1996 14:51:46 +0800 + +dhcpd (0.5.11-1) unstable; urgency=high + + * New upstream version + + -- Christoph Lameter Wed, 11 Sep 1996 14:51:46 +0800 + +dhcpd (0.5.9-1) unstable; urgency=high + + * New upstream version + * Debian changelog made available in /usr/doc/dhcpd + + -- Christoph Lameter Wed, 4 Sep 1996 14:51:46 +0800 + +dhcpd (0.5.7-1) unstable; urgency=high + + * New upstream version + + -- Christoph Lameter Wed, 4 Sep 1996 14:51:46 +0800 + +dhcpd (0.5.5-1) experimental; urgency=low + + * Initial Release + + -- Christoph Lameter Wed, 4 Sep 1996 14:51:46 +0800 + --- dhcp-2.0pl5.orig/debian/dhcp-relay.docs +++ dhcp-2.0pl5/debian/dhcp-relay.docs @@ -0,0 +1 @@ +README RELNOTES doc/ debian/dhcp-on-linux.txt --- dhcp-2.0pl5.orig/debian/dhcp-client.prerm +++ dhcp-2.0pl5/debian/dhcp-client.prerm @@ -0,0 +1,13 @@ +#!/bin/sh -e +# +# $Id: dhcp-client.prerm,v 1.2.2.2 2004/05/26 16:45:04 peloy Exp $ +# + +if [ "$1" != upgrade ]; then + update-alternatives --remove dhcp-options.5.gz \ + /usr/share/man/man5/dhcp-options-dhclient.5.gz +fi + +#DEBHELPER# + +exit 0 --- dhcp-2.0pl5.orig/debian/dhcpd.conf +++ dhcp-2.0pl5/debian/dhcpd.conf @@ -0,0 +1,91 @@ +# +# Sample configuration file for ISC dhcpd for Debian +# +# $Id: dhcpd.conf,v 1.4.2.2 2002/07/10 03:50:33 peloy Exp $ +# + +# option definitions common to all supported networks... +option domain-name "fugue.com"; +option domain-name-servers toccata.fugue.com; + +option subnet-mask 255.255.255.224; +default-lease-time 600; +max-lease-time 7200; + +#subnet 204.254.239.0 netmask 255.255.255.224 { +# range 204.254.239.10 204.254.239.20; +# option broadcast-address 204.254.239.31; +# option routers prelude.fugue.com; +#} + +# The other subnet that shares this physical network +#subnet 204.254.239.32 netmask 255.255.255.224 { +# range dynamic-bootp 204.254.239.10 204.254.239.20; +# option broadcast-address 204.254.239.31; +# option routers snarg.fugue.com; +#} + +#subnet 192.5.5.0 netmask 255.255.255.224 { +# range 192.5.5.26 192.5.5.30; +# option name-servers bb.home.vix.com, gw.home.vix.com; +# option domain-name "vix.com"; +# option routers 192.5.5.1; +# option subnet-mask 255.255.255.224; +# option broadcast-address 192.5.5.31; +# default-lease-time 600; +# max-lease-time 7200; +#} + +# Hosts which require special configuration options can be listed in +# host statements. If no address is specified, the address will be +# allocated dynamically (if possible), but the host-specific information +# will still come from the host declaration. + +#host passacaglia { +# hardware ethernet 0:0:c0:5d:bd:95; +# filename "vmunix.passacaglia"; +# server-name "toccata.fugue.com"; +#} + +# Fixed IP addresses can also be specified for hosts. These addresses +# should not also be listed as being available for dynamic assignment. +# Hosts for which fixed IP addresses have been specified can boot using +# BOOTP or DHCP. Hosts for which no fixed address is specified can only +# be booted with DHCP, unless there is an address range on the subnet +# to which a BOOTP client is connected which has the dynamic-bootp flag +# set. +#host fantasia { +# hardware ethernet 08:00:07:26:c0:a5; +# fixed-address fantasia.fugue.com; +#} + +# If a DHCP or BOOTP client is mobile and might be connected to a variety +# of networks, more than one fixed address for that host can be specified. +# Hosts can have fixed addresses on some networks, but receive dynamically +# allocated address on other subnets; in order to support this, a host +# declaration for that client must be given which does not have a fixed +# address. If a client should get different parameters depending on +# what subnet it boots on, host declarations for each such network should +# be given. Finally, if a domain name is given for a host's fixed address +# and that domain name evaluates to more than one address, the address +# corresponding to the network to which the client is attached, if any, +# will be assigned. +#host confusia { +# hardware ethernet 02:03:04:05:06:07; +# fixed-address confusia-1.fugue.com, confusia-2.fugue.com; +# filename "vmunix.confusia"; +# server-name "toccata.fugue.com"; +#} + +#host confusia { +# hardware ethernet 02:03:04:05:06:07; +# fixed-address confusia-3.fugue.com; +# filename "vmunix.confusia"; +# server-name "snarg.fugue.com"; +#} + +#host confusia { +# hardware ethernet 02:03:04:05:06:07; +# filename "vmunix.confusia"; +# server-name "bb.home.vix.com"; +#} --- dhcp-2.0pl5.orig/debian/copyright +++ dhcp-2.0pl5/debian/copyright @@ -0,0 +1,39 @@ +This package was debianized by Eloy A. Paris on +Fri, 19 Feb 1999 19:38:45 -0400. It is based on the work of previous +maintainers of this package (see /usr/share/doc/dhcp/changelog.Debian.gz). + +It was downloaded from ftp://ftp.isc.org/isc/dhcp/. + +Upstream Author: Ted Lemon + +Copyright: +/* + * Copyright (c) 1996, 1997 The Internet Software Consortium. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. Neither the name of The Internet Software Consortium nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE INTERNET SOFTWARE CONSORTIUM AND + * CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, + * BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS + * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL + * THE INTERNET SOFTWARE CONSORTIUM OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR + * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED + * OF THE POSSIBILITY OF SUCH DAMAGE. + */ --- dhcp-2.0pl5.orig/debian/dhclient.conf +++ dhcp-2.0pl5/debian/dhclient.conf @@ -0,0 +1,49 @@ +# /etc/dhclient.conf file for /sbin/dhclient included in Debian's +# dhcp-client package. +# +# This is a sample configuration file for dhclient. See dhclient.conf's +# man page for more information about the syntax of this file +# and a more comprehensive list of the parameters understood by +# dhclient. +# +# Normally, if the DHCP server provides reasonable information and does +# not leave anything out (like the domain name, for example), then +# few changes must be made to this file, if any. +# + +#send host-name "andare.fugue.com"; +#send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; +#send dhcp-lease-time 3600; +#supersede domain-name "fugue.com home.vix.com"; +#prepend domain-name-servers 127.0.0.1; +#request subnet-mask, broadcast-address, time-offset, routers, +# domain-name, domain-name-servers, host-name; +#require subnet-mask, domain-name-servers; +#timeout 60; +#retry 60; +#reboot 10; +#select-timeout 5; +#initial-interval 2; +#script "/etc/dhclient-script"; +#media "-link0 -link1 -link2", "link0 link1"; +#reject 192.33.137.209; + +#alias { +# interface "eth0"; +# fixed-address 192.5.5.213; +# option subnet-mask 255.255.255.255; +#} + +#lease { +# interface "eth0"; +# fixed-address 192.33.137.200; +# medium "link0 link1"; +# option host-name "andare.swiftmedia.com"; +# option subnet-mask 255.255.255.0; +# option broadcast-address 192.33.137.255; +# option routers 192.33.137.250; +# option domain-name-servers 127.0.0.1; +# renew 2 2000/1/12 00:00:01; +# rebind 2 2000/1/12 00:00:01; +# expire 2 2000/1/12 00:00:01; +#} --- dhcp-2.0pl5.orig/debian/dhcp.prerm +++ dhcp-2.0pl5/debian/dhcp.prerm @@ -0,0 +1,21 @@ +#!/bin/sh -e +# +# $Id: dhcp.prerm,v 1.2.2.2 2004/05/26 16:45:04 peloy Exp $ +# + +if [ "$1" != upgrade ]; then + update-alternatives --remove dhcp-options.5.gz \ + /usr/share/man/man5/dhcp-options-dhcpd.5.gz +fi + +if [ -x /etc/init.d/dhcp ]; then + if [ -x /usr/sbin/invoke-rc.d ]; then + invoke-rc.d dhcp stop + else + /etc/init.d/dhcp stop + fi +fi + +#DEBHELPER# + +exit 0 --- dhcp-2.0pl5.orig/debian/dhcp.dirs +++ dhcp-2.0pl5/debian/dhcp.dirs @@ -0,0 +1,2 @@ +/var/run +/var/lib/dhcp --- dhcp-2.0pl5.orig/debian/dhcp-on-linux.txt +++ dhcp-2.0pl5/debian/dhcp-on-linux.txt @@ -0,0 +1,54 @@ +From: mellon@hoffman.vix.com (Ted Lemon) +Subject: Re: Linux 2.0/2.1/2.2 -- Anyway to avoid different binaries?? +Date: 4 Feb 1999 17:30:11 -0400 +Message-ID: <199902041802.NAA01184@grosse.fugue.com> + + *** From dhcp-client -- To unsubscribe, see the end of this message. *** + +> Any way to avoid having to have different binaries for the various Linux +> kernels? On one or two boxes, it's no big deal to maintain, but in an +> enterprise it can be real pain. + +Yes. Send email to the Linux kernel network people requesting that +they revisit the issue of whether or not to allow network interfaces +to be configured with IP addresses of 0.0.0.0. + +The reason behind switching to lpf is that in 2.1.100 (or thereabouts) +somebody noticed that if you configured a network interface with an IP +address of 0.0.0.0 and some other machine arped for 0.0.0.0, it would +respond, which is incorrect. This bug was fixed by making it +impossible to configure an interface with that address. A preferable, +and equally effective fix would have been to hack the ARP code to +never reply to requests of this kind. + +Since DHCP clients depend on being able to send requests from the +0.0.0.0 IP address, which is a perfectly legitimate thing to do, and +since this is no longer permitted in Linux, DHCP clients and servers +for 2.0 and 2.1/2.2 are not interchangeable. An additional +consequence is that it is not possible to run the DHCP server or +client on a Linux 2.1/2.2 box connected to a token ring network, +because the physical layer encapsulation protocol is different, and +with lpf the application has to do the physical layer encapsulation (I +kid you not!). This can be worked around by adding code to support +token ring - there's already similar code to support FDDI. But my +take on this is that it's really the O.S.'s job to do physical layer +encapsulation, and doing it in the application is just needless +duplication. + +I've tried arguing this point with the Linux network gods, but for +some reason they concluded that my motivation was to avoid having to +do extra work, not that my concern was legitimate, so they refused to +back out the change. A sufficiently vocal response from real Linux +users like you might change their minds. + + _MelloN_ + + +------------------------------------------------------------------------------ +To unsubscribe from this list, please visit http://www.fugue.com/dhcp/lists +If you are without web access, or if you are having trouble with the web page, +please send mail to dhcp-request@fugue.com. Please try to use the web +page first - it will take a long time for your request to be processed by hand. +------------------------------------------------------------------------------ + + --- dhcp-2.0pl5.orig/debian/dhcp-client.docs +++ dhcp-2.0pl5/debian/dhcp-client.docs @@ -0,0 +1 @@ +README RELNOTES doc/ debian/dhcp-on-linux.txt --- dhcp-2.0pl5.orig/debian/dhcp-relay.install +++ dhcp-2.0pl5/debian/dhcp-relay.install @@ -0,0 +1,2 @@ +/usr/sbin/dhcrelay +/usr/share/man/man8/dhcrelay.8 --- dhcp-2.0pl5.orig/debian/dhcp-relay.init.d +++ dhcp-2.0pl5/debian/dhcp-relay.init.d @@ -0,0 +1,52 @@ +#!/bin/sh +# +# $Id: dhcp-relay.init.d,v 1.3.2.3 2003/09/10 19:49:21 peloy Exp $ +# + +test -x /usr/sbin/dhcrelay || exit 0 + +# It is not safe to start if we don't have a default configuration... +if [ ! -f /etc/default/dhcp-relay ]; then + echo "/etc/default/dhcp-relay does not exist! - Aborting..." + exit 0 +fi + +# Read init script configuration (interfaces the daemon should listen on +# and the DHCP server we should forward requests to.) +. /etc/default/dhcp-relay + +if [ "$DHCP_SERVERS" = "" ]; then + echo "No DHCP servers configured! Edit /etc/default/dhcp-relay." + exit 0 +fi + +# Build command line for interfaces (will be passed to dhrelay below.) +IFCMD="" +if test "$INTERFACES" != ""; then + for I in $INTERFACES; do + IFCMD=${IFCMD}"-i "${I}" " + done +fi + +DHCRELAYPID=/var/run/dhcrelay.pid + +case "$1" in + start) + start-stop-daemon --start --quiet --pidfile $DHCRELAYPID \ + --exec /usr/sbin/dhcrelay -- -q $OPTIONS $IFCMD \ + $DHCP_SERVERS + ;; + stop) + start-stop-daemon --stop --quiet --pidfile $DHCRELAYPID + ;; + restart | force-reload) + $0 stop + sleep 2 + $0 start + ;; + *) + echo "Usage: /etc/init.d/dhcp-relay {start|stop|restart|force-reload}" + exit 1 +esac + +exit 0 --- dhcp-2.0pl5.orig/debian/dhcp-client.install +++ dhcp-2.0pl5/debian/dhcp-client.install @@ -0,0 +1,7 @@ +/sbin/dhclient +/etc/dhclient-script +/etc/dhclient.conf +/usr/share/man/man8/dhclient.8 +/usr/share/man/man8/dhclient-script.8 +/usr/share/man/man5/dhclient.conf.5 +/usr/share/man/man5/dhclient.leases.5 --- dhcp-2.0pl5.orig/debian/dhcp-client.postinst +++ dhcp-2.0pl5/debian/dhcp-client.postinst @@ -0,0 +1,67 @@ +#!/bin/sh -e +# +# $Id: dhcp-client.postinst,v 1.3.2.3 2004/05/26 16:45:04 peloy Exp $ +# + +case "$1" in + configure) + # continue below + ;; + + abort-upgrade|abort-remove|abort-deconfigure) + exit 0 + ;; + + *) + echo "postinst called with unknown argument \`$1'" >&2 + exit 0 + ;; +esac + +PATH_DHCLIENT_DB=/var/lib/dhcp/dhclient.leases + +# --- Begin FHS migration code --- + +# Starting with dhcp-2.0pl5-10 we are FHS-compliant. The following +# code takes care of moving important files in the old, non +# FHS-compliant directory (/var/dhcp/) to their new location +# (/var/lib/dhcp/) +if [ -d /var/dhcp/ ]; then + mv /var/dhcp/dhclient* /var/lib/dhcp/ 2> /dev/null || true + rmdir /var/dhcp/ 2> /dev/null || true +fi + +# --- End FHS migration code --- + +if [ ! -e $PATH_DHCLIENT_DB ]; then + touch $PATH_DHCLIENT_DB +fi + +# We handle the multiple occurence of the manual page dhcp-options.5 through +# the alternative system. It is nice to have this page in all the +# dhcp* packages and since I can't make one package to conflict +# with the others the alternatives system looks like a good way +# to solve the problem. +if [ "$1" != upgrade ]; then + update-alternatives --install /usr/share/man/man5/dhcp-options.5.gz \ + dhcp-options.5.gz \ + /usr/share/man/man5/dhcp-options-dhclient.5.gz \ + 100 +fi + +# I failed to handle the /usr/doc transition when I should have (shame +# on me; sorry Joey). This is an attempt to fix my oversight: if +# /usr/doc/dhcp-client is a symlink we remove it. +if [ -h /usr/doc/dhcp-client ]; then + rm -f /usr/doc/dhcp-client +fi + +# Since 2.0pl5-6.1 we do not start dhclient ourselves, we rely on +# ifup/ifdown or the PCMCIA subsystem for this. So, we remove here +# the old init script and the rc.d links. +rm -f /etc/init.d/dhcp-client +update-rc.d dhcp-client remove > /dev/null 2>&1 + +#DEBHELPER# + +exit 0 --- dhcp-2.0pl5.orig/debian/dhcp-client.dirs +++ dhcp-2.0pl5/debian/dhcp-client.dirs @@ -0,0 +1,3 @@ +var/run +var/lib/dhcp +usr/share/man/man5 --- dhcp-2.0pl5.orig/debian/compat +++ dhcp-2.0pl5/debian/compat @@ -0,0 +1 @@ +4 --- dhcp-2.0pl5.orig/debian/dhcp-client-udeb.dirs +++ dhcp-2.0pl5/debian/dhcp-client-udeb.dirs @@ -0,0 +1,3 @@ +sbin +etc +var/lib/dhcp --- dhcp-2.0pl5.orig/debian/dhcp-relay.dirs +++ dhcp-2.0pl5/debian/dhcp-relay.dirs @@ -0,0 +1,2 @@ +var/run +usr/share/man/man5 --- dhcp-2.0pl5.orig/debian/patches/110_extra-nul.patch +++ dhcp-2.0pl5/debian/patches/110_extra-nul.patch @@ -0,0 +1,14 @@ +--- dhcp-2.0pl5/common/options.c.orig Thu Mar 13 14:01:24 2003 ++++ dhcp-2.0pl5/common/options.c Thu Mar 13 13:30:39 2003 +@@ -492,6 +492,11 @@ + fmtbuf [i] = 't'; + fmtbuf [i + 1] = 0; + numhunk = -2; ++ ++ /* Coping with bug in Microsoft DHCP server */ ++ if(data[len-1] == '\0') ++ len--; ++ + break; + case 'I': + case 'l': --- dhcp-2.0pl5.orig/debian/patches/201_script_arpcheck.patch +++ dhcp-2.0pl5/debian/patches/201_script_arpcheck.patch @@ -0,0 +1,15 @@ +--- dhcp-2.0pl5.orig/client/scripts/linux ++++ dhcp-2.0pl5/client/scripts/linux +@@ -90,7 +90,11 @@ + exit_with_hooks 0 + fi + +-if [ x$reason = xARPCHECK ] || [ x$reason = xARPSEND ]; then ++if [ x$reason = xARPSEND ]; then ++ exit_with_hooks 1 ++fi ++ ++if [ x$reason = xARPCHECK ]; then + exit_with_hooks 0 + fi + --- dhcp-2.0pl5.orig/debian/patches/202_script_resolvconf-support.patch +++ dhcp-2.0pl5/debian/patches/202_script_resolvconf-support.patch @@ -0,0 +1,89 @@ +--- dhcp-2.0pl5/client/scripts/linux.orig 2004-05-16 23:17:37.000000000 -0400 ++++ dhcp-2.0pl5/client/scripts/linux 2004-05-16 23:17:52.000000000 -0400 +@@ -3,6 +3,7 @@ + # Updated for Linux 2.[12] by Brian J. Murrell, January 1999. + # No guarantees about this. I'm a novice at the details of Linux + # networking. ++# Support for resolvconf added by Thomas Hood, May 2004. + + # Notes: + +@@ -32,12 +33,35 @@ + exit $exit_status + } + +-make_resolv_conf() { +- echo search $new_domain_name >/etc/resolv.conf +- for nameserver in $new_domain_name_servers; do +- echo nameserver $nameserver >>/etc/resolv.conf +- done +-} ++if [ -x /sbin/resolvconf ]; then ++ make_resolv_conf() { ++ R="" ++ [ "x$new_domain_name" != x ] && R="${R}search $new_domain_name ++" ++ for NMSRVR in $new_domain_name_servers; do ++ R="${R}nameserver $NMSRVR ++" ++ done ++ echo -n "$R" | /sbin/resolvconf -a "$interface" || return 1 ++ } ++ unmake_resolv_conf() { ++ /sbin/resolvconf -d "$interface" || return 1 ++ } ++else ++ make_resolv_conf() { ++ : >/etc/resolv.conf ++ if [ "$new_domain_name" ]; then ++ echo search $new_domain_name >>/etc/resolv.conf ++ fi ++ for nameserver in $new_domain_name_servers; do ++ echo nameserver $nameserver >>/etc/resolv.conf ++ done ++ return 0 ++ } ++ unmake_resolv_conf() { ++ return 0 ++ } ++fi + + # Invoke the local dhcp client enter hooks, if they exist. + if [ -f /etc/dhclient-enter-hooks ]; then +@@ -138,11 +159,12 @@ + ifconfig $interface:0 inet $alias_ip_address $alias_subnet_arg + route add -host $alias_ip_address $interface:0 + fi +- make_resolv_conf ++ make_resolv_conf || exit_with_hooks 1 + exit_with_hooks 0 + fi + + if [ x$reason = xEXPIRE ] || [ x$reason = xFAIL ]; then ++ unmake_resolv_conf + if [ x$alias_ip_address != x ]; then + # Turn off alias interface. + ifconfig $interface:0- inet 0 +@@ -158,6 +180,10 @@ + exit_with_hooks 0 + fi + ++if [ x$reason = xRELEASE ] || [ x$reason = xSTOP ]; then ++ unmake_resolv_conf ++fi ++ + if [ x$reason = xTIMEOUT ]; then + if [ x$alias_ip_address != x ]; then + ifconfig $interface:0- inet 0 +@@ -179,9 +205,10 @@ + for router in $new_routers; do + route add default gw $router + done +- make_resolv_conf ++ make_resolv_conf || exit_with_hooks 1 + exit_with_hooks 0 + fi ++ unmake_resolv_conf + ifconfig $interface inet down + exit_with_hooks 1 + fi --- dhcp-2.0pl5.orig/debian/patches/117_fix_CVE-2006-3122.patch +++ dhcp-2.0pl5/debian/patches/117_fix_CVE-2006-3122.patch @@ -0,0 +1,12 @@ +diff -ur dhcp-2.0pl5~/common/memory.c dhcp-2.0pl5/common/memory.c +--- dhcp-2.0pl5~/common/memory.c 1999-05-27 17:47:43.000000000 +0000 ++++ dhcp-2.0pl5/common/memory.c 2006-12-04 15:17:05.000000000 +0000 +@@ -528,7 +528,7 @@ + /* Copy the data files, but not the linkages. */ + comp -> starts = lease -> starts; + if (lease -> uid) { +- if (lease -> uid_len < sizeof (lease -> uid_buf)) { ++ if (lease -> uid_len <= sizeof (lease -> uid_buf)) { + memcpy (comp -> uid_buf, + lease -> uid, lease -> uid_len); + comp -> uid = &comp -> uid_buf [0]; --- dhcp-2.0pl5.orig/debian/patches/113_dhcp.patch +++ dhcp-2.0pl5/debian/patches/113_dhcp.patch @@ -0,0 +1,31 @@ +diff -uNr --exclude=debian --exclude=CVS dhcp-2.0pl5.orig/common/ethernet.c dhcp-2.0pl5/common/ethernet.c +--- dhcp-2.0pl5.orig/common/ethernet.c Thu Nov 11 11:10:41 1999 ++++ dhcp-2.0pl5/common/ethernet.c Mon Jan 15 12:05:11 2001 +@@ -105,6 +105,6 @@ + from -> htype = ARPHRD_ETHER; + from -> hlen = sizeof eh.ether_shost; + +- return sizeof eh; ++ return ETHER_HEADER_SIZE; + } + #endif /* PACKET_DECODING */ +diff -uNr --exclude=debian --exclude=CVS dhcp-2.0pl5.orig/server/dhcpd.conf dhcp-2.0pl5/server/dhcpd.conf +--- dhcp-2.0pl5.orig/server/dhcpd.conf Tue Feb 23 12:49:00 1999 ++++ dhcp-2.0pl5/server/dhcpd.conf Mon Sep 11 22:24:39 2000 +@@ -19,14 +19,14 @@ + + # The other subnet that shares this physical network + subnet 204.254.239.32 netmask 255.255.255.224 { +- range dynamic-bootp 204.254.239.10 204.254.239.20; ++ range dynamic-bootp 204.254.239.33 204.254.239.40; + option broadcast-address 204.254.239.31; + option routers snarg.fugue.com; + } + + subnet 192.5.5.0 netmask 255.255.255.224 { + range 192.5.5.26 192.5.5.30; +- option name-servers bb.home.vix.com, gw.home.vix.com; ++ option domain-name-servers bb.home.vix.com, gw.home.vix.com; + option domain-name "vix.com"; + option routers 192.5.5.1; + option subnet-mask 255.255.255.224; --- dhcp-2.0pl5.orig/debian/patches/400_missing_type_h.patch +++ dhcp-2.0pl5/debian/patches/400_missing_type_h.patch @@ -0,0 +1,10 @@ +--- dhcp-2.0pl5/common/tr.c.orig 2006-10-13 12:09:19.000000000 +0200 ++++ dhcp-2.0pl5/common/tr.c 2006-10-13 12:09:31.000000000 +0200 +@@ -12,6 +12,7 @@ + #include "includes/netinet/if_ether.h" + #include "netinet/if_tr.h" + #include ++#include + + /* + * token ring device handling subroutines. These are required as token-ring --- dhcp-2.0pl5.orig/debian/patches/303_manpage_typos.patch +++ dhcp-2.0pl5/debian/patches/303_manpage_typos.patch @@ -0,0 +1,192 @@ +diff -puriN dhcp-2.0pl5.orig/client/dhclient.8 dhcp-2.0pl5/client/dhclient.8 +--- dhcp-2.0pl5.orig/client/dhclient.8 2005-11-15 18:42:28.000000000 +0100 ++++ dhcp-2.0pl5/client/dhclient.8 2005-11-15 18:46:21.000000000 +0100 +@@ -113,7 +113,7 @@ than cycling through the list of old lea + The names of the network interfaces that dhclient should attempt to + configure may be specified on the command line. If no interface names + are specified on the command line dhclient will identify all network +-interfaces, elimininating non-broadcast interfaces if possible, and ++interfaces, eliminating non-broadcast interfaces if possible, and + attempt to configure each interface. + .PP + If dhclient should listen and transmit on a port other than the +@@ -142,7 +142,7 @@ flag should be specified. This is usefu + a debugger, or when running it out of inittab on System V systems. + .PP + .SH CONFIGURATION +-The syntax of the dhclient.conf(8) file is discussed seperately. ++The syntax of the dhclient.conf(8) file is discussed separately. + .SH FILES + .B ETCDIR/dhclient.conf, DBDIR/dhclient.leases, RUNDIR/dhclient.pid, + .B DBDIR/dhclient.leases~. +diff -puriN dhcp-2.0pl5.orig/client/dhclient.conf.5 dhcp-2.0pl5/client/dhclient.conf.5 +--- dhcp-2.0pl5.orig/client/dhclient.conf.5 2005-11-15 18:42:28.000000000 +0100 ++++ dhcp-2.0pl5/client/dhclient.conf.5 2005-11-15 18:43:06.000000000 +0100 +@@ -488,7 +488,7 @@ succeeds in getting a request to the ser + probably right (no guarantees). + .PP + The media setup is only used for the initial phase of address +-acquisition (the DHCPDISCOVER and DHCPOFFER packtes). Once an ++acquisition (the DHCPDISCOVER and DHCPOFFER packets). Once an + address has been acquired, the dhcp client will record it in its lease + database and will record the media type used to acquire the address. + Whenever the client tries to renew the lease, it will use that same +diff -puriN dhcp-2.0pl5.orig/client/dhclient.leases.5 dhcp-2.0pl5/client/dhclient.leases.5 +--- dhcp-2.0pl5.orig/client/dhclient.leases.5 1997-11-22 07:31:53.000000000 +0100 ++++ dhcp-2.0pl5/client/dhclient.leases.5 2005-11-15 18:43:22.000000000 +0100 +@@ -44,7 +44,7 @@ database of leases that it has acquired + database is a free-form ASCII file containing one valid declaration + per lease. If more than one declaration appears for a given lease, + the last one in the file is used. The file is written as a log, so +-this is not an unusual occurrance. ++this is not an unusual occurrence. + .PP + The format of the lease declarations is described in + .B dhclient.conf(5). +diff -puriN dhcp-2.0pl5.orig/client/dhclient-script.8 dhcp-2.0pl5/client/dhclient-script.8 +--- dhcp-2.0pl5.orig/client/dhclient-script.8 1999-05-06 23:53:39.000000000 +0200 ++++ dhcp-2.0pl5/client/dhclient-script.8 2005-11-15 18:44:30.000000000 +0100 +@@ -141,7 +141,7 @@ When a binding has been completed, a lot + likely to need to be set up. A new /etc/resolv.conf needs to be + created, using the values of $new_domain_name and + $new_domain_name_servers (which may list more than one server, +-seperated by spaces). A default route should be set using ++separated by spaces). A default route should be set using + $new_routers, and static routes may need to be set up using + $new_static_routes. + .PP +diff -puriN dhcp-2.0pl5.orig/common/dhcp-options.5 dhcp-2.0pl5/common/dhcp-options.5 +--- dhcp-2.0pl5.orig/common/dhcp-options.5 2005-11-15 18:42:29.000000000 +0100 ++++ dhcp-2.0pl5/common/dhcp-options.5 2005-11-15 18:45:26.000000000 +0100 +@@ -100,7 +100,7 @@ The + .B data-string + data type specifies either an NVT ASCII string + enclosed in double quotes, or a series of octets specified in +-hexadecimal, seperated by colons. For example: ++hexadecimal, separated by colons. For example: + .nf + .sp 1 + option dhcp-client-identifier "CLIENT-FOO"; +@@ -113,7 +113,7 @@ from the latest IETF draft document on D + are not listed by name may be defined by the name option-\fInnn\fR, + where \fInnn\fI is the decimal number of the option code. These + options may be followed either by a string, enclosed in quotes, or by +-a series of octets, expressed as two-digit hexadecimal numbers seperated ++a series of octets, expressed as two-digit hexadecimal numbers separated + by colons. For example: + .PP + .nf +diff -puriN dhcp-2.0pl5.orig/common/dhcp-options.cat5 dhcp-2.0pl5/common/dhcp-options.cat5 +--- dhcp-2.0pl5.orig/common/dhcp-options.cat5 2005-11-15 18:37:21.000000000 +0100 ++++ dhcp-2.0pl5/common/dhcp-options.cat5 2005-11-15 18:44:48.000000000 +0100 +@@ -44,7 +44,7 @@ RREEFFEERREENNCCEE:: OOPPTT + + The ddaattaa--ssttrriinngg data type specifies either an NVT ASCII string enclosed + in double quotes, or a series of octets specified in hexadecimal, +- seperated by colons. For example: ++ separated by colons. For example: + + option dhcp-client-identifier "CLIENT-FOO"; + or +diff -puriN dhcp-2.0pl5.orig/common/dhcp-options.man5 dhcp-2.0pl5/common/dhcp-options.man5 +--- dhcp-2.0pl5.orig/common/dhcp-options.man5 2005-11-15 18:37:21.000000000 +0100 ++++ dhcp-2.0pl5/common/dhcp-options.man5 2005-11-15 18:45:17.000000000 +0100 +@@ -100,7 +100,7 @@ The + .B data-string + data type specifies either an NVT ASCII string + enclosed in double quotes, or a series of octets specified in +-hexadecimal, seperated by colons. For example: ++hexadecimal, separated by colons. For example: + .nf + .sp 1 + option dhcp-client-identifier "CLIENT-FOO"; +@@ -113,7 +113,7 @@ from the latest IETF draft document on D + are not listed by name may be defined by the name option-\fInnn\fR, + where \fInnn\fI is the decimal number of the option code. These + options may be followed either by a string, enclosed in quotes, or by +-a series of octets, expressed as two-digit hexadecimal numbers seperated ++a series of octets, expressed as two-digit hexadecimal numbers separated + by colons. For example: + .PP + .nf +diff -puriN dhcp-2.0pl5.orig/relay/dhcrelay.8 dhcp-2.0pl5/relay/dhcrelay.8 +--- dhcp-2.0pl5.orig/relay/dhcrelay.8 1999-04-24 18:49:37.000000000 +0200 ++++ dhcp-2.0pl5/relay/dhcrelay.8 2005-11-15 18:46:27.000000000 +0100 +@@ -94,7 +94,7 @@ configure may be specified on the comman + .I -i + option. If no interface names + are specified on the command line dhcrelay will identify all network +-interfaces, elimininating non-broadcast interfaces if possible, and ++interfaces, eliminating non-broadcast interfaces if possible, and + attempt to configure each interface. + .PP + If dhcrelay should listen and transmit on a port other than the +diff -puriN dhcp-2.0pl5.orig/relay/dhcrelay.man8 dhcp-2.0pl5/relay/dhcrelay.man8 +--- dhcp-2.0pl5.orig/relay/dhcrelay.man8 2005-11-15 16:04:12.000000000 +0100 ++++ dhcp-2.0pl5/relay/dhcrelay.man8 2005-11-15 18:46:41.000000000 +0100 +@@ -94,7 +94,7 @@ configure may be specified on the comman + .I -i + option. If no interface names + are specified on the command line dhcrelay will identify all network +-interfaces, elimininating non-broadcast interfaces if possible, and ++interfaces, eliminating non-broadcast interfaces if possible, and + attempt to configure each interface. + .PP + If dhcrelay should listen and transmit on a port other than the +diff -puriN dhcp-2.0pl5.orig/RELNOTES dhcp-2.0pl5/RELNOTES +--- dhcp-2.0pl5.orig/RELNOTES 2000-09-06 23:33:01.000000000 +0200 ++++ dhcp-2.0pl5/RELNOTES 2005-11-15 18:45:41.000000000 +0100 +@@ -669,7 +669,7 @@ since June of 1997. + + - 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 ++ a separate man page which is referred to by the dhclient.conf and + dhcpd.conf man pages. + + - Updated README to answer some frequently asked questions. +diff -puriN dhcp-2.0pl5.orig/server/dhcpd.8 dhcp-2.0pl5/server/dhcpd.8 +--- dhcp-2.0pl5.orig/server/dhcpd.8 2000-09-06 23:04:00.000000000 +0200 ++++ dhcp-2.0pl5/server/dhcpd.8 2005-11-15 18:46:28.000000000 +0100 +@@ -150,7 +150,7 @@ broadcasts may be specified on the comma + on systems where dhcpd is unable to identify non-broadcast interfaces, + but should not be required on other systems. If no interface names + are specified on the command line dhcpd will identify all network +-interfaces which are up, elimininating non-broadcast interfaces if ++interfaces which are up, eliminating non-broadcast interfaces if + possible, and listen for DHCP broadcasts on each interface. + .PP + If dhcpd should listen on a port other than the standard (port 67), +@@ -200,7 +200,7 @@ startup. To avoid printing this messag + .B -q + flag may be specified. + .SH CONFIGURATION +-The syntax of the dhcpd.conf(5) file is discussed seperately. This ++The syntax of the dhcpd.conf(5) file is discussed separately. This + section should be used as an overview of the configuration process, + and the dhcpd.conf(5) documentation should be consulted for detailed + reference information. +diff -puriN dhcp-2.0pl5.orig/server/dhcpd.conf.5 dhcp-2.0pl5/server/dhcpd.conf.5 +--- dhcp-2.0pl5.orig/server/dhcpd.conf.5 2005-11-15 18:42:29.000000000 +0100 ++++ dhcp-2.0pl5/server/dhcpd.conf.5 2005-11-15 18:45:06.000000000 +0100 +@@ -515,7 +515,7 @@ hardware type (and others) would also be + The + .I hardware-address + should be a set of hexadecimal octets (numbers from 0 through ff) +-seperated by colons. The \fIhardware\fR statement may also be used ++separated by colons. The \fIhardware\fR statement may also be used + for DHCP clients. + .PP + .B The +diff -puriN dhcp-2.0pl5.orig/server/dhcpd.leases.5 dhcp-2.0pl5/server/dhcpd.leases.5 +--- dhcp-2.0pl5.orig/server/dhcpd.leases.5 1998-06-26 00:59:54.000000000 +0200 ++++ dhcp-2.0pl5/server/dhcpd.leases.5 2005-11-15 18:45:35.000000000 +0100 +@@ -118,7 +118,7 @@ lease is recorded with the \fBhardware\f + \fBhardware \fIhardware-type mac-address\fB;\fR + .PP + The MAC address is specified as a series of hexadecimal octets, +-seperated by colons. ++separated by colons. + .PP + If the client used a client identifier to acquire its address, the + client identifier is recorded using the \fBuid\fR statement: --- dhcp-2.0pl5.orig/debian/patches/111_token-ring.patch +++ dhcp-2.0pl5/debian/patches/111_token-ring.patch @@ -0,0 +1,44 @@ +diff -uNr --exclude=debian --exclude=CVS dhcp-2.0pl5.orig/common/dispatch.c dhcp-2.0pl5/common/dispatch.c +--- dhcp-2.0pl5.orig/common/dispatch.c Tue Jul 13 08:51:55 1999 ++++ dhcp-2.0pl5/common/dispatch.c Tue Jan 22 10:43:07 2002 +@@ -379,6 +379,15 @@ + memcpy (tmp -> hw_address.haddr, sa.sa_data, 6); + break; + ++#ifndef HAVE_ARPHRD_IEEE802_TR ++# define ARPHRD_IEEE802_TR HTYPE_IEEE802_TR ++#endif ++ case ARPHRD_IEEE802_TR: ++ tmp -> hw_address.hlen = 6; ++ tmp -> hw_address.htype = ARPHRD_IEEE802; ++ memcpy (tmp -> hw_address.haddr, sa.sa_data, 6); ++ break; ++ + #ifndef HAVE_ARPHRD_FDDI + # define ARPHRD_FDDI HTYPE_FDDI + #endif +diff -uNr --exclude=debian --exclude=CVS dhcp-2.0pl5.orig/includes/cf/linux.h dhcp-2.0pl5/includes/cf/linux.h +--- dhcp-2.0pl5.orig/includes/cf/linux.h Thu May 27 13:44:53 1999 ++++ dhcp-2.0pl5/includes/cf/linux.h Tue Jan 22 10:43:07 2002 +@@ -123,6 +123,7 @@ + # endif + # define HAVE_ARPHRD_METRICOM + # define HAVE_ARPHRD_IEEE802 ++# define HAVE_ARPHRD_IEEE802_TR + # define HAVE_ARPHRD_LOOPBACK + # define HAVE_SO_BINDTODEVICE + # define HAVE_SIOCGIFHWADDR +diff -uNr --exclude=debian --exclude=CVS dhcp-2.0pl5.orig/includes/osdep.h dhcp-2.0pl5/includes/osdep.h +--- dhcp-2.0pl5.orig/includes/osdep.h Mon Oct 25 11:40:32 1999 ++++ dhcp-2.0pl5/includes/osdep.h Tue Jan 22 10:43:07 2002 +@@ -265,6 +265,10 @@ + # define HAVE_ARPHRD_IEEE802 + #endif + ++#if defined (ARPHRD_IEEE802_TR) && !defined (HAVE_ARPHRD_IEEE802_TR) ++# define HAVE_ARPHRD_IEEE802_TR ++#endif ++ + #if defined (ARPHRD_FDDI) && !defined (HAVE_ARPHRD_FDDI) + # define HAVE_ARPHRD_FDDI + #endif --- dhcp-2.0pl5.orig/debian/patches/300_documentation.patch +++ dhcp-2.0pl5/debian/patches/300_documentation.patch @@ -0,0 +1,79 @@ +diff -uNr --exclude=debian --exclude=CVS dhcp-2.0pl5.orig/client/dhclient.8 dhcp-2.0pl5/client/dhclient.8 +--- dhcp-2.0pl5.orig/client/dhclient.8 Fri Mar 5 11:04:52 1999 ++++ dhcp-2.0pl5/client/dhclient.8 Sun Dec 2 23:36:24 2001 +@@ -45,6 +45,9 @@ + .I port + ] + [ ++.B -e ++] ++[ + .B -d + ] + [ +@@ -141,6 +144,12 @@ + flag should be specified. This is useful when running dhclient under + a debugger, or when running it out of inittab on System V systems. + .PP ++The ++.B -e ++flag will cause dhclient to exit with an error if the interface cannot ++be configured after a certain amount of time. This is useful when dhclient ++is used in scripts or other systems when a failed dhcp attempt needs to be ++reported. + .SH CONFIGURATION + The syntax of the dhclient.conf(8) file is discussed seperately. + .SH FILES +diff -uNr --exclude=debian --exclude=CVS dhcp-2.0pl5.orig/client/dhclient.conf.5 dhcp-2.0pl5/client/dhclient.conf.5 +--- dhcp-2.0pl5.orig/client/dhclient.conf.5 Fri Mar 26 11:38:50 1999 ++++ dhcp-2.0pl5/client/dhclient.conf.5 Sat Dec 15 21:14:18 2001 +@@ -380,7 +380,9 @@ + no lease is acquired, the script is used to test predefined leases, if + any, and also called once if no valid lease can be identified. For + more information, see +-.B dhclient-lease(8). ++.B dhclient.leases(5) ++and ++.B dhclient-script(8). + .PP + \fBmedium "\fImedia setup\fB";\fR + .PP +@@ -432,8 +434,8 @@ + should generally be four digits except for really long leases. The + month is specified as a number starting with 1 for January. The day + of the month is likewise specified starting with 1. The hour is a +-number between 0 and 23, the minute a number between 0 and 69, and the +-second also a number between 0 and 69. ++number between 0 and 23, the minute a number between 0 and 59, and the ++second also a number between 0 and 59. + .SH ALIAS DECLARATIONS + \fBalias { \fI declarations ... \fB}\fR + .PP +diff -uNr --exclude=debian --exclude=CVS dhcp-2.0pl5.orig/common/dhcp-options.5 dhcp-2.0pl5/common/dhcp-options.5 +--- dhcp-2.0pl5.orig/common/dhcp-options.5 Sat Apr 24 12:46:43 1999 ++++ dhcp-2.0pl5/common/dhcp-options.5 Tue Jan 29 22:26:17 2002 +@@ -489,7 +489,7 @@ + ]\fB;\fR + .RS 0.25i + .PP +-This option specifies a list of IP addresses indicating NTP (RFC 1035) ++This option specifies a list of IP addresses indicating NTP (RFC 1305) + servers available to the client. Servers should be listed in order + of preference. + .RE +diff -uNr --exclude=debian --exclude=CVS dhcp-2.0pl5.orig/server/dhcpd.conf.5 dhcp-2.0pl5/server/dhcpd.conf.5 +--- dhcp-2.0pl5.orig/server/dhcpd.conf.5 Wed Sep 6 17:27:47 2000 ++++ dhcp-2.0pl5/server/dhcpd.conf.5 Tue Jan 29 22:17:56 2002 +@@ -770,9 +770,10 @@ + .B dhcp-options(5) + manual page. + .SH SEE ALSO +-dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131. ++dhcpd(8), dhcpd.leases(5), RFC2132, RFC2131. + .SH AUTHOR +-.B dhcpd(8) ++.B dhcpd(8), ++which uses the configuration file described in this man page, + was written by Ted Lemon + under a contract with Vixie Labs. Funding + for this project was provided by the Internet Software Corporation. --- dhcp-2.0pl5.orig/debian/patches/101_dhclient_wait.patch +++ dhcp-2.0pl5/debian/patches/101_dhclient_wait.patch @@ -0,0 +1,16 @@ +--- dhcp-2.0pl5.orig/client/dhclient.c ++++ dhcp-2.0pl5/client/dhclient.c +@@ -2125,7 +2125,12 @@ + ip -> client -> envc = 0; + dfree (envp, "script_go"); + } +- return wstatus & 0xff; ++ ++ if (WIFEXITED(wstatus)) ++ return WEXITSTATUS(wstatus); ++ ++ /* Anything else is considered failure */ ++ return 1; + } + + void client_envadd (struct client_state *client, --- dhcp-2.0pl5.orig/debian/patches/115_format_string.patch +++ dhcp-2.0pl5/debian/patches/115_format_string.patch @@ -0,0 +1,49 @@ +--- dhcp-2.0pl5.orig/common/errwarn.c ++++ dhcp-2.0pl5/common/errwarn.c +@@ -71,7 +71,7 @@ + va_end (list); + + #ifndef DEBUG +- syslog (log_priority | LOG_ERR, mbuf); ++ syslog (log_priority | LOG_ERR, "%s", mbuf); + #endif + + /* Also log it to stderr? */ +@@ -104,7 +104,7 @@ + va_end (list); + + #ifndef DEBUG +- syslog (log_priority | LOG_ERR, mbuf); ++ syslog (log_priority | LOG_ERR, "%s", mbuf); + #endif + + if (log_perror) { +@@ -130,7 +130,7 @@ + va_end (list); + + #ifndef DEBUG +- syslog (log_priority | LOG_INFO, mbuf); ++ syslog (log_priority | LOG_INFO, "%s", mbuf); + #endif + + if (log_perror) { +@@ -156,7 +156,7 @@ + va_end (list); + + #ifndef DEBUG +- syslog (log_priority | LOG_DEBUG, mbuf); ++ syslog (log_priority | LOG_DEBUG, "%s", mbuf); + #endif + + if (log_perror) { +@@ -231,8 +231,8 @@ + va_end (list); + + #ifndef DEBUG +- syslog (log_priority | LOG_ERR, mbuf); +- syslog (log_priority | LOG_ERR, token_line); ++ syslog (log_priority | LOG_ERR, "%s", mbuf); ++ syslog (log_priority | LOG_ERR, "%s", token_line); + if (lexline < 81) + syslog (log_priority | LOG_ERR, + "%s^", &spaces [sizeof spaces - lexchar]); --- dhcp-2.0pl5.orig/debian/patches/302_README.patch +++ dhcp-2.0pl5/debian/patches/302_README.patch @@ -0,0 +1,752 @@ +--- dhcp-2.0pl5/README.orig Sun Feb 10 21:23:37 2002 ++++ dhcp-2.0pl5/README Sun Feb 10 21:58:29 2002 +@@ -1,81 +1,74 @@ +-

Internet Software Consortium

 +-

Dynamic Host Configuration Protocol Distribution

 +-

Version 2 Patchlevel 5

 +-

September 6, 2000

 +- +-

README FILE

 +- +-

You should read this file carefully before trying to install or use +-the ISC DHCP Distribution.

+- +-
    +-TABLE OF CONTENTS +-
    +-
    WHERE TO FIND DOCUMENTATION +-
    RELEASE STATUS +-
    BUILDING THE DHCP DISTRIBUTION +-
    INSTALLING THE DHCP DISTRIBUTION +-
    USING THE DHCP DISTRIBUTION +-
    +-
    LINUX +-
    +-
    SO_ATTACH_FILTER UNDECLARED +-
    PROTOCOL NOT CONFIGURED +-
    BROADCAST +-
    FIREWALL RULES +-
    IP BOOTP AGENT +-
    MULTIPLE INTERFACES +-
    +-
    SCO +-
    HP-UX +-
    ULTRIX +-
    FreeBSD +-
    NeXTSTEP +-
    SOLARIS +-
    +-
    SUPPORT +-
    +-
    HOW TO REPORT BUGS +-
    +-
    KNOWN BUGS ++Internet Software Consortium ++Dynamic Host Configuration Protocol Distribution ++Version 2 Patchlevel 5 ++September 6, 2000 ++ ++README FILE ++ ++You should read this file carefully before trying to install or use ++the ISC DHCP Distribution. ++ ++TABLE OF CONTENTS ++ ++ 1 WHERE TO FIND DOCUMENTATION ++ 2 RELEASE STATUS ++ 3 BUILDING THE DHCP DISTRIBUTION ++ 4 INSTALLING THE DHCP DISTRIBUTION ++ 5 USING THE DHCP DISTRIBUTION ++ 5.1 LINUX ++ 5.1.1 SO_ATTACH_FILTER UNDECLARED ++ 5.1.2 PROTOCOL NOT CONFIGURED ++ 5.1.3 BROADCAST ++ 5.1.4 FIREWALL RULES ++ 5.1.5 IP BOOTP AGENT ++ 5.1.6 MULTIPLE INTERFACES ++ 5.2 SCO ++ 5.3 HP-UX ++ 5.4 ULTRIX ++ 5.5 FreeBSD ++ 5.6 NeXTSTEP ++ 5.7 SOLARIS ++ 6 SUPPORT ++ 6.1 HOW TO REPORT BUGS ++ 7 KNOWN BUGS + +-

    Where to find documentation

    ++1. WHERE TO FIND DOCUMENTATION + +-

    Documentation for this software includes this README file, the ++Documentation for this software includes this README file, the + RELNOTES file, and the manual pages, which are in the server, common, + client and relay subdirectories. Internet standards relating to the + DHCP protocol are stored in the doc subdirectory. You will have the + best luck reading the manual pages if you build this software and then + install it, although you can read them directly out of the +-distribution if you need to.

    ++distribution if you need to. + +-

    DHCP server documentation is in the dhcpd man page. Information about ++DHCP server documentation is in the dhcpd man page. Information about + the DHCP server lease database is in the dhcpd.leases man page. + Server configuration documentation is in the dhcpd.conf man page as + well as the dhcp-options man page. A sample DHCP server + configuration is in the file server/dhcpd.conf. The source for the + dhcpd, dhcpd.leases and dhcpd.conf man pages is in the server/ sub- + directory in the distribution. The source for the dhcp-options.5 +-man page is in the common/ subdirectory.

    ++man page is in the common/ subdirectory. + +-

    DHCP Client documentation is in the dhclient man page. DHCP client ++DHCP Client documentation is in the dhclient man page. DHCP client + configuration documentation is in the dhclient.conf man page and the + dhcp-options man page. The DHCP client configuration script is + documented in the dhclient-script man page. The format of the DHCP + client lease database is documented in the dhclient.leases man page. + The source for all these man pages is in the client/ subdirectory in + the distribution. In addition, the dhcp-options man page should be +-referred to for information about DHCP options.

    ++referred to for information about DHCP options. + +-

    DHCP relay agent documentation is in the dhcrelay man page, the source +-for which is distributed in the relay/ subdirectory.

    ++DHCP relay agent documentation is in the dhcrelay man page, the source ++for which is distributed in the relay/ subdirectory. + +-

    To read installed manual pages, use the man command. Type "man page" ++To read installed manual pages, use the man command. Type "man page" + where page is the name of the manual page. This will only work if + you have installed the ISC DHCP distribution using the ``make install'' +-command (described later).

    ++command (described later). + +-

    If you want to read manual pages that aren't installed, you can type ++If you want to read manual pages that aren't installed, you can type + ``nroff -man page |more'' where page is the filename of the + unformatted manual page. The filename of an unformatted manual page + is the name of the manual page, followed by '.', followed by some +@@ -83,78 +76,74 @@ + about programs. For example, to read the dhcp-options man page, + you would type ``nroff -man common/dhcp-options.5 |more'', assuming + your current working directory is the top level directory of the ISC +-DHCP Distribution.

    ++DHCP Distribution. + +-

    If you do not have the nroff command, you can type ``more catpage'' ++If you do not have the nroff command, you can type ``more catpage'' + where catpage is the filename of the catted man page. Catted man + pages names are the name of the manual page followed by ".cat" +-followed by 5 or 8, as with unformatted manual pages.

    ++followed by 5 or 8, as with unformatted manual pages. + +-

    Please note that until you install the manual pages, the pathnames of ++Please note that until you install the manual pages, the pathnames of + files to which they refer will not be correct for your operating +-system.

    ++system. + +-

    Release status

    ++2. RELEASE STATUS + +-

    This is the final release of Version 2 of the Internet Software ++This is the final release of Version 2 of the Internet Software + Consortium DHCP Distribution. In version 2.0, this distribution + includes a DHCP server, a DHCP client, and a BOOTP/DHCP relay agent. +-This release is stable.

    ++This release is stable. + +-

    In this release, the server and relay agent currently work well on ++In this release, the server and relay agent currently work well on + NetBSD, Linux after kernel version 2.0.30, FreeBSD, BSD/OS, Ultrix, + Digital Alpha OSF/1, Solaris and SunOS 4.1.4. On AIX, HPUX, IRIX and + Linux 2.0.30, only a single broadcast network interface is supported. + They also runs on QNX as long as only one broadcast network interface + is configured and a host route is added from that interface to the +-255.255.255.255 broadcast address.

    ++255.255.255.255 broadcast address. + +-

    The DHCP client currently only knows how to configure the network on ++The DHCP client currently only knows how to configure the network on + NetBSD, FreeBSD, BSD/os, Linux, Solaris and NextStep. The client + depends on a system-dependent shell script to do network + configuration - support for other operating systems is simply a matter +-of porting this shell script to the new platform.

    ++of porting this shell script to the new platform. + +-

    If you wish to run the DHCP Distribution on Linux, please see the ++If you wish to run the DHCP Distribution on Linux, please see the + Linux-specific notes later in this document. If you wish to run on an + SCO release, please see the SCO-specific notes later in this document. + You particularly need to read these notes if you intend to support + Windows 95 clients. If you are running a version of FreeBSD prior to + 2.2, please read the note on FreeBSD. If you are running HP-UX or + Ultrix, please read the notes for those operating systems below. +-If you are running NeXTSTEP, please see the notes on NeXTSTEP below.

    ++If you are running NeXTSTEP, please see the notes on NeXTSTEP below. + +-

    If you start dhcpd and get a message, "no free bpf", that means you ++If you start dhcpd and get a message, "no free bpf", that means you + need to configure the Berkeley Packet Filter into your operating + system kernel. On NetBSD, FreeBSD and BSD/os, type ``man bpf'' for +-information. On Digital Unix, type ``man pfilt''.

    ++information. On Digital Unix, type ``man pfilt''. + +-

    Building the DHCP Distribution

    ++3. BUILDING THE DHCP DISTRIBUTION + +-

    To build the DHCP Distribution, unpack the compressed tar file using +-the tar utility and the gzip command - type something like:

    ++To build the DHCP Distribution, unpack the compressed tar file using ++the tar utility and the gzip command - type something like: + +-
    + zcat dhcp-2.0pl5.tar.gz |tar xvf - +-
    + +-

    On BSD/OS, you have to type gzcat, not zcat, and you may run into +-similar problems on other operating systems.

    ++On BSD/OS, you have to type gzcat, not zcat, and you may run into ++similar problems on other operating systems. + +-

    Now, cd to the dhcp-2.0pl5 subdirectory that you've just created and +-configure the source tree by typing:

    ++Now, cd to the dhcp-2.0pl5 subdirectory that you've just created and ++configure the source tree by typing: + +-
    + ./configure +-
    + +-

    If the configure utility can figure out what sort of system you're ++If the configure utility can figure out what sort of system you're + running on, it will create a custom Makefile for you for that + system; otherwise, it will complain. If it can't figure out what + system you are using, that system is not supported - you are on +-your own.

    ++your own. + +-

    Once you've run configure, just type ``make'', and after a while ++Once you've run configure, just type ``make'', and after a while + you should have a dhcp server. If you get compile errors on one + of the supported systems mentioned earlier, please let us know. + If you get warnings, it's not likely to be a problem - the DHCP +@@ -162,56 +151,52 @@ + as we can manage, but there are a few for which this is difficult. + If you get errors on a system not mentioned above, you will need + to do some programming or debugging on your own to get the DHCP +-Distribution working.

    ++Distribution working. + +-

    Installing the dhcp distribution

    ++4. INSTALLING THE DHCP DISTRIBUTION + +-

    Once you have successfully gotten the DHCP Distribution to build, you ++Once you have successfully gotten the DHCP Distribution to build, you + can install it by typing ``make install''. If you already have an old + version of the DHCP Distribution installed, you may want to save it +-before typing ``make install''.

    ++before typing ``make install''. + +-

    Using the dhcp distribution

    ++5. USING THE DHCP DISTRIBUTION + +-

    Linux

    ++5.1 LINUX + +-

    There are three big LINUX issues: the all-ones broadcast address, ++There are three big LINUX issues: the all-ones broadcast address, + Linux 2.1 ip_bootp_agent enabling, and operations with more than one + network interface. There are also two potential compilation/runtime + problems for Linux 2.1/2.2: the "SO_ATTACH_FILTER undeclared" problem +-and the "protocol not configured" problem.

    ++and the "protocol not configured" problem. + +-

    So_attach_filter undeclared

    ++5.1.1 SO_ATTACH_FILTER UNDECLARED + +-

    In addition, there is a minor issue that we will mention here because ++In addition, there is a minor issue that we will mention here because + this release is so close on the heels of the Linux 2.2 release: there + is a symlink in /usr/include that points at the linux asm headers. It + appears to be not uncommon that this link won't be updated correctly, +-in which case you'll get the following error when you try to build:

    ++in which case you'll get the following error when you try to build: + +-
    + lpf.c: In function `if_register_receive': + lpf.c:152: `SO_ATTACH_FILTER' undeclared (first use this function) + lpf.c:152: (Each undeclared identifier is reported only once + lpf.c:152: for each function it appears in.) +-
    + +-

    The line numbers may be different, of course. If you see this ++The line numbers may be different, of course. If you see this + header, your linux asm header link is probably bad, and you should +-make sure it's pointing to correct linux source directory.

    ++make sure it's pointing to correct linux source directory. + +-

    Protocol not configured

    ++5.1.2 PROTOCOL NOT CONFIGURED + +-

    One additional Linux 2.1/2.2 issue: if you get the following message, ++One additional Linux 2.1/2.2 issue: if you get the following message, + it's because your kernel doesn't have the linux packetfilter or raw +-packet socket configured:

    ++packet socket configured: + +-
    + Make sure CONFIG_PACKET (Packet socket) and CONFIG_FILTER (Socket + Filtering) are enabled in your kernel configuration +-
    + +-

    If this happens, you need to configure your Linux kernel to support ++If this happens, you need to configure your Linux kernel to support + Socket Filtering and the Packet socket. You can do this by typing + ``make config'', ``make menuconfig'' or ``make xconfig'', and then + enabling the Packet socket and Socket Filtering options that you'll +@@ -222,21 +207,21 @@ + kernel header files. After you've reconfigured, you need to type + ``make'' to build a new Linux kernel, and then install it in the + appropriate place (probably /linux). Make sure to save a copy of your +-old /linux.

    ++old /linux. + +-

    If the preceding paragraph made no sense to you, ask your Linux +-vendor/guru for help - please don't ask us.

    ++If the preceding paragraph made no sense to you, ask your Linux ++vendor/guru for help - please don't ask us. + +-

    If you set CONFIG_PACKET=m or CONFIG_FILTER=m, then you must tell the ++If you set CONFIG_PACKET=m or CONFIG_FILTER=m, then you must tell the + kernel module loader to load the appropriate modules. If this doesn't + make sense to you, don't use CONFIG_whatever=m - use CONFIG_whatever=y. + Don't ask for help with this on the DHCP mailing list - it's a Linux + kernel issue. This is probably not a problem with the most recent +-Linux 2.2.x kernels.

    ++Linux 2.2.x kernels. + +-

    Broadcast

    ++5.1.3 BROADCAST + +-

    In order for dhcpd to work correctly with picky DHCP clients (e.g., ++In order for dhcpd to work correctly with picky DHCP clients (e.g., + Windows 95), it must be able to send packets with an IP destination + address of 255.255.255.255. Unfortunately, Linux changes an IP + destination of 255.255.255.255 into the local subnet broadcast address +@@ -245,43 +230,35 @@ + old versions of Linux 2.1 and all versions of Linux prior to 2.1, it + is a problem - pickier DHCP clients connected to the same network as + the ISC DHCP server or ISC relay agent will not see messages from the +-DHCP server.

    ++DHCP server. + +-

    It is possible to work around this problem on some versions of Linux ++It is possible to work around this problem on some versions of Linux + by creating a host route from your network interface address to + 255.255.255.255. The command you need to use to do this on Linux +-varies from version to version. The easiest version is:

    ++varies from version to version. The easiest version is: + +-
    + route add -host 255.255.255.255 dev eth0 +-
    + +-

    On some older Linux systems, you will get an error if you try to do ++On some older Linux systems, you will get an error if you try to do + this. On those systems, try adding the following entry to your +-/etc/hosts file:

    ++/etc/hosts file: + +-
    + 255.255.255.255 all-ones +-
    + +-

    Then, try:

    ++Then, try: + +-
    + route add -host all-ones dev eth0 +-
    + +-

    Another route that has worked for some users is:

    ++Another route that has worked for some users is: + +-
    + route add -net 255.255.255.0 dev eth0 +-
    + +-

    If you are not using eth0 as your network interface, you should +-specify the network interface you *are* using in your route command.

    ++If you are not using eth0 as your network interface, you should ++specify the network interface you *are* using in your route command. + +-

    Firewall rules

    ++5.1.4 FIREWALL RULES + +-

    If you are running the DHCP server or client on a Linux system that's ++If you are running the DHCP server or client on a Linux system that's + also acting as a firewall, you must be sure to allow DHCP packets + through the firewall - Linux firewalls make filtering decisions before + they make the forwarding decision, so they will filter packets that +@@ -292,20 +269,18 @@ + your local firewall's IP address and UDP port 67 through to any + address your DHCP server might serve on UDP port 68. Finally, + packets from relay agents on port 67 to the DHCP server on port 67, +-and vice versa, must be permitted.

    ++and vice versa, must be permitted. + +-

    IP BOOTP agent

    ++5.1.5 IP BOOTP AGENT + +-

    Some versions of the Linux 2.1 kernel apparently prevent dhcpd from +-working unless you enable it by doing the following:

    ++Some versions of the Linux 2.1 kernel apparently prevent dhcpd from ++working unless you enable it by doing the following: + +-
    + echo 1 >/proc/sys/net/ipv4/ip_bootp_agent +-
    + +-

    Multiple interfaces

    ++5.1.6 MULTIPLE INTERFACES + +-

    Very old versions of the Linux kernel do not provide a networking API ++Very old versions of the Linux kernel do not provide a networking API + that allows dhcpd to operate correctly if the system has more than one + broadcast network interface. However, Linux 2.0 kernels with version + numbers greater than or equal to 2.0.31 add an API feature: the +@@ -313,89 +288,85 @@ + possible for dhcpd to operate on Linux with more than one network + interface. In order to take advantage of this, you must be running a + 2.0.31 or greater kernel, and you must have 2.0.31 or later system +-headers installed *before* you build the DHCP Distribution.

    ++headers installed *before* you build the DHCP Distribution. + +-

    We have heard reports that you must still add routes to 255.255.255.255 ++We have heard reports that you must still add routes to 255.255.255.255 + in order for the all-ones broadcast to work, even on 2.0.31 kernels. + In fact, you now need to add a route for each interface. Hopefully +-the Linux kernel gurus will get this straight eventually.

    ++the Linux kernel gurus will get this straight eventually. + +-

    Linux 2.1 and later kernels do not use SO_BINDTODEVICE or require the ++Linux 2.1 and later kernels do not use SO_BINDTODEVICE or require the + broadcast address hack, but do support multiple interfaces, using the +-Linux Packet Filter.

    ++Linux Packet Filter. + +-

    SCO

    ++5.2 SCO + +-

    SCO has the same problem as Linux (described earlier). The thing is, ++SCO has the same problem as Linux (described earlier). The thing is, + SCO *really* doesn't want to let you add a host route to the all-ones + broadcast address. One technique that has been successful on some +-versions of SCO is the very bizarre command:

    ++versions of SCO is the very bizarre command: + +-
    + ifconfig net0 alias 10.1.1.1 netmask 8.0.0.0 +-
    + +-

    Apparently this works because of an interaction between SCO's support ++Apparently this works because of an interaction between SCO's support + for network classes and the weird netmask. The 10.* network is just a + dummy that can generally be assumed to be safe. Don't ask why this + works. Just try it. If it works for you, great. If not, SCO is + supposedly adding hooks to support real DHCP service in a future + release - I have this on good authority from the people at SCO who do +-*their* DHCP server and client.

    ++*their* DHCP server and client. + +-

    HP-UX

    ++5.3 HP-UX + +-

    HP-UX has the same problem with the all-ones broadcast address that ++HP-UX has the same problem with the all-ones broadcast address that + SCO and Linux have. One user reported that adding the following to + /etc/rc.config.d/netconf helped (you may have to modify this to suit +-your local configuration):

    ++your local configuration): + +-
    + INTERFACE_NAME[0]=lan0 + IP_ADDRESS[0]=1.1.1.1 + SUBNET_MASK[0]=255.255.255.0 + BROADCAST_ADDRESS[0]="255.255.255.255" + LANCONFIG_ARGS[0]="ether" + DHCP_ENABLE[0]=0 +-
    + +-

    Ultrix

    ++5.4 ULTRIX + +-

    Now that we have Ultrix packet filter support, the DHCP Distribution ++Now that we have Ultrix packet filter support, the DHCP Distribution + on Ultrix should be pretty trouble-free. However, one thing you do + need to be aware of is that it now requires that the pfilt device be + configured into your kernel and present in /dev. If you type ``man + packetfilter'', you will get some information on how to configure your + kernel for the packet filter (if it isn't already) and how to make an +-entry for it in /dev.

    ++entry for it in /dev. + +-

    FreeBSD

    ++5.5 FreeBSD + +-

    Versions of FreeBSD prior to 2.2 have a bug in BPF support in that the ++Versions of FreeBSD prior to 2.2 have a bug in BPF support in that the + ethernet driver swaps the ethertype field in the ethernet header + downstream from BPF, which corrupts the output packet. If you are + running a version of FreeBSD prior to 2.2, and you find that dhcpd + can't communicate with its clients, you should #define BROKEN_FREEBSD_BPF +-in site.h and recompile.

    ++in site.h and recompile. + +-

    NeXTStep

    ++5.6 NeXTStep + +-

    The NeXTSTEP support uses the NeXTSTEP Berkeley Packet Filter ++The NeXTSTEP support uses the NeXTSTEP Berkeley Packet Filter + extension, which is not included in the base NextStep system. You +-must install this extension in order to get dhcpd or dhclient to work.

    ++must install this extension in order to get dhcpd or dhclient to work. + +-

    Solaris

    ++5.7 SOLARIS + +-

    One problem which has been observed and is not fixed in this ++One problem which has been observed and is not fixed in this + patchlevel has to do with using DLPI on Solaris machines. The symptom + of this problem is that the DHCP server never receives any requests. + If you are using Solaris 2.6, and you encounter this symptom, and + you are running the DHCP server on a machine with a single broadcast + network interface, you may wish to edit the includes/site.h file and + uncomment the #define USE_SOCKETS line. Then type ``make clean; +-make''.

    ++make''. + +-

    The DHCP client on Solaris will only work with DLPI. If you run it ++The DHCP client on Solaris will only work with DLPI. If you run it + and it just keeps saying it's sending DHCPREQUEST packets, but never + gets a response, you may be having DLPI trouble as described above. + If so, you are SOL. Also, because Solaris requires you to "plumb" an +@@ -404,9 +375,9 @@ + on the command line, or must plumb the interfaces prior to invoking + the DHCP client. This can be done with ``ifconfig iface plumb'', + where iface is the name of the interface (e.g., ``ifconfig hme0 +-plumb'').

    ++plumb''). + +-

    It should be noted that Solaris versions from 2.6 onward include a ++It should be noted that Solaris versions from 2.6 onward include a + DHCP client that you can run with ``/sbin/ifconfig iface dhcp start'' + rather than using the ISC DHCP client. The feature set of the Solaris + client is different (not necessarily better or worse) than that of the +@@ -415,22 +386,22 @@ + on Internet Software Consortium mailing lists - that's why you're + paying Sun the big bucks. If you're having a problem with the + Solaris client interoperating with the ISC dhcp server, that's another +-matter, but please check with Sun first.

    ++matter, but please check with Sun first. + +-

    Support

    ++6. SUPPORT + +-

    The Internet Software Consortium DHCP server is not a commercial ++The Internet Software Consortium DHCP server is not a commercial + product, and is not supported in that sense. However, it has + attracted a fairly sizable following on the Internet, which means that + there are a lot of knowledgable users who may be able to help you if + you get stuck. These people generally read the dhcp-server@fugue.com +-mailing list.

    ++mailing list. + +-

    If you are going to use dhcpd, you should probably subscribe to the ++If you are going to use dhcpd, you should probably subscribe to the + dhcp-server and dhcp-announce mailing lists. If you will be using +-dhclient, you should subscribe to the dhcp-client mailing list.

    ++dhclient, you should subscribe to the dhcp-client mailing list. + +-

    If you need help, you should ask on the dhcp-server or dhcp-client ++If you need help, you should ask on the dhcp-server or dhcp-client + mailing list (or both) - whichever is appropriate to your + application. This includes reporting bugs. Please do not report + bugs in old software releases - fetch the latest release and see if +@@ -438,98 +409,92 @@ + report it. It's okay to report bugs in the latest patchlevel of a + major version that's not the most recent major version, though - for + example, if you're running 2.0, you don't have to upgrade to 3.0 +-before you can report bugs.

    ++before you can report bugs. + +-

    Please read this readme file carefully before reporting bugs!

    +-

    How to report bugs

    ++7. HOW TO REPORT BUGS + +-

    When you report bugs, please provide us complete information. A list ++Please read this readme file carefully before reporting bugs! ++ ++When you report bugs, please provide us complete information. A list + of information we need follows. Please read it carefully, and put + all the information you can into your initial bug report, so that we + don't have to ask you any questions in order to figure out your +-problem.

    ++problem. + +-
      +-
    • The specific operating system name and version of the +-machine on which the DHCP server or client is running. +-
    • The specific operating system name and version of the +-machine on which the client is running, if you are having +-trouble getting a client working with the server. +-
    • If you're running Linux, the version number we care about is +-the kernel version and maybe the library version, not the +-distribution version - e.g., while we don't mind knowing +-that you're running Redhat version mumble.foo, we must know +-what kernel version you're running, and it helps if you can +-tell us what version of the C library you're running, +-although if you don't know that off the top of your head it +-may be hard for you to figure it out, so don't go crazy +-trying. +-
    • The specific version of the DHCP distribution you're +-running, for example 2.0b1pl19, not 2.0. +-
    • Please explain the problem carefully, thinking through what +-you're saying to ensure that you don't assume we know +-something about your situation that we don't know. +-
    • Include your dhcpd.conf and dhcpd.leases file if they're not +-huge (if they are huge, we may need them anyway, but don't +-send them until you're asked). +-
    • Include a log of your server or client running until it +-encounters the problem - for example, if you are having +-trouble getting some client to get an address, restart the +-server with the -d flag and then restart the client, and +-send us what the server prints. Likewise, with the client, +-include the output of the client as it fails to get an +-address or otherwise does the wrong thing. Do not leave +-out parts of the output that you think aren't interesting. +-
    • If the client or server is dumping core, please run the +-debugger and get a stack trace, and include that in your +-bug report. For example, if your debugger is gdb, do the +-following: ++ 1. The specific operating system name and version of the ++ machine on which the DHCP server or client is running. ++ 2. The specific operating system name and version of the ++ machine on which the client is running, if you are having ++ trouble getting a client working with the server. ++ 3. If you're running Linux, the version number we care about is ++ the kernel version and maybe the library version, not the ++ distribution version - e.g., while we don't mind knowing ++ that you're running Redhat version mumble.foo, we must know ++ what kernel version you're running, and it helps if you can ++ tell us what version of the C library you're running, ++ although if you don't know that off the top of your head it ++ may be hard for you to figure it out, so don't go crazy ++ trying. ++ 4. The specific version of the DHCP distribution you're ++ running, for example 2.0b1pl19, not 2.0. ++ 5. Please explain the problem carefully, thinking through what ++ you're saying to ensure that you don't assume we know ++ something about your situation that we don't know. ++ 6. Include your dhcpd.conf and dhcpd.leases file if they're not ++ huge (if they are huge, we may need them anyway, but don't ++ send them until you're asked). ++ 7. Include a log of your server or client running until it ++ encounters the problem - for example, if you are having ++ trouble getting some client to get an address, restart the ++ server with the -d flag and then restart the client, and ++ send us what the server prints. Likewise, with the client, ++ include the output of the client as it fails to get an ++ address or otherwise does the wrong thing. Do not leave ++ out parts of the output that you think aren't interesting. ++ 8. If the client or server is dumping core, please run the ++ debugger and get a stack trace, and include that in your ++ bug report. For example, if your debugger is gdb, do the ++ following: + +-
      + gdb dhcpd dhcpd.core + (gdb) where + [...] + (gdb) quit +-
      + +-

      This assumes that it's the dhcp server you're debugging, and +-that the core file is in dhcpd.core.

      +-
    +- +-

    Please, do not send queries about non-isc clients +-to the dhcp-client mailing list. If you're asking about them on an +-ISC mailing list, it's probably because you're using the ISC DHCP +-server, so ask there. If you are having problems with a client whose +-executable is called dhcpcd, this is not the ISC DHCP client, +-and we probably can't help you with it.

    +- +-

    Please see +-http://www.fugue.com/dhcp/lists for details on how to subscribe. +-If you don't have WorldWide Web access, you can send mail to +-dhcp-request@fugue.com and tell me which lists you want to subscribe +-to, but please use the web interface if you can, since I have to +-handle the -request mailing list manually, and I will give you the +-third degree if you make me do your subscription manually.

    +- +-

    Please do not send requests for help directly to the author! +-The number of people using the DHCP Distribution is sufficiently large +-that if we take an interrupt every time any one of those people runs into +-trouble, we will never get any more coding done.

    +- +-

    Please do not call the author on the phone for support! +-Answering the phone takes a lot more time and attention than answering +-email. If you do call on the phone, you will be told to send email to +-the mailing list, so there's no point in doing it.

    +- +-

    Exception: if you are a support customer, you already know +-how to get in touch with us. To become a support customer, see our +-Support web +-page. +- +-

    Known bugs

    +- +-

    This release of the DHCP Distribution does not yet contain support for +-DHCPINFORM. The Vendor Specific Data option is not supported. Site- +-specific options are not supported. All of these are supported in the +-3.0 release of the DHCP distribution, which is now in beta testing.

    ++ This assumes that it's the dhcp server you're debugging, and ++ that the core file is in dhcpd.core. ++ ++PLEASE DO NOT send queries about non-isc clients to the dhcp-client ++mailing list. If you're asking about them on an ISC mailing list, it's ++probably because you're using the ISC DHCP server, so ask there. If you ++are having problems with a client whose executable is called dhcpcd, ++this is _not_ the ISC DHCP client, and we probably can't help you with it. ++ ++Please see http://www.fugue.com/dhcp/lists for details on how to ++subscribe. If you don't have WorldWide Web access, you can send mail to ++dhcp-request@fugue.com and tell me which lists you want to subscribe to, ++but please use the web interface if you can, since I have to handle the ++-request mailing list manually, and I will give you the third degree if ++you make me do your subscription manually. ++ ++Please do not send requests for help directly to the author! The number ++of people using the DHCP Distribution is sufficiently large that if we ++take an interrupt every time any one of those people runs into trouble, ++we will never get any more coding done. ++ ++Please do not call the author on the phone for support! Answering the ++phone takes a lot more time and attention than answering email. If you ++do call on the phone, you will be told to send email to the mailing list, ++so there's no point in doing it. ++ ++Exception: if you are a support customer, you already know how to get ++in touch with us. To become a support customer, see our Support web page. ++ ++7. KNOWN BUGS ++ ++This release of the DHCP Distribution does not yet contain ++support for DHCPINFORM. The Vendor Specific Data option is not ++supported. Site-specific options are not supported. All of these are ++supported in the 3.0 release of the DHCP distribution, which is now in ++beta testing. + --- dhcp-2.0pl5.orig/debian/patches/203_script_expr.patch +++ dhcp-2.0pl5/debian/patches/203_script_expr.patch @@ -0,0 +1,15 @@ +--- dhcp-2.0pl5.orig/client/scripts/linux ++++ dhcp-2.0pl5/client/scripts/linux +@@ -73,9 +73,9 @@ + fi + + release=`uname -r` +-release=`expr $release : '\(.*\)\..*'` +-relmajor=`echo $release |sed -e 's/^\([^\.]*\)\..*$/\1/'` +-relminor=`echo $release |sed -e 's/^.*\.\([^\.]*\)$/\1/'` ++relminor=`echo $release | sed 's/^[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/'` ++relmajor=`echo $release | sed 's/^[0-9]*\.\([0-9]*\)\..*/\1/'` ++release=`echo $release | sed 's/\([0-9]*\)\..*/\1/'` + + if [ x$new_broadcast_address != x ]; then + new_broadcast_arg="broadcast $new_broadcast_address" --- dhcp-2.0pl5.orig/debian/patches/114_dispatch.patch +++ dhcp-2.0pl5/debian/patches/114_dispatch.patch @@ -0,0 +1,11 @@ +--- /tmp/dhcp-2.0pl5/common/dispatch.c Tue Jul 13 08:51:55 1999 ++++ dhcp-2.0pl5/common/dispatch.c Mon Feb 18 21:30:17 2002 +@@ -668,7 +668,7 @@ + GET_TIME (&cur_time); + + /* Not likely to be transitory... */ +- if (count < 0) ++ if (count < 0 && (errno != EINTR) ) + error ("select: %m"); + + for (l = protocols; l; l = l -> next) { --- dhcp-2.0pl5.orig/debian/patches/304_manpage_see_also.patch +++ dhcp-2.0pl5/debian/patches/304_manpage_see_also.patch @@ -0,0 +1,11 @@ +--- dhcp-2.0pl5.orig/client/dhclient.8 Thu Aug 21 11:00:35 2003 ++++ dhcp-2.0pl5/client/dhclient.8 Thu Aug 21 11:01:09 2003 +@@ -147,7 +147,7 @@ + .B ETCDIR/dhclient.conf, DBDIR/dhclient.leases, RUNDIR/dhclient.pid, + .B DBDIR/dhclient.leases~. + .SH SEE ALSO +-dhcpd(8), dhcrelay(8), dhclient.conf(5), dhclient.leases(5) ++dhcpd(8), dhcrelay(8), dhclient.conf(5), dhclient.leases(5), dhclient-script(8) + .SH AUTHOR + .B dhclient(8) + has been written for the Internet Software Consortium --- dhcp-2.0pl5.orig/debian/patches/116_aligned_structs.patch +++ dhcp-2.0pl5/debian/patches/116_aligned_structs.patch @@ -0,0 +1,43 @@ +--- dhcp-2.0pl5.orig/common/packet.c ++++ dhcp-2.0pl5/common/packet.c +@@ -70,7 +70,8 @@ + #ifdef DEBUG_CHECKSUM_VERBOSE + debug ("sum = %x", sum); + #endif +- sum += (u_int16_t) ntohs(*((u_int16_t *)(buf + i))); ++ sum += ((u_int16_t)(u_int8_t)buf [i]) << 8; ++ sum += (u_int8_t)buf [i + 1]; + /* Add carry. */ + if (sum > 0xFFFF) + sum -= 0xFFFF; +@@ -82,7 +83,7 @@ + #ifdef DEBUG_CHECKSUM_VERBOSE + debug ("sum = %x", sum); + #endif +- sum += buf [i] << 8; ++ sum += ((u_int16_t)(u_int8_t)buf [i]) << 8; + /* Add carry. */ + if (sum > 0xFFFF) + sum -= 0xFFFF; +@@ -218,6 +219,8 @@ + unsigned char *data; + int buflen; + { ++ struct ip _ip; ++ struct udphdr _udp; + struct ip *ip; + struct udphdr *udp; + u_int32_t ip_len = (buf [bufix] & 0xf) << 2; +@@ -230,8 +233,10 @@ + static int udp_packets_length_overflow; + int len; + +- ip = (struct ip *)(buf + bufix); +- udp = (struct udphdr *)(buf + bufix + ip_len); ++ memcpy(&_ip, buf + bufix, sizeof(struct ip)); ++ memcpy(&_udp, buf + bufix + ip_len, sizeof(struct udphdr)); ++ ip = &_ip; ++ udp = &_udp; + + #ifdef USERLAND_FILTER + /* Is it a UDP packet? */ --- dhcp-2.0pl5.orig/debian/patches/100_dhclient.patch +++ dhcp-2.0pl5/debian/patches/100_dhclient.patch @@ -0,0 +1,238 @@ +--- /tmp/dhcp-2.0pl5/client/dhclient.c Wed Sep 6 16:59:09 2000 ++++ dhcp-2.0pl5/client/dhclient.c Mon Feb 18 22:30:24 2002 +@@ -89,6 +89,7 @@ + int log_priority; + int no_daemon; + int save_scripts; ++int exit_on_panic = 0; + + static char copyright[] = + "Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium."; +@@ -99,6 +100,17 @@ + + static void usage PROTO ((char *)); + ++void rebindsignal(int sig) ++{ ++ struct interface_info *ip; ++ ++ note ("USR1 signal received, forcing a DHCP refresh."); ++ ++ for (ip = interfaces; ip; ip = ip -> next) ++ if (ip -> client -> state == S_BOUND) ++ state_reboot (ip); ++} ++ + int main (argc, argv, envp) + int argc; + char **argv, **envp; +@@ -154,6 +166,8 @@ + } else if (!strcmp (argv [i], "-q")) { + quiet = 1; + quiet_interface_discovery = 1; ++ } else if (!strcmp (argv [i], "-e")) { ++ exit_on_panic = 1; + } else if (argv [i][0] == '-') { + usage (s); + } else { +@@ -279,6 +293,9 @@ + /* Set up the bootp packet handler... */ + bootp_packet_handler = do_packet; + ++ /* Register a USR1 signal handler to rebind interfaces */ ++ signal(SIGUSR1, rebindsignal); ++ + /* Start dispatching packets and timeouts... */ + dispatch (); + +@@ -297,7 +314,7 @@ + note (url); + note (""); + +- warn ("Usage: %s [-c] [-p ] [-lf lease-file]", appname); ++ warn ("Usage: %s [-c] [-d] [-e] [-p ] [-lf lease-file]", appname); + error (" [-pf pidfile] [interface]"); + } + +@@ -528,8 +545,12 @@ + cancel_timeout (send_request, ip); + + /* Figure out the lease time. */ +- ip -> client -> new -> expiry = +- getULong (ip -> client -> ++ if (ip -> client -> new -> options [DHO_DHCP_LEASE_TIME].len ++ < sizeof (u_int32_t)) ++ ip -> client -> new -> expiry = TIME_MAX; ++ else ++ ip -> client -> new -> expiry = ++ getULong (ip -> client -> + new -> options [DHO_DHCP_LEASE_TIME].data); + /* A number that looks negative here is really just very large, + because the lease expiry offset is unsigned. */ +@@ -1095,7 +1116,11 @@ + /* state_panic gets called if we haven't received any offers in a preset + amount of time. When this happens, we try to use existing leases that + haven't yet expired, and failing that, we call the client script and +- hope it can do something. */ ++ hope it can do something. ++ ++ Unless we've been told at the command line to exit on panic in which case ++ we do our best to get an interface and then exit with an error if we can't. ++ */ + + void state_panic (ipp) + void *ipp; +@@ -1181,8 +1206,11 @@ + + /* No leases were available, or what was available didn't work, so + tell the shell script that we failed to allocate an address, +- and try again later. */ +- note ("No working leases in persistent database - sleeping.\n"); ++ and try again later. ++ ++ Unless we've been told to exit on an error, in which case we ++ do just that. */ ++ note ("No working leases in persistent database.\n"); + script_init (ip, "FAIL", (struct string_list *)0); + if (ip -> client -> alias) + script_write_params (ip, "alias_", ip -> client -> alias); +@@ -1190,6 +1218,13 @@ + ip -> client -> state = S_INIT; + add_timeout (cur_time + ip -> client -> config -> retry_interval, + state_init, ip); ++ ++ if (exit_on_panic) { ++ note ("Exiting.\n"); ++ exit(1); ++ } ++ ++ note ("Sleeping.\n"); + go_daemon (); + } + +@@ -1298,6 +1333,11 @@ + ip -> client -> state == S_REBOOTING || + cur_time > ip -> client -> active -> rebind) + destination.sin_addr.s_addr = INADDR_BROADCAST; ++ else if (ip->client->config->default_actions[DHO_DHCP_SERVER_IDENTIFIER] ++ == ACTION_SUPERSEDE) ++ memcpy (&destination.sin_addr.s_addr, ++ ip->client->config->defaults[DHO_DHCP_SERVER_IDENTIFIER].data, ++ sizeof destination.sin_addr.s_addr); + else + memcpy (&destination.sin_addr.s_addr, + ip -> client -> destination.iabuf, +@@ -1395,6 +1435,9 @@ + + struct tree_cache *options [256]; + struct tree_cache option_elements [256]; ++#ifdef DEBUG_PACKET ++ struct packet sendpkt; ++#endif + + memset (option_elements, 0, sizeof option_elements); + memset (options, 0, sizeof options); +@@ -1480,9 +1523,11 @@ + ip -> hw_address.haddr, ip -> hw_address.hlen); + + #ifdef DEBUG_PACKET +- dump_packet (sendpkt); +- dump_raw ((unsigned char *)ip -> client -> packet, +- sendpkt->packet_length); ++ sendpkt.raw = &(ip -> client -> packet); ++ sendpkt.packet_length = ip -> client -> packet_length; ++ dump_packet (&sendpkt); ++ dump_raw ((unsigned char *)&(ip -> client -> packet), ++ ip -> client -> packet_length); + #endif + } + +@@ -1496,6 +1541,9 @@ + + struct tree_cache *options [256]; + struct tree_cache option_elements [256]; ++#ifdef DEBUG_PACKET ++ struct packet sendpkt; ++#endif + + memset (options, 0, sizeof options); + memset (&ip -> client -> packet, 0, sizeof (ip -> client -> packet)); +@@ -1602,8 +1650,11 @@ + ip -> hw_address.haddr, ip -> hw_address.hlen); + + #ifdef DEBUG_PACKET +- dump_packet (sendpkt); +- dump_raw ((unsigned char *)ip -> client -> packet, sendpkt->packet_length); ++ sendpkt.raw = &(ip -> client -> packet); ++ sendpkt.packet_length = ip -> client -> packet_length; ++ dump_packet (&sendpkt); ++ dump_raw ((unsigned char *)&(ip -> client -> packet), ++ ip -> client -> packet_length); + #endif + } + +@@ -1620,6 +1671,10 @@ + struct tree_cache server_id_tree; + struct tree_cache client_id_tree; + ++#ifdef DEBUG_PACKET ++ struct packet sendpkt; ++#endif ++ + memset (options, 0, sizeof options); + memset (&ip -> client -> packet, 0, sizeof (ip -> client -> packet)); + +@@ -1693,8 +1748,11 @@ + ip -> hw_address.haddr, ip -> hw_address.hlen); + + #ifdef DEBUG_PACKET +- dump_packet (sendpkt); +- dump_raw ((unsigned char *)ip -> client -> packet, sendpkt->packet_length); ++ sendpkt.raw = &(ip -> client -> packet); ++ sendpkt.packet_length = ip -> client -> packet_length; ++ dump_packet (&sendpkt); ++ dump_raw ((unsigned char *)&(ip -> client -> packet), ++ ip -> client -> packet_length); + #endif + } + +@@ -1709,6 +1767,10 @@ + struct tree_cache message_type_tree; + struct tree_cache server_id_tree; + ++#ifdef DEBUG_PACKET ++ struct packet sendpkt; ++#endif ++ + memset (options, 0, sizeof options); + memset (&ip -> client -> packet, 0, sizeof (ip -> client -> packet)); + +@@ -1757,8 +1819,10 @@ + ip -> hw_address.haddr, ip -> hw_address.hlen); + + #ifdef DEBUG_PACKET +- dump_packet (sendpkt); +- dump_raw ((unsigned char *)ip -> client -> packet, ++ sendpkt.raw = &(ip -> client -> packet); ++ sendpkt.packet_length = ip -> client -> packet_length; ++ dump_packet (&sendpkt); ++ dump_raw ((unsigned char *)&(ip -> client -> packet), + ip -> client -> packet_length); + #endif + } +--- dhcp-2.0pl5/client/dhclient.c.orig Sun Jun 2 22:03:45 2002 ++++ dhcp-2.0pl5/client/dhclient.c Sun Jun 2 22:05:43 2002 +@@ -2111,6 +2111,13 @@ + wstatus = 0; + } + } else { ++ /* ++ We don't want to pass an open file descriptor for ++ dhclient.leases when executing dhclient-script. ++ Debian bug #147582 ++ */ ++ if (leaseFile) ++ fclose (leaseFile); + execve (scriptName, argv, envp); + error ("execve (%s, ...): %m", scriptName); + exit (0); --- dhcp-2.0pl5.orig/debian/patches/112_common.patch +++ dhcp-2.0pl5/debian/patches/112_common.patch @@ -0,0 +1,12 @@ +--- dhcp-2.0pl5/common/packet.c.orig 1999-06-09 19:58:16.000000000 -0500 ++++ dhcp-2.0pl5/common/packet.c 2002-07-25 19:02:17.000000000 -0500 +@@ -153,7 +153,7 @@ + ip.ip_len = htons(sizeof(ip) + sizeof(udp) + len); + ip.ip_id = 0; + ip.ip_off = 0; +- ip.ip_ttl = 16; ++ ip.ip_ttl = IPDEFTTL; + ip.ip_p = IPPROTO_UDP; + ip.ip_sum = 0; + ip.ip_src.s_addr = from; + --- dhcp-2.0pl5.orig/debian/patches/301_no-rfcs.patch +++ dhcp-2.0pl5/debian/patches/301_no-rfcs.patch @@ -0,0 +1,5152 @@ +diff -Naru dhcp-2.0pl5_original/doc/rfc2131.txt dhcp-2.0pl5/doc/rfc2131.txt +--- dhcp-2.0pl5_original/doc/rfc2131.txt 1997-12-06 06:08:03.000000000 -0600 ++++ dhcp-2.0pl5/doc/rfc2131.txt 1969-12-31 18:00:00.000000000 -0600 +@@ -1,2523 +0,0 @@ +- +- +- +- +- +- +-Network Working Group R. Droms +-Request for Comments: 2131 Bucknell University +-Obsoletes: 1541 March 1997 +-Category: Standards Track +- +- Dynamic Host Configuration Protocol +- +-Status of this memo +- +- This document specifies an Internet standards track protocol for the +- Internet community, and requests discussion and suggestions for +- improvements. Please refer to the current edition of the "Internet +- Official Protocol Standards" (STD 1) for the standardization state +- and status of this protocol. Distribution of this memo is unlimited. +- +-Abstract +- +- The Dynamic Host Configuration Protocol (DHCP) provides a framework +- for passing configuration information to hosts on a TCPIP network. +- DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the +- capability of automatic allocation of reusable network addresses and +- additional configuration options [19]. DHCP captures the behavior of +- BOOTP relay agents [7, 21], and DHCP participants can interoperate +- with BOOTP participants [9]. +- +-Table of Contents +- +- 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 +- 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3 +- 1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4 +- 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4 +- 1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5 +- 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 +- 1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6 +- 2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8 +- 2.1 Configuration parameters repository . . . . . . . . . . . . . 11 +- 2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12 +- 3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13 +- 3.1 Client-server interaction - allocating a network address. . . 13 +- 3.2 Client-server interaction - reusing a previously allocated +- network address . . . . . . . . . . . . . . . . . . . . . . . 17 +- 3.3 Interpretation and representation of time values. . . . . . . 20 +- 3.4 Obtaining parameters with externally configured network +- address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 +- 3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21 +- 3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22 +- 3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22 +- 4. Specification of the DHCP client-server protocol. . . . . . . 22 +- +- +- +-Droms Standards Track [Page 1] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- 4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22 +- 4.2 DHCP server administrative controls . . . . . . . . . . . . . 25 +- 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26 +- 4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34 +- 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42 +- 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .42 +- 7. Security Considerations. . . . . . . . . . . . . . . . . . . .43 +- 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44 +- A. Host Configuration Parameters . . . . . . . . . . . . . . . .45 +-List of Figures +- 1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9 +- 2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11 +- 3. Timeline diagram of messages exchanged between DHCP client and +- servers when allocating a new network address. . . . . . . . . 15 +- 4. Timeline diagram of messages exchanged between DHCP client and +- servers when reusing a previously allocated network address. . 18 +- 5. State-transition diagram for DHCP clients. . . . . . . . . . . 34 +-List of Tables +- 1. Description of fields in a DHCP message. . . . . . . . . . . . 10 +- 2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14 +- 3. Fields and options used by DHCP servers. . . . . . . . . . . . 28 +- 4. Client messages from various states. . . . . . . . . . . . . . 33 +- 5. Fields and options used by DHCP clients. . . . . . . . . . . . 37 +- +-1. Introduction +- +- The Dynamic Host Configuration Protocol (DHCP) provides configuration +- parameters to Internet hosts. DHCP consists of two components: a +- protocol for delivering host-specific configuration parameters from a +- DHCP server to a host and a mechanism for allocation of network +- addresses to hosts. +- +- DHCP is built on a client-server model, where designated DHCP server +- hosts allocate network addresses and deliver configuration parameters +- to dynamically configured hosts. Throughout the remainder of this +- document, the term "server" refers to a host providing initialization +- parameters through DHCP, and the term "client" refers to a host +- requesting initialization parameters from a DHCP server. +- +- A host should not act as a DHCP server unless explicitly configured +- to do so by a system administrator. The diversity of hardware and +- protocol implementations in the Internet would preclude reliable +- operation if random hosts were allowed to respond to DHCP requests. +- For example, IP requires the setting of many parameters within the +- protocol implementation software. Because IP can be used on many +- dissimilar kinds of network hardware, values for those parameters +- cannot be guessed or assumed to have correct defaults. Also, +- distributed address allocation schemes depend on a polling/defense +- +- +- +-Droms Standards Track [Page 2] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- mechanism for discovery of addresses that are already in use. IP +- hosts may not always be able to defend their network addresses, so +- that such a distributed address allocation scheme cannot be +- guaranteed to avoid allocation of duplicate network addresses. +- +- DHCP supports three mechanisms for IP address allocation. In +- "automatic allocation", DHCP assigns a permanent IP address to a +- client. In "dynamic allocation", DHCP assigns an IP address to a +- client for a limited period of time (or until the client explicitly +- relinquishes the address). In "manual allocation", a client's IP +- address is assigned by the network administrator, and DHCP is used +- simply to convey the assigned address to the client. A particular +- network will use one or more of these mechanisms, depending on the +- policies of the network administrator. +- +- Dynamic allocation is the only one of the three mechanisms that +- allows automatic reuse of an address that is no longer needed by the +- client to which it was assigned. Thus, dynamic allocation is +- particularly useful for assigning an address to a client that will be +- connected to the network only temporarily or for sharing a limited +- pool of IP addresses among a group of clients that do not need +- permanent IP addresses. Dynamic allocation may also be a good choice +- for assigning an IP address to a new client being permanently +- connected to a network where IP addresses are sufficiently scarce +- that it is important to reclaim them when old clients are retired. +- Manual allocation allows DHCP to be used to eliminate the error-prone +- process of manually configuring hosts with IP addresses in +- environments where (for whatever reasons) it is desirable to manage +- IP address assignment outside of the DHCP mechanisms. +- +- The format of DHCP messages is based on the format of BOOTP messages, +- to capture the BOOTP relay agent behavior described as part of the +- BOOTP specification [7, 21] and to allow interoperability of existing +- BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates +- the necessity of having a DHCP server on each physical network +- segment. +- +-1.1 Changes to RFC 1541 +- +- This document updates the DHCP protocol specification that appears in +- RFC1541. A new DHCP message type, DHCPINFORM, has been added; see +- section 3.4, 4.3 and 4.4 for details. The classing mechanism for +- identifying DHCP clients to DHCP servers has been extended to include +- "vendor" classes as defined in sections 4.2 and 4.3. The minimum +- lease time restriction has been removed. Finally, many editorial +- changes have been made to clarify the text as a result of experience +- gained in DHCP interoperability tests. +- +- +- +- +-Droms Standards Track [Page 3] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +-1.2 Related Work +- +- There are several Internet protocols and related mechanisms that +- address some parts of the dynamic host configuration problem. The +- Reverse Address Resolution Protocol (RARP) [10] (through the +- extensions defined in the Dynamic RARP (DRARP) [5]) explicitly +- addresses the problem of network address discovery, and includes an +- automatic IP address assignment mechanism. The Trivial File Transfer +- Protocol (TFTP) [20] provides for transport of a boot image from a +- boot server. The Internet Control Message Protocol (ICMP) [16] +- provides for informing hosts of additional routers via "ICMP +- redirect" messages. ICMP also can provide subnet mask information +- through the "ICMP mask request" message and other information through +- the (obsolete) "ICMP information request" message. Hosts can locate +- routers through the ICMP router discovery mechanism [8]. +- +- BOOTP is a transport mechanism for a collection of configuration +- information. BOOTP is also extensible, and official extensions [17] +- have been defined for several configuration parameters. Morgan has +- proposed extensions to BOOTP for dynamic IP address assignment [15]. +- The Network Information Protocol (NIP), used by the Athena project at +- MIT, is a distributed mechanism for dynamic IP address assignment +- [19]. The Resource Location Protocol RLP [1] provides for location +- of higher level services. Sun Microsystems diskless workstations use +- a boot procedure that employs RARP, TFTP and an RPC mechanism called +- "bootparams" to deliver configuration information and operating +- system code to diskless hosts. (Sun Microsystems, Sun Workstation +- and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun +- networks also use DRARP and an auto-installation mechanism to +- automate the configuration of new hosts in an existing network. +- +- In other related work, the path minimum transmission unit (MTU) +- discovery algorithm can determine the MTU of an arbitrary internet +- path [14]. The Address Resolution Protocol (ARP) has been proposed +- as a transport protocol for resource location and selection [6]. +- Finally, the Host Requirements RFCs [3, 4] mention specific +- requirements for host reconfiguration and suggest a scenario for +- initial configuration of diskless hosts. +- +-1.3 Problem definition and issues +- +- DHCP is designed to supply DHCP clients with the configuration +- parameters defined in the Host Requirements RFCs. After obtaining +- parameters via DHCP, a DHCP client should be able to exchange packets +- with any other host in the Internet. The TCP/IP stack parameters +- supplied by DHCP are listed in Appendix A. +- +- +- +- +- +-Droms Standards Track [Page 4] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- Not all of these parameters are required for a newly initialized +- client. A client and server may negotiate for the transmission of +- only those parameters required by the client or specific to a +- particular subnet. +- +- DHCP allows but does not require the configuration of client +- parameters not directly related to the IP protocol. DHCP also does +- not address registration of newly configured clients with the Domain +- Name System (DNS) [12, 13]. +- +- DHCP is not intended for use in configuring routers. +- +-1.4 Requirements +- +- Throughout this document, the words that are used to define the +- significance of particular requirements are capitalized. These words +- are: +- +- o "MUST" +- +- This word or the adjective "REQUIRED" means that the +- item is an absolute requirement of this specification. +- +- o "MUST NOT" +- +- This phrase means that the item is an absolute prohibition +- of this specification. +- +- o "SHOULD" +- +- This word or the adjective "RECOMMENDED" means that there +- may exist valid reasons in particular circumstances to ignore +- this item, but the full implications should be understood and +- the case carefully weighed before choosing a different course. +- +- o "SHOULD NOT" +- +- This phrase means that there may exist valid reasons in +- particular circumstances when the listed behavior is acceptable +- or even useful, but the full implications should be understood +- and the case carefully weighed before implementing any behavior +- described with this label. +- +- +- +- +- +- +- +- +- +-Droms Standards Track [Page 5] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- o "MAY" +- +- This word or the adjective "OPTIONAL" means that this item is +- truly optional. One vendor may choose to include the item +- because a particular marketplace requires it or because it +- enhances the product, for example; another vendor may omit the +- same item. +- +-1.5 Terminology +- +- This document uses the following terms: +- +- o "DHCP client" +- +- A DHCP client is an Internet host using DHCP to obtain +- configuration parameters such as a network address. +- +- o "DHCP server" +- +- A DHCP server is an Internet host that returns configuration +- parameters to DHCP clients. +- +- o "BOOTP relay agent" +- +- A BOOTP relay agent or relay agent is an Internet host or router +- that passes DHCP messages between DHCP clients and DHCP servers. +- DHCP is designed to use the same relay agent behavior as specified +- in the BOOTP protocol specification. +- +- o "binding" +- +- A binding is a collection of configuration parameters, including +- at least an IP address, associated with or "bound to" a DHCP +- client. Bindings are managed by DHCP servers. +- +-1.6 Design goals +- +- The following list gives general design goals for DHCP. +- +- o DHCP should be a mechanism rather than a policy. DHCP must +- allow local system administrators control over configuration +- parameters where desired; e.g., local system administrators +- should be able to enforce local policies concerning allocation +- and access to local resources where desired. +- +- +- +- +- +- +- +-Droms Standards Track [Page 6] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- o Clients should require no manual configuration. Each client +- should be able to discover appropriate local configuration +- parameters without user intervention and incorporate those +- parameters into its own configuration. +- +- o Networks should require no manual configuration for individual +- clients. Under normal circumstances, the network manager +- should not have to enter any per-client configuration +- parameters. +- +- o DHCP should not require a server on each subnet. To allow for +- scale and economy, DHCP must work across routers or through the +- intervention of BOOTP relay agents. +- +- o A DHCP client must be prepared to receive multiple responses +- to a request for configuration parameters. Some installations +- may include multiple, overlapping DHCP servers to enhance +- reliability and increase performance. +- +- o DHCP must coexist with statically configured, non-participating +- hosts and with existing network protocol implementations. +- +- o DHCP must interoperate with the BOOTP relay agent behavior as +- described by RFC 951 and by RFC 1542 [21]. +- +- o DHCP must provide service to existing BOOTP clients. +- +- The following list gives design goals specific to the transmission of +- the network layer parameters. DHCP must: +- +- o Guarantee that any specific network address will not be in +- use by more than one DHCP client at a time, +- +- o Retain DHCP client configuration across DHCP client reboot. A +- DHCP client should, whenever possible, be assigned the same +- configuration parameters (e.g., network address) in response +- to each request, +- +- o Retain DHCP client configuration across server reboots, and, +- whenever possible, a DHCP client should be assigned the same +- configuration parameters despite restarts of the DHCP mechanism, +- +- o Allow automated assignment of configuration parameters to new +- clients to avoid hand configuration for new clients, +- +- o Support fixed or permanent allocation of configuration +- parameters to specific clients. +- +- +- +- +-Droms Standards Track [Page 7] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +-2. Protocol Summary +- +- From the client's point of view, DHCP is an extension of the BOOTP +- mechanism. This behavior allows existing BOOTP clients to +- interoperate with DHCP servers without requiring any change to the +- clients' initialization software. RFC 1542 [2] details the +- interactions between BOOTP and DHCP clients and servers [9]. There +- are some new, optional transactions that optimize the interaction +- between DHCP clients and servers that are described in sections 3 and +- 4. +- +- Figure 1 gives the format of a DHCP message and table 1 describes +- each of the fields in the DHCP message. The numbers in parentheses +- indicate the size of each field in octets. The names for the fields +- given in the figure will be used throughout this document to refer to +- the fields in DHCP messages. +- +- There are two primary differences between DHCP and BOOTP. First, +- DHCP defines mechanisms through which clients can be assigned a +- network address for a finite lease, allowing for serial reassignment +- of network addresses to different clients. Second, DHCP provides the +- mechanism for a client to acquire all of the IP configuration +- parameters that it needs in order to operate. +- +- DHCP introduces a small change in terminology intended to clarify the +- meaning of one of the fields. What was the "vendor extensions" field +- in BOOTP has been re-named the "options" field in DHCP. Similarly, +- the tagged data items that were used inside the BOOTP "vendor +- extensions" field, which were formerly referred to as "vendor +- extensions," are now termed simply "options." +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +-Droms Standards Track [Page 8] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- 0 1 2 3 +- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +- | op (1) | htype (1) | hlen (1) | hops (1) | +- +---------------+---------------+---------------+---------------+ +- | xid (4) | +- +-------------------------------+-------------------------------+ +- | secs (2) | flags (2) | +- +-------------------------------+-------------------------------+ +- | ciaddr (4) | +- +---------------------------------------------------------------+ +- | yiaddr (4) | +- +---------------------------------------------------------------+ +- | siaddr (4) | +- +---------------------------------------------------------------+ +- | giaddr (4) | +- +---------------------------------------------------------------+ +- | | +- | chaddr (16) | +- | | +- | | +- +---------------------------------------------------------------+ +- | | +- | sname (64) | +- +---------------------------------------------------------------+ +- | | +- | file (128) | +- +---------------------------------------------------------------+ +- | | +- | options (variable) | +- +---------------------------------------------------------------+ +- +- Figure 1: Format of a DHCP message +- +- DHCP defines a new 'client identifier' option that is used to pass an +- explicit client identifier to a DHCP server. This change eliminates +- the overloading of the 'chaddr' field in BOOTP messages, where +- 'chaddr' is used both as a hardware address for transmission of BOOTP +- reply messages and as a client identifier. The 'client identifier' +- is an opaque key, not to be interpreted by the server; for example, +- the 'client identifier' may contain a hardware address, identical to +- the contents of the 'chaddr' field, or it may contain another type of +- identifier, such as a DNS name. The 'client identifier' chosen by a +- DHCP client MUST be unique to that client within the subnet to which +- the client is attached. If the client uses a 'client identifier' in +- one message, it MUST use that same identifier in all subsequent +- messages, to ensure that all servers correctly identify the client. +- +- +- +- +-Droms Standards Track [Page 9] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- DHCP clarifies the interpretation of the 'siaddr' field as the +- address of the server to use in the next step of the client's +- bootstrap process. A DHCP server may return its own address in the +- 'siaddr' field, if the server is prepared to supply the next +- bootstrap service (e.g., delivery of an operating system executable +- image). A DHCP server always returns its own address in the 'server +- identifier' option. +- +- FIELD OCTETS DESCRIPTION +- ----- ------ ----------- +- +- op 1 Message op code / message type. +- 1 = BOOTREQUEST, 2 = BOOTREPLY +- htype 1 Hardware address type, see ARP section in "Assigned +- Numbers" RFC; e.g., '1' = 10mb ethernet. +- hlen 1 Hardware address length (e.g. '6' for 10mb +- ethernet). +- hops 1 Client sets to zero, optionally used by relay agents +- when booting via a relay agent. +- xid 4 Transaction ID, a random number chosen by the +- client, used by the client and server to associate +- messages and responses between a client and a +- server. +- secs 2 Filled in by client, seconds elapsed since client +- began address acquisition or renewal process. +- flags 2 Flags (see figure 2). +- ciaddr 4 Client IP address; only filled in if client is in +- BOUND, RENEW or REBINDING state and can respond +- to ARP requests. +- yiaddr 4 'your' (client) IP address. +- siaddr 4 IP address of next server to use in bootstrap; +- returned in DHCPOFFER, DHCPACK by server. +- giaddr 4 Relay agent IP address, used in booting via a +- relay agent. +- chaddr 16 Client hardware address. +- sname 64 Optional server host name, null terminated string. +- file 128 Boot file name, null terminated string; "generic" +- name or null in DHCPDISCOVER, fully qualified +- directory-path name in DHCPOFFER. +- options var Optional parameters field. See the options +- documents for a list of defined options. +- +- Table 1: Description of fields in a DHCP message +- +- The 'options' field is now variable length. A DHCP client must be +- prepared to receive DHCP messages with an 'options' field of at least +- length 312 octets. This requirement implies that a DHCP client must +- be prepared to receive a message of up to 576 octets, the minimum IP +- +- +- +-Droms Standards Track [Page 10] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- datagram size an IP host must be prepared to accept [3]. DHCP +- clients may negotiate the use of larger DHCP messages through the +- 'maximum DHCP message size' option. The options field may be further +- extended into the 'file' and 'sname' fields. +- +- In the case of a client using DHCP for initial configuration (before +- the client's TCP/IP software has been completely configured), DHCP +- requires creative use of the client's TCP/IP software and liberal +- interpretation of RFC 1122. The TCP/IP software SHOULD accept and +- forward to the IP layer any IP packets delivered to the client's +- hardware address before the IP address is configured; DHCP servers +- and BOOTP relay agents may not be able to deliver DHCP messages to +- clients that cannot accept hardware unicast datagrams before the +- TCP/IP software is configured. +- +- To work around some clients that cannot accept IP unicast datagrams +- before the TCP/IP software is configured as discussed in the previous +- paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is +- defined as the BROADCAST (B) flag. The semantics of this flag are +- discussed in section 4.1 of this document. The remaining bits of the +- flags field are reserved for future use. They MUST be set to zero by +- clients and ignored by servers and relay agents. Figure 2 gives the +- format of the 'flags' field. +- +- 1 1 1 1 1 1 +- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +- |B| MBZ | +- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +- +- B: BROADCAST flag +- +- MBZ: MUST BE ZERO (reserved for future use) +- +- Figure 2: Format of the 'flags' field +- +-2.1 Configuration parameters repository +- +- The first service provided by DHCP is to provide persistent storage +- of network parameters for network clients. The model of DHCP +- persistent storage is that the DHCP service stores a key-value entry +- for each client, where the key is some unique identifier (for +- example, an IP subnet number and a unique identifier within the +- subnet) and the value contains the configuration parameters for the +- client. +- +- For example, the key might be the pair (IP-subnet-number, hardware- +- address) (note that the "hardware-address" should be typed by the +- +- +- +-Droms Standards Track [Page 11] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- type of hardware to accommodate possible duplication of hardware +- addresses resulting from bit-ordering problems in a mixed-media, +- bridged network) allowing for serial or concurrent reuse of a +- hardware address on different subnets, and for hardware addresses +- that may not be globally unique. Alternately, the key might be the +- pair (IP-subnet-number, hostname), allowing the server to assign +- parameters intelligently to a DHCP client that has been moved to a +- different subnet or has changed hardware addresses (perhaps because +- the network interface failed and was replaced). The protocol defines +- that the key will be (IP-subnet-number, hardware-address) unless the +- client explicitly supplies an identifier using the 'client +- identifier' option. A client can query the DHCP service to +- retrieve its configuration parameters. The client interface to the +- configuration parameters repository consists of protocol messages to +- request configuration parameters and responses from the server +- carrying the configuration parameters. +- +-2.2 Dynamic allocation of network addresses +- +- The second service provided by DHCP is the allocation of temporary or +- permanent network (IP) addresses to clients. The basic mechanism for +- the dynamic allocation of network addresses is simple: a client +- requests the use of an address for some period of time. The +- allocation mechanism (the collection of DHCP servers) guarantees not +- to reallocate that address within the requested time and attempts to +- return the same network address each time the client requests an +- address. In this document, the period over which a network address +- is allocated to a client is referred to as a "lease" [11]. The +- client may extend its lease with subsequent requests. The client may +- issue a message to release the address back to the server when the +- client no longer needs the address. The client may ask for a +- permanent assignment by asking for an infinite lease. Even when +- assigning "permanent" addresses, a server may choose to give out +- lengthy but non-infinite leases to allow detection of the fact that +- the client has been retired. +- +- In some environments it will be necessary to reassign network +- addresses due to exhaustion of available addresses. In such +- environments, the allocation mechanism will reuse addresses whose +- lease has expired. The server should use whatever information is +- available in the configuration information repository to choose an +- address to reuse. For example, the server may choose the least +- recently assigned address. As a consistency check, the allocating +- server SHOULD probe the reused address before allocating the address, +- e.g., with an ICMP echo request, and the client SHOULD probe the +- newly received address, e.g., with ARP. +- +- +- +- +- +-Droms Standards Track [Page 12] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +-3. The Client-Server Protocol +- +- DHCP uses the BOOTP message format defined in RFC 951 and given in +- table 1 and figure 1. The 'op' field of each DHCP message sent from +- a client to a server contains BOOTREQUEST. BOOTREPLY is used in the +- 'op' field of each DHCP message sent from a server to a client. +- +- The first four octets of the 'options' field of the DHCP message +- contain the (decimal) values 99, 130, 83 and 99, respectively (this +- is the same magic cookie as is defined in RFC 1497 [17]). The +- remainder of the 'options' field consists of a list of tagged +- parameters that are called "options". All of the "vendor extensions" +- listed in RFC 1497 are also DHCP options. RFC 1533 gives the +- complete set of options defined for use with DHCP. +- +- Several options have been defined so far. One particular option - +- the "DHCP message type" option - must be included in every DHCP +- message. This option defines the "type" of the DHCP message. +- Additional options may be allowed, required, or not allowed, +- depending on the DHCP message type. +- +- Throughout this document, DHCP messages that include a 'DHCP message +- type' option will be referred to by the type of the message; e.g., a +- DHCP message with 'DHCP message type' option type 1 will be referred +- to as a "DHCPDISCOVER" message. +- +-3.1 Client-server interaction - allocating a network address +- +- The following summary of the protocol exchanges between clients and +- servers refers to the DHCP messages described in table 2. The +- timeline diagram in figure 3 shows the timing relationships in a +- typical client-server interaction. If the client already knows its +- address, some steps may be omitted; this abbreviated interaction is +- described in section 3.2. +- +- 1. The client broadcasts a DHCPDISCOVER message on its local physical +- subnet. The DHCPDISCOVER message MAY include options that suggest +- values for the network address and lease duration. BOOTP relay +- agents may pass the message on to DHCP servers not on the same +- physical subnet. +- +- 2. Each server may respond with a DHCPOFFER message that includes an +- available network address in the 'yiaddr' field (and other +- configuration parameters in DHCP options). Servers need not +- reserve the offered network address, although the protocol will +- work more efficiently if the server avoids allocating the offered +- network address to another client. When allocating a new address, +- servers SHOULD check that the offered network address is not +- +- +- +-Droms Standards Track [Page 13] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- already in use; e.g., the server may probe the offered address +- with an ICMP Echo Request. Servers SHOULD be implemented so that +- network administrators MAY choose to disable probes of newly +- allocated addresses. The server transmits the DHCPOFFER message +- to the client, using the BOOTP relay agent if necessary. +- +- Message Use +- ------- --- +- +- DHCPDISCOVER - Client broadcast to locate available servers. +- +- DHCPOFFER - Server to client in response to DHCPDISCOVER with +- offer of configuration parameters. +- +- DHCPREQUEST - Client message to servers either (a) requesting +- offered parameters from one server and implicitly +- declining offers from all others, (b) confirming +- correctness of previously allocated address after, +- e.g., system reboot, or (c) extending the lease on a +- particular network address. +- +- DHCPACK - Server to client with configuration parameters, +- including committed network address. +- +- DHCPNAK - Server to client indicating client's notion of network +- address is incorrect (e.g., client has moved to new +- subnet) or client's lease as expired +- +- DHCPDECLINE - Client to server indicating network address is already +- in use. +- +- DHCPRELEASE - Client to server relinquishing network address and +- cancelling remaining lease. +- +- DHCPINFORM - Client to server, asking only for local configuration +- parameters; client already has externally configured +- network address. +- +- Table 2: DHCP messages +- +- +- +- +- +- +- +- +- +- +- +- +-Droms Standards Track [Page 14] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- Server Client Server +- (not selected) (selected) +- +- v v v +- | | | +- | Begins initialization | +- | | | +- | _____________/|\____________ | +- |/DHCPDISCOVER | DHCPDISCOVER \| +- | | | +- Determines | Determines +- configuration | configuration +- | | | +- |\ | ____________/ | +- | \________ | /DHCPOFFER | +- | DHCPOFFER\ |/ | +- | \ | | +- | Collects replies | +- | \| | +- | Selects configuration | +- | | | +- | _____________/|\____________ | +- |/ DHCPREQUEST | DHCPREQUEST\ | +- | | | +- | | Commits configuration +- | | | +- | | _____________/| +- | |/ DHCPACK | +- | | | +- | Initialization complete | +- | | | +- . . . +- . . . +- | | | +- | Graceful shutdown | +- | | | +- | |\ ____________ | +- | | DHCPRELEASE \| +- | | | +- | | Discards lease +- | | | +- v v v +- Figure 3: Timeline diagram of messages exchanged between DHCP +- client and servers when allocating a new network address +- +- +- +- +- +- +- +-Droms Standards Track [Page 15] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- 3. The client receives one or more DHCPOFFER messages from one or more +- servers. The client may choose to wait for multiple responses. +- The client chooses one server from which to request configuration +- parameters, based on the configuration parameters offered in the +- DHCPOFFER messages. The client broadcasts a DHCPREQUEST message +- that MUST include the 'server identifier' option to indicate which +- server it has selected, and that MAY include other options +- specifying desired configuration values. The 'requested IP +- address' option MUST be set to the value of 'yiaddr' in the +- DHCPOFFER message from the server. This DHCPREQUEST message is +- broadcast and relayed through DHCP/BOOTP relay agents. To help +- ensure that any BOOTP relay agents forward the DHCPREQUEST message +- to the same set of DHCP servers that received the original +- DHCPDISCOVER message, the DHCPREQUEST message MUST use the same +- value in the DHCP message header's 'secs' field and be sent to the +- same IP broadcast address as the original DHCPDISCOVER message. +- The client times out and retransmits the DHCPDISCOVER message if +- the client receives no DHCPOFFER messages. +- +- 4. The servers receive the DHCPREQUEST broadcast from the client. +- Those servers not selected by the DHCPREQUEST message use the +- message as notification that the client has declined that server's +- offer. The server selected in the DHCPREQUEST message commits the +- binding for the client to persistent storage and responds with a +- DHCPACK message containing the configuration parameters for the +- requesting client. The combination of 'client identifier' or +- 'chaddr' and assigned network address constitute a unique +- identifier for the client's lease and are used by both the client +- and server to identify a lease referred to in any DHCP messages. +- Any configuration parameters in the DHCPACK message SHOULD NOT +- conflict with those in the earlier DHCPOFFER message to which the +- client is responding. The server SHOULD NOT check the offered +- network address at this point. The 'yiaddr' field in the DHCPACK +- messages is filled in with the selected network address. +- +- If the selected server is unable to satisfy the DHCPREQUEST message +- (e.g., the requested network address has been allocated), the +- server SHOULD respond with a DHCPNAK message. +- +- A server MAY choose to mark addresses offered to clients in +- DHCPOFFER messages as unavailable. The server SHOULD mark an +- address offered to a client in a DHCPOFFER message as available if +- the server receives no DHCPREQUEST message from that client. +- +- 5. The client receives the DHCPACK message with configuration +- parameters. The client SHOULD perform a final check on the +- parameters (e.g., ARP for allocated network address), and notes the +- duration of the lease specified in the DHCPACK message. At this +- +- +- +-Droms Standards Track [Page 16] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- point, the client is configured. If the client detects that the +- address is already in use (e.g., through the use of ARP), the +- client MUST send a DHCPDECLINE message to the server and restarts +- the configuration process. The client SHOULD wait a minimum of ten +- seconds before restarting the configuration process to avoid +- excessive network traffic in case of looping. +- +- If the client receives a DHCPNAK message, the client restarts the +- configuration process. +- +- The client times out and retransmits the DHCPREQUEST message if the +- client receives neither a DHCPACK or a DHCPNAK message. The client +- retransmits the DHCPREQUEST according to the retransmission +- algorithm in section 4.1. The client should choose to retransmit +- the DHCPREQUEST enough times to give adequate probability of +- contacting the server without causing the client (and the user of +- that client) to wait overly long before giving up; e.g., a client +- retransmitting as described in section 4.1 might retransmit the +- DHCPREQUEST message four times, for a total delay of 60 seconds, +- before restarting the initialization procedure. If the client +- receives neither a DHCPACK or a DHCPNAK message after employing the +- retransmission algorithm, the client reverts to INIT state and +- restarts the initialization process. The client SHOULD notify the +- user that the initialization process has failed and is restarting. +- +- 6. The client may choose to relinquish its lease on a network address +- by sending a DHCPRELEASE message to the server. The client +- identifies the lease to be released with its 'client identifier', +- or 'chaddr' and network address in the DHCPRELEASE message. If the +- client used a 'client identifier' when it obtained the lease, it +- MUST use the same 'client identifier' in the DHCPRELEASE message. +- +-3.2 Client-server interaction - reusing a previously allocated network +- address +- +- If a client remembers and wishes to reuse a previously allocated +- network address, a client may choose to omit some of the steps +- described in the previous section. The timeline diagram in figure 4 +- shows the timing relationships in a typical client-server interaction +- for a client reusing a previously allocated network address. +- +- +- +- +- +- +- +- +- +- +- +-Droms Standards Track [Page 17] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- 1. The client broadcasts a DHCPREQUEST message on its local subnet. +- The message includes the client's network address in the +- 'requested IP address' option. As the client has not received its +- network address, it MUST NOT fill in the 'ciaddr' field. BOOTP +- relay agents pass the message on to DHCP servers not on the same +- subnet. If the client used a 'client identifier' to obtain its +- address, the client MUST use the same 'client identifier' in the +- DHCPREQUEST message. +- +- 2. Servers with knowledge of the client's configuration parameters +- respond with a DHCPACK message to the client. Servers SHOULD NOT +- check that the client's network address is already in use; the +- client may respond to ICMP Echo Request messages at this point. +- +- Server Client Server +- +- v v v +- | | | +- | Begins | +- | initialization | +- | | | +- | /|\ | +- | _________ __/ | \__________ | +- | /DHCPREQU EST | DHCPREQUEST\ | +- |/ | \| +- | | | +- Locates | Locates +- configuration | configuration +- | | | +- |\ | /| +- | \ | ___________/ | +- | \ | / DHCPACK | +- | \ _______ |/ | +- | DHCPACK\ | | +- | Initialization | +- | complete | +- | \| | +- | | | +- | (Subsequent | +- | DHCPACKS | +- | ignored) | +- | | | +- | | | +- v v v +- +- Figure 4: Timeline diagram of messages exchanged between DHCP +- client and servers when reusing a previously allocated +- network address +- +- +- +-Droms Standards Track [Page 18] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- If the client's request is invalid (e.g., the client has moved +- to a new subnet), servers SHOULD respond with a DHCPNAK message to +- the client. Servers SHOULD NOT respond if their information is not +- guaranteed to be accurate. For example, a server that identifies a +- request for an expired binding that is owned by another server SHOULD +- NOT respond with a DHCPNAK unless the servers are using an explicit +- mechanism to maintain coherency among the servers. +- +- If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on +- the same subnet as the server. The server MUST +- broadcast the DHCPNAK message to the 0xffffffff broadcast address +- because the client may not have a correct network address or subnet +- mask, and the client may not be answering ARP requests. +- Otherwise, the server MUST send the DHCPNAK message to the IP +- address of the BOOTP relay agent, as recorded in 'giaddr'. The +- relay agent will, in turn, forward the message directly to the +- client's hardware address, so that the DHCPNAK can be delivered even +- if the client has moved to a new network. +- +- 3. The client receives the DHCPACK message with configuration +- parameters. The client performs a final check on the parameters +- (as in section 3.1), and notes the duration of the lease specified +- in the DHCPACK message. The specific lease is implicitly identified +- by the 'client identifier' or 'chaddr' and the network address. At +- this point, the client is configured. +- +- If the client detects that the IP address in the DHCPACK message +- is already in use, the client MUST send a DHCPDECLINE message to the +- server and restarts the configuration process by requesting a +- new network address. This action corresponds to the client +- moving to the INIT state in the DHCP state diagram, which is +- described in section 4.4. +- +- If the client receives a DHCPNAK message, it cannot reuse its +- remembered network address. It must instead request a new +- address by restarting the configuration process, this time +- using the (non-abbreviated) procedure described in section +- 3.1. This action also corresponds to the client moving to +- the INIT state in the DHCP state diagram. +- +- The client times out and retransmits the DHCPREQUEST message if +- the client receives neither a DHCPACK nor a DHCPNAK message. The +- client retransmits the DHCPREQUEST according to the retransmission +- algorithm in section 4.1. The client should choose to retransmit +- the DHCPREQUEST enough times to give adequate probability of +- contacting the server without causing the client (and the user of +- that client) to wait overly long before giving up; e.g., a client +- retransmitting as described in section 4.1 might retransmit the +- +- +- +-Droms Standards Track [Page 19] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- DHCPREQUEST message four times, for a total delay of 60 seconds, +- before restarting the initialization procedure. If the client +- receives neither a DHCPACK or a DHCPNAK message after employing +- the retransmission algorithm, the client MAY choose to use the +- previously allocated network address and configuration parameters +- for the remainder of the unexpired lease. This corresponds to +- moving to BOUND state in the client state transition diagram shown +- in figure 5. +- +- 4. The client may choose to relinquish its lease on a network +- address by sending a DHCPRELEASE message to the server. The +- client identifies the lease to be released with its +- 'client identifier', or 'chaddr' and network address in the +- DHCPRELEASE message. +- +- Note that in this case, where the client retains its network +- address locally, the client will not normally relinquish its +- lease during a graceful shutdown. Only in the case where the +- client explicitly needs to relinquish its lease, e.g., the client +- is about to be moved to a different subnet, will the client send +- a DHCPRELEASE message. +- +-3.3 Interpretation and representation of time values +- +- A client acquires a lease for a network address for a fixed period of +- time (which may be infinite). Throughout the protocol, times are to +- be represented in units of seconds. The time value of 0xffffffff is +- reserved to represent "infinity". +- +- As clients and servers may not have synchronized clocks, times are +- represented in DHCP messages as relative times, to be interpreted +- with respect to the client's local clock. Representing relative +- times in units of seconds in an unsigned 32 bit word gives a range of +- relative times from 0 to approximately 100 years, which is sufficient +- for the relative times to be measured using DHCP. +- +- The algorithm for lease duration interpretation given in the previous +- paragraph assumes that client and server clocks are stable relative +- to each other. If there is drift between the two clocks, the server +- may consider the lease expired before the client does. To +- compensate, the server may return a shorter lease duration to the +- client than the server commits to its local database of client +- information. +- +-3.4 Obtaining parameters with externally configured network address +- +- If a client has obtained a network address through some other means +- (e.g., manual configuration), it may use a DHCPINFORM request message +- +- +- +-Droms Standards Track [Page 20] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- to obtain other local configuration parameters. Servers receiving a +- DHCPINFORM message construct a DHCPACK message with any local +- configuration parameters appropriate for the client without: +- allocating a new address, checking for an existing binding, filling +- in 'yiaddr' or including lease time parameters. The servers SHOULD +- unicast the DHCPACK reply to the address given in the 'ciaddr' field +- of the DHCPINFORM message. +- +- The server SHOULD check the network address in a DHCPINFORM message +- for consistency, but MUST NOT check for an existing lease. The +- server forms a DHCPACK message containing the configuration +- parameters for the requesting client and sends the DHCPACK message +- directly to the client. +- +-3.5 Client parameters in DHCP +- +- Not all clients require initialization of all parameters listed in +- Appendix A. Two techniques are used to reduce the number of +- parameters transmitted from the server to the client. First, most of +- the parameters have defaults defined in the Host Requirements RFCs; +- if the client receives no parameters from the server that override +- the defaults, a client uses those default values. Second, in its +- initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the +- server with a list of specific parameters the client is interested +- in. If the client includes a list of parameters in a DHCPDISCOVER +- message, it MUST include that list in any subsequent DHCPREQUEST +- messages. +- +- The client SHOULD include the 'maximum DHCP message size' option to +- let the server know how large the server may make its DHCP messages. +- The parameters returned to a client may still exceed the space +- allocated to options in a DHCP message. In this case, two additional +- options flags (which must appear in the 'options' field of the +- message) indicate that the 'file' and 'sname' fields are to be used +- for options. +- +- The client can inform the server which configuration parameters the +- client is interested in by including the 'parameter request list' +- option. The data portion of this option explicitly lists the options +- requested by tag number. +- +- In addition, the client may suggest values for the network address +- and lease time in the DHCPDISCOVER message. The client may include +- the 'requested IP address' option to suggest that a particular IP +- address be assigned, and may include the 'IP address lease time' +- option to suggest the lease time it would like. Other options +- representing "hints" at configuration parameters are allowed in a +- DHCPDISCOVER or DHCPREQUEST message. However, additional options may +- +- +- +-Droms Standards Track [Page 21] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- be ignored by servers, and multiple servers may, therefore, not +- return identical values for some options. The 'requested IP address' +- option is to be filled in only in a DHCPREQUEST message when the +- client is verifying network parameters obtained previously. The +- client fills in the 'ciaddr' field only when correctly configured +- with an IP address in BOUND, RENEWING or REBINDING state. +- +- If a server receives a DHCPREQUEST message with an invalid 'requested +- IP address', the server SHOULD respond to the client with a DHCPNAK +- message and may choose to report the problem to the system +- administrator. The server may include an error message in the +- 'message' option. +- +-3.6 Use of DHCP in clients with multiple interfaces +- +- A client with multiple network interfaces must use DHCP through each +- interface independently to obtain configuration information +- parameters for those separate interfaces. +- +-3.7 When clients should use DHCP +- +- A client SHOULD use DHCP to reacquire or verify its IP address and +- network parameters whenever the local network parameters may have +- changed; e.g., at system boot time or after a disconnection from the +- local network, as the local network configuration may change without +- the client's or user's knowledge. +- +- If a client has knowledge of a previous network address and is unable +- to contact a local DHCP server, the client may continue to use the +- previous network address until the lease for that address expires. +- If the lease expires before the client can contact a DHCP server, the +- client must immediately discontinue use of the previous network +- address and may inform local users of the problem. +- +-4. Specification of the DHCP client-server protocol +- +- In this section, we assume that a DHCP server has a block of network +- addresses from which it can satisfy requests for new addresses. Each +- server also maintains a database of allocated addresses and leases in +- local permanent storage. +- +-4.1 Constructing and sending DHCP messages +- +- DHCP clients and servers both construct DHCP messages by filling in +- fields in the fixed format section of the message and appending +- tagged data items in the variable length option area. The options +- area includes first a four-octet 'magic cookie' (which was described +- in section 3), followed by the options. The last option must always +- +- +- +-Droms Standards Track [Page 22] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- be the 'end' option. +- +- DHCP uses UDP as its transport protocol. DHCP messages from a client +- to a server are sent to the 'DHCP server' port (67), and DHCP +- messages from a server to a client are sent to the 'DHCP client' port +- (68). A server with multiple network address (e.g., a multi-homed +- host) MAY use any of its network addresses in outgoing DHCP messages. +- +- The 'server identifier' field is used both to identify a DHCP server +- in a DHCP message and as a destination address from clients to +- servers. A server with multiple network addresses MUST be prepared +- to to accept any of its network addresses as identifying that server +- in a DHCP message. To accommodate potentially incomplete network +- connectivity, a server MUST choose an address as a 'server +- identifier' that, to the best of the server's knowledge, is reachable +- from the client. For example, if the DHCP server and the DHCP client +- are connected to the same subnet (i.e., the 'giaddr' field in the +- message from the client is zero), the server SHOULD select the IP +- address the server is using for communication on that subnet as the +- 'server identifier'. If the server is using multiple IP addresses on +- that subnet, any such address may be used. If the server has +- received a message through a DHCP relay agent, the server SHOULD +- choose an address from the interface on which the message was +- recieved as the 'server identifier' (unless the server has other, +- better information on which to make its choice). DHCP clients MUST +- use the IP address provided in the 'server identifier' option for any +- unicast requests to the DHCP server. +- +- DHCP messages broadcast by a client prior to that client obtaining +- its IP address must have the source address field in the IP header +- set to 0. +- +- If the 'giaddr' field in a DHCP message from a client is non-zero, +- the server sends any return messages to the 'DHCP server' port on the +- BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr' +- field is zero and the 'ciaddr' field is nonzero, then the server +- unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'. +- If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is +- set, then the server broadcasts DHCPOFFER and DHCPACK messages to +- 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and +- 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK +- messages to the client's hardware address and 'yiaddr' address. In +- all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK +- messages to 0xffffffff. +- +- If the options in a DHCP message extend into the 'sname' and 'file' +- fields, the 'option overload' option MUST appear in the 'options' +- field, with value 1, 2 or 3, as specified in RFC 1533. If the +- +- +- +-Droms Standards Track [Page 23] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- 'option overload' option is present in the 'options' field, the +- options in the 'options' field MUST be terminated by an 'end' option, +- and MAY contain one or more 'pad' options to fill the options field. +- The options in the 'sname' and 'file' fields (if in use as indicated +- by the 'options overload' option) MUST begin with the first octet of +- the field, MUST be terminated by an 'end' option, and MUST be +- followed by 'pad' options to fill the remainder of the field. Any +- individual option in the 'options', 'sname' and 'file' fields MUST be +- entirely contained in that field. The options in the 'options' field +- MUST be interpreted first, so that any 'option overload' options may +- be interpreted. The 'file' field MUST be interpreted next (if the +- 'option overload' option indicates that the 'file' field contains +- DHCP options), followed by the 'sname' field. +- +- The values to be passed in an 'option' tag may be too long to fit in +- the 255 octets available to a single option (e.g., a list of routers +- in a 'router' option [21]). Options may appear only once, unless +- otherwise specified in the options document. The client concatenates +- the values of multiple instances of the same option into a single +- parameter list for configuration. +- +- DHCP clients are responsible for all message retransmission. The +- client MUST adopt a retransmission strategy that incorporates a +- randomized exponential backoff algorithm to determine the delay +- between retransmissions. The delay between retransmissions SHOULD be +- chosen to allow sufficient time for replies from the server to be +- delivered based on the characteristics of the internetwork between +- the client and the server. For example, in a 10Mb/sec Ethernet +- internetwork, the delay before the first retransmission SHOULD be 4 +- seconds randomized by the value of a uniform random number chosen +- from the range -1 to +1. Clients with clocks that provide resolution +- granularity of less than one second may choose a non-integer +- randomization value. The delay before the next retransmission SHOULD +- be 8 seconds randomized by the value of a uniform number chosen from +- the range -1 to +1. The retransmission delay SHOULD be doubled with +- subsequent retransmissions up to a maximum of 64 seconds. The client +- MAY provide an indication of retransmission attempts to the user as +- an indication of the progress of the configuration process. +- +- The 'xid' field is used by the client to match incoming DHCP messages +- with pending requests. A DHCP client MUST choose 'xid's in such a +- way as to minimize the chance of using an 'xid' identical to one used +- by another client. For example, a client may choose a different, +- random initial 'xid' each time the client is rebooted, and +- subsequently use sequential 'xid's until the next reboot. Selecting +- a new 'xid' for each retransmission is an implementation decision. A +- client may choose to reuse the same 'xid' or select a new 'xid' for +- each retransmitted message. +- +- +- +-Droms Standards Track [Page 24] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- Normally, DHCP servers and BOOTP relay agents attempt to deliver +- DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using +- uicast delivery. The IP destination address (in the IP header) is +- set to the DHCP 'yiaddr' address and the link-layer destination +- address is set to the DHCP 'chaddr' address. Unfortunately, some +- client implementations are unable to receive such unicast IP +- datagrams until the implementation has been configured with a valid +- IP address (leading to a deadlock in which the client's IP address +- cannot be delivered until the client has been configured with an IP +- address). +- +- A client that cannot receive unicast IP datagrams until its protocol +- software has been configured with an IP address SHOULD set the +- BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or +- DHCPREQUEST messages that client sends. The BROADCAST bit will +- provide a hint to the DHCP server and BOOTP relay agent to broadcast +- any messages to the client on the client's subnet. A client that can +- receive unicast IP datagrams before its protocol software has been +- configured SHOULD clear the BROADCAST bit to 0. The BOOTP +- clarifications document discusses the ramifications of the use of the +- BROADCAST bit [21]. +- +- A server or relay agent sending or relaying a DHCP message directly +- to a DHCP client (i.e., not to a relay agent specified in the +- 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags' +- field. If this bit is set to 1, the DHCP message SHOULD be sent as +- an IP broadcast using an IP broadcast address (preferably 0xffffffff) +- as the IP destination address and the link-layer broadcast address as +- the link-layer destination address. If the BROADCAST bit is cleared +- to 0, the message SHOULD be sent as an IP unicast to the IP address +- specified in the 'yiaddr' field and the link-layer address specified +- in the 'chaddr' field. If unicasting is not possible, the message +- MAY be sent as an IP broadcast using an IP broadcast address +- (preferably 0xffffffff) as the IP destination address and the link- +- layer broadcast address as the link-layer destination address. +- +-4.2 DHCP server administrative controls +- +- DHCP servers are not required to respond to every DHCPDISCOVER and +- DHCPREQUEST message they receive. For example, a network +- administrator, to retain stringent control over the clients attached +- to the network, may choose to configure DHCP servers to respond only +- to clients that have been previously registered through some external +- mechanism. The DHCP specification describes only the interactions +- between clients and servers when the clients and servers choose to +- interact; it is beyond the scope of the DHCP specification to +- describe all of the administrative controls that system +- administrators might want to use. Specific DHCP server +- +- +- +-Droms Standards Track [Page 25] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- implementations may incorporate any controls or policies desired by a +- network administrator. +- +- In some environments, a DHCP server will have to consider the values +- of the vendor class options included in DHCPDISCOVER or DHCPREQUEST +- messages when determining the correct parameters for a particular +- client. +- +- A DHCP server needs to use some unique identifier to associate a +- client with its lease. The client MAY choose to explicitly provide +- the identifier through the 'client identifier' option. If the client +- supplies a 'client identifier', the client MUST use the same 'client +- identifier' in all subsequent messages, and the server MUST use that +- identifier to identify the client. If the client does not provide a +- 'client identifier' option, the server MUST use the contents of the +- 'chaddr' field to identify the client. It is crucial for a DHCP +- client to use an identifier unique within the subnet to which the +- client is attached in the 'client identifier' option. Use of +- 'chaddr' as the client's unique identifier may cause unexpected +- results, as that identifier may be associated with a hardware +- interface that could be moved to a new client. Some sites may choose +- to use a manufacturer's serial number as the 'client identifier', to +- avoid unexpected changes in a clients network address due to transfer +- of hardware interfaces among computers. Sites may also choose to use +- a DNS name as the 'client identifier', causing address leases to be +- associated with the DNS name rather than a specific hardware box. +- +- DHCP clients are free to use any strategy in selecting a DHCP server +- among those from which the client receives a DHCPOFFER message. The +- client implementation of DHCP SHOULD provide a mechanism for the user +- to select directly the 'vendor class identifier' values. +- +-4.3 DHCP server behavior +- +- A DHCP server processes incoming DHCP messages from a client based on +- the current state of the binding for that client. A DHCP server can +- receive the following messages from a client: +- +- o DHCPDISCOVER +- +- o DHCPREQUEST +- +- o DHCPDECLINE +- +- o DHCPRELEASE +- +- o DHCPINFORM +- +- +- +- +-Droms Standards Track [Page 26] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- Table 3 gives the use of the fields and options in a DHCP message by +- a server. The remainder of this section describes the action of the +- DHCP server for each possible incoming message. +- +-4.3.1 DHCPDISCOVER message +- +- When a server receives a DHCPDISCOVER message from a client, the +- server chooses a network address for the requesting client. If no +- address is available, the server may choose to report the problem to +- the system administrator. If an address is available, the new address +- SHOULD be chosen as follows: +- +- o The client's current address as recorded in the client's current +- binding, ELSE +- +- o The client's previous address as recorded in the client's (now +- expired or released) binding, if that address is in the server's +- pool of available addresses and not already allocated, ELSE +- +- o The address requested in the 'Requested IP Address' option, if that +- address is valid and not already allocated, ELSE +- +- o A new address allocated from the server's pool of available +- addresses; the address is selected based on the subnet from which +- the message was received (if 'giaddr' is 0) or on the address of +- the relay agent that forwarded the message ('giaddr' when not 0). +- +- As described in section 4.2, a server MAY, for administrative +- reasons, assign an address other than the one requested, or may +- refuse to allocate an address to a particular client even though free +- addresses are available. +- +- Note that, in some network architectures (e.g., internets with more +- than one IP subnet assigned to a physical network segment), it may be +- the case that the DHCP client should be assigned an address from a +- different subnet than the address recorded in 'giaddr'. Thus, DHCP +- does not require that the client be assigned as address from the +- subnet in 'giaddr'. A server is free to choose some other subnet, +- and it is beyond the scope of the DHCP specification to describe ways +- in which the assigned IP address might be chosen. +- +- While not required for correct operation of DHCP, the server SHOULD +- NOT reuse the selected network address before the client responds to +- the server's DHCPOFFER message. The server may choose to record the +- address as offered to the client. +- +- The server must also choose an expiration time for the lease, as +- follows: +- +- +- +-Droms Standards Track [Page 27] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- o IF the client has not requested a specific lease in the +- DHCPDISCOVER message and the client already has an assigned network +- address, the server returns the lease expiration time previously +- assigned to that address (note that the client must explicitly +- request a specific lease to extend the expiration time on a +- previously assigned address), ELSE +- +- o IF the client has not requested a specific lease in the +- DHCPDISCOVER message and the client does not have an assigned +- network address, the server assigns a locally configured default +- lease time, ELSE +- +- o IF the client has requested a specific lease in the DHCPDISCOVER +- message (regardless of whether the client has an assigned network +- address), the server may choose either to return the requested +- lease (if the lease is acceptable to local policy) or select +- another lease. +- +-Field DHCPOFFER DHCPACK DHCPNAK +------ --------- ------- ------- +-'op' BOOTREPLY BOOTREPLY BOOTREPLY +-'htype' (From "Assigned Numbers" RFC) +-'hlen' (Hardware address length in octets) +-'hops' 0 0 0 +-'xid' 'xid' from client 'xid' from client 'xid' from client +- DHCPDISCOVER DHCPREQUEST DHCPREQUEST +- message message message +-'secs' 0 0 0 +-'ciaddr' 0 'ciaddr' from 0 +- DHCPREQUEST or 0 +-'yiaddr' IP address offered IP address 0 +- to client assigned to client +-'siaddr' IP address of next IP address of next 0 +- bootstrap server bootstrap server +-'flags' 'flags' from 'flags' from 'flags' from +- client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST +- message message message +-'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from +- client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST +- message message message +-'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from +- client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST +- message message message +-'sname' Server host name Server host name (unused) +- or options or options +-'file' Client boot file Client boot file (unused) +- name or options name or options +-'options' options options +- +- +- +-Droms Standards Track [Page 28] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +-Option DHCPOFFER DHCPACK DHCPNAK +------- --------- ------- ------- +-Requested IP address MUST NOT MUST NOT MUST NOT +-IP address lease time MUST MUST (DHCPREQUEST) MUST NOT +- MUST NOT (DHCPINFORM) +-Use 'file'/'sname' fields MAY MAY MUST NOT +-DHCP message type DHCPOFFER DHCPACK DHCPNAK +-Parameter request list MUST NOT MUST NOT MUST NOT +-Message SHOULD SHOULD SHOULD +-Client identifier MUST NOT MUST NOT MAY +-Vendor class identifier MAY MAY MAY +-Server identifier MUST MUST MUST +-Maximum message size MUST NOT MUST NOT MUST NOT +-All others MAY MAY MUST NOT +- +- Table 3: Fields and options used by DHCP servers +- +- Once the network address and lease have been determined, the server +- constructs a DHCPOFFER message with the offered configuration +- parameters. It is important for all DHCP servers to return the same +- parameters (with the possible exception of a newly allocated network +- address) to ensure predictable client behavior regardless of which +- server the client selects. The configuration parameters MUST be +- selected by applying the following rules in the order given below. +- The network administrator is responsible for configuring multiple +- DHCP servers to ensure uniform responses from those servers. The +- server MUST return to the client: +- +- o The client's network address, as determined by the rules given +- earlier in this section, +- +- o The expiration time for the client's lease, as determined by the +- rules given earlier in this section, +- +- o Parameters requested by the client, according to the following +- rules: +- +- -- IF the server has been explicitly configured with a default +- value for the parameter, the server MUST include that value +- in an appropriate option in the 'option' field, ELSE +- +- -- IF the server recognizes the parameter as a parameter +- defined in the Host Requirements Document, the server MUST +- include the default value for that parameter as given in the +- Host Requirements Document in an appropriate option in the +- 'option' field, ELSE +- +- -- The server MUST NOT return a value for that parameter, +- +- +- +-Droms Standards Track [Page 29] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- The server MUST supply as many of the requested parameters as +- possible and MUST omit any parameters it cannot provide. The +- server MUST include each requested parameter only once unless +- explicitly allowed in the DHCP Options and BOOTP Vendor +- Extensions document. +- +- o Any parameters from the existing binding that differ from the Host +- Requirements Document defaults, +- +- o Any parameters specific to this client (as identified by +- the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER +- or DHCPREQUEST message), e.g., as configured by the network +- administrator, +- +- o Any parameters specific to this client's class (as identified +- by the contents of the 'vendor class identifier' +- option in the DHCPDISCOVER or DHCPREQUEST message), +- e.g., as configured by the network administrator; the parameters +- MUST be identified by an exact match between the client's vendor +- class identifiers and the client's classes identified in the +- server, +- +- o Parameters with non-default values on the client's subnet. +- +- The server MAY choose to return the 'vendor class identifier' used to +- determine the parameters in the DHCPOFFER message to assist the +- client in selecting which DHCPOFFER to accept. The server inserts +- the 'xid' field from the DHCPDISCOVER message into the 'xid' field of +- the DHCPOFFER message and sends the DHCPOFFER message to the +- requesting client. +- +-4.3.2 DHCPREQUEST message +- +- A DHCPREQUEST message may come from a client responding to a +- DHCPOFFER message from a server, from a client verifying a previously +- allocated IP address or from a client extending the lease on a +- network address. If the DHCPREQUEST message contains a 'server +- identifier' option, the message is in response to a DHCPOFFER +- message. Otherwise, the message is a request to verify or extend an +- existing lease. If the client uses a 'client identifier' in a +- DHCPREQUEST message, it MUST use that same 'client identifier' in all +- subsequent messages. If the client included a list of requested +- parameters in a DHCPDISCOVER message, it MUST include that list in +- all subsequent messages. +- +- +- +- +- +- +- +-Droms Standards Track [Page 30] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- Any configuration parameters in the DHCPACK message SHOULD NOT +- conflict with those in the earlier DHCPOFFER message to which the +- client is responding. The client SHOULD use the parameters in the +- DHCPACK message for configuration. +- +- Clients send DHCPREQUEST messages as follows: +- +- o DHCPREQUEST generated during SELECTING state: +- +- Client inserts the address of the selected server in 'server +- identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be +- filled in with the yiaddr value from the chosen DHCPOFFER. +- +- Note that the client may choose to collect several DHCPOFFER +- messages and select the "best" offer. The client indicates its +- selection by identifying the offering server in the DHCPREQUEST +- message. If the client receives no acceptable offers, the client +- may choose to try another DHCPDISCOVER message. Therefore, the +- servers may not receive a specific DHCPREQUEST from which they can +- decide whether or not the client has accepted the offer. Because +- the servers have not committed any network address assignments on +- the basis of a DHCPOFFER, servers are free to reuse offered +- network addresses in response to subsequent requests. As an +- implementation detail, servers SHOULD NOT reuse offered addresses +- and may use an implementation-specific timeout mechanism to decide +- when to reuse an offered address. +- +- o DHCPREQUEST generated during INIT-REBOOT state: +- +- 'server identifier' MUST NOT be filled in, 'requested IP address' +- option MUST be filled in with client's notion of its previously +- assigned address. 'ciaddr' MUST be zero. The client is seeking to +- verify a previously allocated, cached configuration. Server SHOULD +- send a DHCPNAK message to the client if the 'requested IP address' +- is incorrect, or is on the wrong network. +- +- Determining whether a client in the INIT-REBOOT state is on the +- correct network is done by examining the contents of 'giaddr', the +- 'requested IP address' option, and a database lookup. If the DHCP +- server detects that the client is on the wrong net (i.e., the +- result of applying the local subnet mask or remote subnet mask (if +- 'giaddr' is not zero) to 'requested IP address' option value +- doesn't match reality), then the server SHOULD send a DHCPNAK +- message to the client. +- +- +- +- +- +- +- +-Droms Standards Track [Page 31] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- If the network is correct, then the DHCP server should check if +- the client's notion of its IP address is correct. If not, then the +- server SHOULD send a DHCPNAK message to the client. If the DHCP +- server has no record of this client, then it MUST remain silent, +- and MAY output a warning to the network administrator. This +- behavior is necessary for peaceful coexistence of non- +- communicating DHCP servers on the same wire. +- +- If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on +- the same subnet as the server. The server MUST broadcast the +- DHCPNAK message to the 0xffffffff broadcast address because the +- client may not have a correct network address or subnet mask, and +- the client may not be answering ARP requests. +- +- If 'giaddr' is set in the DHCPREQUEST message, the client is on a +- different subnet. The server MUST set the broadcast bit in the +- DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the +- client, because the client may not have a correct network address +- or subnet mask, and the client may not be answering ARP requests. +- +- o DHCPREQUEST generated during RENEWING state: +- +- 'server identifier' MUST NOT be filled in, 'requested IP address' +- option MUST NOT be filled in, 'ciaddr' MUST be filled in with +- client's IP address. In this situation, the client is completely +- configured, and is trying to extend its lease. This message will +- be unicast, so no relay agents will be involved in its +- transmission. Because 'giaddr' is therefore not filled in, the +- DHCP server will trust the value in 'ciaddr', and use it when +- replying to the client. +- +- A client MAY choose to renew or extend its lease prior to T1. The +- server may choose not to extend the lease (as a policy decision by +- the network administrator), but should return a DHCPACK message +- regardless. +- +- o DHCPREQUEST generated during REBINDING state: +- +- 'server identifier' MUST NOT be filled in, 'requested IP address' +- option MUST NOT be filled in, 'ciaddr' MUST be filled in with +- client's IP address. In this situation, the client is completely +- configured, and is trying to extend its lease. This message MUST +- be broadcast to the 0xffffffff IP broadcast address. The DHCP +- server SHOULD check 'ciaddr' for correctness before replying to +- the DHCPREQUEST. +- +- +- +- +- +- +-Droms Standards Track [Page 32] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- The DHCPREQUEST from a REBINDING client is intended to accommodate +- sites that have multiple DHCP servers and a mechanism for +- maintaining consistency among leases managed by multiple servers. +- A DHCP server MAY extend a client's lease only if it has local +- administrative authority to do so. +- +-4.3.3 DHCPDECLINE message +- +- If the server receives a DHCPDECLINE message, the client has +- discovered through some other means that the suggested network +- address is already in use. The server MUST mark the network address +- as not available and SHOULD notify the local system administrator of +- a possible configuration problem. +- +-4.3.4 DHCPRELEASE message +- +- Upon receipt of a DHCPRELEASE message, the server marks the network +- address as not allocated. The server SHOULD retain a record of the +- client's initialization parameters for possible reuse in response to +- subsequent requests from the client. +- +-4.3.5 DHCPINFORM message +- +- The server responds to a DHCPINFORM message by sending a DHCPACK +- message directly to the address given in the 'ciaddr' field of the +- DHCPINFORM message. The server MUST NOT send a lease expiration time +- to the client and SHOULD NOT fill in 'yiaddr'. The server includes +- other parameters in the DHCPACK message as defined in section 4.3.1. +- +-4.3.6 Client messages +- +- Table 4 details the differences between messages from clients in +- various states. +- +- --------------------------------------------------------------------- +- | |INIT-REBOOT |SELECTING |RENEWING |REBINDING | +- --------------------------------------------------------------------- +- |broad/unicast |broadcast |broadcast |unicast |broadcast | +- |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT | +- |requested-ip |MUST |MUST |MUST NOT |MUST NOT | +- |ciaddr |zero |zero |IP address |IP address| +- --------------------------------------------------------------------- +- +- Table 4: Client messages from different states +- +- +- +- +- +- +- +-Droms Standards Track [Page 33] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +-4.4 DHCP client behavior +- +- Figure 5 gives a state-transition diagram for a DHCP client. A +- client can receive the following messages from a server: +- +- o DHCPOFFER +- +- o DHCPACK +- +- o DHCPNAK +- +- The DHCPINFORM message is not shown in figure 5. A client simply +- sends the DHCPINFORM and waits for DHCPACK messages. Once the client +- has selected its parameters, it has completed the configuration +- process. +- +- Table 5 gives the use of the fields and options in a DHCP message by +- a client. The remainder of this section describes the action of the +- DHCP client for each possible incoming message. The description in +- the following section corresponds to the full configuration procedure +- previously described in section 3.1, and the text in the subsequent +- section corresponds to the abbreviated configuration procedure +- described in section 3.2. +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +-Droms Standards Track [Page 34] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- -------- ------- +-| | +-------------------------->| |<-------------------+ +-| INIT- | | +-------------------->| INIT | | +-| REBOOT |DHCPNAK/ +---------->| |<---+ | +-| |Restart| | ------- | | +- -------- | DHCPNAK/ | | | +- | Discard offer | -/Send DHCPDISCOVER | +--/Send DHCPREQUEST | | | +- | | | DHCPACK v | | +- ----------- | (not accept.)/ ----------- | | +-| | | Send DHCPDECLINE | | | +-| REBOOTING | | | | SELECTING |<----+ | +-| | | / | | |DHCPOFFER/ | +- ----------- | / ----------- | |Collect | +- | | / | | | replies | +-DHCPACK/ | / +----------------+ +-------+ | +-Record lease, set| | v Select offer/ | +-timers T1, T2 ------------ send DHCPREQUEST | | +- | +----->| | DHCPNAK, Lease expired/ | +- | | | REQUESTING | Halt network | +- DHCPOFFER/ | | | | +- Discard ------------ | | +- | | | | ----------- | +- | +--------+ DHCPACK/ | | | +- | Record lease, set -----| REBINDING | | +- | timers T1, T2 / | | | +- | | DHCPACK/ ----------- | +- | v Record lease, set ^ | +- +----------------> ------- /timers T1,T2 | | +- +----->| |<---+ | | +- | | BOUND |<---+ | | +- DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/ +- DHCPNAK/Discard ------- | Broadcast Halt network +- | | | | DHCPREQUEST | +- +-------+ | DHCPACK/ | | +- T1 expires/ Record lease, set | | +- Send DHCPREQUEST timers T1, T2 | | +- to leasing server | | | +- | ---------- | | +- | | |------------+ | +- +->| RENEWING | | +- | |----------------------------+ +- ---------- +- Figure 5: State-transition diagram for DHCP clients +- +- +- +- +- +- +- +-Droms Standards Track [Page 35] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +-4.4.1 Initialization and allocation of network address +- +- The client begins in INIT state and forms a DHCPDISCOVER message. +- The client SHOULD wait a random time between one and ten seconds to +- desynchronize the use of DHCP at startup. The client sets 'ciaddr' +- to 0x00000000. The client MAY request specific parameters by +- including the 'parameter request list' option. The client MAY +- suggest a network address and/or lease time by including the +- 'requested IP address' and 'IP address lease time' options. The +- client MUST include its hardware address in the 'chaddr' field, if +- necessary for delivery of DHCP reply messages. The client MAY +- include a different unique identifier in the 'client identifier' +- option, as discussed in section 4.2. If the client included a list +- of requested parameters in a DHCPDISCOVER message, it MUST include +- that list in all subsequent messages. +- +- The client generates and records a random transaction identifier and +- inserts that identifier into the 'xid' field. The client records its +- own local time for later use in computing the lease expiration. The +- client then broadcasts the DHCPDISCOVER on the local hardware +- broadcast address to the 0xffffffff IP broadcast address and 'DHCP +- server' UDP port. +- +- If the 'xid' of an arriving DHCPOFFER message does not match the +- 'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message +- must be silently discarded. Any arriving DHCPACK messages must be +- silently discarded. +- +- The client collects DHCPOFFER messages over a period of time, selects +- one DHCPOFFER message from the (possibly many) incoming DHCPOFFER +- messages (e.g., the first DHCPOFFER message or the DHCPOFFER message +- from the previously used server) and extracts the server address from +- the 'server identifier' option in the DHCPOFFER message. The time +- over which the client collects messages and the mechanism used to +- select one DHCPOFFER are implementation dependent. +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +-Droms Standards Track [Page 36] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +-Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE, +- DHCPINFORM DHCPRELEASE +------ ------------ ----------- ----------- +-'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST +-'htype' (From "Assigned Numbers" RFC) +-'hlen' (Hardware address length in octets) +-'hops' 0 0 0 +-'xid' selected by client 'xid' from server selected by +- DHCPOFFER message client +-'secs' 0 or seconds since 0 or seconds since 0 +- DHCP process started DHCP process started +-'flags' Set 'BROADCAST' Set 'BROADCAST' 0 +- flag if client flag if client +- requires broadcast requires broadcast +- reply reply +-'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE) +- client's network address client's network +- network address (BOUND/RENEW/REBIND) address +- (DHCPINFORM) (DHCPRELEASE) +-'yiaddr' 0 0 0 +-'siaddr' 0 0 0 +-'giaddr' 0 0 0 +-'chaddr' client's hardware client's hardware client's hardware +- address address address +-'sname' options, if options, if (unused) +- indicated in indicated in +- 'sname/file' 'sname/file' +- option; otherwise option; otherwise +- unused unused +-'file' options, if options, if (unused) +- indicated in indicated in +- 'sname/file' 'sname/file' +- option; otherwise option; otherwise +- unused unused +-'options' options options (unused) +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +-Droms Standards Track [Page 37] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +-Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE, +- DHCPINFORM DHCPRELEASE +------- ------------ ----------- ----------- +-Requested IP address MAY MUST (in MUST +- (DISCOVER) SELECTING or (DHCPDECLINE), +- MUST NOT INIT-REBOOT) MUST NOT +- (INFORM) MUST NOT (in (DHCPRELEASE) +- BOUND or +- RENEWING) +-IP address lease time MAY MAY MUST NOT +- (DISCOVER) +- MUST NOT +- (INFORM) +-Use 'file'/'sname' fields MAY MAY MAY +-DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/ +- DHCPINFORM DHCPRELEASE +-Client identifier MAY MAY MAY +-Vendor class identifier MAY MAY MUST NOT +-Server identifier MUST NOT MUST (after MUST +- SELECTING) +- MUST NOT (after +- INIT-REBOOT, +- BOUND, RENEWING +- or REBINDING) +-Parameter request list MAY MAY MUST NOT +-Maximum message size MAY MAY MUST NOT +-Message SHOULD NOT SHOULD NOT SHOULD +-Site-specific MAY MAY MUST NOT +-All others MAY MAY MUST NOT +- +- Table 5: Fields and options used by DHCP clients +- +- If the parameters are acceptable, the client records the address of +- the server that supplied the parameters from the 'server identifier' +- field and sends that address in the 'server identifier' field of a +- DHCPREQUEST broadcast message. Once the DHCPACK message from the +- server arrives, the client is initialized and moves to BOUND state. +- The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER +- message. The client records the lease expiration time as the sum of +- the time at which the original request was sent and the duration of +- the lease from the DHCPACK message. The client SHOULD perform a +- check on the suggested address to ensure that the address is not +- already in use. For example, if the client is on a network that +- supports ARP, the client may issue an ARP request for the suggested +- request. When broadcasting an ARP request for the suggested address, +- the client must fill in its own hardware address as the sender's +- hardware address, and 0 as the sender's IP address, to avoid +- confusing ARP caches in other hosts on the same subnet. If the +- +- +- +-Droms Standards Track [Page 38] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- network address appears to be in use, the client MUST send a +- DHCPDECLINE message to the server. The client SHOULD broadcast an ARP +- reply to announce the client's new IP address and clear any outdated +- ARP cache entries in hosts on the client's subnet. +- +-4.4.2 Initialization with known network address +- +- The client begins in INIT-REBOOT state and sends a DHCPREQUEST +- message. The client MUST insert its known network address as a +- 'requested IP address' option in the DHCPREQUEST message. The client +- may request specific configuration parameters by including the +- 'parameter request list' option. The client generates and records a +- random transaction identifier and inserts that identifier into the +- 'xid' field. The client records its own local time for later use in +- computing the lease expiration. The client MUST NOT include a +- 'server identifier' in the DHCPREQUEST message. The client then +- broadcasts the DHCPREQUEST on the local hardware broadcast address to +- the 'DHCP server' UDP port. +- +- Once a DHCPACK message with an 'xid' field matching that in the +- client's DHCPREQUEST message arrives from any server, the client is +- initialized and moves to BOUND state. The client records the lease +- expiration time as the sum of the time at which the DHCPREQUEST +- message was sent and the duration of the lease from the DHCPACK +- message. +- +-4.4.3 Initialization with an externally assigned network address +- +- The client sends a DHCPINFORM message. The client may request +- specific configuration parameters by including the 'parameter request +- list' option. The client generates and records a random transaction +- identifier and inserts that identifier into the 'xid' field. The +- client places its own network address in the 'ciaddr' field. The +- client SHOULD NOT request lease time parameters. +- +- The client then unicasts the DHCPINFORM to the DHCP server if it +- knows the server's address, otherwise it broadcasts the message to +- the limited (all 1s) broadcast address. DHCPINFORM messages MUST be +- directed to the 'DHCP server' UDP port. +- +- Once a DHCPACK message with an 'xid' field matching that in the +- client's DHCPINFORM message arrives from any server, the client is +- initialized. +- +- If the client does not receive a DHCPACK within a reasonable period +- of time (60 seconds or 4 tries if using timeout suggested in section +- 4.1), then it SHOULD display a message informing the user of the +- problem, and then SHOULD begin network processing using suitable +- +- +- +-Droms Standards Track [Page 39] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- defaults as per Appendix A. +- +-4.4.4 Use of broadcast and unicast +- +- The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM +- messages, unless the client knows the address of a DHCP server. The +- client unicasts DHCPRELEASE messages to the server. Because the +- client is declining the use of the IP address supplied by the server, +- the client broadcasts DHCPDECLINE messages. +- +- When the DHCP client knows the address of a DHCP server, in either +- INIT or REBOOTING state, the client may use that address in the +- DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. +- The client may also use unicast to send DHCPINFORM messages to a +- known DHCP server. If the client receives no response to DHCP +- messages sent to the IP address of a known DHCP server, the DHCP +- client reverts to using the IP broadcast address. +- +-4.4.5 Reacquisition and expiration +- +- The client maintains two times, T1 and T2, that specify the times at +- which the client tries to extend its lease on its network address. +- T1 is the time at which the client enters the RENEWING state and +- attempts to contact the server that originally issued the client's +- network address. T2 is the time at which the client enters the +- REBINDING state and attempts to contact any server. T1 MUST be +- earlier than T2, which, in turn, MUST be earlier than the time at +- which the client's lease will expire. +- +- To avoid the need for synchronized clocks, T1 and T2 are expressed in +- options as relative times [2]. +- +- At time T1 the client moves to RENEWING state and sends (via unicast) +- a DHCPREQUEST message to the server to extend its lease. The client +- sets the 'ciaddr' field in the DHCPREQUEST to its current network +- address. The client records the local time at which the DHCPREQUEST +- message is sent for computation of the lease expiration time. The +- client MUST NOT include a 'server identifier' in the DHCPREQUEST +- message. +- +- Any DHCPACK messages that arrive with an 'xid' that does not match +- the 'xid' of the client's DHCPREQUEST message are silently discarded. +- When the client receives a DHCPACK from the server, the client +- computes the lease expiration time as the sum of the time at which +- the client sent the DHCPREQUEST message and the duration of the lease +- in the DHCPACK message. The client has successfully reacquired its +- network address, returns to BOUND state and may continue network +- processing. +- +- +- +-Droms Standards Track [Page 40] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- If no DHCPACK arrives before time T2, the client moves to REBINDING +- state and sends (via broadcast) a DHCPREQUEST message to extend its +- lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its +- current network address. The client MUST NOT include a 'server +- identifier' in the DHCPREQUEST message. +- +- Times T1 and T2 are configurable by the server through options. T1 +- defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * +- duration_of_lease). Times T1 and T2 SHOULD be chosen with some +- random "fuzz" around a fixed value, to avoid synchronization of +- client reacquisition. +- +- A client MAY choose to renew or extend its lease prior to T1. The +- server MAY choose to extend the client's lease according to policy +- set by the network administrator. The server SHOULD return T1 and +- T2, and their values SHOULD be adjusted from their original values to +- take account of the time remaining on the lease. +- +- In both RENEWING and REBINDING states, if the client receives no +- response to its DHCPREQUEST message, the client SHOULD wait one-half +- of the remaining time until T2 (in RENEWING state) and one-half of +- the remaining lease time (in REBINDING state), down to a minimum of +- 60 seconds, before retransmitting the DHCPREQUEST message. +- +- If the lease expires before the client receives a DHCPACK, the client +- moves to INIT state, MUST immediately stop any other network +- processing and requests network initialization parameters as if the +- client were uninitialized. If the client then receives a DHCPACK +- allocating that client its previous network address, the client +- SHOULD continue network processing. If the client is given a new +- network address, it MUST NOT continue using the previous network +- address and SHOULD notify the local users of the problem. +- +-4.4.6 DHCPRELEASE +- +- If the client no longer requires use of its assigned network address +- (e.g., the client is gracefully shut down), the client sends a +- DHCPRELEASE message to the server. Note that the correct operation +- of DHCP does not depend on the transmission of DHCPRELEASE messages. +- +- +- +- +- +- +- +- +- +- +- +- +-Droms Standards Track [Page 41] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +-5. Acknowledgments +- +- The author thanks the many (and too numerous to mention!) members of +- the DHC WG for their tireless and ongoing efforts in the development +- of DHCP and this document. +- +- The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John +- Mendonca in organizing DHCP interoperability testing sessions are +- gratefully acknowledged. +- +- The development of this document was supported in part by grants from +- the Corporation for National Research Initiatives (CNRI), Bucknell +- University and Sun Microsystems. +- +-6. References +- +- [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December +- 1983. +- +- [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor +- Extensions", RFC 1533, Lachman Technology, Inc., Bucknell +- University, October 1993. +- +- [3] Braden, R., Editor, "Requirements for Internet Hosts -- +- Communication Layers", STD 3, RFC 1122, USC/Information Sciences +- Institute, October 1989. +- +- [4] Braden, R., Editor, "Requirements for Internet Hosts -- +- Application and Support, STD 3, RFC 1123, USC/Information +- Sciences Institute, October 1989. +- +- [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol +- (DRARP)", Work in Progress. +- +- [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory +- Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer +- Communications Review), 20(4):50--59, 1990. +- +- [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, +- Stanford and SUN Microsystems, September 1985. +- +- [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox +- PARC, September 1991. +- +- [9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534, +- Bucknell University, October 1993. +- +- +- +- +- +-Droms Standards Track [Page 42] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse +- Address Resolution Protocol", RFC 903, Stanford, June 1984. +- +- [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant +- Mechanism for Distributed File Cache Consistency", In Proc. of +- the Twelfth ACM Symposium on Operating Systems Design, 1989. +- +- [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD +- 13, RFC 1034, USC/Information Sciences Institute, November 1987. +- +- [13] Mockapetris, P., "Domain Names -- Implementation and +- Specification", STD 13, RFC 1035, USC/Information Sciences +- Institute, November 1987. +- +- [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191, +- November 1990. +- +- [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached +- Hosts", Work in Progress. +- +- [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, +- USC/Information Sciences Institute, September 1981. +- +- [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, +- USC/Information Sciences Institute, August 1993. +- +- [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, +- USC/Information Sciences Institute, October 1994. +- +- [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic +- Assignment of IP Addresses for use on an Ethernet. (Available +- from the Athena Project, MIT), 1989. +- +- [20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, +- June 1981. +- +- [21] Wimer, W., "Clarifications and Extensions for the Bootstrap +- Protocol", RFC 1542, Carnegie Mellon University, October 1993. +- +-7. Security Considerations +- +- DHCP is built directly on UDP and IP which are as yet inherently +- insecure. Furthermore, DHCP is generally intended to make +- maintenance of remote and/or diskless hosts easier. While perhaps +- not impossible, configuring such hosts with passwords or keys may be +- difficult and inconvenient. Therefore, DHCP in its current form is +- quite insecure. +- +- +- +- +-Droms Standards Track [Page 43] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +- Unauthorized DHCP servers may be easily set up. Such servers can +- then send false and potentially disruptive information to clients +- such as incorrect or duplicate IP addresses, incorrect routing +- information (including spoof routers, etc.), incorrect domain +- nameserver addresses (such as spoof nameservers), and so on. +- Clearly, once this seed information is in place, an attacker can +- further compromise affected systems. +- +- Malicious DHCP clients could masquerade as legitimate clients and +- retrieve information intended for those legitimate clients. Where +- dynamic allocation of resources is used, a malicious client could +- claim all resources for itself, thereby denying resources to +- legitimate clients. +- +-8. Author's Address +- +- Ralph Droms +- Computer Science Department +- 323 Dana Engineering +- Bucknell University +- Lewisburg, PA 17837 +- +- Phone: (717) 524-1145 +- EMail: droms@bucknell.edu +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +-Droms Standards Track [Page 44] +- +-RFC 2131 Dynamic Host Configuration Protocol March 1997 +- +- +-A. Host Configuration Parameters +- +- IP-layer_parameters,_per_host:_ +- +- Be a router on/off HRC 3.1 +- Non-local source routing on/off HRC 3.3.5 +- Policy filters for +- non-local source routing (list) HRC 3.3.5 +- Maximum reassembly size integer HRC 3.3.2 +- Default TTL integer HRC 3.2.1.7 +- PMTU aging timeout integer MTU 6.6 +- MTU plateau table (list) MTU 7 +- IP-layer_parameters,_per_interface:_ +- IP address (address) HRC 3.3.1.6 +- Subnet mask (address mask) HRC 3.3.1.6 +- MTU integer HRC 3.3.3 +- All-subnets-MTU on/off HRC 3.3.3 +- Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6 +- Perform mask discovery on/off HRC 3.2.2.9 +- Be a mask supplier on/off HRC 3.2.2.9 +- Perform router discovery on/off RD 5.1 +- Router solicitation address (address) RD 5.1 +- Default routers, list of: +- router address (address) HRC 3.3.1.6 +- preference level integer HRC 3.3.1.6 +- Static routes, list of: +- destination (host/subnet/net) HRC 3.3.1.2 +- destination mask (address mask) HRC 3.3.1.2 +- type-of-service integer HRC 3.3.1.2 +- first-hop router (address) HRC 3.3.1.2 +- ignore redirects on/off HRC 3.3.1.2 +- PMTU integer MTU 6.6 +- perform PMTU discovery on/off MTU 6.6 +- +- Link-layer_parameters,_per_interface:_ +- Trailers on/off HRC 2.3.1 +- ARP cache timeout integer HRC 2.3.2.1 +- Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3 +- +- TCP_parameters,_per_host:_ +- TTL integer HRC 4.2.2.19 +- Keep-alive interval integer HRC 4.2.3.6 +- Keep-alive data size 0/1 HRC 4.2.3.6 +- +-Key: +- +- MTU = Path MTU Discovery (RFC 1191, Proposed Standard) +- RD = Router Discovery (RFC 1256, Proposed Standard) +- +- +- +-Droms Standards Track [Page 45] +- +diff -Naru dhcp-2.0pl5_original/doc/rfc2132.txt dhcp-2.0pl5/doc/rfc2132.txt +--- dhcp-2.0pl5_original/doc/rfc2132.txt 1997-12-06 06:09:40.000000000 -0600 ++++ dhcp-2.0pl5/doc/rfc2132.txt 1969-12-31 18:00:00.000000000 -0600 +@@ -1,1907 +0,0 @@ +- +- +- +- +- +- +-Network Working Group S. Alexander +-Request for Comments: 2132 Silicon Graphics, Inc. +-Obsoletes: 1533 R. Droms +-Category: Standards Track Bucknell University +- March 1997 +- +- DHCP Options and BOOTP Vendor Extensions +- +-Status of this memo +- +- This document specifies an Internet standards track protocol for the +- Internet community, and requests discussion and suggestions for +- improvements. Please refer to the current edition of the "Internet +- Official Protocol Standards" (STD 1) for the standardization state +- and status of this protocol. Distribution of this memo is unlimited. +- +-Abstract +- +- The Dynamic Host Configuration Protocol (DHCP) [1] provides a +- framework for passing configuration information to hosts on a TCP/IP +- network. Configuration parameters and other control information are +- carried in tagged data items that are stored in the 'options' field +- of the DHCP message. The data items themselves are also called +- "options." +- +- This document specifies the current set of DHCP options. Future +- options will be specified in separate RFCs. The current list of +- valid options is also available in ftp://ftp.isi.edu/in- +- notes/iana/assignments [22]. +- +- All of the vendor information extensions defined in RFC 1497 [2] may +- be used as DHCP options. The definitions given in RFC 1497 are +- included in this document, which supersedes RFC 1497. All of the +- DHCP options defined in this document, except for those specific to +- DHCP as defined in section 9, may be used as BOOTP vendor information +- extensions. +- +-Table of Contents +- +- 1. Introduction .............................................. 2 +- 2. BOOTP Extension/DHCP Option Field Format .................. 4 +- 3. RFC 1497 Vendor Extensions ................................ 5 +- 4. IP Layer Parameters per Host .............................. 11 +- 5. IP Layer Parameters per Interface ........................ 13 +- 6. Link Layer Parameters per Interface ....................... 16 +- 7. TCP Parameters ............................................ 17 +- 8. Application and Service Parameters ........................ 18 +- 9. DHCP Extensions ........................................... 25 +- +- +- +-Alexander & Droms Standards Track [Page 1] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- 10. Defining new extensions ................................... 31 +- 11. Acknowledgements .......................................... 31 +- 12. References ................................................ 32 +- 13. Security Considerations ................................... 33 +- 14. Authors' Addresses ........................................ 34 +- +-1. Introduction +- +- This document specifies options for use with both the Dynamic Host +- Configuration Protocol and the Bootstrap Protocol. +- +- The full description of DHCP packet formats may be found in the DHCP +- specification document [1], and the full description of BOOTP packet +- formats may be found in the BOOTP specification document [3]. This +- document defines the format of information in the last field of DHCP +- packets ('options') and of BOOTP packets ('vend'). The remainder of +- this section defines a generalized use of this area for giving +- information useful to a wide class of machines, operating systems and +- configurations. Sites with a single DHCP or BOOTP server that is +- shared among heterogeneous clients may choose to define other, site- +- specific formats for the use of the 'options' field. +- +- Section 2 of this memo describes the formats of DHCP options and +- BOOTP vendor extensions. Section 3 describes options defined in +- previous documents for use with BOOTP (all may also be used with +- DHCP). Sections 4-8 define new options intended for use with both +- DHCP and BOOTP. Section 9 defines options used only in DHCP. +- +- References further describing most of the options defined in sections +- 2-6 can be found in section 12. The use of the options defined in +- section 9 is described in the DHCP specification [1]. +- +- Information on registering new options is contained in section 10. +- +- This document updates the definition of DHCP/BOOTP options that +- appears in RFC1533. The classing mechanism has been extended to +- include vendor classes as described in section 8.4 and 9.13. The new +- procedure for defining new DHCP/BOOTP options in described in section +- 10. Several new options, including NIS+ domain and servers, Mobile +- IP home agent, SMTP server, TFTP server and Bootfile server, have +- been added. Text giving definitions used throughout the document has +- been added in section 1.1. Text emphasizing the need for uniqueness +- of client-identifiers has been added to section 9.14. +- +- +- +- +- +- +- +- +-Alexander & Droms Standards Track [Page 2] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +-1.1 Requirements +- +- Throughout this document, the words that are used to define the +- significance of particular requirements are capitalized. These words +- are: +- +- o "MUST" +- +- This word or the adjective "REQUIRED" means that the item is an +- absolute requirement of this specification. +- +- o "MUST NOT" +- +- This phrase means that the item is an absolute prohibition of +- this specification. +- +- o "SHOULD" +- +- This word or the adjective "RECOMMENDED" means that there may +- exist valid reasons in particular circumstances to ignore this +- item, but the full implications should be understood and the case +- carefully weighed before choosing a different course. +- +- o "SHOULD NOT" +- +- This phrase means that there may exist valid reasons in +- particular circumstances when the listed behavior is acceptable +- or even useful, but the full implications should be understood +- and the case carefully weighed before implementing any behavior +- described with this label. +- +- o "MAY" +- +- This word or the adjective "OPTIONAL" means that this item is +- truly optional. One vendor may choose to include the item +- because a particular marketplace requires it or because it +- enhances the product, for example; another vendor may omit the +- same item. +- +-1.2 Terminology +- +- This document uses the following terms: +- +- o "DHCP client" +- +- A DHCP client or "client" is an Internet host using DHCP to +- obtain configuration parameters such as a network address. +- +- +- +- +-Alexander & Droms Standards Track [Page 3] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- o "DHCP server" +- +- A DHCP server of "server"is an Internet host that returns +- configuration parameters to DHCP clients. +- +- o "binding" +- +- A binding is a collection of configuration parameters, including +- at least an IP address, associated with or "bound to" a DHCP +- client. Bindings are managed by DHCP servers. +- +-2. BOOTP Extension/DHCP Option Field Format +- +- +- DHCP options have the same format as the BOOTP 'vendor extensions' +- defined in RFC 1497 [2]. Options may be fixed length or variable +- length. All options begin with a tag octet, which uniquely +- identifies the option. Fixed-length options without data consist of +- only a tag octet. Only options 0 and 255 are fixed length. All +- other options are variable-length with a length octet following the +- tag octet. The value of the length octet does not include the two +- octets specifying the tag and length. The length octet is followed +- by "length" octets of data. Options containing NVT ASCII data SHOULD +- NOT include a trailing NULL; however, the receiver of such options +- MUST be prepared to delete trailing nulls if they exist. The +- receiver MUST NOT require that a trailing null be included in the +- data. In the case of some variable-length options the length field +- is a constant but must still be specified. +- +- Any options defined subsequent to this document MUST contain a length +- octet even if the length is fixed or zero. +- +- All multi-octet quantities are in network byte-order. +- +- When used with BOOTP, the first four octets of the vendor information +- field have been assigned to the "magic cookie" (as suggested in RFC +- 951). This field identifies the mode in which the succeeding data is +- to be interpreted. The value of the magic cookie is the 4 octet +- dotted decimal 99.130.83.99 (or hexadecimal number 63.82.53.63) in +- network byte order. +- +- All of the "vendor extensions" defined in RFC 1497 are also DHCP +- options. +- +- Option codes 128 to 254 (decimal) are reserved for site-specific +- options. +- +- +- +- +- +-Alexander & Droms Standards Track [Page 4] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- Except for the options in section 9, all options may be used with +- either DHCP or BOOTP. +- +- Many of these options have their default values specified in other +- documents. In particular, RFC 1122 [4] specifies default values for +- most IP and TCP configuration parameters. +- +- Many options supply one or more 32-bit IP address. Use of IP +- addresses rather than fully-qualified Domain Names (FQDNs) may make +- future renumbering of IP hosts more difficult. Use of these +- addresses is discouraged at sites that may require renumbering. +- +-3. RFC 1497 Vendor Extensions +- +- This section lists the vendor extensions as defined in RFC 1497. +- They are defined here for completeness. +- +-3.1. Pad Option +- +- The pad option can be used to cause subsequent fields to align on +- word boundaries. +- +- The code for the pad option is 0, and its length is 1 octet. +- +- Code +- +-----+ +- | 0 | +- +-----+ +- +-3.2. End Option +- +- The end option marks the end of valid information in the vendor +- field. Subsequent octets should be filled with pad options. +- +- The code for the end option is 255, and its length is 1 octet. +- +- Code +- +-----+ +- | 255 | +- +-----+ +- +-3.3. Subnet Mask +- +- The subnet mask option specifies the client's subnet mask as per RFC +- 950 [5]. +- +- If both the subnet mask and the router option are specified in a DHCP +- reply, the subnet mask option MUST be first. +- +- +- +-Alexander & Droms Standards Track [Page 5] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- The code for the subnet mask option is 1, and its length is 4 octets. +- +- Code Len Subnet Mask +- +-----+-----+-----+-----+-----+-----+ +- | 1 | 4 | m1 | m2 | m3 | m4 | +- +-----+-----+-----+-----+-----+-----+ +- +-3.4. Time Offset +- +- The time offset field specifies the offset of the client's subnet in +- seconds from Coordinated Universal Time (UTC). The offset is +- expressed as a two's complement 32-bit integer. A positive offset +- indicates a location east of the zero meridian and a negative offset +- indicates a location west of the zero meridian. +- +- The code for the time offset option is 2, and its length is 4 octets. +- +- Code Len Time Offset +- +-----+-----+-----+-----+-----+-----+ +- | 2 | 4 | n1 | n2 | n3 | n4 | +- +-----+-----+-----+-----+-----+-----+ +- +-3.5. Router Option +- +- The router option specifies a list of IP addresses for routers on the +- client's subnet. Routers SHOULD be listed in order of preference. +- +- The code for the router option is 3. The minimum length for the +- router option is 4 octets, and the length MUST always be a multiple +- of 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 3 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-3.6. Time Server Option +- +- The time server option specifies a list of RFC 868 [6] time servers +- available to the client. Servers SHOULD be listed in order of +- preference. +- +- The code for the time server option is 4. The minimum length for +- this option is 4 octets, and the length MUST always be a multiple of +- 4. +- +- +- +- +- +- +-Alexander & Droms Standards Track [Page 6] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 4 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-3.7. Name Server Option +- +- The name server option specifies a list of IEN 116 [7] name servers +- available to the client. Servers SHOULD be listed in order of +- preference. +- +- The code for the name server option is 5. The minimum length for +- this option is 4 octets, and the length MUST always be a multiple of +- 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 5 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-3.8. Domain Name Server Option +- +- The domain name server option specifies a list of Domain Name System +- (STD 13, RFC 1035 [8]) name servers available to the client. Servers +- SHOULD be listed in order of preference. +- +- The code for the domain name server option is 6. The minimum length +- for this option is 4 octets, and the length MUST always be a multiple +- of 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 6 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-3.9. Log Server Option +- +- The log server option specifies a list of MIT-LCS UDP log servers +- available to the client. Servers SHOULD be listed in order of +- preference. +- +- The code for the log server option is 7. The minimum length for this +- option is 4 octets, and the length MUST always be a multiple of 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 7 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +- +- +-Alexander & Droms Standards Track [Page 7] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +-3.10. Cookie Server Option +- +- The cookie server option specifies a list of RFC 865 [9] cookie +- servers available to the client. Servers SHOULD be listed in order +- of preference. +- +- The code for the log server option is 8. The minimum length for this +- option is 4 octets, and the length MUST always be a multiple of 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 8 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-3.11. LPR Server Option +- +- The LPR server option specifies a list of RFC 1179 [10] line printer +- servers available to the client. Servers SHOULD be listed in order +- of preference. +- +- The code for the LPR server option is 9. The minimum length for this +- option is 4 octets, and the length MUST always be a multiple of 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 9 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-3.12. Impress Server Option +- +- The Impress server option specifies a list of Imagen Impress servers +- available to the client. Servers SHOULD be listed in order of +- preference. +- +- The code for the Impress server option is 10. The minimum length for +- this option is 4 octets, and the length MUST always be a multiple of +- 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 10 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-3.13. Resource Location Server Option +- +- This option specifies a list of RFC 887 [11] Resource Location +- servers available to the client. Servers SHOULD be listed in order +- of preference. +- +- +- +-Alexander & Droms Standards Track [Page 8] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- The code for this option is 11. The minimum length for this option +- is 4 octets, and the length MUST always be a multiple of 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 11 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-3.14. Host Name Option +- +- This option specifies the name of the client. The name may or may +- not be qualified with the local domain name (see section 3.17 for the +- preferred way to retrieve the domain name). See RFC 1035 for +- character set restrictions. +- +- The code for this option is 12, and its minimum length is 1. +- +- Code Len Host Name +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 12 | n | h1 | h2 | h3 | h4 | h5 | h6 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-3.15. Boot File Size Option +- +- This option specifies the length in 512-octet blocks of the default +- boot image for the client. The file length is specified as an +- unsigned 16-bit integer. +- +- The code for this option is 13, and its length is 2. +- +- Code Len File Size +- +-----+-----+-----+-----+ +- | 13 | 2 | l1 | l2 | +- +-----+-----+-----+-----+ +- +-3.16. Merit Dump File +- +- This option specifies the path-name of a file to which the client's +- core image should be dumped in the event the client crashes. The +- path is formatted as a character string consisting of characters from +- the NVT ASCII character set. +- +- The code for this option is 14. Its minimum length is 1. +- +- Code Len Dump File Pathname +- +-----+-----+-----+-----+-----+-----+--- +- | 14 | n | n1 | n2 | n3 | n4 | ... +- +-----+-----+-----+-----+-----+-----+--- +- +- +- +-Alexander & Droms Standards Track [Page 9] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +-3.17. Domain Name +- +- This option specifies the domain name that client should use when +- resolving hostnames via the Domain Name System. +- +- The code for this option is 15. Its minimum length is 1. +- +- Code Len Domain Name +- +-----+-----+-----+-----+-----+-----+-- +- | 15 | n | d1 | d2 | d3 | d4 | ... +- +-----+-----+-----+-----+-----+-----+-- +- +-3.18. Swap Server +- +- This specifies the IP address of the client's swap server. +- +- The code for this option is 16 and its length is 4. +- +- Code Len Swap Server Address +- +-----+-----+-----+-----+-----+-----+ +- | 16 | n | a1 | a2 | a3 | a4 | +- +-----+-----+-----+-----+-----+-----+ +- +-3.19. Root Path +- +- This option specifies the path-name that contains the client's root +- disk. The path is formatted as a character string consisting of +- characters from the NVT ASCII character set. +- +- The code for this option is 17. Its minimum length is 1. +- +- Code Len Root Disk Pathname +- +-----+-----+-----+-----+-----+-----+--- +- | 17 | n | n1 | n2 | n3 | n4 | ... +- +-----+-----+-----+-----+-----+-----+--- +- +-3.20. Extensions Path +- +- A string to specify a file, retrievable via TFTP, which contains +- information which can be interpreted in the same way as the 64-octet +- vendor-extension field within the BOOTP response, with the following +- exceptions: +- +- - the length of the file is unconstrained; +- - all references to Tag 18 (i.e., instances of the +- BOOTP Extensions Path field) within the file are +- ignored. +- +- +- +- +-Alexander & Droms Standards Track [Page 10] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- The code for this option is 18. Its minimum length is 1. +- +- Code Len Extensions Pathname +- +-----+-----+-----+-----+-----+-----+--- +- | 18 | n | n1 | n2 | n3 | n4 | ... +- +-----+-----+-----+-----+-----+-----+--- +- +-4. IP Layer Parameters per Host +- +- This section details the options that affect the operation of the IP +- layer on a per-host basis. +- +-4.1. IP Forwarding Enable/Disable Option +- +- This option specifies whether the client should configure its IP +- layer for packet forwarding. A value of 0 means disable IP +- forwarding, and a value of 1 means enable IP forwarding. +- +- The code for this option is 19, and its length is 1. +- +- Code Len Value +- +-----+-----+-----+ +- | 19 | 1 | 0/1 | +- +-----+-----+-----+ +- +-4.2. Non-Local Source Routing Enable/Disable Option +- +- This option specifies whether the client should configure its IP +- layer to allow forwarding of datagrams with non-local source routes +- (see Section 3.3.5 of [4] for a discussion of this topic). A value +- of 0 means disallow forwarding of such datagrams, and a value of 1 +- means allow forwarding. +- +- The code for this option is 20, and its length is 1. +- +- Code Len Value +- +-----+-----+-----+ +- | 20 | 1 | 0/1 | +- +-----+-----+-----+ +- +-4.3. Policy Filter Option +- +- This option specifies policy filters for non-local source routing. +- The filters consist of a list of IP addresses and masks which specify +- destination/mask pairs with which to filter incoming source routes. +- +- Any source routed datagram whose next-hop address does not match one +- of the filters should be discarded by the client. +- +- +- +-Alexander & Droms Standards Track [Page 11] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- See [4] for further information. +- +- The code for this option is 21. The minimum length of this option is +- 8, and the length MUST be a multiple of 8. +- +- Code Len Address 1 Mask 1 +- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +- | 21 | n | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | +- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +- Address 2 Mask 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+--- +- | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+--- +- +-4.4. Maximum Datagram Reassembly Size +- +- This option specifies the maximum size datagram that the client +- should be prepared to reassemble. The size is specified as a 16-bit +- unsigned integer. The minimum value legal value is 576. +- +- The code for this option is 22, and its length is 2. +- +- Code Len Size +- +-----+-----+-----+-----+ +- | 22 | 2 | s1 | s2 | +- +-----+-----+-----+-----+ +- +-4.5. Default IP Time-to-live +- +- This option specifies the default time-to-live that the client should +- use on outgoing datagrams. The TTL is specified as an octet with a +- value between 1 and 255. +- +- The code for this option is 23, and its length is 1. +- +- Code Len TTL +- +-----+-----+-----+ +- | 23 | 1 | ttl | +- +-----+-----+-----+ +- +-4.6. Path MTU Aging Timeout Option +- +- This option specifies the timeout (in seconds) to use when aging Path +- MTU values discovered by the mechanism defined in RFC 1191 [12]. The +- timeout is specified as a 32-bit unsigned integer. +- +- The code for this option is 24, and its length is 4. +- +- +- +- +-Alexander & Droms Standards Track [Page 12] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- Code Len Timeout +- +-----+-----+-----+-----+-----+-----+ +- | 24 | 4 | t1 | t2 | t3 | t4 | +- +-----+-----+-----+-----+-----+-----+ +- +-4.7. Path MTU Plateau Table Option +- +- This option specifies a table of MTU sizes to use when performing +- Path MTU Discovery as defined in RFC 1191. The table is formatted as +- a list of 16-bit unsigned integers, ordered from smallest to largest. +- The minimum MTU value cannot be smaller than 68. +- +- The code for this option is 25. Its minimum length is 2, and the +- length MUST be a multiple of 2. +- +- Code Len Size 1 Size 2 +- +-----+-----+-----+-----+-----+-----+--- +- | 25 | n | s1 | s2 | s1 | s2 | ... +- +-----+-----+-----+-----+-----+-----+--- +- +-5. IP Layer Parameters per Interface +- +- This section details the options that affect the operation of the IP +- layer on a per-interface basis. It is expected that a client can +- issue multiple requests, one per interface, in order to configure +- interfaces with their specific parameters. +- +-5.1. Interface MTU Option +- +- This option specifies the MTU to use on this interface. The MTU is +- specified as a 16-bit unsigned integer. The minimum legal value for +- the MTU is 68. +- +- The code for this option is 26, and its length is 2. +- +- Code Len MTU +- +-----+-----+-----+-----+ +- | 26 | 2 | m1 | m2 | +- +-----+-----+-----+-----+ +- +-5.2. All Subnets are Local Option +- +- This option specifies whether or not the client may assume that all +- subnets of the IP network to which the client is connected use the +- same MTU as the subnet of that network to which the client is +- directly connected. A value of 1 indicates that all subnets share +- the same MTU. A value of 0 means that the client should assume that +- some subnets of the directly connected network may have smaller MTUs. +- +- +- +-Alexander & Droms Standards Track [Page 13] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- The code for this option is 27, and its length is 1. +- +- Code Len Value +- +-----+-----+-----+ +- | 27 | 1 | 0/1 | +- +-----+-----+-----+ +- +-5.3. Broadcast Address Option +- +- This option specifies the broadcast address in use on the client's +- subnet. Legal values for broadcast addresses are specified in +- section 3.2.1.3 of [4]. +- +- The code for this option is 28, and its length is 4. +- +- Code Len Broadcast Address +- +-----+-----+-----+-----+-----+-----+ +- | 28 | 4 | b1 | b2 | b3 | b4 | +- +-----+-----+-----+-----+-----+-----+ +- +-5.4. Perform Mask Discovery Option +- +- This option specifies whether or not the client should perform subnet +- mask discovery using ICMP. A value of 0 indicates that the client +- should not perform mask discovery. A value of 1 means that the +- client should perform mask discovery. +- +- The code for this option is 29, and its length is 1. +- +- Code Len Value +- +-----+-----+-----+ +- | 29 | 1 | 0/1 | +- +-----+-----+-----+ +- +-5.5. Mask Supplier Option +- +- This option specifies whether or not the client should respond to +- subnet mask requests using ICMP. A value of 0 indicates that the +- client should not respond. A value of 1 means that the client should +- respond. +- +- The code for this option is 30, and its length is 1. +- +- Code Len Value +- +-----+-----+-----+ +- | 30 | 1 | 0/1 | +- +-----+-----+-----+ +- +- +- +- +-Alexander & Droms Standards Track [Page 14] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +-5.6. Perform Router Discovery Option +- +- This option specifies whether or not the client should solicit +- routers using the Router Discovery mechanism defined in RFC 1256 +- [13]. A value of 0 indicates that the client should not perform +- router discovery. A value of 1 means that the client should perform +- router discovery. +- +- The code for this option is 31, and its length is 1. +- +- Code Len Value +- +-----+-----+-----+ +- | 31 | 1 | 0/1 | +- +-----+-----+-----+ +- +-5.7. Router Solicitation Address Option +- +- This option specifies the address to which the client should transmit +- router solicitation requests. +- +- The code for this option is 32, and its length is 4. +- +- Code Len Address +- +-----+-----+-----+-----+-----+-----+ +- | 32 | 4 | a1 | a2 | a3 | a4 | +- +-----+-----+-----+-----+-----+-----+ +- +-5.8. Static Route Option +- +- This option specifies a list of static routes that the client should +- install in its routing cache. If multiple routes to the same +- destination are specified, they are listed in descending order of +- priority. +- +- The routes consist of a list of IP address pairs. The first address +- is the destination address, and the second address is the router for +- the destination. +- +- The default route (0.0.0.0) is an illegal destination for a static +- route. See section 3.5 for information about the router option. +- +- The code for this option is 33. The minimum length of this option is +- 8, and the length MUST be a multiple of 8. +- +- +- +- +- +- +- +- +-Alexander & Droms Standards Track [Page 15] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- Code Len Destination 1 Router 1 +- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +- | 33 | n | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 | +- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +- Destination 2 Router 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+--- +- | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+--- +- +-6. Link Layer Parameters per Interface +- +- This section lists the options that affect the operation of the data +- link layer on a per-interface basis. +- +-6.1. Trailer Encapsulation Option +- +- This option specifies whether or not the client should negotiate the +- use of trailers (RFC 893 [14]) when using the ARP protocol. A value +- of 0 indicates that the client should not attempt to use trailers. A +- value of 1 means that the client should attempt to use trailers. +- +- The code for this option is 34, and its length is 1. +- +- Code Len Value +- +-----+-----+-----+ +- | 34 | 1 | 0/1 | +- +-----+-----+-----+ +- +-6.2. ARP Cache Timeout Option +- +- This option specifies the timeout in seconds for ARP cache entries. +- The time is specified as a 32-bit unsigned integer. +- +- The code for this option is 35, and its length is 4. +- +- Code Len Time +- +-----+-----+-----+-----+-----+-----+ +- | 35 | 4 | t1 | t2 | t3 | t4 | +- +-----+-----+-----+-----+-----+-----+ +- +-6.3. Ethernet Encapsulation Option +- +- This option specifies whether or not the client should use Ethernet +- Version 2 (RFC 894 [15]) or IEEE 802.3 (RFC 1042 [16]) encapsulation +- if the interface is an Ethernet. A value of 0 indicates that the +- client should use RFC 894 encapsulation. A value of 1 means that the +- client should use RFC 1042 encapsulation. +- +- +- +- +-Alexander & Droms Standards Track [Page 16] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- The code for this option is 36, and its length is 1. +- +- Code Len Value +- +-----+-----+-----+ +- | 36 | 1 | 0/1 | +- +-----+-----+-----+ +- +-7. TCP Parameters +- +- This section lists the options that affect the operation of the TCP +- layer on a per-interface basis. +- +-7.1. TCP Default TTL Option +- +- This option specifies the default TTL that the client should use when +- sending TCP segments. The value is represented as an 8-bit unsigned +- integer. The minimum value is 1. +- +- The code for this option is 37, and its length is 1. +- +- Code Len TTL +- +-----+-----+-----+ +- | 37 | 1 | n | +- +-----+-----+-----+ +- +-7.2. TCP Keepalive Interval Option +- +- This option specifies the interval (in seconds) that the client TCP +- should wait before sending a keepalive message on a TCP connection. +- The time is specified as a 32-bit unsigned integer. A value of zero +- indicates that the client should not generate keepalive messages on +- connections unless specifically requested by an application. +- +- The code for this option is 38, and its length is 4. +- +- Code Len Time +- +-----+-----+-----+-----+-----+-----+ +- | 38 | 4 | t1 | t2 | t3 | t4 | +- +-----+-----+-----+-----+-----+-----+ +- +-7.3. TCP Keepalive Garbage Option +- +- This option specifies the whether or not the client should send TCP +- keepalive messages with a octet of garbage for compatibility with +- older implementations. A value of 0 indicates that a garbage octet +- should not be sent. A value of 1 indicates that a garbage octet +- should be sent. +- +- +- +- +-Alexander & Droms Standards Track [Page 17] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- The code for this option is 39, and its length is 1. +- +- Code Len Value +- +-----+-----+-----+ +- | 39 | 1 | 0/1 | +- +-----+-----+-----+ +- +-8. Application and Service Parameters +- +- This section details some miscellaneous options used to configure +- miscellaneous applications and services. +- +-8.1. Network Information Service Domain Option +- +- This option specifies the name of the client's NIS [17] domain. The +- domain is formatted as a character string consisting of characters +- from the NVT ASCII character set. +- +- The code for this option is 40. Its minimum length is 1. +- +- Code Len NIS Domain Name +- +-----+-----+-----+-----+-----+-----+--- +- | 40 | n | n1 | n2 | n3 | n4 | ... +- +-----+-----+-----+-----+-----+-----+--- +- +-8.2. Network Information Servers Option +- +- This option specifies a list of IP addresses indicating NIS servers +- available to the client. Servers SHOULD be listed in order of +- preference. +- +- The code for this option is 41. Its minimum length is 4, and the +- length MUST be a multiple of 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 41 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-8.3. Network Time Protocol Servers Option +- +- This option specifies a list of IP addresses indicating NTP [18] +- servers available to the client. Servers SHOULD be listed in order +- of preference. +- +- The code for this option is 42. Its minimum length is 4, and the +- length MUST be a multiple of 4. +- +- +- +- +-Alexander & Droms Standards Track [Page 18] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 42 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-8.4. Vendor Specific Information +- +- This option is used by clients and servers to exchange vendor- +- specific information. The information is an opaque object of n +- octets, presumably interpreted by vendor-specific code on the clients +- and servers. The definition of this information is vendor specific. +- The vendor is indicated in the vendor class identifier option. +- Servers not equipped to interpret the vendor-specific information +- sent by a client MUST ignore it (although it may be reported). +- Clients which do not receive desired vendor-specific information +- SHOULD make an attempt to operate without it, although they may do so +- (and announce they are doing so) in a degraded mode. +- +- If a vendor potentially encodes more than one item of information in +- this option, then the vendor SHOULD encode the option using +- "Encapsulated vendor-specific options" as described below: +- +- The Encapsulated vendor-specific options field SHOULD be encoded as a +- sequence of code/length/value fields of identical syntax to the DHCP +- options field with the following exceptions: +- +- 1) There SHOULD NOT be a "magic cookie" field in the encapsulated +- vendor-specific extensions field. +- +- 2) Codes other than 0 or 255 MAY be redefined by the vendor within +- the encapsulated vendor-specific extensions field, but SHOULD +- conform to the tag-length-value syntax defined in section 2. +- +- 3) Code 255 (END), if present, signifies the end of the +- encapsulated vendor extensions, not the end of the vendor +- extensions field. If no code 255 is present, then the end of +- the enclosing vendor-specific information field is taken as the +- end of the encapsulated vendor-specific extensions field. +- +- The code for this option is 43 and its minimum length is 1. +- +- Code Len Vendor-specific information +- +-----+-----+-----+-----+--- +- | 43 | n | i1 | i2 | ... +- +-----+-----+-----+-----+--- +- +- +- +- +- +- +-Alexander & Droms Standards Track [Page 19] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- When encapsulated vendor-specific extensions are used, the +- information bytes 1-n have the following format: +- +- Code Len Data item Code Len Data item Code +- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +- | T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... | +- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +- +-8.5. NetBIOS over TCP/IP Name Server Option +- +- The NetBIOS name server (NBNS) option specifies a list of RFC +- 1001/1002 [19] [20] NBNS name servers listed in order of preference. +- +- The code for this option is 44. The minimum length of the option is +- 4 octets, and the length must always be a multiple of 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- +- | 44 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- +- +-8.6. NetBIOS over TCP/IP Datagram Distribution Server Option +- +- The NetBIOS datagram distribution server (NBDD) option specifies a +- list of RFC 1001/1002 NBDD servers listed in order of preference. The +- code for this option is 45. The minimum length of the option is 4 +- octets, and the length must always be a multiple of 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- +- | 45 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- +- +-8.7. NetBIOS over TCP/IP Node Type Option +- +- The NetBIOS node type option allows NetBIOS over TCP/IP clients which +- are configurable to be configured as described in RFC 1001/1002. The +- value is specified as a single octet which identifies the client type +- as follows: +- +- Value Node Type +- ----- --------- +- 0x1 B-node +- 0x2 P-node +- 0x4 M-node +- 0x8 H-node +- +- +- +- +- +-Alexander & Droms Standards Track [Page 20] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- In the above chart, the notation '0x' indicates a number in base-16 +- (hexadecimal). +- +- The code for this option is 46. The length of this option is always +- 1. +- +- Code Len Node Type +- +-----+-----+-----------+ +- | 46 | 1 | see above | +- +-----+-----+-----------+ +- +-8.8. NetBIOS over TCP/IP Scope Option +- +- The NetBIOS scope option specifies the NetBIOS over TCP/IP scope +- parameter for the client as specified in RFC 1001/1002. See [19], +- [20], and [8] for character-set restrictions. +- +- The code for this option is 47. The minimum length of this option is +- 1. +- +- Code Len NetBIOS Scope +- +-----+-----+-----+-----+-----+-----+---- +- | 47 | n | s1 | s2 | s3 | s4 | ... +- +-----+-----+-----+-----+-----+-----+---- +- +-8.9. X Window System Font Server Option +- +- This option specifies a list of X Window System [21] Font servers +- available to the client. Servers SHOULD be listed in order of +- preference. +- +- The code for this option is 48. The minimum length of this option is +- 4 octets, and the length MUST be a multiple of 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+--- +- | 48 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+--- +- +-8.10. X Window System Display Manager Option +- +- This option specifies a list of IP addresses of systems that are +- running the X Window System Display Manager and are available to the +- client. +- +- Addresses SHOULD be listed in order of preference. +- +- +- +- +- +-Alexander & Droms Standards Track [Page 21] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- The code for the this option is 49. The minimum length of this option +- is 4, and the length MUST be a multiple of 4. +- +- Code Len Address 1 Address 2 +- +- +-----+-----+-----+-----+-----+-----+-----+-----+--- +- | 49 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+--- +- +-8.11. Network Information Service+ Domain Option +- +- This option specifies the name of the client's NIS+ [17] domain. The +- domain is formatted as a character string consisting of characters +- from the NVT ASCII character set. +- +- The code for this option is 64. Its minimum length is 1. +- +- Code Len NIS Client Domain Name +- +-----+-----+-----+-----+-----+-----+--- +- | 64 | n | n1 | n2 | n3 | n4 | ... +- +-----+-----+-----+-----+-----+-----+--- +- +-8.12. Network Information Service+ Servers Option +- +- This option specifies a list of IP addresses indicating NIS+ servers +- available to the client. Servers SHOULD be listed in order of +- preference. +- +- The code for this option is 65. Its minimum length is 4, and the +- length MUST be a multiple of 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 65 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-8.13. Mobile IP Home Agent option +- +- This option specifies a list of IP addresses indicating mobile IP +- home agents available to the client. Agents SHOULD be listed in +- order of preference. +- +- The code for this option is 68. Its minimum length is 0 (indicating +- no home agents are available) and the length MUST be a multiple of 4. +- It is expected that the usual length will be four octets, containing +- a single home agent's address. +- +- +- +- +- +-Alexander & Droms Standards Track [Page 22] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- Code Len Home Agent Addresses (zero or more) +- +-----+-----+-----+-----+-----+-----+-- +- | 68 | n | a1 | a2 | a3 | a4 | ... +- +-----+-----+-----+-----+-----+-----+-- +- +-8.14. Simple Mail Transport Protocol (SMTP) Server Option +- +- The SMTP server option specifies a list of SMTP servers available to +- the client. Servers SHOULD be listed in order of preference. +- +- The code for the SMTP server option is 69. The minimum length for +- this option is 4 octets, and the length MUST always be a multiple of +- 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 69 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-8.15. Post Office Protocol (POP3) Server Option +- +- The POP3 server option specifies a list of POP3 available to the +- client. Servers SHOULD be listed in order of preference. +- +- The code for the POP3 server option is 70. The minimum length for +- this option is 4 octets, and the length MUST always be a multiple of +- 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 70 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-8.16. Network News Transport Protocol (NNTP) Server Option +- +- The NNTP server option specifies a list of NNTP available to the +- client. Servers SHOULD be listed in order of preference. +- +- The code for the NNTP server option is 71. The minimum length for +- this option is 4 octets, and the length MUST always be a multiple of +- 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 71 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +- +- +- +- +-Alexander & Droms Standards Track [Page 23] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +-8.17. Default World Wide Web (WWW) Server Option +- +- The WWW server option specifies a list of WWW available to the +- client. Servers SHOULD be listed in order of preference. +- +- The code for the WWW server option is 72. The minimum length for +- this option is 4 octets, and the length MUST always be a multiple of +- 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 72 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-8.18. Default Finger Server Option +- +- The Finger server option specifies a list of Finger available to the +- client. Servers SHOULD be listed in order of preference. +- +- The code for the Finger server option is 73. The minimum length for +- this option is 4 octets, and the length MUST always be a multiple of +- 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 73 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-8.19. Default Internet Relay Chat (IRC) Server Option +- +- The IRC server option specifies a list of IRC available to the +- client. Servers SHOULD be listed in order of preference. +- +- The code for the IRC server option is 74. The minimum length for +- this option is 4 octets, and the length MUST always be a multiple of +- 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 74 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-8.20. StreetTalk Server Option +- +- The StreetTalk server option specifies a list of StreetTalk servers +- available to the client. Servers SHOULD be listed in order of +- preference. +- +- +- +- +-Alexander & Droms Standards Track [Page 24] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- The code for the StreetTalk server option is 75. The minimum length +- for this option is 4 octets, and the length MUST always be a multiple +- of 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 75 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-8.21. StreetTalk Directory Assistance (STDA) Server Option +- +- The StreetTalk Directory Assistance (STDA) server option specifies a +- list of STDA servers available to the client. Servers SHOULD be +- listed in order of preference. +- +- The code for the StreetTalk Directory Assistance server option is 76. +- The minimum length for this option is 4 octets, and the length MUST +- always be a multiple of 4. +- +- Code Len Address 1 Address 2 +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- | 76 | n | a1 | a2 | a3 | a4 | a1 | a2 | ... +- +-----+-----+-----+-----+-----+-----+-----+-----+-- +- +-9. DHCP Extensions +- +- This section details the options that are specific to DHCP. +- +-9.1. Requested IP Address +- +- This option is used in a client request (DHCPDISCOVER) to allow the +- client to request that a particular IP address be assigned. +- +- The code for this option is 50, and its length is 4. +- +- Code Len Address +- +-----+-----+-----+-----+-----+-----+ +- | 50 | 4 | a1 | a2 | a3 | a4 | +- +-----+-----+-----+-----+-----+-----+ +- +-9.2. IP Address Lease Time +- +- This option is used in a client request (DHCPDISCOVER or DHCPREQUEST) +- to allow the client to request a lease time for the IP address. In a +- server reply (DHCPOFFER), a DHCP server uses this option to specify +- the lease time it is willing to offer. +- +- +- +- +- +-Alexander & Droms Standards Track [Page 25] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- The time is in units of seconds, and is specified as a 32-bit +- unsigned integer. +- +- The code for this option is 51, and its length is 4. +- +- Code Len Lease Time +- +-----+-----+-----+-----+-----+-----+ +- | 51 | 4 | t1 | t2 | t3 | t4 | +- +-----+-----+-----+-----+-----+-----+ +- +-9.3. Option Overload +- +- This option is used to indicate that the DHCP 'sname' or 'file' +- fields are being overloaded by using them to carry DHCP options. A +- DHCP server inserts this option if the returned parameters will +- exceed the usual space allotted for options. +- +- If this option is present, the client interprets the specified +- additional fields after it concludes interpretation of the standard +- option fields. +- +- The code for this option is 52, and its length is 1. Legal values +- for this option are: +- +- Value Meaning +- ----- -------- +- 1 the 'file' field is used to hold options +- 2 the 'sname' field is used to hold options +- 3 both fields are used to hold options +- +- Code Len Value +- +-----+-----+-----+ +- | 52 | 1 |1/2/3| +- +-----+-----+-----+ +- +-9.4 TFTP server name +- +- This option is used to identify a TFTP server when the 'sname' field +- in the DHCP header has been used for DHCP options. +- +- The code for this option is 66, and its minimum length is 1. +- +- Code Len TFTP server +- +-----+-----+-----+-----+-----+--- +- | 66 | n | c1 | c2 | c3 | ... +- +-----+-----+-----+-----+-----+--- +- +- +- +- +- +-Alexander & Droms Standards Track [Page 26] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +-9.5 Bootfile name +- +- This option is used to identify a bootfile when the 'file' field in +- the DHCP header has been used for DHCP options. +- +- The code for this option is 67, and its minimum length is 1. +- +- Code Len Bootfile name +- +-----+-----+-----+-----+-----+--- +- | 67 | n | c1 | c2 | c3 | ... +- +-----+-----+-----+-----+-----+--- +- +-9.6. DHCP Message Type +- +- This option is used to convey the type of the DHCP message. The code +- for this option is 53, and its length is 1. Legal values for this +- option are: +- +- Value Message Type +- ----- ------------ +- 1 DHCPDISCOVER +- 2 DHCPOFFER +- 3 DHCPREQUEST +- 4 DHCPDECLINE +- 5 DHCPACK +- 6 DHCPNAK +- 7 DHCPRELEASE +- 8 DHCPINFORM +- +- Code Len Type +- +-----+-----+-----+ +- | 53 | 1 | 1-9 | +- +-----+-----+-----+ +- +-9.7. Server Identifier +- +- This option is used in DHCPOFFER and DHCPREQUEST messages, and may +- optionally be included in the DHCPACK and DHCPNAK messages. DHCP +- servers include this option in the DHCPOFFER in order to allow the +- client to distinguish between lease offers. DHCP clients use the +- contents of the 'server identifier' field as the destination address +- for any DHCP messages unicast to the DHCP server. DHCP clients also +- indicate which of several lease offers is being accepted by including +- this option in a DHCPREQUEST message. +- +- The identifier is the IP address of the selected server. +- +- The code for this option is 54, and its length is 4. +- +- +- +-Alexander & Droms Standards Track [Page 27] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- Code Len Address +- +-----+-----+-----+-----+-----+-----+ +- | 54 | 4 | a1 | a2 | a3 | a4 | +- +-----+-----+-----+-----+-----+-----+ +- +-9.8. Parameter Request List +- +- This option is used by a DHCP client to request values for specified +- configuration parameters. The list of requested parameters is +- specified as n octets, where each octet is a valid DHCP option code +- as defined in this document. +- +- The client MAY list the options in order of preference. The DHCP +- server is not required to return the options in the requested order, +- but MUST try to insert the requested options in the order requested +- by the client. +- +- The code for this option is 55. Its minimum length is 1. +- +- Code Len Option Codes +- +-----+-----+-----+-----+--- +- | 55 | n | c1 | c2 | ... +- +-----+-----+-----+-----+--- +- +-9.9. Message +- +- This option is used by a DHCP server to provide an error message to a +- DHCP client in a DHCPNAK message in the event of a failure. A client +- may use this option in a DHCPDECLINE message to indicate the why the +- client declined the offered parameters. The message consists of n +- octets of NVT ASCII text, which the client may display on an +- available output device. +- +- The code for this option is 56 and its minimum length is 1. +- +- Code Len Text +- +-----+-----+-----+-----+--- +- | 56 | n | c1 | c2 | ... +- +-----+-----+-----+-----+--- +- +-9.10. Maximum DHCP Message Size +- +- This option specifies the maximum length DHCP message that it is +- willing to accept. The length is specified as an unsigned 16-bit +- integer. A client may use the maximum DHCP message size option in +- DHCPDISCOVER or DHCPREQUEST messages, but should not use the option +- in DHCPDECLINE messages. +- +- +- +- +-Alexander & Droms Standards Track [Page 28] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- The code for this option is 57, and its length is 2. The minimum +- legal value is 576 octets. +- +- Code Len Length +- +-----+-----+-----+-----+ +- | 57 | 2 | l1 | l2 | +- +-----+-----+-----+-----+ +- +-9.11. Renewal (T1) Time Value +- +- This option specifies the time interval from address assignment until +- the client transitions to the RENEWING state. +- +- The value is in units of seconds, and is specified as a 32-bit +- unsigned integer. +- +- The code for this option is 58, and its length is 4. +- +- Code Len T1 Interval +- +-----+-----+-----+-----+-----+-----+ +- | 58 | 4 | t1 | t2 | t3 | t4 | +- +-----+-----+-----+-----+-----+-----+ +- +-9.12. Rebinding (T2) Time Value +- +- This option specifies the time interval from address assignment until +- the client transitions to the REBINDING state. +- +- The value is in units of seconds, and is specified as a 32-bit +- unsigned integer. +- +- The code for this option is 59, and its length is 4. +- +- Code Len T2 Interval +- +-----+-----+-----+-----+-----+-----+ +- | 59 | 4 | t1 | t2 | t3 | t4 | +- +-----+-----+-----+-----+-----+-----+ +- +-9.13. Vendor class identifier +- +- This option is used by DHCP clients to optionally identify the vendor +- type and configuration of a DHCP client. The information is a string +- of n octets, interpreted by servers. Vendors may choose to define +- specific vendor class identifiers to convey particular configuration +- or other identification information about a client. For example, the +- identifier may encode the client's hardware configuration. Servers +- not equipped to interpret the class-specific information sent by a +- client MUST ignore it (although it may be reported). Servers that +- +- +- +-Alexander & Droms Standards Track [Page 29] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- respond SHOULD only use option 43 to return the vendor-specific +- information to the client. +- +- The code for this option is 60, and its minimum length is 1. +- +- Code Len Vendor class Identifier +- +-----+-----+-----+-----+--- +- | 60 | n | i1 | i2 | ... +- +-----+-----+-----+-----+--- +- +-9.14. Client-identifier +- +- This option is used by DHCP clients to specify their unique +- identifier. DHCP servers use this value to index their database of +- address bindings. This value is expected to be unique for all +- clients in an administrative domain. +- +- Identifiers SHOULD be treated as opaque objects by DHCP servers. +- +- The client identifier MAY consist of type-value pairs similar to the +- 'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist +- of a hardware type and hardware address. In this case the type field +- SHOULD be one of the ARP hardware types defined in STD2 [22]. A +- hardware type of 0 (zero) should be used when the value field +- contains an identifier other than a hardware address (e.g. a fully +- qualified domain name). +- +- For correct identification of clients, each client's client- +- identifier MUST be unique among the client-identifiers used on the +- subnet to which the client is attached. Vendors and system +- administrators are responsible for choosing client-identifiers that +- meet this requirement for uniqueness. +- +- The code for this option is 61, and its minimum length is 2. +- +- Code Len Type Client-Identifier +- +-----+-----+-----+-----+-----+--- +- | 61 | n | t1 | i1 | i2 | ... +- +-----+-----+-----+-----+-----+--- +- +- +- +- +- +- +- +- +- +- +- +- +-Alexander & Droms Standards Track [Page 30] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +-10. Defining new extensions +- +- The author of a new DHCP option will follow these steps to obtain +- acceptance of the option as a part of the DHCP Internet Standard: +- +- 1. The author devises the new option. +- 2. The author requests a number for the new option from IANA by +- contacting: +- Internet Assigned Numbers Authority (IANA) +- USC/Information Sciences Institute +- 4676 Admiralty Way +- Marina del Rey, California 90292-6695 +- +- or by email as: iana@iana.org +- +- 3. The author documents the new option, using the newly obtained +- option number, as an Internet Draft. +- 4. The author submits the Internet Draft for review through the IETF +- standards process as defined in "Internet Official Protocol +- Standards" (STD 1). The new option will be submitted for eventual +- acceptance as an Internet Standard. +- 5. The new option progresses through the IETF standards process; the +- new option will be reviewed by the Dynamic Host Configuration +- Working Group (if that group still exists), or as an Internet +- Draft not submitted by an IETF working group. +- 6. If the new option fails to gain acceptance as an Internet +- Standard, the assigned option number will be returned to IANA for +- reassignment. +- +- This procedure for defining new extensions will ensure that: +- +- * allocation of new option numbers is coordinated from a single +- authority, +- * new options are reviewed for technical correctness and +- appropriateness, and +- * documentation for new options is complete and published. +- +-11. Acknowledgements +- +- The author thanks the many (and too numerous to mention!) members of +- the DHC WG for their tireless and ongoing efforts in the development +- of DHCP and this document. +- +- The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John +- Mendonca in organizing DHCP interoperability testing sessions are +- gratefully acknowledged. +- +- +- +- +- +-Alexander & Droms Standards Track [Page 31] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- The development of this document was supported in part by grants from +- the Corporation for National Research Initiatives (CNRI), Bucknell +- University and Sun Microsystems. +- +-12. References +- +- [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, +- Bucknell University, March 1997. +- +- [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, +- USC/Information Sciences Institute, August 1993. +- +- [3] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951, +- Stanford University and Sun Microsystems, September 1985. +- +- [4] Braden, R., Editor, "Requirements for Internet Hosts - +- Communication Layers", STD 3, RFC 1122, USC/Information Sciences +- Institute, October 1989. +- +- [5] Mogul, J., and J. Postel, "Internet Standard Subnetting +- Procedure", STD 5, RFC 950, USC/Information Sciences Institute, +- August 1985. +- +- [6] Postel, J., and K. Harrenstien, "Time Protocol", STD 26, RFC +- 868, USC/Information Sciences Institute, SRI, May 1983. +- +- [7] Postel, J., "Name Server", IEN 116, USC/Information Sciences +- Institute, August 1979. +- +- [8] Mockapetris, P., "Domain Names - Implementation and +- Specification", STD 13, RFC 1035, USC/Information Sciences +- Institute, November 1987. +- +- [9] Postel, J., "Quote of the Day Protocol", STD 23, RFC 865, +- USC/Information Sciences Institute, May 1983. +- +- [10] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, The +- Wollongong Group, August 1990. +- +- [11] Accetta, M., "Resource Location Protocol", RFC 887, CMU, +- December 1983. +- +- [12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, +- DECWRL, Stanford University, November 1990. +- +- [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256, +- Xerox PARC, September 1991. +- +- +- +- +-Alexander & Droms Standards Track [Page 32] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +- [14] Leffler, S. and M. Karels, "Trailer Encapsulations", RFC 893, +- U. C. Berkeley, April 1984. +- +- [15] Hornig, C., "Standard for the Transmission of IP Datagrams over +- Ethernet Networks", RFC 894, Symbolics, April 1984. +- +- [16] Postel, J. and J. Reynolds, "Standard for the Transmission of +- IP Datagrams Over IEEE 802 Networks", RFC 1042, USC/Information +- Sciences Institute, February 1988. +- +- [17] Sun Microsystems, "System and Network Administration", March +- 1990. +- +- [18] Mills, D., "Internet Time Synchronization: The Network Time +- Protocol", RFC 1305, UDEL, March 1992. +- +- [19] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service +- on a TCP/UDP transport: Concepts and Methods", STD 19, RFC 1001, +- March 1987. +- +- [20] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service +- on a TCP/UDP transport: Detailed Specifications", STD 19, RFC +- 1002, March 1987. +- +- [21] Scheifler, R., "FYI On the X Window System", FYI 6, RFC 1198, +- MIT Laboratory for Computer Science, January 1991. +- +- [22] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, +- USC/Information Sciences Institute, July 1992. +- +-13. Security Considerations +- +- Security issues are not discussed in this memo. +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +-Alexander & Droms Standards Track [Page 33] +- +-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997 +- +- +-14. Authors' Addresses +- +- Steve Alexander +- Silicon Graphics, Inc. +- 2011 N. Shoreline Boulevard +- Mailstop 510 +- Mountain View, CA 94043-1389 +- +- Phone: (415) 933-6172 +- EMail: sca@engr.sgi.com +- +- +- Ralph Droms +- Bucknell University +- Lewisburg, PA 17837 +- +- Phone: (717) 524-1145 +- EMail: droms@bucknell.edu +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +-Alexander & Droms Standards Track [Page 34] +- +diff -Naru dhcp-2.0pl5_original/doc/rfc951.txt dhcp-2.0pl5/doc/rfc951.txt +--- dhcp-2.0pl5_original/doc/rfc951.txt 1997-12-06 06:13:48.000000000 -0600 ++++ dhcp-2.0pl5/doc/rfc951.txt 1969-12-31 18:00:00.000000000 -0600 +@@ -1,684 +0,0 @@ +- +- +-Network Working Group Bill Croft (Stanford University) +-Request for Comments: 951 John Gilmore (Sun Microsystems) +- September 1985 +- +- BOOTSTRAP PROTOCOL (BOOTP) +- +- +-1. Status of this Memo +- +- This RFC suggests a proposed protocol for the ARPA-Internet +- community, and requests discussion and suggestions for improvements. +- Distribution of this memo is unlimited. +- +-2. Overview +- +- This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows +- a diskless client machine to discover its own IP address, the address +- of a server host, and the name of a file to be loaded into memory and +- executed. The bootstrap operation can be thought of as consisting of +- TWO PHASES. This RFC describes the first phase, which could be +- labeled 'address determination and bootfile selection'. After this +- address and filename information is obtained, control passes to the +- second phase of the bootstrap where a file transfer occurs. The file +- transfer will typically use the TFTP protocol [9], since it is +- intended that both phases reside in PROM on the client. However +- BOOTP could also work with other protocols such as SFTP [3] or +- FTP [6]. +- +- We suggest that the client's PROM software provide a way to do a +- complete bootstrap without 'user' interaction. This is the type of +- boot that would occur during an unattended power-up. A mechanism +- should be provided for the user to manually supply the necessary +- address and filename information to bypass the BOOTP protocol and +- enter the file transfer phase directly. If non-volatile storage is +- available, we suggest keeping default settings there and bypassing +- the BOOTP protocol unless these settings cause the file transfer +- phase to fail. If the cached information fails, the bootstrap should +- fall back to phase 1 and use BOOTP. +- +- Here is a brief outline of the protocol: +- +- 1. A single packet exchange is performed. Timeouts are used to +- retransmit until a reply is received. The same packet field +- layout is used in both directions. Fixed length fields of maximum +- reasonable length are used to simplify structure definition and +- parsing. +- +- 2. An 'opcode' field exists with two values. The client +- broadcasts a 'bootrequest' packet. The server then answers with a +- 'bootreply' packet. The bootrequest contains the client's +- hardware address and its IP address, if known. +- +- +-Croft & Gilmore [Page 1] +- +- +- +-RFC 951 September 1985 +-Bootstrap Protocol +- +- +- 3. The request can optionally contain the name of the server the +- client wishes to respond. This is so the client can force the +- boot to occur from a specific host (e.g. if multiple versions of +- the same bootfile exist or if the server is in a far distant +- net/domain). The client does not have to deal with name / domain +- services; instead this function is pushed off to the BOOTP server. +- +- 4. The request can optionally contain the 'generic' filename to be +- booted. For example 'unix' or 'ethertip'. When the server sends +- the bootreply, it replaces this field with the fully qualified +- path name of the appropriate boot file. In determining this name, +- the server may consult his own database correlating the client's +- address and filename request, with a particular boot file +- customized for that client. If the bootrequest filename is a null +- string, then the server returns a filename field indicating the +- 'default' file to be loaded for that client. +- +- 5. In the case of clients who do not know their IP addresses, the +- server must also have a database relating hardware address to IP +- address. This client IP address is then placed into a field in +- the bootreply. +- +- 6. Certain network topologies (such as Stanford's) may be such +- that a given physical cable does not have a TFTP server directly +- attached to it (e.g. all the gateways and hosts on a certain cable +- may be diskless). With the cooperation of neighboring gateways, +- BOOTP can allow clients to boot off of servers several hops away, +- through these gateways. See the section 'Booting Through +- Gateways' below. This part of the protocol requires no special +- action on the part of the client. Implementation is optional and +- requires a small amount of additional code in gateways and +- servers. +- +-3. Packet Format +- +- All numbers shown are decimal, unless indicated otherwise. The BOOTP +- packet is enclosed in a standard IP [8] UDP [7] datagram. For +- simplicity it is assumed that the BOOTP packet is never fragmented. +- Any numeric fields shown are packed in 'standard network byte order', +- i.e. high order bits are sent first. +- +- In the IP header of a bootrequest, the client fills in its own IP +- source address if known, otherwise zero. When the server address is +- unknown, the IP destination address will be the 'broadcast address' +- 255.255.255.255. This address means 'broadcast on the local cable, +- (I don't know my net number)' [4]. +- +- +- +-Croft & Gilmore [Page 2] +- +- +- +-RFC 951 September 1985 +-Bootstrap Protocol +- +- +- The UDP header contains source and destination port numbers. The +- BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68) +- and 'BOOTP server' (67). The client sends requests using 'BOOTP +- server' as the destination port; this is usually a broadcast. The +- server sends replies using 'BOOTP client' as the destination port; +- depending on the kernel or driver facilities in the server, this may +- or may not be a broadcast (this is explained further in the section +- titled 'Chicken/Egg issues' below). The reason TWO reserved ports +- are used, is to avoid 'waking up' and scheduling the BOOTP server +- daemons, when a bootreply must be broadcast to a client. Since the +- server and other hosts won't be listening on the 'BOOTP client' port, +- any such incoming broadcasts will be filtered out at the kernel +- level. We could not simply allow the client to pick a 'random' port +- number for the UDP source port field; since the server reply may be +- broadcast, a randomly chosen port number could confuse other hosts +- that happened to be listening on that port. +- +- The UDP length field is set to the length of the UDP plus BOOTP +- portions of the packet. The UDP checksum field can be set to zero by +- the client (or server) if desired, to avoid this extra overhead in a +- PROM implementation. In the 'Packet Processing' section below the +- phrase '[UDP checksum.]' is used whenever the checksum might be +- verified/computed. +- +- FIELD BYTES DESCRIPTION +- ----- ----- ----------- +- +- op 1 packet op code / message type. +- 1 = BOOTREQUEST, 2 = BOOTREPLY +- +- htype 1 hardware address type, +- see ARP section in "Assigned Numbers" RFC. +- '1' = 10mb ethernet +- +- hlen 1 hardware address length +- (eg '6' for 10mb ethernet). +- +- hops 1 client sets to zero, +- optionally used by gateways +- in cross-gateway booting. +- +- xid 4 transaction ID, a random number, +- used to match this boot request with the +- responses it generates. +- +- secs 2 filled in by client, seconds elapsed since +- client started trying to boot. +- +- +-Croft & Gilmore [Page 3] +- +- +- +-RFC 951 September 1985 +-Bootstrap Protocol +- +- +- -- 2 unused +- +- ciaddr 4 client IP address; +- filled in by client in bootrequest if known. +- +- yiaddr 4 'your' (client) IP address; +- filled by server if client doesn't +- know its own address (ciaddr was 0). +- +- siaddr 4 server IP address; +- returned in bootreply by server. +- +- giaddr 4 gateway IP address, +- used in optional cross-gateway booting. +- +- chaddr 16 client hardware address, +- filled in by client. +- +- sname 64 optional server host name, +- null terminated string. +- +- file 128 boot file name, null terminated string; +- 'generic' name or null in bootrequest, +- fully qualified directory-path +- name in bootreply. +- +- vend 64 optional vendor-specific area, +- e.g. could be hardware type/serial on request, +- or 'capability' / remote file system handle +- on reply. This info may be set aside for use +- by a third phase bootstrap or kernel. +- +-4. Chicken / Egg Issues +- +- How can the server send an IP datagram to the client, if the client +- doesnt know its own IP address (yet)? Whenever a bootreply is being +- sent, the transmitting machine performs the following operations: +- +- 1. If the client knows its own IP address ('ciaddr' field is +- nonzero), then the IP can be sent 'as normal', since the client +- will respond to ARPs [5]. +- +- 2. If the client does not yet know its IP address (ciaddr zero), +- then the client cannot respond to ARPs sent by the transmitter of +- the bootreply. There are two options: +- +- a. If the transmitter has the necessary kernel or driver hooks +- +- +-Croft & Gilmore [Page 4] +- +- +- +-RFC 951 September 1985 +-Bootstrap Protocol +- +- +- to 'manually' construct an ARP address cache entry, then it can +- fill in an entry using the 'chaddr' and 'yiaddr' fields. Of +- course, this entry should have a timeout on it, just like any +- other entry made by the normal ARP code itself. The +- transmitter of the bootreply can then simply send the bootreply +- to the client's IP address. UNIX (4.2 BSD) has this +- capability. +- +- b. If the transmitter lacks these kernel hooks, it can simply +- send the bootreply to the IP broadcast address on the +- appropriate interface. This is only one additional broadcast +- over the previous case. +- +-5. Client Use of ARP +- +- The client PROM must contain a simple implementation of ARP, e.g. the +- address cache could be just one entry in size. This will allow a +- second-phase-only boot (TFTP) to be performed when the client knows +- the IP addresses and bootfile name. +- +- Any time the client is expecting to receive a TFTP or BOOTP reply, it +- should be prepared to answer an ARP request for its own IP to +- hardware address mapping (if known). +- +- Since the bootreply will contain (in the hardware encapsulation) the +- hardware source address of the server/gateway, the client MAY be able +- to avoid sending an ARP request for the server/gateway IP address to +- be used in the following TFTP phase. However this should be treated +- only as a special case, since it is desirable to still allow a +- second-phase-only boot as described above. +- +-6. Comparison to RARP +- +- An earlier protocol, Reverse Address Resolution Protocol (RARP) [1] +- was proposed to allow a client to determine its IP address, given +- that it knew its hardware address. However RARP had the disadvantage +- that it was a hardware link level protocol (not IP/UDP based). This +- means that RARP could only be implemented on hosts containing special +- kernel or driver modifications to access these 'raw' packets. Since +- there are many network kernels existent now, with each source +- maintained by different organizations, a boot protocol that does not +- require kernel modifications is a decided advantage. +- +- BOOTP provides this hardware to IP address lookup function, in +- addition to the other useful features described in the sections +- above. +- +- +- +-Croft & Gilmore [Page 5] +- +- +- +-RFC 951 September 1985 +-Bootstrap Protocol +- +- +-7. Packet Processing +- +- 7.1. Client Transmission +- +- Before setting up the packet for the first time, it is a good idea +- to clear the entire packet buffer to all zeros; this will place +- all fields in their default state. The client then creates a +- packet with the following fields. +- +- The IP destination address is set to 255.255.255.255. (the +- broadcast address) or to the server's IP address (if known). The +- IP source address and 'ciaddr' are set to the client's IP address +- if known, else 0. The UDP header is set with the proper length; +- source port = 'BOOTP client' port destination port = 'BOOTP +- server' port. +- +- 'op' is set to '1', BOOTREQUEST. 'htype' is set to the hardware +- address type as assigned in the ARP section of the "Assigned +- Numbers" RFC. 'hlen' is set to the length of the hardware address, +- e.g. '6' for 10mb ethernet. +- +- 'xid' is set to a 'random' transaction id. 'secs' is set to the +- number of seconds that have elapsed since the client has started +- booting. This will let the servers know how long a client has +- been trying. As the number gets larger, certain servers may feel +- more 'sympathetic' towards a client they don't normally service. +- If a client lacks a suitable clock, it could construct a rough +- estimate using a loop timer. Or it could choose to simply send +- this field as always a fixed value, say 100 seconds. +- +- If the client knows its IP address, 'ciaddr' (and the IP source +- address) are set to this value. 'chaddr' is filled in with the +- client's hardware address. +- +- If the client wishes to restrict booting to a particular server +- name, it may place a null-terminated string in 'sname'. The name +- used should be any of the allowable names or nicknames of the +- desired host. +- +- The client has several options for filling the 'file' name field. +- If left null, the meaning is 'I want to boot the default file for +- my machine'. A null file name can also mean 'I am only interested +- in finding out client/server/gateway IP addresses, I dont care +- about file names'. +- +- The field can also be a 'generic' name such as 'unix' or +- +- +- +-Croft & Gilmore [Page 6] +- +- +- +-RFC 951 September 1985 +-Bootstrap Protocol +- +- +- 'gateway'; this means 'boot the named program configured for my +- machine'. Finally the field can be a fully directory qualified +- path name. +- +- The 'vend' field can be filled in by the client with +- vendor-specific strings or structures. For example the machine +- hardware type or serial number may be placed here. However the +- operation of the BOOTP server should not DEPEND on this +- information existing. +- +- If the 'vend' field is used, it is recommended that a 4 byte +- 'magic number' be the first item within 'vend'. This lets a +- server determine what kind of information it is seeing in this +- field. Numbers can be assigned by the usual 'magic number' +- process --you pick one and it's magic. A different magic number +- could be used for bootreply's than bootrequest's to allow the +- client to take special action with the reply information. +- +- [UDP checksum.] +- +- 7.2. Client Retransmission Strategy +- +- If no reply is received for a certain length of time, the client +- should retransmit the request. The time interval must be chosen +- carefully so as not to flood the network. Consider the case of a +- cable containing 100 machines that are just coming up after a +- power failure. Simply retransmitting the request every four +- seconds will inundate the net. +- +- As a possible strategy, you might consider backing off +- exponentially, similar to the way ethernet backs off on a +- collision. So for example if the first packet is at time 0:00, +- the second would be at :04, then :08, then :16, then :32, then +- :64. You should also randomize each time; this would be done +- similar to the ethernet specification by starting with a mask and +- 'and'ing that with with a random number to get the first backoff. +- On each succeeding backoff, the mask is increased in length by one +- bit. This doubles the average delay on each backoff. +- +- After the 'average' backoff reaches about 60 seconds, it should be +- increased no further, but still randomized. +- +- Before each retransmission, the client should update the 'secs' +- field. [UDP checksum.] +- +- +- +- +- +-Croft & Gilmore [Page 7] +- +- +- +-RFC 951 September 1985 +-Bootstrap Protocol +- +- +- 7.3. Server Receives BOOTREQUEST +- +- [UDP checksum.] If the UDP destination port does not match the +- 'BOOTP server' port, discard the packet. +- +- If the server name field (sname) is null (no particular server +- specified), or sname is specified and matches our name or +- nickname, then continue with packet processing. +- +- If the sname field is specified, but does not match 'us', then +- there are several options: +- +- 1. You may choose to simply discard this packet. +- +- 2. If a name lookup on sname shows it to be on this same cable, +- discard the packet. +- +- 3. If sname is on a different net, you may choose to forward +- the packet to that address. If so, check the 'giaddr' (gateway +- address) field. If 'giaddr' is zero, fill it in with my +- address or the address of a gateway that can be used to get to +- that net. Then forward the packet. +- +- If the client IP address (ciaddr) is zero, then the client does +- not know its own IP address. Attempt to lookup the client +- hardware address (chaddr, hlen, htype) in our database. If no +- match is found, discard the packet. Otherwise we now have an IP +- address for this client; fill it into the 'yiaddr' (your IP +- address) field. +- +- We now check the boot file name field (file). The field will be +- null if the client is not interested in filenames, or wants the +- default bootfile. If the field is non-null, it is used as a +- lookup key in a database, along with the client's IP address. If +- there is a default file or generic file (possibly indexed by the +- client address) or a fully-specified path name that matches, then +- replace the 'file' field with the fully-specified path name of the +- selected boot file. If the field is non-null and no match was +- found, then the client is asking for a file we dont have; discard +- the packet, perhaps some other BOOTP server will have it. +- +- The 'vend' vendor-specific data field should now be checked and if +- a recognized type of data is provided, client-specific actions +- should be taken, and a response placed in the 'vend' data field of +- the reply packet. For example, a workstation client could provide +- +- +- +- +-Croft & Gilmore [Page 8] +- +- +- +-RFC 951 September 1985 +-Bootstrap Protocol +- +- +- an authentication key and receive from the server a capability for +- remote file access, or a set of configuration options, which can +- be passed to the operating system that will shortly be booted in. +- +- Place my (server) IP address in the 'siaddr' field. Set the 'op' +- field to BOOTREPLY. The UDP destination port is set to 'BOOTP +- client'. If the client address 'ciaddr' is nonzero, send the +- packet there; else if the gateway address 'giaddr' is nonzero, set +- the UDP destination port to 'BOOTP server' and send the packet to +- 'giaddr'; else the client is on one of our cables but it doesnt +- know its own IP address yet --use a method described in the 'Egg' +- section above to send it to the client. If 'Egg' is used and we +- have multiple interfaces on this host, use the 'yiaddr' (your IP +- address) field to figure out which net (cable/interface) to send +- the packet to. [UDP checksum.] +- +- 7.4. Server/Gateway Receives BOOTREPLY +- +- [UDP checksum.] If 'yiaddr' (your [the client's] IP address) +- refers to one of our cables, use one of the 'Egg' methods above to +- forward it to the client. Be sure to send it to the 'BOOTP +- client' UDP destination port. +- +- 7.5. Client Reception +- +- Don't forget to process ARP requests for my own IP address (if I +- know it). [UDP checksum.] The client should discard incoming +- packets that: are not IP/UDPs addressed to the boot port; are not +- BOOTREPLYs; do not match my IP address (if I know it) or my +- hardware address; do not match my transaction id. Otherwise we +- have received a successful reply. 'yiaddr' will contain my IP +- address, if I didnt know it before. 'file' is the name of the +- file name to TFTP 'read request'. The server address is in +- 'siaddr'. If 'giaddr' (gateway address) is nonzero, then the +- packets should be forwarded there first, in order to get to the +- server. +- +-8. Booting Through Gateways +- +- This part of the protocol is optional and requires some additional +- code in cooperating gateways and servers, but it allows cross-gateway +- booting. This is mainly useful when gateways are diskless machines. +- Gateways containing disks (e.g. a UNIX machine acting as a gateway), +- might as well run their own BOOTP/TFTP servers. +- +- Gateways listening to broadcast BOOTREQUESTs may decide to forward or +- rebroadcast these requests 'when appropriate'. For example, the +- +- +-Croft & Gilmore [Page 9] +- +- +- +-RFC 951 September 1985 +-Bootstrap Protocol +- +- +- gateway could have, as part of his configuration tables, a list of +- other networks or hosts to receive a copy of any broadcast +- BOOTREQUESTs. Even though a 'hops' field exists, it is a poor idea +- to simply globally rebroadcast the requests, since broadcast loops +- will almost certainly occur. +- +- The forwarding could begin immediately, or wait until the 'secs' +- (seconds client has been trying) field passes a certain threshold. +- +- If a gateway does decide to forward the request, it should look at +- the 'giaddr' (gateway IP address) field. If zero, it should plug its +- own IP address (on the receiving cable) into this field. It may also +- use the 'hops' field to optionally control how far the packet is +- reforwarded. Hops should be incremented on each forwarding. For +- example, if hops passes '3', the packet should probably be discarded. +- [UDP checksum.] +- +- Here we have recommended placing this special forwarding function in +- the gateways. But that does not have to be the case. As long as +- some 'BOOTP forwarding agent' exists on the net with the booting +- client, the agent can do the forwarding when appropriate. Thus this +- service may or may not be co-located with the gateway. +- +- In the case of a forwarding agent not located in the gateway, the +- agent could save himself some work by plugging the broadcast address +- of the interface receiving the bootrequest into the 'giaddr' field. +- Thus the reply would get forwarded using normal gateways, not +- involving the forwarding agent. Of course the disadvantage here is +- that you lose the ability to use the 'Egg' non-broadcast method of +- sending the reply, causing extra overhead for every host on the +- client cable. +- +-9. Sample BOOTP Server Database +- +- As a suggestion, we show a sample text file database that the BOOTP +- server program might use. The database has two sections, delimited +- by a line containing an percent in column 1. The first section +- contains a 'default directory' and mappings from generic names to +- directory/pathnames. The first generic name in this section is the +- 'default file' you get when the bootrequest contains a null 'file' +- string. +- +- The second section maps hardware addresstype/address into an +- ipaddress. Optionally you can also overide the default generic name +- by supplying a ipaddress specific genericname. A 'suffix' item is +- also an option; if supplied, any generic names specified by the +- client will be accessed by first appending 'suffix' to the 'pathname' +- +- +-Croft & Gilmore [Page 10] +- +- +- +-RFC 951 September 1985 +-Bootstrap Protocol +- +- +- appropriate to that generic name. If that file is not found, then +- the plain 'pathname' will be tried. This 'suffix' option allows a +- whole set of custom generics to be setup without a lot of effort. +- Below is shown the general format; fields are delimited by one or +- more spaces or tabs; trailing empty fields may be omitted; blank +- lines and lines beginning with '#' are ignored. +- +- # comment line +- +- homedirectory +- genericname1 pathname1 +- genericname2 pathname2 +- ... +- +- % end of generic names, start of address mappings +- +- hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix +- hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix +- ... +- +- Here is a specific example. Note the 'hardwaretype' number is the +- same as that shown in the ARP section of the 'Assigned Numbers' RFC. +- The 'hardwaretype' and 'ipaddr' numbers are in decimal; +- 'hardwareaddr' is in hex. +- +- # last updated by smith +- +- /usr/boot +- vmunix vmunix +- tip ethertip +- watch /usr/diag/etherwatch +- gate gate. +- +- % end of generic names, start of address mappings +- +- hamilton 1 02.60.8c.06.34.98 36.19.0.5 +- burr 1 02.60.8c.34.11.78 36.44.0.12 +- 101-gateway 1 02.60.8c.23.ab.35 36.44.0.32 gate 101 +- mjh-gateway 1 02.60.8c.12.32.bc 36.42.0.64 gate mjh +- welch-tipa 1 02.60.8c.22.65.32 36.47.0.14 tip +- welch-tipb 1 02.60.8c.12.15.c8 36.46.0.12 tip +- +- In the example above, if 'mjh-gateway' does a default boot, it will +- get the file '/usr/boot/gate.mjh'. +- +- +- +- +- +-Croft & Gilmore [Page 11] +- +- +- +-RFC 951 September 1985 +-Bootstrap Protocol +- +- +-10. Acknowledgements +- +- Ross Finlayson (et. al.) produced two earlier RFC's discussing TFTP +- bootstraping [2] using RARP [1]. +- +- We would also like to acknowledge the previous work and comments of +- Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer. +- +-REFERENCES +- +- 1. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A +- Reverse Address Resolution Protocol. RFC 903, NIC, June, 1984. +- +- 2. Ross Finlayson. Bootstrap Loading using TFTP. RFC 906, NIC, +- June, 1984. +- +- 3. Mark Lottor. Simple File Transfer Protocol. RFC 913, NIC, +- September, 1984. +- +- 4. Jeffrey Mogul. Broadcasting Internet Packets. RFC 919, NIC, +- October, 1984. +- +- 5. David Plummer. An Ethernet Address Resolution Protocol. RFC +- 826, NIC, September, 1982. +- +- 6. Jon Postel. File Transfer Protocol. RFC 765, NIC, June, 1980. +- +- 7. Jon Postel. User Datagram Protocol. RFC 768, NIC, August, 1980. +- +- 8. Jon Postel. Internet Protocol. RFC 791, NIC, September, 1981. +- +- 9. K. R. Sollins, Noel Chiappa. The TFTP Protocol. RFC 783, NIC, +- June, 1981. +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +- +-Croft & Gilmore [Page 12] +- +diff -Naru dhcp-2.0pl5_original/doc/rfcindex.html dhcp-2.0pl5/doc/rfcindex.html +--- dhcp-2.0pl5_original/doc/rfcindex.html 1969-12-31 18:00:00.000000000 -0600 ++++ dhcp-2.0pl5/doc/rfcindex.html 2003-09-01 00:25:23.000000000 -0500 +@@ -0,0 +1,22 @@ ++ ++RFCs Relevant to dhcp ++ ++ ++

    ++RFCs Relevant to dhcp ++

    ++ ++

    ++

    ++There are three RFCs (Request For Comments) that contain information ++relevant to the structure and motivation of dhcp and attendant ++programs. However, the DFSG-free-ness of distributing RFCs has come ++into question, so they have been removed from this package. ++

    ++ ++

    ++The relevant RFCs are: 951, 2131, and 2132. RFC archives can be found ++many places on the web, including: ++www.faqs.org. ++

    ++ --- dhcp-2.0pl5.orig/debian/patches/305_CVE-2007-5365.patch +++ dhcp-2.0pl5/debian/patches/305_CVE-2007-5365.patch @@ -0,0 +1,16 @@ +--- dhcp-2.0pl5.orig/common/options.c Thu Aug 21 11:00:35 2003 ++++ dhcp-2.0pl5/common/options.c Thu Aug 21 11:01:09 2003 +@@ -188,9 +188,12 @@ + inpacket && + inpacket -> options [DHO_DHCP_MAX_MESSAGE_SIZE].data && + (inpacket -> options [DHO_DHCP_MAX_MESSAGE_SIZE].len >= +- sizeof (u_int16_t))) ++ sizeof (u_int16_t))){ + mms = getUShort (inpacket -> options + [DHO_DHCP_MAX_MESSAGE_SIZE].data); ++ if (mms < 576) ++ mms = 576; /* mms must be >= minimum IP MTU */ ++ } + + /* If the client has provided a maximum DHCP message size, + use that; otherwise, if it's BOOTP, only 64 bytes; otherwise --- dhcp-2.0pl5.orig/debian/patches/200_script.patch +++ dhcp-2.0pl5/debian/patches/200_script.patch @@ -0,0 +1,68 @@ +--- /tmp/dhcp-2.0pl5/client/scripts/linux Fri Feb 5 15:15:48 1999 ++++ dhcp-2.0pl5/client/scripts/linux Tue Feb 19 07:48:32 2002 +@@ -23,17 +23,24 @@ + # of the $1 in its args. + + # Must be used on exit. Invokes the local dhcp client exit hooks, if any. +-function exit_with_hooks() { ++exit_with_hooks() { + exit_status=$1 +- if [ -x /etc/dhclient-exit-hooks ]; then ++ if [ -f /etc/dhclient-exit-hooks ]; then + . /etc/dhclient-exit-hooks + fi + # probably should do something with exit status of the local script + exit $exit_status + } + ++make_resolv_conf() { ++ echo search $new_domain_name >/etc/resolv.conf ++ for nameserver in $new_domain_name_servers; do ++ echo nameserver $nameserver >>/etc/resolv.conf ++ done ++} ++ + # Invoke the local dhcp client enter hooks, if they exist. +-if [ -x /etc/dhclient-enter-hooks ]; then ++if [ -f /etc/dhclient-enter-hooks ]; then + exit_status=0 + . /etc/dhclient-enter-hooks + # allow the local script to abort processing of this state +@@ -112,6 +120,9 @@ + + ifconfig $interface inet $new_ip_address $new_subnet_arg \ + $new_broadcast_arg ++ if [ x$new_interface_mtu != x ]; then ++ ifconfig $interface mtu $new_interface_mtu ++ fi + # Add a network route to the computed network address. + if [ $relmajor -lt 2 ] || \ + ( [ $relmajor -eq 2 ] && [ $relminor -eq 0 ] ); then +@@ -127,10 +138,7 @@ + ifconfig $interface:0 inet $alias_ip_address $alias_subnet_arg + route add -host $alias_ip_address $interface:0 + fi +- echo search $new_domain_name >/etc/resolv.conf +- for nameserver in $new_domain_name_servers; do +- echo nameserver $nameserver >>/etc/resolv.conf +- done ++ make_resolv_conf + exit_with_hooks 0 + fi + +@@ -171,14 +179,7 @@ + for router in $new_routers; do + route add default gw $router + done +- echo search $new_domain_name >/etc/resolv.conf.std +- for nameserver in $new_domain_name_servers; do +- echo nameserver $nameserver >>/etc/resolv.conf.std +- done +- if [ -f /etc/resolv.conf ]; then +- rm -f /etc/resolv.conf +- ln /etc/resolv.conf.std /etc/resolv.conf +- fi ++ make_resolv_conf + exit_with_hooks 0 + fi + ifconfig $interface inet down --- dhcp-2.0pl5.orig/debian/dhcp.install +++ dhcp-2.0pl5/debian/dhcp.install @@ -0,0 +1,6 @@ +/usr/sbin/dhcpd +/etc/dhcpd.conf +/usr/share/man/man5/dhcpd.conf.5 +/usr/share/man/man5/dhcpd.leases.5 +/usr/share/man/man5/dhcp-options-dhcpd.5 +/usr/share/man/man8/dhcpd.8 --- dhcp-2.0pl5.orig/debian/scripts/patch-source +++ dhcp-2.0pl5/debian/scripts/patch-source @@ -0,0 +1,11 @@ +#!/bin/sh -e +# +# $Id: patch-source,v 1.2.2.2 2003/09/09 17:12:47 peloy Exp $ +# + +for patch in debian/patches/*.patch; do + echo '->'`basename $patch`: + patch -p1 --ignore-whitespace < $patch +done + +exit 0 --- dhcp-2.0pl5.orig/debian/scripts/unpatch-source +++ dhcp-2.0pl5/debian/scripts/unpatch-source @@ -0,0 +1,12 @@ +#!/bin/sh -e +# +# $Id: unpatch-source,v 1.2.2.2 2003/09/09 17:12:47 peloy Exp $ +# + +# We want to reverse the patches in the opposite order we applied +# them, hence the 'ls|sort -r'. +for patch in `ls debian/patches/*.patch | sort -r`; do + patch -p1 -R --ignore-whitespace < $patch +done + +exit 0 --- dhcp-2.0pl5.orig/common/dhcp-options.man5 +++ dhcp-2.0pl5/common/dhcp-options.man5 @@ -0,0 +1,690 @@ +.\" dhcp-options.5 +.\" +.\" Copyright (c) 1995, 1996, 1997, 1998 The Internet Software Consortium. +.\" All rights reserved. +.\" +.\" Redistribution and use in source and binary forms, with or without +.\" modification, are permitted provided that the following conditions +.\" are met: +.\" +.\" 1. Redistributions of source code must retain the above copyright +.\" notice, this list of conditions and the following disclaimer. +.\" 2. Redistributions in binary form must reproduce the above copyright +.\" notice, this list of conditions and the following disclaimer in the +.\" documentation and/or other materials provided with the distribution. +.\" 3. Neither the name of The Internet Software Consortium nor the names +.\" of its contributors may be used to endorse or promote products derived +.\" from this software without specific prior written permission. +.\" +.\" THIS SOFTWARE IS PROVIDED BY THE INTERNET SOFTWARE CONSORTIUM AND +.\" CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, +.\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE +.\" DISCLAIMED. IN NO EVENT SHALL THE INTERNET SOFTWARE CONSORTIUM OR +.\" CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +.\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +.\" LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF +.\" USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND +.\" ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, +.\" OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT +.\" OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\" SUCH DAMAGE. +.\" +.\" This software has been written for the Internet Software Consortium +.\" by Ted Lemon in cooperation with Vixie +.\" Enterprises. To learn more about the Internet Software Consortium, +.\" see ``http://www.isc.org/isc''. To learn more about Vixie +.\" Enterprises, see ``http://www.vix.com''. +.TH dhcpd-options 5 +.SH NAME +dhcp-options - Dynamic Host Configuration Protocol options +.SH DESCRIPTION +The Dynamic Host Configuration protocol allows the client to receive +.B options +from the DHCP server describing the network configuration and various +services that are available on the network. When configuring +.B dhcpd(8) +or +.B dhclient(8) , +options must often be declared. The syntax for declaring options, +and the names and formats of the options that can be declared, are +documented here. +.SH REFERENCE: OPTION STATEMENTS +.PP +DHCP \fIoption\fR statements always start with the \fIoption\fR +keyword, followed by an option name, followed by option data. The +option names and data formats are described below. It is not +necessary to exhaustively specify all DHCP options - only those +options which are needed by clients must be specified. +.PP +Option data comes in a variety of formats, as defined below: +.PP +The +.B ip-address +data type can be entered either as an explicit IP +address (e.g., 239.254.197.10) or as a domain name (e.g., +haagen.isc.org). When entering a domain name, be sure that that +domain name resolves to a single IP address. +.PP +The +.B int32 +data type specifies a signed 32-bit integer. The +.B uint32 +data type specifies an unsigned 32-bit integer. The +.B int16 +and +.B uint16 +data types specify signed and unsigned 16-bit integers. The +.B int8 +and +.B uint8 +data types specify signed and unsigned 8-bit integers. +Unsigned 8-bit integers are also sometimes referred to as octets. +.PP +The +.B string +data type specifies an NVT ASCII string, which must be +enclosed in double quotes - for example, to specify a domain-name +option, the syntax would be +.nf +.sp 1 + option domain-name "isc.org"; +.fi +.PP +The +.B flag +data type specifies a boolean value. Booleans can be either true or +false (or on or off, if that makes more sense to you). +.PP +The +.B data-string +data type specifies either an NVT ASCII string +enclosed in double quotes, or a series of octets specified in +hexadecimal, seperated by colons. For example: +.nf +.sp 1 + option dhcp-client-identifier "CLIENT-FOO"; +or + option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f; +.fi +.PP +The documentation for the various options mentioned below is taken +from the latest IETF draft document on DHCP options. Options which +are not listed by name may be defined by the name option-\fInnn\fR, +where \fInnn\fI is the decimal number of the option code. These +options may be followed either by a string, enclosed in quotes, or by +a series of octets, expressed as two-digit hexadecimal numbers seperated +by colons. For example: +.PP +.nf + option option-133 "my-option-133-text"; + option option-129 1:54:c9:2b:47; +.fi +.PP +Because dhcpd does not know the format of these undefined option codes, +no checking is done to ensure the correctness of the entered data. +.PP +The standard options are: +.PP +.B option subnet-mask \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +The subnet mask option specifies the client's subnet mask as per RFC +950. If no subnet mask option is provided anywhere in scope, as a +last resort dhcpd will use the subnet mask from the subnet declaration +for the network on which an address is being assigned. However, +.I any +subnet-mask option declaration that is in scope for the address being +assigned will override the subnet mask specified in the subnet +declaration. +.RE +.PP +.B option time-offset \fIint32\fR\fB;\fR +.RS 0.25i +.PP +The time-offset option specifies the offset of the client's subnet in +seconds from Coordinated Universal Time (UTC). +.RE +.PP +.B option routers \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +The routers option specifies a list of IP addresses for routers on the +client's subnet. Routers should be listed in order of preference. +.RE +.PP +.B option time-servers \fIip-address\fR [, \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +The time-server option specifies a list of RFC 868 time servers +available to the client. Servers should be listed in order of +preference. +.RE +.PP +.B option \fBien116-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]; +.RS 0.25i +.PP +The ien116-name-servers option specifies a list of IEN 116 name servers +available to the client. Servers should be listed in order of +preference. +.RE +.PP +.B option \fBdomain-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +The domain-name-servers option specifies a list of Domain Name System +(STD 13, RFC 1035) name servers available to the client. Servers +should be listed in order of preference. +.RE +.PP +.B option \fBlog-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +The log-server option specifies a list of MIT-LCS UDP log servers +available to the client. Servers should be listed in order of +preference. +.RE +.PP +.B option \fBcookie-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +The cookie server option specifies a list of RFC 865 cookie +servers available to the client. Servers should be listed in order +of preference. +.RE +.PP +.B option \fBlpr-servers\fR \fIip-address \fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +The LPR server option specifies a list of RFC 1179 line printer +servers available to the client. Servers should be listed in order +of preference. +.RE +.PP +.B option \fBimpress-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +The impress-server option specifies a list of Imagen Impress servers +available to the client. Servers should be listed in order of +preference. +.RE +.PP +.B option \fBresource-location-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +This option specifies a list of RFC 887 Resource Location +servers available to the client. Servers should be listed in order +of preference. +.RE +.PP +.B option \fBhost-name\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the name of the client. The name may or may +not be qualified with the local domain name (it is preferable to use +the domain-name option to specify the domain name). See RFC 1035 for +character set restrictions. +.RE +.PP +.B option \fBboot-size\fR \fIuint16\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the length in 512-octet blocks of the default +boot image for the client. +.RE +.PP +.B option \fBmerit-dump\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the path-name of a file to which the client's +core image should be dumped in the event the client crashes. The +path is formatted as a character string consisting of characters from +the NVT ASCII character set. +.RE +.PP +.B option \fBdomain-name\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the domain name that client should use when +resolving hostnames via the Domain Name System. +.RE +.PP +.B option \fBswap-server\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +This specifies the IP address of the client's swap server. +.RE +.PP +.B option \fBroot-path\fR \fIstring\fB;\fR\fR +.RS 0.25i +.PP +This option specifies the path-name that contains the client's root +disk. The path is formatted as a character string consisting of +characters from the NVT ASCII character set. +.RE +.PP +.B option \fBip-forwarding\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +This option specifies whether the client should configure its IP +layer for packet forwarding. A value of 0 means disable IP +forwarding, and a value of 1 means enable IP forwarding. +.RE +.PP +.B option \fBnon-local-source-routing\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +This option specifies whether the client should configure its IP +layer to allow forwarding of datagrams with non-local source routes +(see Section 3.3.5 of [4] for a discussion of this topic). A value +of 0 means disallow forwarding of such datagrams, and a value of 1 +means allow forwarding. +.RE +.PP +.B option \fBpolicy-filter\fR \fIip-address ip-address\fR [\fB,\fR \fIip-address ip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +This option specifies policy filters for non-local source routing. +The filters consist of a list of IP addresses and masks which specify +destination/mask pairs with which to filter incoming source routes. +.PP +Any source routed datagram whose next-hop address does not match one +of the filters should be discarded by the client. +.PP +See STD 3 (RFC1122) for further information. +.RE +.PP +.B option \fBmax-dgram-reassembly\fR \fIuint16\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the maximum size datagram that the client +should be prepared to reassemble. The minimum value legal value is +576. +.RE +.PP +.B option \fBdefault-ip-ttl\fR \fIuint8;\fR +.RS 0.25i +.PP +This option specifies the default time-to-live that the client should +use on outgoing datagrams. +.RE +.PP +.B option \fBpath-mtu-aging-timeout\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the timeout (in seconds) to use when aging Path +MTU values discovered by the mechanism defined in RFC 1191. +.RE +.PP +.B option \fBpath-mtu-plateau-table\fR \fIuint16\fR [\fB,\fR \fIuint16\fR... +]\fB;\fR +.RS 0.25i +.PP +This option specifies a table of MTU sizes to use when performing +Path MTU Discovery as defined in RFC 1191. The table is formatted as +a list of 16-bit unsigned integers, ordered from smallest to largest. +The minimum MTU value cannot be smaller than 68. +.RE +.PP +.B option \fBinterface-mtu\fR \fIuint16\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the MTU to use on this interface. The minimum +legal value for the MTU is 68. +.RE +.PP +.B option \fBall-subnets-local\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +This option specifies whether or not the client may assume that all +subnets of the IP network to which the client is connected use the +same MTU as the subnet of that network to which the client is +directly connected. A value of 1 indicates that all subnets share +the same MTU. A value of 0 means that the client should assume that +some subnets of the directly connected network may have smaller MTUs. +.RE +.PP +.B option \fBbroadcast-address\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the broadcast address in use on the client's +subnet. Legal values for broadcast addresses are specified in +section 3.2.1.3 of STD 3 (RFC1122). +.RE +.PP +.B option \fBperform-mask-discovery\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +This option specifies whether or not the client should perform subnet +mask discovery using ICMP. A value of 0 indicates that the client +should not perform mask discovery. A value of 1 means that the +client should perform mask discovery. +.RE +.PP +.B option \fBmask-supplier\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +This option specifies whether or not the client should respond to +subnet mask requests using ICMP. A value of 0 indicates that the +client should not respond. A value of 1 means that the client should +respond. +.RE +.PP +.B option \fBrouter-discovery\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +This option specifies whether or not the client should solicit +routers using the Router Discovery mechanism defined in RFC 1256. +A value of 0 indicates that the client should not perform +router discovery. A value of 1 means that the client should perform +router discovery. +.RE +.PP +.B option \fBrouter-solicitation-address\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the address to which the client should transmit +router solicitation requests. +.RE +.PP +.B option \fBstatic-routes\fR \fIip-address ip-address\fR [\fB,\fR \fIip-address ip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +This option specifies a list of static routes that the client should +install in its routing cache. If multiple routes to the same +destination are specified, they are listed in descending order of +priority. +.PP +The routes consist of a list of IP address pairs. The first address +is the destination address, and the second address is the router for +the destination. +.PP +The default route (0.0.0.0) is an illegal destination for a static +route. To specify the default route, use the +.B routers +option. +.RE +.PP +.B option \fBtrailer-encapsulation\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +This option specifies whether or not the client should negotiate the +use of trailers (RFC 893 [14]) when using the ARP protocol. A value +of 0 indicates that the client should not attempt to use trailers. A +value of 1 means that the client should attempt to use trailers. +.RE +.PP +.B option \fBarp-cache-timeout\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the timeout in seconds for ARP cache entries. +.RE +.PP +.B option \fBieee802-3-encapsulation\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +This option specifies whether or not the client should use Ethernet +Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the +interface is an Ethernet. A value of 0 indicates that the client +should use RFC 894 encapsulation. A value of 1 means that the client +should use RFC 1042 encapsulation. +.RE +.PP +.B option \fBdefault-tcp-ttl\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the default TTL that the client should use when +sending TCP segments. The minimum value is 1. +.RE +.PP +.B option \fBtcp-keepalive-interval\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the interval (in seconds) that the client TCP +should wait before sending a keepalive message on a TCP connection. +The time is specified as a 32-bit unsigned integer. A value of zero +indicates that the client should not generate keepalive messages on +connections unless specifically requested by an application. +.RE +.PP +.B option \fBtcp-keepalive-garbage\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the whether or not the client should send TCP +keepalive messages with a octet of garbage for compatibility with +older implementations. A value of 0 indicates that a garbage octet +should not be sent. A value of 1 indicates that a garbage octet +should be sent. +.RE +.PP +.B option \fBnis-domain\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the name of the client's NIS (Sun Network +Information Services) domain. The domain is formatted as a character +string consisting of characters from the NVT ASCII character set. +.RE +.PP +.B option \fBnis-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +This option specifies a list of IP addresses indicating NIS servers +available to the client. Servers should be listed in order of +preference. +.RE +.PP +.B option \fBntp-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +This option specifies a list of IP addresses indicating NTP (RFC 1305) +servers available to the client. Servers should be listed in order +of preference. +.RE +.PP +.B option \fBnetbios-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +The NetBIOS name server (NBNS) option specifies a list of RFC +1001/1002 NBNS name servers listed in order of preference. NetBIOS +Name Service is currently more commonly referred to as WINS. WINS +servers can be specified using the netbios-name-servers option. +.RE +.PP +.B option \fBnetbios-dd-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +The NetBIOS datagram distribution server (NBDD) option specifies a +list of RFC 1001/1002 NBDD servers listed in order of preference. +.RE +.PP +.B option \fBnetbios-node-type\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +The NetBIOS node type option allows NetBIOS over TCP/IP clients which +are configurable to be configured as described in RFC 1001/1002. The +value is specified as a single octet which identifies the client type. +.PP +Possible node types are: +.PP +.TP 5 +.I 1 +B-node: Broadcast - no WINS +.TP +.I 2 +P-node: Peer - WINS only. +.TP +.I 4 +M-node: Mixed - broadcast, then WINS +.TP +.I 8 +H-node: Hybrid - WINS, then broadcast +.RE +.PP +.B option +.B netbios-scope +.I string\fB;\fR +.RS 0.25i +.PP +The NetBIOS scope option specifies the NetBIOS over TCP/IP scope +parameter for the client as specified in RFC 1001/1002. See RFC1001, +RFC1002, and RFC1035 for character-set restrictions. +.RE +.PP +.B option \fBfont-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +This option specifies a list of X Window System Font servers available +to the client. Servers should be listed in order of preference. +.RE +.PP +.B option \fBx-display-manager\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +This option specifies a list of systems that are running the X Window +System Display Manager and are available to the client. Addresses +should be listed in order of preference. +.RE +.PP +.B option \fBdhcp-client-identifier\fR \fIdata-string\fR\fB;\fR +.RS 0.25i +.PP +This option can be used to specify the a DHCP client identifier in a +host declaration, so that dhcpd can find the host record by matching +against the client identifier. +.RE +.B option \fBnisplus-domain\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +This option specifies the name of the client's NIS+ domain. The +domain is formatted as a character string consisting of characters +from the NVT ASCII character set. +.RE +.B option \fBnisplus-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +This option specifies a list of IP addresses indicating NIS+ servers +available to the client. Servers should be listed in order of +preference. +.RE +.PP +.B option \fBtftp-server-name\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +This option is used to identify a TFTP server and, if supported by the +client, should have the same effect as the \fBserver-name\fR +declaration. BOOTP clients are unlikely to support this option. +Some DHCP clients will support it, and others actually require it. +.RE +.PP +.B option \fBbootfile-name\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +This option is used to identify a bootstrap file. If supported by the +client, it should have the same effect as the \fBfilename\fR +declaration. BOOTP clients are unlikely to support this option. Some +DHCP clients will support it, and others actually require it. +.RE +.PP +.B option \fBmobile-ip-home-agent\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +This option specifies a list of IP addresses indicating mobile IP +home agents available to the client. Agents should be listed in +order of preference, although normally there will be only one such +agent. +.RE +.PP +.B option \fBsmtp-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +The SMTP server option specifies a list of SMTP servers available to +the client. Servers should be listed in order of preference. +.RE +.PP +.B option \fBpop-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +The POP3 server option specifies a list of POP3 available to the +client. Servers should be listed in order of preference. +.RE +.PP +.B option \fBnntp-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +The NNTP server option specifies a list of NNTP available to the +client. Servers should be listed in order of preference. +.RE +.PP +.B option \fBwww-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +The WWW server option specifies a list of WWW available to the +client. Servers should be listed in order of preference. +.RE +.PP +.B option \fBfinger-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +The Finger server option specifies a list of Finger available to the +client. Servers should be listed in order of preference. +.RE +.PP +.B option \fBirc-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +The IRC server option specifies a list of IRC available to the +client. Servers should be listed in order of preference. +.RE +.PP +.B option \fBstreettalk-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +The StreetTalk server option specifies a list of StreetTalk servers +available to the client. Servers should be listed in order of +preference. +.RE +.PP +.B option \fBstreetalk-directory-assistance-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +The StreetTalk Directory Assistance (STDA) server option specifies a +list of STDA servers available to the client. Servers should be +listed in order of preference. +.RE +.SH SEE ALSO +dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcpd(8), +dhclient(8), RFC2132, RFC2131. +.SH AUTHOR +.B dhcpd(8) +was written by Ted Lemon +under a contract with Vixie Labs. Funding +for this project was provided by the Internet Software Corporation. +Information about the Internet Software Consortium can be found at +.B http://www.isc.org/isc. --- dhcp-2.0pl5.orig/common/dhcp-options.cat5 +++ dhcp-2.0pl5/common/dhcp-options.cat5 @@ -1,660 +1,483 @@ +dhcpd-options(5) dhcpd-options(5) - ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) +NNAAMMEE + dhcp-options - Dynamic Host Configuration Protocol options +DDEESSCCRRIIPPTTIIOONN + The Dynamic Host Configuration protocol allows the client to receive + ooppttiioonnss from the DHCP server describing the network configuration and + various services that are available on the network. When configuring + ddhhccppdd((88)) or ddhhcclliieenntt((88)) ,, options must often be declared. The syntax + for declaring options, and the names and formats of the options that + can be declared, are documented here. +RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS + DHCP _o_p_t_i_o_n statements always start with the _o_p_t_i_o_n keyword, followed + by an option name, followed by option data. The option names and data + formats are described below. It is not necessary to exhaustively + specify all DHCP options - only those options which are needed by + clients must be specified. - NNNNAAAAMMMMEEEE - dhcp-options - Dynamic Host Configuration Protocol options + Option data comes in a variety of formats, as defined below: - DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN - The Dynamic Host Configuration protocol allows the client to - receive ooooppppttttiiiioooonnnnssss from the DHCP server describing the network - configuration and various services that are available on the - network. When configuring ddddhhhhccccppppdddd((((8888)))) or ddddhhhhcccclllliiiieeeennnntttt((((8888)))) ,,,, - options must often be declared. The syntax for declaring - options, and the names and formats of the options that can - be declared, are documented here. + The iipp--aaddddrreessss data type can be entered either as an explicit IP + address (e.g., 239.254.197.10) or as a domain name (e.g., haa‐ + gen.isc.org). When entering a domain name, be sure that that domain + name resolves to a single IP address. - RRRREEEEFFFFEEEERRRREEEENNNNCCCCEEEE:::: OOOOPPPPTTTTIIIIOOOONNNN SSSSTTTTAAAATTTTEEEEMMMMEEEENNNNTTTTSSSS - DHCP _o_p_t_i_o_n statements always start with the _o_p_t_i_o_n keyword, - followed by an option name, followed by option data. The - option names and data formats are described below. It is - not necessary to exhaustively specify all DHCP options - - only those options which are needed by clients must be - specified. + The iinntt3322 data type specifies a signed 32-bit integer. The uuiinntt3322 + data type specifies an unsigned 32-bit integer. The iinntt1166 and uuiinntt1166 + data types specify signed and unsigned 16-bit integers. The iinntt88 and + uuiinntt88 data types specify signed and unsigned 8-bit integers. Unsigned + 8-bit integers are also sometimes referred to as octets. - Option data comes in a variety of formats, as defined below: + The ssttrriinngg data type specifies an NVT ASCII string, which must be + enclosed in double quotes - for example, to specify a domain-name + option, the syntax would be - The iiiipppp----aaaaddddddddrrrreeeessssssss data type can be entered either as an - explicit IP address (e.g., 239.254.197.10) or as a domain - name (e.g., haagen.isc.org). When entering a domain name, - be sure that that domain name resolves to a single IP - address. + option domain-name "isc.org"; - The iiiinnnntttt33332222 data type specifies a signed 32-bit integer. The - uuuuiiiinnnntttt33332222 data type specifies an unsigned 32-bit integer. The - iiiinnnntttt11116666 and uuuuiiiinnnntttt11116666 data types specify signed and unsigned 16- - bit integers. The iiiinnnntttt8888 and uuuuiiiinnnntttt8888 data types specify signed - and unsigned 8-bit integers. Unsigned 8-bit integers are - also sometimes referred to as octets. + The ffllaagg data type specifies a boolean value. Booleans can be either + true or false (or on or off, if that makes more sense to you). - The ssssttttrrrriiiinnnngggg data type specifies an NVT ASCII string, which - must be enclosed in double quotes - for example, to specify - a domain-name option, the syntax would be + The ddaattaa--ssttrriinngg data type specifies either an NVT ASCII string enclosed + in double quotes, or a series of octets specified in hexadecimal, + seperated by colons. For example: - option domain-name "isc.org"; + option dhcp-client-identifier "CLIENT-FOO"; + or + option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f; - The ffffllllaaaagggg data type specifies a boolean value. Booleans can - be either true or false (or on or off, if that makes more - sense to you). + The documentation for the various options mentioned below is taken from + the latest IETF draft document on DHCP options. Options which are not + listed by name may be defined by the name option-_n_n_n, where _n_n_n _i_s _t_h_e + _d_e_c_i_m_a_l _n_u_m_b_e_r _o_f _t_h_e _o_p_t_i_o_n _c_o_d_e_. _T_h_e_s_e _o_p_t_i_o_n_s _m_a_y _b_e _f_o_l_l_o_w_e_d + _e_i_t_h_e_r _b_y _a _s_t_r_i_n_g_, _e_n_c_l_o_s_e_d _i_n _q_u_o_t_e_s_, _o_r _b_y _a _s_e_r_i_e_s _o_f _o_c_t_e_t_s_, + _e_x_p_r_e_s_s_e_d _a_s _t_w_o_-_d_i_g_i_t _h_e_x_a_d_e_c_i_m_a_l _n_u_m_b_e_r_s _s_e_p_e_r_a_t_e_d _b_y _c_o_l_o_n_s_. _F_o_r + _e_x_a_m_p_l_e_: - The ddddaaaattttaaaa----ssssttttrrrriiiinnnngggg data type specifies either an NVT ASCII - string enclosed in double quotes, or a series of octets - specified in hexadecimal, seperated by colons. For - example: + option option-133 "my-option-133-text"; + option option-129 1:54:c9:2b:47; - option dhcp-client-identifier "CLIENT-FOO"; - or + Because dhcpd does not know the format of these undefined option codes, + no checking is done to ensure the correctness of the entered data. + The standard options are: + ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s;; - Page 1 (printed 11/17/99) + The subnet mask option specifies the client’s subnet mask as per RFC + 950. If no subnet mask option is provided anywhere in scope, as a + last resort dhcpd will use the subnet mask from the subnet declara‐ + tion for the network on which an address is being assigned. How‐ + ever, _a_n_y subnet-mask option declaration that is in scope for the + address being assigned will override the subnet mask specified in + the subnet declaration. + ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2;; + The time-offset option specifies the offset of the client’s subnet + in seconds from Coordinated Universal Time (UTC). + ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; + The routers option specifies a list of IP addresses for routers on + the client’s subnet. Routers should be listed in order of prefer‐ + ence. + ooppttiioonn ttiimmee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s... ];; - ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) + The time-server option specifies a list of RFC 868 time servers + available to the client. Servers should be listed in order of pref‐ + erence. + ooppttiioonn iieenn111166--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ]; + The ien116-name-servers option specifies a list of IEN 116 name + servers available to the client. Servers should be listed in order + of preference. - option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f; + ooppttiioonn ddoommaaiinn--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - The documentation for the various options mentioned below is - taken from the latest IETF draft document on DHCP options. - Options which are not listed by name may be defined by the - name option-_n_n_n, where _n_n_n _i_s _t_h_e _d_e_c_i_m_a_l _n_u_m_b_e_r _o_f _t_h_e - _o_p_t_i_o_n _c_o_d_e. _T_h_e_s_e _o_p_t_i_o_n_s _m_a_y _b_e _f_o_l_l_o_w_e_d _e_i_t_h_e_r _b_y _a - _s_t_r_i_n_g, _e_n_c_l_o_s_e_d _i_n _q_u_o_t_e_s, _o_r _b_y _a _s_e_r_i_e_s _o_f _o_c_t_e_t_s, - _e_x_p_r_e_s_s_e_d _a_s _t_w_o-_d_i_g_i_t _h_e_x_a_d_e_c_i_m_a_l _n_u_m_b_e_r_s _s_e_p_e_r_a_t_e_d _b_y - _c_o_l_o_n_s. _F_o_r _e_x_a_m_p_l_e: + The domain-name-servers option specifies a list of Domain Name Sys‐ + tem (STD 13, RFC 1035) name servers available to the client. + Servers should be listed in order of preference. - option option-133 "my-option-133-text"; - option option-129 1:54:c9:2b:47; + ooppttiioonn lloogg--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - Because dhcpd does not know the format of these undefined - option codes, no checking is done to ensure the correctness - of the entered data. + The log-server option specifies a list of MIT-LCS UDP log servers + available to the client. Servers should be listed in order of pref‐ + erence. - The standard options are: + ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - ooooppppttttiiiioooonnnn ssssuuuubbbbnnnneeeetttt----mmmmaaaasssskkkk _i_p-_a_d_d_r_e_s_s;;;; + The cookie server option specifies a list of RFC 865 cookie servers + available to the client. Servers should be listed in order of pref‐ + erence. - The subnet mask option specifies the client's subnet mask - as per RFC 950. If no subnet mask option is provided - anywhere in scope, as a last resort dhcpd will use the - subnet mask from the subnet declaration for the network on - which an address is being assigned. However, _a_n_y subnet- - mask option declaration that is in scope for the address - being assigned will override the subnet mask specified in - the subnet declaration. + ooppttiioonn llpprr--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - ooooppppttttiiiioooonnnn ttttiiiimmmmeeee----ooooffffffffsssseeeetttt _i_n_t_3_2;;;; + The LPR server option specifies a list of RFC 1179 line printer + servers available to the client. Servers should be listed in order + of preference. - The time-offset option specifies the offset of the - client's subnet in seconds from Coordinated Universal Time - (UTC). + ooppttiioonn iimmpprreessss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - ooooppppttttiiiioooonnnn rrrroooouuuutttteeeerrrrssss _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; + The impress-server option specifies a list of Imagen Impress servers + available to the client. Servers should be listed in order of pref‐ + erence. - The routers option specifies a list of IP addresses for - routers on the client's subnet. Routers should be listed - in order of preference. + ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - ooooppppttttiiiioooonnnn ttttiiiimmmmeeee----sssseeeerrrrvvvveeeerrrrssss _i_p-_a_d_d_r_e_s_s [, _i_p-_a_d_d_r_e_s_s... ];;;; + This option specifies a list of RFC 887 Resource Location servers + available to the client. Servers should be listed in order of pref‐ + erence. - The time-server option specifies a list of RFC 868 time - servers available to the client. Servers should be listed - in order of preference. + ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g;; - ooooppppttttiiiioooonnnn iiiieeeennnn111111116666----nnnnaaaammmmeeee----sssseeeerrrrvvvveeeerrrrssss _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ]; + This option specifies the name of the client. The name may or may + not be qualified with the local domain name (it is preferable to use + the domain-name option to specify the domain name). See RFC 1035 + for character set restrictions. - The ien116-name-servers option specifies a list of IEN 116 + ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6;; + This option specifies the length in 512-octet blocks of the default + boot image for the client. + ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g;; - Page 2 (printed 11/17/99) + This option specifies the path-name of a file to which the client’s + core image should be dumped in the event the client crashes. The + path is formatted as a character string consisting of characters + from the NVT ASCII character set. + ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g;; + This option specifies the domain name that client should use when + resolving hostnames via the Domain Name System. + ooppttiioonn sswwaapp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s;; + This specifies the IP address of the client’s swap server. + ooppttiioonn rroooott--ppaatthh _s_t_r_i_n_g;; - ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) + This option specifies the path-name that contains the client’s root + disk. The path is formatted as a character string consisting of + characters from the NVT ASCII character set. + ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g;; + This option specifies whether the client should configure its IP + layer for packet forwarding. A value of 0 means disable IP forward‐ + ing, and a value of 1 means enable IP forwarding. - name servers available to the client. Servers should be - listed in order of preference. + ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g;; - ooooppppttttiiiioooonnnn ddddoooommmmaaaaiiiinnnn----nnnnaaaammmmeeee----sssseeeerrrrvvvveeeerrrrssss _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; + This option specifies whether the client should configure its IP + layer to allow forwarding of datagrams with non-local source routes + (see Section 3.3.5 of [4] for a discussion of this topic). A value + of 0 means disallow forwarding of such datagrams, and a value of 1 + means allow forwarding. - The domain-name-servers option specifies a list of Domain - Name System (STD 13, RFC 1035) name servers available to - the client. Servers should be listed in order of - preference. + ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s... + ];; - ooooppppttttiiiioooonnnn lllloooogggg----sssseeeerrrrvvvveeeerrrrssss _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; + This option specifies policy filters for non-local source routing. + The filters consist of a list of IP addresses and masks which spec‐ + ify destination/mask pairs with which to filter incoming source + routes. - The log-server option specifies a list of MIT-LCS UDP log - servers available to the client. Servers should be listed - in order of preference. + Any source routed datagram whose next-hop address does not match one + of the filters should be discarded by the client. - ooooppppttttiiiioooonnnn ccccooooooookkkkiiiieeee----sssseeeerrrrvvvveeeerrrrssss _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; + See STD 3 (RFC1122) for further information. - The cookie server option specifies a list of RFC 865 - cookie servers available to the client. Servers should be - listed in order of preference. + ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6;; - ooooppppttttiiiioooonnnn llllpppprrrr----sssseeeerrrrvvvveeeerrrrssss _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; + This option specifies the maximum size datagram that the client + should be prepared to reassemble. The minimum value legal value is + 576. - The LPR server option specifies a list of RFC 1179 line - printer servers available to the client. Servers should - be listed in order of preference. + ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8_; - ooooppppttttiiiioooonnnn iiiimmmmpppprrrreeeessssssss----sssseeeerrrrvvvveeeerrrrssss _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; + This option specifies the default time-to-live that the client + should use on outgoing datagrams. - The impress-server option specifies a list of Imagen - Impress servers available to the client. Servers should - be listed in order of preference. + ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2;; - ooooppppttttiiiioooonnnn rrrreeeessssoooouuuurrrrcccceeee----llllooooccccaaaattttiiiioooonnnn----sssseeeerrrrvvvveeeerrrrssss _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... - ];;;; + This option specifies the timeout (in seconds) to use when aging + Path MTU values discovered by the mechanism defined in RFC 1191. - This option specifies a list of RFC 887 Resource Location - servers available to the client. Servers should be listed - in order of preference. + ooppttiioonn ppaatthh--mmttuu--ppllaatteeaauu--ttaabbllee _u_i_n_t_1_6 [,, _u_i_n_t_1_6... ];; - ooooppppttttiiiioooonnnn hhhhoooosssstttt----nnnnaaaammmmeeee _s_t_r_i_n_g;;;; + This option specifies a table of MTU sizes to use when performing + Path MTU Discovery as defined in RFC 1191. The table is formatted + as a list of 16-bit unsigned integers, ordered from smallest to + largest. The minimum MTU value cannot be smaller than 68. - This option specifies the name of the client. The name - may or may not be qualified with the local domain name (it - is preferable to use the domain-name option to specify the - domain name). See RFC 1035 for character set - restrictions. + ooppttiioonn iinntteerrffaaccee--mmttuu _u_i_n_t_1_6;; - ooooppppttttiiiioooonnnn bbbbooooooootttt----ssssiiiizzzzeeee _u_i_n_t_1_6;;;; + This option specifies the MTU to use on this interface. The mini‐ + mum legal value for the MTU is 68. - This option specifies the length in 512-octet blocks of + ooppttiioonn aallll--ssuubbnneettss--llooccaall _f_l_a_g;; + This option specifies whether or not the client may assume that all + subnets of the IP network to which the client is connected use the + same MTU as the subnet of that network to which the client is + directly connected. A value of 1 indicates that all subnets share + the same MTU. A value of 0 means that the client should assume that + some subnets of the directly connected network may have smaller + MTUs. + ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; - Page 3 (printed 11/17/99) + This option specifies the broadcast address in use on the client’s + subnet. Legal values for broadcast addresses are specified in sec‐ + tion 3.2.1.3 of STD 3 (RFC1122). + ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g;; + This option specifies whether or not the client should perform sub‐ + net mask discovery using ICMP. A value of 0 indicates that the + client should not perform mask discovery. A value of 1 means that + the client should perform mask discovery. + ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g;; + This option specifies whether or not the client should respond to + subnet mask requests using ICMP. A value of 0 indicates that the + client should not respond. A value of 1 means that the client + should respond. + ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g;; - ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) + This option specifies whether or not the client should solicit + routers using the Router Discovery mechanism defined in RFC 1256. A + value of 0 indicates that the client should not perform router dis‐ + covery. A value of 1 means that the client should perform router + discovery. + ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; + This option specifies the address to which the client should trans‐ + mit router solicitation requests. - the default boot image for the client. + ooppttiioonn ssttaattiicc--rroouutteess _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s... + ];; - ooooppppttttiiiioooonnnn mmmmeeeerrrriiiitttt----dddduuuummmmpppp _s_t_r_i_n_g;;;; + This option specifies a list of static routes that the client should + install in its routing cache. If multiple routes to the same desti‐ + nation are specified, they are listed in descending order of prior‐ + ity. - This option specifies the path-name of a file to which the - client's core image should be dumped in the event the - client crashes. The path is formatted as a character - string consisting of characters from the NVT ASCII - character set. + The routes consist of a list of IP address pairs. The first address + is the destination address, and the second address is the router for + the destination. - ooooppppttttiiiioooonnnn ddddoooommmmaaaaiiiinnnn----nnnnaaaammmmeeee _s_t_r_i_n_g;;;; + The default route (0.0.0.0) is an illegal destination for a static + route. To specify the default route, use the rroouutteerrss option. - This option specifies the domain name that client should - use when resolving hostnames via the Domain Name System. + ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g;; - ooooppppttttiiiioooonnnn sssswwwwaaaapppp----sssseeeerrrrvvvveeeerrrr _i_p-_a_d_d_r_e_s_s;;;; + This option specifies whether or not the client should negotiate the + use of trailers (RFC 893 [14]) when using the ARP protocol. A value + of 0 indicates that the client should not attempt to use trailers. + A value of 1 means that the client should attempt to use trailers. - This specifies the IP address of the client's swap server. + ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2;; - ooooppppttttiiiioooonnnn rrrrooooooootttt----ppppaaaatttthhhh _s_t_r_i_n_g;;;; + This option specifies the timeout in seconds for ARP cache entries. - This option specifies the path-name that contains the - client's root disk. The path is formatted as a character - string consisting of characters from the NVT ASCII - character set. + ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g;; - ooooppppttttiiiioooonnnn iiiipppp----ffffoooorrrrwwwwaaaarrrrddddiiiinnnngggg _f_l_a_g;;;; + This option specifies whether or not the client should use Ethernet + Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the + interface is an Ethernet. A value of 0 indicates that the client + should use RFC 894 encapsulation. A value of 1 means that the + client should use RFC 1042 encapsulation. - This option specifies whether the client should configure - its IP layer for packet forwarding. A value of 0 means - disable IP forwarding, and a value of 1 means enable IP - forwarding. + ooppttiioonn ddeeffaauulltt--ttccpp--ttttll _u_i_n_t_8;; - ooooppppttttiiiioooonnnn nnnnoooonnnn----llllooooccccaaaallll----ssssoooouuuurrrrcccceeee----rrrroooouuuuttttiiiinnnngggg _f_l_a_g;;;; + This option specifies the default TTL that the client should use + when sending TCP segments. The minimum value is 1. - This option specifies whether the client should configure - its IP layer to allow forwarding of datagrams with non- - local source routes (see Section 3.3.5 of [4] for a - discussion of this topic). A value of 0 means disallow - forwarding of such datagrams, and a value of 1 means allow - forwarding. + ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2;; - ooooppppttttiiiioooonnnn ppppoooolllliiiiccccyyyy----ffffiiiilllltttteeeerrrr _i_p-_a_d_d_r_e_s_s _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s ];;;; + This option specifies the interval (in seconds) that the client TCP + should wait before sending a keepalive message on a TCP connection. + The time is specified as a 32-bit unsigned integer. A value of zero + indicates that the client should not generate keepalive messages on + connections unless specifically requested by an application. - This option specifies policy filters for non-local source - routing. The filters consist of a list of IP addresses - and masks which specify destination/mask pairs with which - to filter incoming source routes. + ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g;; - Any source routed datagram whose next-hop address does not - match one of the filters should be discarded by the - client. + This option specifies the whether or not the client should send TCP + keepalive messages with a octet of garbage for compatibility with + older implementations. A value of 0 indicates that a garbage octet + should not be sent. A value of 1 indicates that a garbage octet + should be sent. + ooppttiioonn nniiss--ddoommaaiinn _s_t_r_i_n_g;; + This option specifies the name of the client’s NIS (Sun Network + Information Services) domain. The domain is formatted as a charac‐ + ter string consisting of characters from the NVT ASCII character + set. - Page 4 (printed 11/17/99) + ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; + This option specifies a list of IP addresses indicating NIS servers + available to the client. Servers should be listed in order of pref‐ + erence. + ooppttiioonn nnttpp--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; + This option specifies a list of IP addresses indicating NTP (RFC + 1305) servers available to the client. Servers should be listed in + order of preference. + ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; + The NetBIOS name server (NBNS) option specifies a list of RFC + 1001/1002 NBNS name servers listed in order of preference. NetBIOS + Name Service is currently more commonly referred to as WINS. WINS + servers can be specified using the netbios-name-servers option. - ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) + ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; + The NetBIOS datagram distribution server (NBDD) option specifies a + list of RFC 1001/1002 NBDD servers listed in order of preference. + ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8;; - See STD 3 (RFC1122) for further information. + The NetBIOS node type option allows NetBIOS over TCP/IP clients + which are configurable to be configured as described in RFC + 1001/1002. The value is specified as a single octet which identi‐ + fies the client type. - ooooppppttttiiiioooonnnn mmmmaaaaxxxx----ddddggggrrrraaaammmm----rrrreeeeaaaasssssssseeeemmmmbbbbllllyyyy _u_i_n_t_1_6;;;; + Possible node types are: - This option specifies the maximum size datagram that the - client should be prepared to reassemble. The minimum - value legal value is 576. - ooooppppttttiiiioooonnnn ddddeeeeffffaaaauuuulllltttt----iiiipppp----ttttttttllll _u_i_n_t_8; + _1 B-node: Broadcast - no WINS - This option specifies the default time-to-live that the - client should use on outgoing datagrams. + _2 P-node: Peer - WINS only. - ooooppppttttiiiioooonnnn ppppaaaatttthhhh----mmmmttttuuuu----aaaaggggiiiinnnngggg----ttttiiiimmmmeeeeoooouuuutttt _u_i_n_t_3_2;;;; + _4 M-node: Mixed - broadcast, then WINS - This option specifies the timeout (in seconds) to use when - aging Path MTU values discovered by the mechanism defined - in RFC 1191. + _8 H-node: Hybrid - WINS, then broadcast - ooooppppttttiiiioooonnnn ppppaaaatttthhhh----mmmmttttuuuu----ppppllllaaaatttteeeeaaaauuuu----ttttaaaabbbblllleeee _u_i_n_t_1_6 [,,,, _u_i_n_t_1_6... ];;;; + ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g;; - This option specifies a table of MTU sizes to use when - performing Path MTU Discovery as defined in RFC 1191. The - table is formatted as a list of 16-bit unsigned integers, - ordered from smallest to largest. The minimum MTU value - cannot be smaller than 68. + The NetBIOS scope option specifies the NetBIOS over TCP/IP scope + parameter for the client as specified in RFC 1001/1002. See RFC1001, + RFC1002, and RFC1035 for character-set restrictions. - ooooppppttttiiiioooonnnn iiiinnnntttteeeerrrrffffaaaacccceeee----mmmmttttuuuu _u_i_n_t_1_6;;;; + ooppttiioonn ffoonntt--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - This option specifies the MTU to use on this interface. - The minimum legal value for the MTU is 68. + This option specifies a list of X Window System Font servers avail‐ + able to the client. Servers should be listed in order of preference. - ooooppppttttiiiioooonnnn aaaallllllll----ssssuuuubbbbnnnneeeettttssss----llllooooccccaaaallll _f_l_a_g;;;; + ooppttiioonn xx--ddiissppllaayy--mmaannaaggeerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - This option specifies whether or not the client may assume - that all subnets of the IP network to which the client is - connected use the same MTU as the subnet of that network - to which the client is directly connected. A value of 1 - indicates that all subnets share the same MTU. A value of - 0 means that the client should assume that some subnets of - the directly connected network may have smaller MTUs. + This option specifies a list of systems that are running the X Win‐ + dow System Display Manager and are available to the client. + Addresses should be listed in order of preference. - ooooppppttttiiiioooonnnn bbbbrrrrooooaaaaddddccccaaaasssstttt----aaaaddddddddrrrreeeessssssss _i_p-_a_d_d_r_e_s_s;;;; + ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _d_a_t_a_-_s_t_r_i_n_g;; - This option specifies the broadcast address in use on the - client's subnet. Legal values for broadcast addresses are - specified in section 3.2.1.3 of STD 3 (RFC1122). + This option can be used to specify the a DHCP client identifier in a + host declaration, so that dhcpd can find the host record by matching + against the client identifier. + ooppttiioonn nniisspplluuss--ddoommaaiinn _s_t_r_i_n_g;; - ooooppppttttiiiioooonnnn ppppeeeerrrrffffoooorrrrmmmm----mmmmaaaasssskkkk----ddddiiiissssccccoooovvvveeeerrrryyyy _f_l_a_g;;;; + This option specifies the name of the client’s NIS+ domain. The + domain is formatted as a character string consisting of characters + from the NVT ASCII character set. + ooppttiioonn nniisspplluuss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - This option specifies whether or not the client should - perform subnet mask discovery using ICMP. A value of 0 + This option specifies a list of IP addresses indicating NIS+ servers + available to the client. Servers should be listed in order of pref‐ + erence. + ooppttiioonn ttffttpp--sseerrvveerr--nnaammee _s_t_r_i_n_g;; + This option is used to identify a TFTP server and, if supported by + the client, should have the same effect as the sseerrvveerr--nnaammee declara‐ + tion. BOOTP clients are unlikely to support this option. Some + DHCP clients will support it, and others actually require it. - Page 5 (printed 11/17/99) + ooppttiioonn bboooottffiillee--nnaammee _s_t_r_i_n_g;; + This option is used to identify a bootstrap file. If supported by + the client, it should have the same effect as the ffiilleennaammee declara‐ + tion. BOOTP clients are unlikely to support this option. Some DHCP + clients will support it, and others actually require it. + ooppttiioonn mmoobbiillee--iipp--hhoommee--aaggeenntt _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; + This option specifies a list of IP addresses indicating mobile IP + home agents available to the client. Agents should be listed in + order of preference, although normally there will be only one such + agent. + ooppttiioonn ssmmttpp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; + The SMTP server option specifies a list of SMTP servers available to + the client. Servers should be listed in order of preference. - ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) + ooppttiioonn ppoopp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; + The POP3 server option specifies a list of POP3 available to the + client. Servers should be listed in order of preference. + ooppttiioonn nnnnttpp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - indicates that the client should not perform mask - discovery. A value of 1 means that the client should - perform mask discovery. + The NNTP server option specifies a list of NNTP available to the + client. Servers should be listed in order of preference. - ooooppppttttiiiioooonnnn mmmmaaaasssskkkk----ssssuuuupppppppplllliiiieeeerrrr _f_l_a_g;;;; + ooppttiioonn wwwwww--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - This option specifies whether or not the client should - respond to subnet mask requests using ICMP. A value of 0 - indicates that the client should not respond. A value of - 1 means that the client should respond. + The WWW server option specifies a list of WWW available to the + client. Servers should be listed in order of preference. - ooooppppttttiiiioooonnnn rrrroooouuuutttteeeerrrr----ddddiiiissssccccoooovvvveeeerrrryyyy _f_l_a_g;;;; + ooppttiioonn ffiinnggeerr--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - This option specifies whether or not the client should - solicit routers using the Router Discovery mechanism - defined in RFC 1256. A value of 0 indicates that the - client should not perform router discovery. A value of 1 - means that the client should perform router discovery. + The Finger server option specifies a list of Finger available to the + client. Servers should be listed in order of preference. - ooooppppttttiiiioooonnnn rrrroooouuuutttteeeerrrr----ssssoooolllliiiicccciiiittttaaaattttiiiioooonnnn----aaaaddddddddrrrreeeessssssss _i_p-_a_d_d_r_e_s_s;;;; + ooppttiioonn iirrcc--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - This option specifies the address to which the client - should transmit router solicitation requests. + The IRC server option specifies a list of IRC available to the + client. Servers should be listed in order of preference. - ooooppppttttiiiioooonnnn ssssttttaaaattttiiiicccc----rrrroooouuuutttteeeessss _i_p-_a_d_d_r_e_s_s _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s ];;;; + ooppttiioonn ssttrreeeettttaallkk--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - This option specifies a list of static routes that the - client should install in its routing cache. If multiple - routes to the same destination are specified, they are - listed in descending order of priority. + The StreetTalk server option specifies a list of StreetTalk servers + available to the client. Servers should be listed in order of pref‐ + erence. - The routes consist of a list of IP address pairs. The - first address is the destination address, and the second - address is the router for the destination. + ooppttiioonn ssttrreeeettaallkk--ddiirreeccttoorryy--aassssiissttaannccee--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_- + _a_d_d_r_e_s_s... ];; - The default route (0.0.0.0) is an illegal destination for - a static route. To specify the default route, use the - rrrroooouuuutttteeeerrrrssss option. + The StreetTalk Directory Assistance (STDA) server option specifies a + list of STDA servers available to the client. Servers should be + listed in order of preference. - ooooppppttttiiiioooonnnn ttttrrrraaaaiiiilllleeeerrrr----eeeennnnccccaaaappppssssuuuullllaaaattttiiiioooonnnn _f_l_a_g;;;; +SSEEEE AALLSSOO + dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcpd(8), + dhclient(8), RFC2132, RFC2131. - This option specifies whether or not the client should - negotiate the use of trailers (RFC 893 [14]) when using - the ARP protocol. A value of 0 indicates that the client - should not attempt to use trailers. A value of 1 means - that the client should attempt to use trailers. - - ooooppppttttiiiioooonnnn aaaarrrrpppp----ccccaaaacccchhhheeee----ttttiiiimmmmeeeeoooouuuutttt _u_i_n_t_3_2;;;; - - This option specifies the timeout in seconds for ARP cache - entries. - - - - - Page 6 (printed 11/17/99) - - - - - - - ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) - - - - ooooppppttttiiiioooonnnn iiiieeeeeeeeeeee888800002222----3333----eeeennnnccccaaaappppssssuuuullllaaaattttiiiioooonnnn _f_l_a_g;;;; - - This option specifies whether or not the client should use - Ethernet Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) - encapsulation if the interface is an Ethernet. A value of - 0 indicates that the client should use RFC 894 - encapsulation. A value of 1 means that the client should - use RFC 1042 encapsulation. - - ooooppppttttiiiioooonnnn ddddeeeeffffaaaauuuulllltttt----ttttccccpppp----ttttttttllll _u_i_n_t_8;;;; - - This option specifies the default TTL that the client - should use when sending TCP segments. The minimum value - is 1. - - ooooppppttttiiiioooonnnn ttttccccpppp----kkkkeeeeeeeeppppaaaalllliiiivvvveeee----iiiinnnntttteeeerrrrvvvvaaaallll _u_i_n_t_3_2;;;; - - This option specifies the interval (in seconds) that the - client TCP should wait before sending a keepalive message - on a TCP connection. The time is specified as a 32-bit - unsigned integer. A value of zero indicates that the - client should not generate keepalive messages on - connections unless specifically requested by an - application. - - ooooppppttttiiiioooonnnn ttttccccpppp----kkkkeeeeeeeeppppaaaalllliiiivvvveeee----ggggaaaarrrrbbbbaaaaggggeeee _f_l_a_g;;;; - - This option specifies the whether or not the client should - send TCP keepalive messages with a octet of garbage for - compatibility with older implementations. A value of 0 - indicates that a garbage octet should not be sent. A value - of 1 indicates that a garbage octet should be sent. - - ooooppppttttiiiioooonnnn nnnniiiissss----ddddoooommmmaaaaiiiinnnn _s_t_r_i_n_g;;;; - - This option specifies the name of the client's NIS (Sun - Network Information Services) domain. The domain is - formatted as a character string consisting of characters - from the NVT ASCII character set. - - ooooppppttttiiiioooonnnn nnnniiiissss----sssseeeerrrrvvvveeeerrrrssss _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - This option specifies a list of IP addresses indicating - NIS servers available to the client. Servers should be - listed in order of preference. - - ooooppppttttiiiioooonnnn nnnnttttpppp----sssseeeerrrrvvvveeeerrrrssss _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - This option specifies a list of IP addresses indicating - NTP (RFC 1035) servers available to the client. Servers - should be listed in order of preference. - - - - - Page 7 (printed 11/17/99) - - - - - - - ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) - - - - ooooppppttttiiiioooonnnn nnnneeeettttbbbbiiiioooossss----nnnnaaaammmmeeee----sssseeeerrrrvvvveeeerrrrssss _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - The NetBIOS name server (NBNS) option specifies a list of - RFC 1001/1002 NBNS name servers listed in order of - preference. NetBIOS Name Service is currently more - commonly referred to as WINS. WINS servers can be - specified using the netbios-name-servers option. - - ooooppppttttiiiioooonnnn nnnneeeettttbbbbiiiioooossss----dddddddd----sssseeeerrrrvvvveeeerrrr _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - The NetBIOS datagram distribution server (NBDD) option - specifies a list of RFC 1001/1002 NBDD servers listed in - order of preference. - - ooooppppttttiiiioooonnnn nnnneeeettttbbbbiiiioooossss----nnnnooooddddeeee----ttttyyyyppppeeee _u_i_n_t_8;;;; - - The NetBIOS node type option allows NetBIOS over TCP/IP - clients which are configurable to be configured as - described in RFC 1001/1002. The value is specified as a - single octet which identifies the client type. - - Possible node types are: - - _1 B-node: Broadcast - no WINS - - _2 P-node: Peer - WINS only. - - _4 M-node: Mixed - broadcast, then WINS - - _8 H-node: Hybrid - WINS, then broadcast - - ooooppppttttiiiioooonnnn nnnneeeettttbbbbiiiioooossss----ssssccccooooppppeeee _s_t_r_i_n_g;;;; - - The NetBIOS scope option specifies the NetBIOS over TCP/IP - scope parameter for the client as specified in RFC - 1001/1002. See RFC1001, RFC1002, and RFC1035 for - character-set restrictions. - - ooooppppttttiiiioooonnnn ffffoooonnnntttt----sssseeeerrrrvvvveeeerrrrssss _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - This option specifies a list of X Window System Font - servers available to the client. Servers should be listed - in order of preference. - - ooooppppttttiiiioooonnnn xxxx----ddddiiiissssppppllllaaaayyyy----mmmmaaaannnnaaaaggggeeeerrrr _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - This option specifies a list of systems that are running - the X Window System Display Manager and are available to - the client. Addresses should be listed in order of - preference. - - ooooppppttttiiiioooonnnn ddddhhhhccccpppp----cccclllliiiieeeennnntttt----iiiiddddeeeennnnttttiiiiffffiiiieeeerrrr _d_a_t_a-_s_t_r_i_n_g;;;; - - - - Page 8 (printed 11/17/99) - - - - - - - ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) - - - - This option can be used to specify the a DHCP client - identifier in a host declaration, so that dhcpd can find - the host record by matching against the client identifier. - ooooppppttttiiiioooonnnn nnnniiiisssspppplllluuuussss----ddddoooommmmaaaaiiiinnnn _s_t_r_i_n_g;;;; - - This option specifies the name of the client's NIS+ - domain. The domain is formatted as a character string - consisting of characters from the NVT ASCII character set. - ooooppppttttiiiioooonnnn nnnniiiisssspppplllluuuussss----sssseeeerrrrvvvveeeerrrrssss _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - This option specifies a list of IP addresses indicating - NIS+ servers available to the client. Servers should be - listed in order of preference. - - ooooppppttttiiiioooonnnn ttttffffttttpppp----sssseeeerrrrvvvveeeerrrr----nnnnaaaammmmeeee _s_t_r_i_n_g;;;; - - This option is used to identify a TFTP server and, if - supported by the client, should have the same effect as - the sssseeeerrrrvvvveeeerrrr----nnnnaaaammmmeeee declaration. BOOTP clients are unlikely - to support this option. Some DHCP clients will support - it, and others actually require it. - - ooooppppttttiiiioooonnnn bbbboooooooottttffffiiiilllleeee----nnnnaaaammmmeeee _s_t_r_i_n_g;;;; - - This option is used to identify a bootstrap file. If - supported by the client, it should have the same effect as - the ffffiiiilllleeeennnnaaaammmmeeee declaration. BOOTP clients are unlikely to - support this option. Some DHCP clients will support it, - and others actually require it. - - ooooppppttttiiiioooonnnn mmmmoooobbbbiiiilllleeee----iiiipppp----hhhhoooommmmeeee----aaaaggggeeeennnntttt _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - This option specifies a list of IP addresses indicating - mobile IP home agents available to the client. Agents - should be listed in order of preference, although normally - there will be only one such agent. - - ooooppppttttiiiioooonnnn ssssmmmmttttpppp----sssseeeerrrrvvvveeeerrrr _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - The SMTP server option specifies a list of SMTP servers - available to the client. Servers should be listed in - order of preference. - - ooooppppttttiiiioooonnnn ppppoooopppp----sssseeeerrrrvvvveeeerrrr _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - The POP3 server option specifies a list of POP3 available - to the client. Servers should be listed in order of - preference. - - ooooppppttttiiiioooonnnn nnnnnnnnttttpppp----sssseeeerrrrvvvveeeerrrr _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - The NNTP server option specifies a list of NNTP available - - - - Page 9 (printed 11/17/99) - - - - - - - ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) ddddhhhhccccppppdddd----ooooppppttttiiiioooonnnnssss((((5555)))) - - - - to the client. Servers should be listed in order of - preference. - - ooooppppttttiiiioooonnnn wwwwwwwwwwww----sssseeeerrrrvvvveeeerrrr _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - The WWW server option specifies a list of WWW available to - the client. Servers should be listed in order of - preference. - - ooooppppttttiiiioooonnnn ffffiiiinnnnggggeeeerrrr----sssseeeerrrrvvvveeeerrrr _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - The Finger server option specifies a list of Finger - available to the client. Servers should be listed in - order of preference. - - ooooppppttttiiiioooonnnn iiiirrrrcccc----sssseeeerrrrvvvveeeerrrr _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - The IRC server option specifies a list of IRC available to - the client. Servers should be listed in order of - preference. - - ooooppppttttiiiioooonnnn ssssttttrrrreeeeeeeettttttttaaaallllkkkk----sssseeeerrrrvvvveeeerrrr _i_p-_a_d_d_r_e_s_s [,,,, _i_p-_a_d_d_r_e_s_s... ];;;; - - The StreetTalk server option specifies a list of - StreetTalk servers available to the client. Servers - should be listed in order of preference. - - ooooppppttttiiiioooonnnn ssssttttrrrreeeeeeeettttaaaallllkkkk----ddddiiiirrrreeeeccccttttoooorrrryyyy----aaaassssssssiiiissssttttaaaannnncccceeee----sssseeeerrrrvvvveeeerrrr _i_p-_a_d_d_r_e_s_s [,,,, - _i_p-_a_d_d_r_e_s_s... ];;;; - - The StreetTalk Directory Assistance (STDA) server option - specifies a list of STDA servers available to the client. - Servers should be listed in order of preference. - - SSSSEEEEEEEE AAAALLLLSSSSOOOO - dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcpd(8), - dhclient(8), RFC2132, RFC2131. - - AAAAUUUUTTTTHHHHOOOORRRR - ddddhhhhccccppppdddd((((8888)))) was written by Ted Lemon under a - contract with Vixie Labs. Funding for this project was - provided by the Internet Software Corporation. Information - about the Internet Software Consortium can be found at - hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc.... - - - - - - - - - - - - Page 10 (printed 11/17/99) +AAUUTTHHOORR + ddhhccppdd((88)) was written by Ted Lemon under a contract + with Vixie Labs. Funding for this project was provided by the Inter‐ + net Software Corporation. Information about the Internet Software Con‐ + sortium can be found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. + dhcpd-options(5)