rpms/dhcp/devel linux, 1.9, 1.10 libdhcp_control.h, 1.5, 1.6 libdhcp4client.pc, 1.5, 1.6 get-ldap-patch.sh, 1.2, 1.3 draft-ietf-dhc-ldap-schema-01.txt, 1.4, 1.5 dhcrelay.init, 1.8, 1.9 dhcpd.init, 1.24, 1.25 dhcpd.conf.sample, 1.5, 1.6 dhclient-script.8, 1.3, 1.4 dhclient.8, 1.3, 1.4 dhclient.conf.5, 1.3, 1.4 dhcp-options.5, 1.3, 1.4 dhcpd.conf.5, 1.3, 1.4 dhcpctl.3, 1.2, 1.3 dhcp4client.h, 1.4, 1.5 dhcp.schema, 1.3, 1.4 sources, 1.21, 1.22
David Cantrell (dcantrel)
fedora-extras-commits at redhat.com
Fri Jan 11 00:14:55 UTC 2008
- Previous message (by thread): rpms/soundconverter/F-8 .cvsignore, 1.10, 1.11 soundconverter.spec, 1.15, 1.16 sources, 1.10, 1.11
- Next message (by thread): rpms/dhcp/devel dhcpd-conf-to-ldap, 1.7, 1.8 dhcpd.conf, 1.2, 1.3 dhcp-3.1.0-xen-checksum.patch, 1.2, 1.3 dhcp-3.1.0-warnings.patch, 1.3, 1.4 dhcp-3.1.0-options.patch, 1.2, 1.3 dhcp-3.1.0-ldap-configuration.patch, 1.3, 1.4 dhcp-3.1.0-dhclient-usage.patch, 1.2, 1.3 dhcp-3.1.0-dhclient-anycast.patch, 1.2, 1.3 dhcp-3.0.6-memory.patch, 1.2, 1.3 dhcp-3.0.6-ignore-hyphen-x.patch, 1.2, 1.3 dhcp-3.0.5-unicast-bootp.patch, 1.2, 1.3 dhcp-3.0.5-selinux.patch, 1.2, 1.3 dhcp-3.0.5-release-by-ifup.patch, 1.2, 1.3 dhcp-3.0.5-prototypes.patch, 1.2, 1.3 dhcp-3.0.5-inherit-leases.patch, 1.2, 1.3 dhcp-3.0.5-fast-timeout.patch, 1.2, 1.3
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Author: dcantrel
Update of /cvs/pkgs/rpms/dhcp/devel
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv23698
Modified Files:
sources
Added Files:
linux libdhcp_control.h libdhcp4client.pc get-ldap-patch.sh
draft-ietf-dhc-ldap-schema-01.txt dhcrelay.init dhcpd.init
dhcpd.conf.sample dhclient-script.8 dhclient.8 dhclient.conf.5
dhcp-options.5 dhcpd.conf.5 dhcpctl.3 dhcp4client.h
dhcp.schema
Log Message:
Revert to dhcp-3.1.0 for now.
Index: linux
===================================================================
RCS file: linux
diff -N linux
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ linux 11 Jan 2008 00:14:20 -0000 1.10
@@ -0,0 +1,557 @@
+#!/bin/bash
+# dhclient-script for Linux. Dan Halbert, March, 1997.
+# 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.
+#
+# Modified by David Cantrell <dcantrell at redhat.com> for Fedora and RHEL
+
+# Notes:
+
+# 0. This script is based on the netbsd script supplied with dhcp-970306.
+
+# 1. ifconfig down apparently deletes all relevant routes and flushes
+# the arp cache, so this doesn't need to be done explicitly.
+
+# 2. The alias address handling here has not been tested AT ALL.
+# I'm just going by the doc of modern Linux ip aliasing, which uses
+# notations like eth0:0, eth0:1, for each alias.
+
+# 3. I have to calculate the network address, and calculate the broadcast
+# address if it is not supplied. This might be much more easily done
+# by the dhclient C code, and passed on.
+
+PATH=/bin:/usr/bin
+
+function save_previous() {
+ if [ -e $1 ]; then
+ mv $1 $1.predhclient
+ else
+ echo ''> $1.predhclient
+ fi
+}
+
+make_resolv_conf() {
+ if [ "${PEERDNS}" == "no" ]; then
+ return
+ fi
+
+ if [ x$reason == xRENEW ] &&
+ [ "$new_domain_name" == "$old_domain_name" ] &&
+ [ "$new_domain_name_servers" == "$old_domain_name_servers" ]; then
+ return
+ fi
+
+ if [ -n "$new_domain_name" ] || [ -n "$new_domain_name_servers" ]; then
+ cp -fp /etc/resolv.conf /etc/resolv.conf.predhclient
+ rscf=`mktemp /tmp/XXXXXX`;
+ echo '; generated by /sbin/dhclient-script' > $rscf
+
+ if [ -n "$SEARCH" ]; then
+ echo search $SEARCH >> $rscf
+ else
+ if [ -n "$new_domain_name" ]; then
+ echo search $new_domain_name >> $rscf
+ fi
+ fi
+
+ for nameserver in $new_domain_name_servers; do
+ echo nameserver $nameserver >> $rscf
+ done
+
+ change_resolv_conf $rscf
+ rm -f $rscf
+ fi
+}
+
+# Must be used on exit. Invokes the local dhcp client exit hooks, if any.
+exit_with_hooks() {
+ exit_status=$1
+
+ 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
+}
+
+# Invoke the local dhcp client enter hooks, if they exist.
+if [ -f /etc/dhclient-enter-hooks ]; then
+ exit_status=0
+ . /etc/dhclient-enter-hooks
+ # allow the local script to abort processing of this state
+ # local script must set exit_status variable to nonzero.
+ if [ $exit_status -ne 0 ]; then
+ exit $exit_status
+ fi
+fi
+
+# Import Red Hat Linux configuration
+cd /etc/sysconfig/network-scripts;
+. /etc/sysconfig/network-scripts/network-functions
+. /etc/rc.d/init.d/functions
+
+[ -f ../network ] && . ../network
+[ -f ../networking/network ] && . ../networking/network
+
+CONFIG=$interface
+
+need_config ${CONFIG}
+
+if [ -f "${CONFIG}" ]; then
+ source_config
+else
+ echo $"$0: configuration for $interface not found. Continuing with defaults." >&2
+fi
+
+source_config
+
+release=$(uname -r)
+relmajor=$(echo $release | cut -f1 -d'.')
+relminor=$(echo $release | cut -f2 -d'.')
+
+# simple IP arithmetic functions:
+function quad2num() {
+ if [ $# -eq 4 ]; then
+ let n="$1<<24|$2<<16|$3<<8|$4"
+ echo $n
+ return 0
+ fi
+ echo '0'
+ return 1
+}
+
+function ip2num() {
+ IFS='.' quad2num $1
+}
+
+function num2ip() {
+ let n="$1"
+ let o1='(n>>24)&0xff'
+ let o2='(n>>16)&0xff'
+ let o3='(n>>8)&0xff'
+ let o4='n & 0xff'
+ echo $o1.$o2.$o3.$o4
+}
+
+function mask() {
+ ip=$1
+ m=$2
+ let ip=$(IFS='.' ip2num $ip)
+ let m=$(IFS='.' ip2num $m)
+ let n='ip&m'
+ num2ip $n
+}
+
+function mask_bits() {
+ ip=$1
+ let ip=$(IFS='.' ip2num $ip)
+ let bits=0
+ for ((bit=1; '((ip&bit)==0) && (bits < 32)'; 'bit<<=1')) do
+ let bits+=1
+ done
+ let n_bits=32-bits
+ echo $n_bits
+}
+
+function class_bits() {
+ let ip=$(IFS='.' ip2num $1)
+ let bits=32
+ let mask='255'
+ for ((i=0; i <= 3; i++, 'mask<<=8')); do
+ let v='ip&mask'
+ if [ "$v" -eq 0 ] ; then
+ let bits-=8
+ else
+ break
+ fi
+ done
+ echo $bits
+}
+
+function routerReachable() {
+ # Handle silly DHCP servers that give us a router not on our subnet:
+ router=$1
+ routerSubnet=$(mask $router $new_subnet_mask)
+ mySubnet=$(mask $new_ip_address $new_subnet_mask)
+ unreachable=0
+ if [ "$routerSubnet" != "$mySubnet" ]; then
+ unreachable=1
+ if /sbin/arping -f -q -I $interface -w2 $router; then
+ /sbin/ip route add ${router}/32 dev $interface
+ if [ $? -eq 0 ]; then
+ unreachable=0
+ else
+ /usr/bin/logger -p local7.notice -t "NET" "dhclient: failed to create host route for unreachable router $router not on subnet $mySubnet";
+ fi
+ else
+ unreachable=1
+ if [ -x /usr/bin/logger ]; then
+ /usr/bin/logger -p local7.notice -t "NET" "dhclient: DHCP router $router is unreachable on DHCP subnet $mySubnet router subnet $routerSubnet";
+ fi
+ fi
+ fi
+ return $unreachable
+}
+
+function add_default_gateway() {
+ router=$1
+ metric=''
+ if [ $# -gt 1 ] && [ "$2" -gt 0 ]; then
+ metric="metric $2"
+ fi
+ if routerReachable $router ; then
+ /sbin/ip route replace default via $router dev $interface $metric
+ if [ $? -ne 0 ]; then
+ /usr/bin/logger -p local7.notice -t "NET" 'dhclient: failed to create default route: '$router dev $interface $metric
+ return 1
+ else
+ return 0
+ fi
+ fi
+ return 1
+}
+
+function dhconfig() {
+ if [ x$old_ip_address != x ] && [ x$alias_ip_address != x ] && [ x$alias_ip_address != x$old_ip_address ]; then
+ # Possible new alias. Remove old alias.
+ ifconfig $interface:0- inet 0
+ fi
+
+ if [ x$old_ip_address != x ] && [ x$old_ip_address != x$new_ip_address ]; then
+ # IP address changed. Bringing down the interface will delete all
+ # routes, and clear the ARP cache.
+ ifconfig $interface inet 0 down
+ fi
+
+ if [ x$reason = xBOUND ] || [ x$reason = xREBOOT ] ||
+ [ x$old_ip_address != x$new_ip_address ] ||
+ [ x$old_subnet_mask != x$new_subnet_mask ] ||
+ [ x$new_network_number != x$new_network_number ] ||
+ [ x$old_broadcast_address != x$new_broadcast_address ] ||
+ [ "x$old_routers" != "x$new_routers" ] ||
+ [ x$old_interface_mtu != x$new_interface_mtu ] ; then
+ ifconfig $interface inet $new_ip_address $new_subnet_arg $new_broadcast_arg
+ if [ -n "$new_interface_mtu" ]; then
+ /sbin/ip link set $interface mtu $new_interface_mtu
+ fi
+
+ if [ -x /etc/dhclient-${interface}-up-hooks ]; then
+ . /etc/dhclient-${interface}-up-hooks
+ elif [ -x /etc/dhclient-up-hooks ]; then
+ . /etc/dhclient-up-hooks
+ fi
+
+ prefix_bits=$(mask_bits $new_subnet_mask)
+ # Add a network route to the computed network address.
+ if [ $relmajor -lt 2 ] || ( [ $relmajor -eq 2 ] && [ $relminor -eq 0 ] ); then
+ /sbin/ip route replace ${new_network_number}/${prefix_bits} dev $interface
+ if [ $added_old_broadcast_route -eq 1 ]; then
+ /sbin/ip route del default
+ fi
+ fi
+
+ if [[ (( -z "$GATEWAYDEV" ) || ( "$GATEWAYDEV" = "$interface" )) && (( -z "$GATEWAY" ) || (( -n "$DHCLIENT_IGNORE_GATEWAY" ) && ( "$DHCLIENT_IGNORE_GATEWAY" = [Yy]* ))) ]]; then
+ metric=${METRIC:-''}
+ let i=${METRIC:-0}
+ default_routers=()
+
+ for router in $new_routers; do
+ added_router=0
+
+ for r in ${default_routers[@]}; do
+ if [ "$r" == "$router" ]; then
+ added_router=1
+ fi
+ done
+
+ if [ -z "$router" ] || [ "$added_router" -eq 1 ] || [ $(IFS=. ip2num $router) -le 0 ] || [[ ( "$router" = "$new_broadcast_address" ) && ( "$new_subnet_mask" != "255.255.255.255" ) ]]; then
+ continue
+ fi
+
+ default_routers=(${default_routers[@]} $router)
+ add_default_gateway $router $metric
+ let i=i+1
+ metric=$i
+ done
+ elif [[ (( -z "$GATEWAYDEV" ) || ( "$GATEWAYDEV" = "$interface" )) && ( -n "$GATEWAY" ) ]]; then
+ routerSubnet=$(mask $GATEWAY $new_subnet_mask)
+ mySubnet=$(mask $new_ip_address $new_subnet_mask)
+
+ if [ "$routerSubnet" = "$mySubnet" ]; then
+ /sbin/ip route replace default via $GATEWAY dev $interface
+ fi
+ fi
+
+ # static routes
+ if [ "x$new_static_routes" != x ]; then
+ IFS=', ' static_routes=($new_static_routes)
+ route_targets=()
+
+ for((i=0; i<${#static_routes[@]}; i+=2)); do
+ target=${static_routes[$i]}
+ gateway=${static_routes[$i+1]}
+ metric=''
+
+ for t in ${route_targets[@]}; do
+ if [ $t == $target ]; then
+ if [ -z "$metric" ]; then
+ metric=1
+ else
+ ((metric=metric+1))
+ fi
+ fi
+ done
+
+ if [ -n "$metric" ]; then
+ metric="metric $metric"
+ fi
+
+ if routerReachable $gateway; then
+ /sbin/ip route replace ${target}/$(class_bits $target) via ${gateway} dev $interface ${metric}
+
+ if [ $? -ne 0 ]; then
+ /usr/bin/logger -p local7.notice -t 'NET' 'dhclient: failed to create static route:' ${target}/`class_bits $target` via ${gateway} dev $interface ${metric}
+ else
+ route_targets=(${route_targets[@]} $target)
+ fi
+ fi
+ done
+ fi
+ fi
+
+ if [ x$new_ip_address != x$alias_ip_address ] && [ x$alias_ip_address != x ]; then
+ ifconfig $interface:0- inet 0
+ ifconfig $interface:0 inet $alias_ip_address $alias_subnet_arg
+ /sbin/ip route replace ${alias_ip_address}/32 dev $interface:0
+ fi
+
+ make_resolv_conf
+
+ if [ -n "$new_host_name" ] && need_hostname; then
+ hostname $new_host_name
+ fi
+
+ if [ "${PEERNIS}" = no ]; then
+ :
+ elif [ -n "$new_nis_domain" ]; then
+ domainname "$new_nis_domain"
+ save_previous /etc/yp.conf
+ let contents=0
+ echo '# generated by /sbin/dhclient-script' > /etc/yp.conf
+
+ if [ -n "$new_nis_servers" ]; then
+ for I in $new_nis_servers; do
+ echo "domain $new_nis_domain server $I" >> /etc/yp.conf
+ let contents=contents+1
+ done
+ else
+ echo "domain $new_nis_domain broadcast" >> /etc/yp.conf
+ let contents=contents+1
+ fi
+
+ if [ $contents -gt 0 ] && [ -r /var/run/ypbind.pid ] && yppid=$(cat /var/run/ypbind.pid) && [ -d /proc/${yppid} ] && [ "$(if [ -x /usr/bin/readlink ]; then readlink /proc/${yppid}/exe; else echo /sbin/ypbind; fi)" = "/sbin/ypbind" ]; then
+ kill -HUP $yppid
+ fi
+ elif [ -n "$new_nis_servers" ]; then
+ save_previous /etc/yp.conf
+ echo '# generated by /sbin/dhclient-script' > /etc/yp.conf
+ let contents=0
+
+ for I in $new_nis_servers; do
+ echo "ypserver $I" >> /etc/yp.conf
+ let contents=contents+1
+ done
+
+ if [ $contents -gt 0 ] && [ -r /var/run/ypbind.pid ] && yppid=$(cat /var/run/ypbind.pid) && [ -d /proc/${yppid} ] && [ "$(if [ -x /usr/bin/readlink ]; then readlink /proc/${yppid}/exe; else echo /sbin/ypbind; fi)" = "/sbin/ypbind" ]; then
+ kill -HUP $yppid
+ fi
+ fi
+
+ if [ -n "$DHCP_TIME_OFFSET_SETS_TIMEZONE" ] && [[ "$DHCP_TIME_OFFSET_SETS_TIMEZONE" = [yY1]* ]]; then
+ if [ -n "$new_time_offset" ]; then
+ # DHCP option "time-offset" is requested by default and should be
+ # handled. The geographical zone abbreviation cannot be determined
+ # from the GMT offset, but the $ZONEINFO/Etc/GMT$offset file can be
+ # used - note: this disables DST.
+ ((z=new_time_offset/3600))
+ ((hoursWest=$(printf '%+d' $z)))
+
+ if (( $hoursWest < 0 )); then
+ # tzdata treats negative 'hours west' as positive 'gmtoff'!
+ ((hoursWest*=-1))
+ fi
+
+ tzfile=/usr/share/zoneinfo/Etc/GMT$(printf '%+d' $hoursWest)
+ if [ -e $tzfile ]; then
+ /bin/mv -f /etc/localtime /etc/localtime.predhclient
+ /bin/cp -fp $tzfile /etc/localtime
+ /bin/touch /etc/localtime
+ fi
+ fi
+ fi
+
+ if [ "${PEERNTP}" = no ]; then
+ :
+ elif [ -n "$new_ntp_servers" ] && [ -e /etc/ntp.conf ]; then
+ save_previous /etc/ntp.conf
+ /bin/egrep -v '^server .* # added by /sbin/dhclient-script$'< /etc/ntp.conf.predhclient > /etc/ntp.conf
+
+ for s in $new_ntp_servers; do
+ echo "server $s # added by /sbin/dhclient-script" >> /etc/ntp.conf
+ done
+
+ if [ -x /usr/bin/diff ] && /usr/bin/diff -q /etc/ntp.conf /etc/ntp.conf.predhclient >/dev/null 2>&1; then
+ :
+ else
+ /sbin/service ntpd condrestart >/dev/null 2>&1
+ fi
+ fi
+}
+
+if [ x$new_broadcast_address != x ] && [ x$new_subnet_mask != x ] && [ "$new_subnet_mask" != "255.255.255.255" ]; then
+ new_broadcast_arg="broadcast $new_broadcast_address"
+fi
+
+if [ x$old_broadcast_address != x ]; then
+ old_broadcast_arg="broadcast $old_broadcast_address"
+fi
+
+if [ x$new_subnet_mask != x ]; then
+ new_subnet_arg="netmask $new_subnet_mask"
+fi
+
+if [ x$old_subnet_mask != x ]; then
+ old_subnet_arg="netmask $old_subnet_mask"
+fi
+
+if [ x$alias_subnet_mask != x ]; then
+ alias_subnet_arg="netmask $alias_subnet_mask"
+fi
+
+if [ x$reason = xMEDIUM ]; then
+ # Linux doesn't do mediums (ok, ok, media).
+ exit_with_hooks 0
+fi
+
+added_old_broadcast_route=0
+if [ x$reason = xPREINIT ]; then
+ if [ x$alias_ip_address != x ]; then
+ # Bring down alias interface. Its routes will disappear too.
+ ifconfig $interface:0- inet 0
+ fi
+
+ if [ x$keep_old_ip = xyes ]; then
+ ifconfig $interface up
+ elif [ $relmajor -lt 2 ] || ( [ $relmajor -eq 2 ] && [ $relminor -eq 0 ] ) then
+ ifconfig $interface inet 0.0.0.0 netmask 0.0.0.0 broadcast 255.255.255.255 up
+ # Add route to make broadcast work. Do not omit netmask.
+ /sbin/ip route replace default dev $interface && added_old_broadcast_route=1
+ else
+ ifconfig $interface 0 up
+ fi
+
+ # We need to give the kernel some time to get the interface up.
+ # sleep 1
+ # I don't think this is necessary with modern kernels - no problems found
+ # during testing - JVD, 2005-06-17
+ # but just in case:
+ if [ -n "$DHCLIENT_DELAY" ] && [ "$DHCLIENT_DELAY" -gt 0 ] ; then
+ sleep $DHCLIENT_DELAY
+ fi
+
+ exit_with_hooks 0
+fi
+
+if [ x$reason = xARPCHECK ] || [ x$reason = xARPSEND ]; then
+ if [ -z "$new_ip_address" ] || [ -z "$interface" ] || /sbin/arping -q -f -c 2 -w 3 -D -I ${interface} ${new_ip_address}; then
+ exit_with_hooks 0
+ else
+ exit_with_hooks 1
+ fi
+fi
+
+if [ x$reason = xBOUND ] || [ x$reason = xRENEW ] || \
+ [ x$reason = xREBIND ] || [ x$reason = xREBOOT ]; then
+ dhconfig
+ exit_with_hooks 0
+fi
+
+if [ x$reason = xEXPIRE ] || [ x$reason = xFAIL ] || [ x$reason = xRELEASE ] \
+ || [ x$reason = xSTOP ]; then
+ if [ -f /etc/resolv.conf.predhclient ]; then
+ change_resolv_conf /etc/resolv.conf.predhclient
+ rm -f /etc/resolv.conf.predhclient
+ fi
+
+ if [ -n "$DHCP_TIME_OFFSET_SETS_TIMEZONE" ] && [[ "$DHCP_TIME_OFFSET_SETS_TIMEZONE" = [yY1]* ]]; then
+ if [ -e /etc/localtime.predhclient ]; then
+ /bin/rm -f /etc/localtime
+ /bin/mv -f /etc/localtime.predhclient /etc/localtime
+ /bin/touch /etc/localtime
+ fi
+ fi
+
+ if [ -f /etc/ntp.conf.predhclient ]; then
+ /bin/rm -f /etc/ntp.conf
+ /bin/mv -f /etc/ntp.conf.predhclient /etc/ntp.conf
+ service ntpd condrestart >/dev/null 2>&1
+ fi
+
+ if [ -f /etc/yp.conf.predhclient ]; then
+ /bin/rm -f /etc/yp.conf
+ /bin/mv -f /etc/yp.conf.predhclient /etc/yp.conf
+
+ if [ -r /var/run/ypbind.pid ] && yppid=$(cat /var/run/ypbind.pid) && [ -d /proc/${yppid} ] && [ "$(if [ -x /usr/bin/readlink ]; then readlink /proc/${yppid}/exe; else echo /sbin/ypbind; fi)" = "/sbin/ypbind" ]; then
+ kill -HUP $yppid
+ fi
+ fi
+
+ if [ -x /etc/dhclient-${interface}-down-hooks ]; then
+ . /etc/dhclient-${interface}-down-hooks
+ elif [ -x /etc/dhclient-down-hooks ]; then
+ . /etc/dhclient-down-hooks
+ fi
+
+ if [ x$alias_ip_address != x ]; then
+ # Turn off alias interface.
+ ifconfig $interface:0- inet 0
+ fi
+
+ if [ x$old_ip_address != x ]; then
+ # Shut down interface, which will delete routes and clear arp cache.
+ ifconfig $interface inet 0 down
+ fi
+
+ if [ x$alias_ip_address != x ]; then
+ ifconfig $interface:0 inet $alias_ip_address $alias_subnet_arg
+ /sbin/ip route replace ${alias_ip_address}/32 $interface:0
+ fi
+
+ exit_with_hooks 0
+fi
+
+if [ x$reason = xTIMEOUT ] && [ "x$new_routers" != 'x' ]; then
+ if [ x$alias_ip_address != x ]; then
+ ifconfig $interface:0- inet 0
+ fi
+
+ ifconfig $interface inet $new_ip_address $new_subnet_arg $new_broadcast_arg
+ set $new_routers
+
+ if ping -q -c 1 -w 10 -I $interface $1; then
+ dhconfig
+ exit_with_hooks 0
+ fi
+
+ if [ -z "${dhc_dbus}" ] || (( ( dhc_dbus & 2 ) != 2 )); then
+ ifconfig $interface inet 0 down
+ fi
+
+ exit_with_hooks 1
+elif [ x$reason = xTIMEOUT ]; then
+ exit_with_hooks 1
+fi
+
+exit_with_hooks 0
Index: libdhcp_control.h
===================================================================
RCS file: libdhcp_control.h
diff -N libdhcp_control.h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ libdhcp_control.h 11 Jan 2008 00:14:20 -0000 1.6
@@ -0,0 +1,132 @@
+/* libdhcp_control.h
+ *
+ * DHCP client control API for libdhcp, a minimal interface to the
+ * ISC dhcp IPv4 client libdhcp4client library,
+ * and to the dhcpv6 DHCPv6 client libdhcp6client library.
+ *
+ * Each DHCP client library must include this file to be controlled
+ * by libdhcp.
+ *
+ * Copyright (C) 2006 Red Hat, Inc. All rights reserved.
+ *
+ * This copyrighted material is made available to anyone wishing to use,
+ * modify, copy, or redistribute it subject to the terms and conditions of
+ * the GNU General Public License v.2, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY expressed or implied, including the implied warranties of
+ * MERCHANTABILITY or FITNESS FOR A * PARTICULAR PURPOSE. See the GNU General
+ * Public License for more details. You should have received a copy of the
+ * GNU General Public License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA. Any Red Hat trademarks that are incorporated in the
+ * source code or documentation are not subject to the GNU General Public
+ * License and may only be used or replicated with the express permission of
+ * Red Hat, Inc.
+ *
+ * Red Hat Author(s): Jason Vas Dias
+ * David Cantrell <dcantrell at redhat.com>
+ */
+
+#ifndef LIBDHCP_CONTROL_H
+#define LIBDHCP_CONTROL_H
+
+#include <stdarg.h>
+#include <stdint.h>
+
+#define LOG_FATAL 8
+
+typedef enum dhcp_state_e {
+ /* DHCPv4 client states
+ * third callback arg will be a 'struct client_state *'
+ */
+ DHC4_NBI, /* failed: no broadcast interfaces found */
+ DHC4_PREINIT, /* configuration started - bring the interface "UP" */
+ DHC4_BOUND, /* lease obtained */
+ DHC4_RENEW, /* lease renewed */
+ DHC4_REBOOT, /* have valid lease, but now obtained a different one */
+ DHC4_REBIND, /* new, different lease */
+ DHC4_STOP, /* remove old lease */
+ DHC4_MEDIUM, /* media selection begun */
+ DHC4_TIMEOUT, /* timed out contacting DHCP server */
+ DHC4_FAIL, /* all attempts to contact server timed out, sleeping */
+ DHC4_EXPIRE, /* lease has expired, renewing */
+ DHC4_RELEASE, /* releasing lease */
+
+ /* This state raised by both clients: */
+ DHC_TIMEDOUT, /* libdhcp_control timeout has been exceeded */
+
+ /* DHCPv6 client states: */
+ DHC6_BOUND, /* new lease obtained - arg is optinfo * */
+ DHC6_REBIND, /* existing expired lease rebound - arg is optinfo * */
+ DHC6_RELEASE /* existing lease expired - arg is dhcp6_iaidaddr*/
+} DHCP_State;
+
+struct libdhcp_control_s;
+
+/* ala syslog(3): LOG_EMERG=0 - LOG_DEBUG=7 (+ LOG_FATAL=8 : finished -> 1) */
+typedef int (*LIBDHCP_Error_Handler) (struct libdhcp_control_s *ctl,
+ int priority, const char *fmt,
+ va_list ap);
+
+/* The DHCP clients will call the users' callback on important state change
+ * events, with the second arg set to the client DHCP_State, and the third
+ * arg set to a client specific pointer as described below. */
+typedef int (*LIBDHCP_Callback) (struct libdhcp_control_s *control,
+ enum dhcp_state_e, void*);
+
+typedef struct libdhcp_control_s {
+ /* the DHCP clients' main loop calls this on state changes */
+ LIBDHCP_Callback callback;
+
+ /* LIBDHCP_Capability bits to enable */
+ uint16_t capability;
+
+ /* set to one to make clients exit their main loop */
+ uint8_t finished;
+
+ /* set to one to decline the lease (DHCPv4 only) */
+ uint8_t decline;
+
+ /* (timeout+now) == time after which clients MUST return */
+ time_t timeout;
+
+ /* clients set this to time(0) on entering main loop */
+ time_t now;
+
+ /* user data pointer */
+ void *arg;
+ LIBDHCP_Error_Handler eh;
+} LIBDHCP_Control;
+
+/* DHCP client "capabilities" */
+typedef enum libdhcp_capability_e {
+ /* use / do not use persistent lease database files */
+ DHCP_USE_LEASE_DATABASE = 1,
+
+ /* use / do not use pid file */
+ DHCP_USE_PID_FILE = 2,
+
+ /*
+ * DHCPv6 supports these capabilities in process,
+ * while the DHCPv4 client will fork and exec the dhclient-script to
+ * implement them if these bits are set - otherwise, if no bits are set,
+ * the callback is called and the script is not run.
+ */
+ /* configure interfaces UP/DOWN as required */
+ DHCP_CONFIGURE_INTERFACES = 4,
+
+ /* configure interface addresses as required */
+ DHCP_CONFIGURE_ADDRESSES = 8,
+
+ /* configure routes as required */
+ DHCP_CONFIGURE_ROUTES = 16,
+
+ /* configure resolv.conf as required */
+ DHCP_CONFIGURE_RESOLVER = 32,
+
+ /* DHCPv6 only: */
+ /* configure radvd.conf & restart radvd as required */
+ DHCP_CONFIGURE_RADVD = 64,
+} LIBDHCP_Capability;
+
+#endif
Index: libdhcp4client.pc
===================================================================
RCS file: libdhcp4client.pc
diff -N libdhcp4client.pc
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ libdhcp4client.pc 11 Jan 2008 00:14:20 -0000 1.6
@@ -0,0 +1,5 @@
+Name: libdhcp4client
+Description: ISC DHCP IPv4 client library
+Version: @DHCP_VERSION@
+Libs: -ldhcp4client
+Cflags: -I/usr/include/dhcp4client
Index: get-ldap-patch.sh
===================================================================
RCS file: get-ldap-patch.sh
diff -N get-ldap-patch.sh
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ get-ldap-patch.sh 11 Jan 2008 00:14:20 -0000 1.3
@@ -0,0 +1,26 @@
+#!/bin/bash
+#
+# Fetch latest version of LDAP patch. The patch is downloaded and split in
+# the ldap/ subdirectory. It is up to the packager to merge the updates with
+# the RPM.
+#
+# Upstream: http://home.ntelos.net/~masneyb/
+#
+# David Cantrell <dcantrell at redhat.com>
+#
+
+CWD=$(pwd)
+
+rm -f masneyb.html-$$
+wget -O masneyb.html-$$ http://home.ntelos.net/~masneyb
+p="$(grep "ldap-patch" masneyb.html-$$ | cut -d '>' -f 3 | cut -d '<' -f 1)"
+rm -f masneyb.html-$$
+
+rm -rf ldap/
+mkdir -p ldap/
+cd ldap/
+wget -N http://home.ntelos.net/~masneyb/$p
+splitdiff -a -d $p
+rm -f $p
+
+rm -f *_debian_*
Index: draft-ietf-dhc-ldap-schema-01.txt
===================================================================
RCS file: draft-ietf-dhc-ldap-schema-01.txt
diff -N draft-ietf-dhc-ldap-schema-01.txt
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ draft-ietf-dhc-ldap-schema-01.txt 11 Jan 2008 00:14:20 -0000 1.5
@@ -0,0 +1,1089 @@
+
+
+
+
+
+Network Working Group M. Meredith,
+Internet Draft V. Nanjundaswamy,
+Document: <draft-ietf-dhc-ldap-schema-00.txt> M. Hinckley
+Category: Proposed Standard Novell Inc.
+Expires: 15th December 2001 16th June 2001
+
+
+ LDAP Schema for DHCP
+
+Status of this Memo
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC2026 [ ].
+
+Internet-Drafts are working documents of the Internet Engineering Task
+Force (IETF), its areas, and its working groups. Note that other groups
+may also distribute working documents as Internet-Drafts. Internet-
+Drafts are draft documents valid for a maximum of six months and may be
+updated, replaced, or obsolete by other documents at any time. It is
+inappropriate to use Internet-Drafts as reference material or to cite
+them other than as "work in progress." The list of current Internet-
+Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The
+list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+1. Abstract
+
+This document defines a schema for representing DHCP configuration in an
+LDAP directory. It can be used to represent the DHCP Service
+configuration(s) for an entire enterprise network, a subset of the
+network, or even a single server. Representing DHCP configuration in an
+LDAP directory enables centralized management of DHCP services offered
+by one or more DHCP Servers within the enterprise.
+
+2. Conventions used in this document
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in RFC-2119 [ ].
+
+In places where different sets of terminology are commonly used to
+represent similar DHCP concepts, this schema uses the terminology of the
+Internet Software Consortium's DHCP server reference implementation.
+For more information see www.isc.org.
+
+3. Design Considerations
+
+The DHCP LDAP schema is designed to be a simple multi-server schema. The
+
+
+
+M. Meredith et al. Expires December 2001 [Page 1]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+intent of this schema is to provide a basic framework for representing
+the most common elements used in the configuration of DHCP Server. This
+should allow other network services to obtain and use basic DHCP
+configuration information in a server-independent but knowledgeable way.
+
+It is expected that some implementations may need to extend the schema
+objects, in order to implement all of their features or needs. It is
+recommended that you use the schema defined in this draft to represent
+DHCP configuration information in an LDAP directory. Conforming to a
+standard schema improves interoperability between DHCP implementations
+from different vendors.
+
+Some implementations may choose not to support all of the objects
+defined here.
+
+Two decisions are explicitly left up to each implementation:
+
+First, implementations may choose not to store the lease information in
+the directory, so those objects would not be used.
+
+Second, implementations may choose not to implement the auditing
+information.
+
+It is up to the implementation to determine if the data in the directory
+is considered "authoritative", or if it is simply a copy of data from an
+authoritative source. Validity of the information if used as a copy is
+to be ensured by the implementation.
+
+Primarily two types of applications will use the information in this
+schema: 1. DHCP servers (for loading their configuration) 2. Management
+Interfaces (for defining/editing configurations).
+
+The schema should be efficient for the needs of both types of
+applications. The schema is designed to allow objects managed by DHCP
+(such as computers, subnets, etc) to be present anywhere in a directory
+hierarchy (to allow those objects to be placed in the directory for
+managing administrative control and access to the objects).
+
+The schema uses a few naming conventions - all object classes and
+attributes are prefixed with "dhcp" to decrease the chance that object
+classes and attributes will have the same name. The schema also uses
+standard naming attributes ("cn", "ou", etc) for all objects.
+
+4. Common DHCP Configuration Attributes
+
+Although DHCP manages several different types of objects, the
+configuration of those objects is often similar. Consequently, most of
+these objects have a common set of attributes, which are defined below.
+
+
+
+M. Meredith et al. Expires December 2001 [Page 2]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+4.1. Attributes Definitions
+
+The schema definitions listed below are for readability. The LDIF
+layout for this schema will follow in section 8.
+
+Name: dhcpPrimaryDN Description: The Distinguished Name of the
+dhcpServer object, which is the primary server for the configuration.
+Syntax: DN Flags: SINGLE-VALUE
+
+Named: dhcpSecondaryDN Description: The Distinguished Name(s) of the
+dhcpServer object(s), which are secondary servers for the configuration.
+Syntax: DN
+
+Name: dhcpStatements Description: Flexible storage for representing any
+specific data depending on the object to which it is attached. Examples
+include conditional statements, Server parameters, etc. This also
+serves as a 'catch-all' attribute that allows the standard to evolve
+without needing to update the schema. Syntax: IA5String
+
+Name: dhcpRange Description: The starting and ending IP Addresses in the
+range (inclusive), separated by a hyphen; if the range only contains one
+address, then just the address can be specified with no hyphen. Each
+range is defined as a separate value. Syntax: IA5String
+
+Name: dhcpPermitList Description: This attribute contains the permit
+lists associated with a pool. Each permit list is defined as a separate
+value. Syntax: IA5String
+
+Name: dhcpNetMask Description: The subnet mask length for the subnet.
+The mask can be easily computed from this length. Syntax: Integer
+Flags: SINGLE-VALUE
+
+Name: dhcpOption Description: Encoded option values to be sent to
+clients. Each value represents a single option and contains (OptionTag,
+Length, OptionData) encoded in the format used by DHCP. For more
+information see [DHCPOPT]. Syntax: OctetString
+
+Name: dhcpClassData Description: Encoded text string or list of bytes
+expressed in hexadecimal, separated by colons. Clients match subclasses
+based on matching the class data with the results of a 'match' or 'spawn
+with' statement in the class name declarations. Syntax: IA5String
+Flags: SINGLE-VALUE
+
+Name: dhcpSubclassesDN Description: List of subclasses, these are the
+actual DN of each subclass object. Syntax: DN
+
+Name: dhcpClassesDN Description: List of classes, these are the actual
+DN of each class object. Syntax: DN
+
+
+
+M. Meredith et al. Expires December 2001 [Page 3]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+Name: dhcpSubnetDN Description: List of subnets, these are the actual DN
+of each subnet object. Syntax: DN
+
+Name: dhcpPoolDN Description: List of pools, these are the actual DN of
+each Pool object. Syntax: DN
+
+Name: dhcpOptionsDN Description: List of options, these are the actual
+DN of each Options object. Syntax: DN
+
+Name: dhcpHostDN Description: List of hosts, these are the actual DN of
+each host object. Syntax: DN
+
+Name: dhcpSharedNetworkDN Description: List of shared networks, these
+are the actual DN of each shared network object. Syntax: DN
+
+Name: dhcpGroupDN Description: List of groups, these are the actual DN
+of each Group object. Syntax: DN
+
+Name: dhcpLeaseDN Description: Single Lease DN. A dhcpHost configuration
+uses this attribute to identify a static IP address assignment. Syntax:
+DN Flags: SINGLE-VALUE
+
+Name: dhcpLeasesDN Description: List of leases, these are the actual DN
+of each lease object. Syntax: DN
+
+Name: dhcpServiceDN Description: The DN of dhcpService object(s)which
+contain the configuration information. Each dhcpServer object has this
+attribute identifying the DHCP configuration(s) that the server is
+associated with. Syntax: DN
+
+Name: dhcpHWAddress Description: The hardware address of the client
+associated with a lease Syntax: OctetString Flags: SINGLE-VALUE
+
+Name: dhcpVersion Description: This is the version identified for the
+object that this attribute is part of. In case of the dhcpServer object,
+this represents the DHCP software version. Syntax: IA5String Flags:
+SINGLE-VALUE
+
+Name: dhcpImplementation Description: DHCP Server implementation
+description e.g. DHCP Vendor information. Syntax: IA5String Flags:
+SINGLE-VALUE
+
+Name: dhcpHashBucketAssignment Description: HashBucketAssignment bit map
+for the DHCP Server, as defined in DHC Load Balancing Algorithm [RFC
+3074]. Syntax: Octet String Flags: SINGLE-VALUE
+
+Name: dhcpDelayedServiceParameter Description: Delay in seconds
+corresponding to Delayed Service Parameter configuration, as defined in
+
+
+
+M. Meredith et al. Expires December 2001 [Page 4]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+DHC Load Balancing Algorithm [RFC 3074]. Syntax: Integer Flags: SINGLE-
+VALUE
+
+Name: dhcpMaxClientLeadTime Description: Maximum Client Lead Time
+configuration in seconds, as defined in DHCP Failover Protocol [FAILOVR]
+Syntax: Integer Flags: SINGLE-VALUE
+
+Name: dhcpFailOverEndpointState Description: Server (Failover Endpoint)
+state, as defined in DHCP Failover Protocol [FAILOVR] Syntax: IA5String
+Flags: SINGLE-VALUE
+
+5. Configurations and Services
+
+The schema definitions below are for readability the LDIF layout for
+this schema will follow in section 8.
+
+The DHC working group is currently considering several proposals for
+fail-over and redundancy of DHCP servers. These may require sharing of
+configuration information between servers. This schema provides a
+generalized mechanism for supporting any of these proposals, by
+separating the definition of a server from the definition of
+configuration service provided by the server.
+
+Separating the DHCP Server (dhcpServer) and the DHCP Configuration
+(dhcpService) representations allows a configuration service to be
+provided by one or more servers. Similarly, a server may provide one or
+more configurations. The schema allows a server to be configured as
+either a primary or secondary provider of a DHCP configuration.
+
+Configurations are also defined so that one configuration can include
+some of the objects that are defined in another configuration. This
+allows for sharing and/or a hierarchy of related configuration items.
+
+Name: dhcpService Description: Service object that represents the
+actual DHCP Service configuration. This will be a container with the
+following attributes. Must: cn, dhcpPrimaryDN May: dhcpSecondaryDN,
+dhcpSharedNetworkDN, dhcpSubnetDN, dhcpGroupDN, dhcpHostDN,
+dhcpClassesDN, dhcpOptionsDN, dhcpStatements
+
+The following objects could exist inside the dhcpService container:
+dhcpSharedNetwork, dhcpSubnet, dhcpGroup, dhcpHost, dhcpClass,
+dhcpOptions, dhcpLog
+
+Name: dhcpServer Description: Server object that the DHCP server will
+login as. The configuration information is in the dhcpService container
+that the dhcpServiceDN points to. Must: cn, dhcpServiceDN May:
+dhcpVersion, dhcpImplementation, dhcpHashBucketAssignment,
+dhcpDelayedServiceParameter, dhcpMaxClientLeadTime,
+
+
+
+M. Meredith et al. Expires December 2001 [Page 5]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+dhcpFailOverEndpointState, dhcpStatements
+
+5.1. DHCP Declaration related classes:
+
+Name: dhcpSharedNetwork Description: Shared Network class will list what
+pools and subnets are in this network.
+
+This will be a container with the following attributes. Must: cn May:
+dhcpSubnetDN, dhcpPoolDN, dhcpOptionsDN, dhcpStatements
+
+The following objects can exist within a dhcpSharedNetwork container:
+dhcpSubnet, dhcpPool, dhcpOptions, dhcpLog
+
+Name: dhcpSubnet Description: Subnet object will include configuration
+information associated with a subnet, including a range and a net mask.
+
+This will be a container with the following attributes. Must: cn
+(Subnet address), dhcpNetMask May: dhcpRange, dhcpPoolDN, dhcpGroupDN,
+dhcpHostDN, dhcpClassesDN, dhcpLeasesDN, dhcpOptionsDN, dhcpStatements
+
+The following objects can exist within a dhcpSubnet container: dhcpPool,
+dhcpGroup, dhcpHost, dhcpClass, dhcpOptions, dhcpLease, dhcpLog
+
+Name: dhcpGroup Description: Group object will have configuration
+information associated with a group.
+
+This will be a container with the following attributes. Must: cn May:
+dhcpHostDN, dhcpOptionsDN, dhcpStatements
+
+The following objects can exist within a dhcpGroup container: dhcpHost,
+dhcpOptions
+
+Name: dhcpHost Description: The host object includes DHCP host
+declarations to assign a static IP address or declare the client as
+known or specify statements for a specific client. Must: cn May:
+dhcpLeaseDN, dhcpHWAddress, dhcpOptionsDN, dhcpStatements
+
+The following objects can exist within a dhcpHost container: dhcpLease,
+dhcpOptions
+
+Name: dhcpOptions Description: The options class is for option space
+declarations, it contains a list of options. Must: cn, dhcpOption
+
+Name: dhcpClass Description: This is a class to group clients together
+based on matching rules.
+
+This will be a container with the following attributes. Must: cn May:
+dhcpSubClassesDN, dhcpOptionsDN, dhcpStatements
+
+The following object can exist within a dhcpClass container:
+dhcpSubclass, dhcpOptions
+
+
+
+M. Meredith et al. Expires December 2001 [Page 6]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+Name: dhcpSubClass Description: This includes configuration information
+for a subclass associated with a class. The dhcpSubClass object will
+always be contained within the corresponding class container object.
+Must: cn May: dhcpClassData, dhcpOptionsDN, dhcpStatements
+
+Name: dhcpPool Description: This contains configuration for a pool that
+will have the range of addresses, permit lists and point to classes and
+leases that are members of this pool.
+
+This will be a container that could be contained by dhcpSubnet or a
+dhcpSharedNetwork. Must: cn, dhcpRange May: dhcpClassesDN,
+dhcpPermitList, dhcpLeasesDN, dhcpOptionsDN, dhcpStatements
+
+The following objects can exist within a dhcpPool container: dhcpClass,
+dhcpOptions, dhcpLease, dhcpLog
+
+6. Tracking Address Assignments
+
+The behavior of a DHCP server is influenced by two factors - it's
+configuration and the current state of the addresses that have been
+assigned to clients. This schema defines a set of objects for
+representing the DHCP configuration associated with a server. The
+following object classes provide the ability to record how addresses are
+used including maintaining history (audit log) on individual leases.
+Recording lease information in a directory could result in a significant
+performance impact and is therefore optional. Implementations supporting
+logging of leases need to consider the performance impact.
+
+6.1. dhcpLeases Attribute Definitions
+
+The schema definitions below are for readability the LDIF layout for
+this schema will follow in section 8.
+
+Name: dhcpAddressState Description: This stores information about the
+current binding-status of an address. For dynamic addresses managed by
+DHCP, the values should be restricted to the states defined in the DHCP
+Failover Protocol draft [FAILOVR]: 'FREE', 'ACTIVE', 'EXPIRED',
+'RELEASED', 'RESET', 'ABANDONED', 'BACKUP'. For more information on
+these states see [FAILOVR]. For other addresses, it SHOULD be one of
+the following: 'UNKNOWN', 'RESERVED' (an address that is managed by DHCP
+that is reserved for a specific client), 'RESERVED-ACTIVE' (same as
+reserved, but address is currently in use), 'ASSIGNED' (assigned
+manually or by some other mechanism), 'UNASSIGNED', 'NOTASSIGNABLE'.
+Syntax: IA5String Flags: SINGLE-VALUE
+
+Name: dhcpExpirationTime Description: This is the time the current lease
+for an address expires. Syntax: DateTime Flags: SINGLE-VALUE
+
+
+
+
+M. Meredith et al. Expires December 2001 [Page 7]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+Name: dhcpStartTimeOfState Description: This is the time of the last
+state change for a leased address. Syntax: DateTime Flags: SINGLE-VALUE
+
+Name: dhcpLastTransactionTime Description: This is the last time a valid
+DHCP packet was received from the client. Syntax: DateTime Flags:
+SINGLE-VALUE
+
+Name: dhcpBootpFlag Description: This indicates whether the address was
+assigned via BOOTP Syntax: Boolean Flags: SINGLE-VALUE
+
+Name: dhcpDomainName Description: This is the name of the domain sent to
+the client by the server. It is essentially the same as the value for
+DHCP option 15 sent to the client, and represents only the domain - not
+the full FQDN. To obtain the full FQDN assigned to the client you must
+prepend the "dhcpAssignedHostName" to this value with a ".". Syntax:
+IA5String Flags: SINGLE-VALUE
+
+Name: dhcpDnsStatus Description: This indicates the status of updating
+DNS resource records on behalf of the client by the DHCP server for this
+address. The value is a 16-bit bitmask that has the same values as
+specified by the Failover-DDNS option (see [FAILOVR]). Syntax: Integer
+Flags: SINGLE-VALUE
+
+Name: dhcpRequestedHostName Description: This is the hostname that was
+requested by the client. Syntax: IA5String Flags: SINGLE-VALUE
+
+Name: dhcpAssignedHostName Description: This is the actual hostname that
+was assigned to a client. It may not be the name that was requested by
+the client. The fully qualified domain name can be determined by
+appending the value of "dhcpDomainName" (with a dot separator) to this
+name. Syntax: IA5String Flags: SINGLE-VALUE
+
+Name: dhcpReservedForClient Description: This is the distinguished name
+of the "dhcpHost" that an address is reserved for. This may not be the
+same as the "dhcpAssignedToClient" attribute if the address is being
+reassigned but the current lease has not yet expired. Syntax: DN Flags:
+SINGLE-VALUE
+
+Name: dhcpAssignedToClient Description: This is the distinguished name
+of a "dhcpHost" that an address is currently assigned to. This
+attribute is only present in the class when the address is leased.
+Syntax: DN Flags: SINGLE-VALUE
+
+Name: dhcpRelayAgentInfo Description: If the client request was received
+via a relay agent, this contains information about the relay agent that
+was available from the DHCP request. This is a hex-encoded option
+value. Syntax: OctetString Flags: SINGLE-VALUE
+
+Name: dhcpErrorLog Description: Generic error log attribute that allows
+logging error conditions within a dhcpService or a dhcpSubnet, like no IP
+addresses available for lease. Syntax: IA5String
+
+M. Meredith et al. Expires December 2001 [Page 8]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+6.2. dhcpLeases Object Class
+
+This class represents an IP address. It may or may not be leaseable,
+and the object may exist even though a lease is not currently active for
+the associated IP address.
+
+It is recommended that all Lease objects for a single DHCP Service be
+centrally located within a single container. This ensures that the lease
+objects and the corresponding logs do not have to be relocated, when
+address ranges allocated to individual DHCP subnets and/or pools change.
+
+The schema definitions below are for readability the LDIF layout for
+this schema will follow in section 8.
+
+Name: dhcpLeases Description: This is the object that holds state
+information about an IP address. The cn (which is the IP address), and
+the current address-state are mandatory attributes. If the address is
+assigned then, some of the optional attributes will have valid data.
+Must: cn, dhcpAddressState May: dhcpExpirationTime,
+dhcpStartTimeOfState, dhcpLastTransactionTime, dhcpBootpFlag,
+dhcpDomainName, dhcpDnsStatus, dhcpRequestedHostName,
+dhcpAssignedHostName, dhcpReservedForClient, dhcpAssignedToClient,
+dhcpRelayAgentInfo, dhcpHWAddress
+
+6.3 Audit Log Information
+
+A dhcpLog object is created whenever a lease is assigned or released.
+This object is intended to be created under the corresponding dhcpLeases
+container, or dhcpPool, dhcpSubnet, dhcpSharedNetwork or dhcpService
+containers.
+
+The log information under the dhcpLeases container would be for
+addresses matching that lease information. The log information in the
+other containers could be used for errors, i.e. when a pool or subnet is
+out our addresses or if a server is not able to assign any more
+addresses for a particular dhcpService.
+
+Name: dhcpLog Description: This is the object that holds past
+information about an IP address. The cn is the time/date stamp when the
+address was assigned or released, the address state at the time, if the
+address was assigned or released. Must: cn May: dhcpAddressState,
+dhcpExpirationTime, dhcpStartTimeOfState, dhcpLastTransactionTime,
+dhcpBootpFlag, dhcpDomainName, dhcpDnsStatus, dhcpRequestedHostName,
+dhcpAssignedHostName, dhcpReservedForClient, dhcpAssignedToClient,
+dhcpRelayAgentInfo, dhcpHWAddress, dhcpErrorLog
+
+
+
+
+
+
+M. Meredith et al. Expires December 2001 [Page 9]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+7. Determining settings
+
+The dhcpStatements attribute is the key to DHC enhancements that may
+come along, and the different key words that a particular server
+implementation may use. This attribute can be used to hold conditional
+DHCP Statements and DHCP server parameters. Having a generic settings
+attribute that is just a string, allows this schema to be extensible and
+easy to configure.
+
+All of the attributes that end with DN are references to the class that
+precedes the DN e.g. the dhcpPrimaryDN and dhcpSecondaryDN attributes
+hold the Distinguished Names of the dhcpServer objects that are
+associated with the dhcpService object.
+
+8. LDIF format for attributes and classes.
+
+# Attributes
+
+( 2.16.840.1.113719.1.203.4.1 NAME 'dhcpPrimaryDN' DESC
+'The DN of the dhcpServer which is the primary server for the
+configuration.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.2 NAME 'dhcpSecondaryDN' DESC 'The DN of
+dhcpServer(s) which provide backup service for the configuration.'
+SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+( 2.16.840.1.113719.1.203.4.3 NAME 'dhcpStatements' DESC 'Flexible
+storage for specific data depending on what object this exists in. Like
+conditional statements, server parameters, etc. This allows the standard
+to evolve without needing to adjust the schema.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.26 )
+
+( 2.16.840.1.113719.1.203.4.4 NAME 'dhcpRange' DESC 'The starting &
+ending IP Addresses in the range (inclusive), separated by a hyphen; if
+the range only contains one address, then just the address can be
+specified with no hyphen. Each range is defined as a separate value.'
+SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+( 2.16.840.1.113719.1.203.4.5 NAME 'dhcpPermitList' DESC 'This attribute
+contains the permit lists associated with a pool. Each permit list is
+defined as a separate value.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+( 2.16.840.1.113719.1.203.4.6 NAME 'dhcpNetMask' DESC 'The subnet mask
+length for the subnet. The mask can be easily computed from this
+length.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.7 NAME 'dhcpOption' DESC 'Encoded option
+values to be sent to clients. Each value represents a single option and
+contains (OptionTag, Length, OptionValue) encoded in the format used by
+DHCP.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+M. Meredith et al. Expires December 2001 [Page 10]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+( 2.16.840.1.113719.1.203.4.8 NAME 'dhcpClassData' DESC 'Encoded text
+string or list of bytes expressed in hexadecimal, separated by colons.
+Clients match subclasses based on matching the class data with the
+results of match or spawn with statements in the class name
+declarations.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.9 NAME 'dhcpOptionsDN' DESC 'The
+distinguished name(s) of the dhcpOption objects containing the
+configuration options provided by the server.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.12 )
+
+( 2.16.840.1.113719.1.203.4.10 NAME 'dhcpHostDN' DESC 'the distinguished
+name(s) of the dhcpHost objects.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+( 2.16.840.1.113719.1.203.4.11 NAME 'dhcpPoolDN' DESC 'The distinguished
+name(s) of pools.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+( 2.16.840.1.113719.1.203.4.12 NAME 'dhcpGroupDN' DESC 'The
+distinguished name(s) of the groups.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.12 )
+
+( 2.16.840.1.113719.1.203.4.13 NAME 'dhcpSubnetDN' DESC 'The
+distinguished name(s) of the subnets.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.12 )
+
+( 2.16.840.1.113719.1.203.4.14 NAME 'dhcpLeaseDN' DESC 'The
+distinguished name of a client address.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE)
+
+( 2.16.840.1.113719.1.203.4.15 NAME 'dhcpLeasesDN' DESC 'The
+distinguished name(s) client addresses.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.12 )
+
+( 2.16.840.1.113719.1.203.4.16 NAME 'dhcpClassesDN' DESC 'The
+distinguished name(s) of a class(es) in a subclass.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.12 )
+
+( 2.16.840.1.113719.1.203.4.17 NAME 'dhcpSubclassesDN' DESC 'The
+distinguished name(s) of subclass(es).' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.12 )
+
+( 2.16.840.1.113719.1.203.4.18 NAME 'dhcpSharedNetworkDN' DESC 'The
+distinguished name(s) of sharedNetworks.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.12 )
+
+( 2.16.840.1.113719.1.203.4.19 NAME 'dhcpServiceDN' DESC 'The DN of
+dhcpService object(s)which contain the configuration information. Each
+dhcpServer object has this attribute identifying the DHCP
+
+
+
+M. Meredith et al. Expires December 2001 [Page 11]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+configuration(s) that the server is associated with.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.12 )
+
+( 2.16.840.1.113719.1.203.4.20 NAME 'dhcpVersion' DESC 'The version
+attribute of this object.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-
+VALUE )
+
+( 2.16.840.1.113719.1.203.4.21 NAME 'dhcpImplementation' DESC
+'Description of the DHCP Server implementation e.g. DHCP Server's
+vendor.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.22 NAME 'dhcpAddressState' DESC 'This stores
+information about the current binding-status of an address. For dynamic
+addresses managed by DHCP, the values should be restricted to the
+following: "FREE", "ACTIVE", "EXPIRED", "RELEASED", "RESET",
+"ABANDONED", "BACKUP". For other addresses, it SHOULD be one of the
+following: "UNKNOWN", "RESERVED" (an address that is managed by DHCP
+that is reserved for a specific client), "RESERVED-ACTIVE" (same as
+reserved, but address is currently in use), "ASSIGNED" (assigned
+manually or by some other mechanism), "UNASSIGNED", "NOTASSIGNABLE".'
+SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.23 NAME 'dhcpExpirationTime' DESC 'This is
+the time the current lease for an address expires.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.24 NAME 'dhcpStartTimeOfState' DESC 'This is
+the time of the last state change for a leased address.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.25 NAME 'dhcpLastTransactionTime' DESC 'This
+is the last time a valid DHCP packet was received from the client.'
+SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.26 NAME 'dhcpBootpFlag' DESC 'This indicates
+whether the address was assigned via BOOTP.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.27 NAME 'dhcpDomainName' DESC 'This is the
+name of the domain sent to the client by the server. It is essentially
+the same as the value for DHCP option 15 sent to the client, and
+represents only the domain - not the full FQDN. To obtain the full FQDN
+assigned to the client you must prepend the "dhcpAssignedHostName" to
+this value with a ".".' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-
+VALUE )
+
+( 2.16.840.1.113719.1.203.4.28 NAME 'dhcpDnsStatus' DESC 'This indicates
+the status of updating DNS resource records on behalf of the client by
+
+
+
+M. Meredith et al. Expires December 2001 [Page 12]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+the DHCP server for this address. The value is a 16-bit bitmask.'
+SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.29 NAME 'dhcpRequestedHostName' DESC 'This
+is the hostname that was requested by the client.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.30 NAME 'dhcpAssignedHostName' DESC 'This is
+the actual hostname that was assigned to a client. It may not be the
+name that was requested by the client. The fully qualified domain name
+can be determined by appending the value of "dhcpDomainName" (with a dot
+separator) to this name.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-
+VALUE )
+
+( 2.16.840.1.113719.1.203.4.31 NAME 'dhcpReservedForClient' DESC 'The
+distinguished name of a "dhcpClient" that an address is reserved for.
+This may not be the same as the "dhcpAssignedToClient" attribute if the
+address is being reassigned but the current lease has not yet expired.'
+SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.32 NAME 'dhcpAssignedToClient' DESC 'This is
+the distinguished name of a "dhcpClient" that an address is currently
+assigned to. This attribute is only present in the class when the
+address is leased.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.33 NAME 'dhcpRelayAgentInfo' DESC 'If the
+client request was received via a relay agent, this contains information
+about the relay agent that was available from the DHCP request. This is
+a hex-encoded option value.' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.34 NAME 'dhcpHWAddress' DESC 'The clients
+hardware address that requested this IP address.' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.35 NAME 'dhcpHashBucketAssignment' DESC
+'HashBucketAssignment bit map for the DHCP Server, as defined in DHC
+Load Balancing Algorithm [RFC 3074].' SYNTAX
+1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.36 NAME 'dhcpDelayedServiceParameter' DESC
+'Delay in seconds corresponding to Delayed Service Parameter
+configuration, as defined in DHC Load Balancing Algorithm [RFC 3074]. '
+SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.37 NAME 'dhcpMaxClientLeadTime' DESC
+'Maximum Client Lead Time configuration in seconds, as defined in DHCP
+Failover Protocol [FAILOVR]' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+
+
+
+M. Meredith et al. Expires December 2001 [Page 13]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.38 NAME 'dhcpFailOverEndpointState' DESC
+'Server (Failover Endpoint) state, as defined in DHCP Failover Protocol
+[FAILOVR]' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+( 2.16.840.1.113719.1.203.4.39 NAME 'dhcpErrorLog' DESC
+Generic error log attribute that allows logging error conditions within a
+dhcpService or a dhcpSubnet, like no IP addresses available for lease.
+SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+#Classes
+
+( 2.16.840.1.113719.1.203.6.1 NAME 'dhcpService' DESC ' Service object
+that represents the actual DHCP Service configuration. This is a
+container object.' SUP top MUST (cn $ dhcpPrimaryDN) MAY
+(dhcpSecondaryDN $ dhcpSharedNetworkDN $ dhcpSubnetDN $ dhcpGroupDN $
+dhcpHostDN $ dhcpClassesDN $ dhcpOptionsDN $ dhcpStatements ) )
+
+( 2.16.840.1.113719.1.203.6.2 NAME 'dhcpSharedNetwork' DESC 'This stores
+configuration information for a shared network.' SUP top MUST cn MAY
+(dhcpSubnetDN $ dhcpPoolDN $ dhcpOptionsDN $ dhcpStatements) X-
+NDS_CONTAINMENT ('dhcpService' ) )
+
+( 2.16.840.1.113719.1.203.6.3 NAME 'dhcpSubnet' DESC 'This class defines
+a subnet. This is a container object.' SUP top MUST ( cn $ dhcpNetMask )
+MAY (dhcpRange $ dhcpPoolDN $ dhcpGroupDN $ dhcpHostDN $ dhcpClassesDN $
+dhcpLeasesDN $ dhcpOptionsDN $ dhcpStatements) X-NDS_CONTAINMENT
+('dhcpService' 'dhcpSharedNetwork') )
+
+( 2.16.840.1.113719.1.203.6.4 NAME 'dhcpPool' DESC 'This stores
+configuration information about a pool.' SUP top MUST ( cn $ dhcpRange )
+MAY (dhcpClassesDN $ dhcpPermitList $ dhcpLeasesDN $ dhcpOptionsDN $
+dhcpStatements) X-NDS_CONTAINMENT ('dhcpSubnet' 'dhcpSharedNetwork') )
+
+( 2.16.840.1.113719.1.203.6.5 NAME 'dhcpGroup' DESC 'Group object that
+lists host DNs and parameters. This is a container object.' SUP top MUST
+cn MAY ( dhcpHostDN $ dhcpOptionsDN $ dhcpStatements ) X-NDS_CONTAINMENT
+('dhcpSubnet' 'dhcpService' ) )
+
+( 2.16.840.1.113719.1.203.6.6 NAME 'dhcpHost' DESC 'This represents
+information about a particular client' SUP top MUST cn MAY (dhcpLeaseDN
+$ dhcpHWAddress $ dhcpOptionsDN $ dhcpStatements) X-NDS_CONTAINMENT
+('dhcpService' 'dhcpSubnet' 'dhcpGroup') )
+
+( 2.16.840.1.113719.1.203.6.7 NAME 'dhcpClass' DESC 'Represents
+information about a collection of related clients.' SUP top MUST cn MAY
+(dhcpSubClassesDN $ dhcpOptionsDN $ dhcpStatements) X-NDS_CONTAINMENT
+('dhcpService' 'dhcpSubnet' ) )
+
+( 2.16.840.1.113719.1.203.6.8 NAME 'dhcpSubClass' DESC 'Represents
+information about a collection of related classes.' SUP top MUST cn MAY
+(dhcpClassData $ dhcpOptionsDN $ dhcpStatements) X-NDS_CONTAINMENT
+
+
+
+M. Meredith et al. Expires December 2001 [Page 14]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+'dhcpClass' )
+
+( 2.16.840.1.113719.1.203.6.9 NAME 'dhcpOptions' DESC 'Represents
+information about a collection of options defined.' SUP top MUST cn MAY
+( dhcpOption ) X-NDS_CONTAINMENT ('dhcpService' 'dhcpSharedNetwork'
+'dhcpSubnet' 'dhcpPool' 'dhcpGroup' 'dhcpHost' 'dhcpClass' )
+
+( 2.16.840.1.113719.1.203.6.10 NAME 'dhcpLeases' DESC 'This class
+represents an IP Address, which may or may not have been leased.' SUP
+top MUST ( cn $ dhcpAddressState ) MAY ( dhcpExpirationTime $
+dhcpStartTimeOfState $ dhcpLastTransactionTime $ dhcpBootpFlag $
+dhcpDomainName $ dhcpDnsStatus $ dhcpRequestedHostName $
+dhcpAssignedHostName $ dhcpReservedForClient $ dhcpAssignedToClient $
+dhcpRelayAgentInfo $ dhcpHWAddress ) X-NDS_CONTAINMENT ( 'dhcpService'
+'dhcpSubnet' 'dhcpPool') )
+
+( 2.16.840.1.113719.1.203.6.11 NAME 'dhcpLog' DESC 'This is the object
+that holds past information about the IP address. The cn is the
+time/date stamp when the address was assigned or released, the address
+state at the time, if the address was assigned or released.' SUP top
+MUST ( cn ) MAY ( dhcpAddressState $ dhcpExpirationTime $
+dhcpStartTimeOfState $ dhcpLastTransactionTime $ dhcpBootpFlag $
+dhcpDomainName $ dhcpDnsStatus $ dhcpRequestedHostName $
+dhcpAssignedHostName $ dhcpReservedForClient $ dhcpAssignedToClient $
+dhcpRelayAgentInfo $ dhcpHWAddress $ dhcpErrorLog) X-NDS_CONTAINMENT
+('dhcpLeases' 'dhcpPool' 'dhcpSubnet' 'dhcpSharedNetwork' 'dhcpService' ) )
+
+( 2.16.840.1.113719.1.203.6.12 NAME 'dhcpServer' DESC 'DHCP Server
+Object' SUP top MUST (cn, dhcpServiceDN) MAY (dhcpVersion $
+dhcpImplementation $ dhcpHashBucketAssignment $
+dhcpDelayedServiceParameter $ dhcpMaxClientLeadTime $
+dhcpFailOverEndpointState $ dhcpStatements) X-NDS_CONTAINMENT ('O' 'OU'
+'dc') )
+
+9. Security Considerations
+
+Since the DHCP Configuration information is stored in a directory, the
+security of the information is limited to the security offered by the
+directory including the security of the objects within that directory.
+
+10. Intellectual Property Rights Notices
+
+The IETF takes no position regarding the validity or scope of any
+intellectual property or other rights that might be claimed to pertain
+to the implementation or use of the technology described in this
+document or the extent to which any license under such rights might or
+might not be available; neither does it represent that it has made any
+effort to identify any such rights. Information on the IETF's
+procedures with respect to rights in standards-track and standards-
+
+
+
+M. Meredith et al. Expires December 2001 [Page 15]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+related documentation can be found in BCP-11. Copies of claims of
+rights made available for publication and any assurances of licenses to
+be made available, or the result of an attempt made to obtain a general
+license or permission for the use of such proprietary rights by
+implementors or users of this specification can be obtained from the
+IETF Secretariat.
+
+The IETF invites any interested party to bring to its attention any
+copyrights, patents or patent applications, or other proprietary rights
+which may cover technology that may be required to practice this
+standard. Please address the information to the IETF Executive
+Director.
+
+11. Full Copyright Statement
+
+Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it or
+assist in its implementation may be prepared, copied, published and
+distributed, in whole or in part, without restriction of any kind,
+provided that the above copyright notice and this paragraph are included
+on all such copies and derivative works. However, this document itself
+may not be modified in any way, such as by removing the copyright notice
+or references to the Internet Society or other Internet organizations,
+except as needed for the purpose of developing Internet standards in
+which case the procedures for copyrights defined in the Internet
+Standards process must be followed, or as required to translate it into
+languages other than English.
+
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an "AS
+IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
+FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
+LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
+INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
+FITNESS FOR A PARTICULAR PURPOSE.
+
+12. References
+
+[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+March 1997.
+
+[RFC2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
+Extensions", RFC 2132, March 1997.
+
+
+
+
+M. Meredith et al. Expires December 2001 [Page 16]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+[MSDHCP] Gu, Y., Vyaghrapuri, R., "An LDAP Schema for Dynamic Host
+Configuration Protocol Service", Internet Draft <draft-gu-dhcp-ldap-
+schema-00.txt>, August 1998.
+
+[NOVDHCP] Miller, T., Patel, A., Rao, P., "Lightweight Directory Access
+Protocol (v3): Schema for Dynamic Host Configuration Protocol (DHCP)",
+Internet Draft <draft-miller-dhcp-ldap-schema-00.txt>, June 1998.
+
+[FAILOVR] Droms, R., Rabil, G., Dooley, M., Kapur, A., Gonczi, S., Volz,
+B., "DHCP Failover Protocol", Internet Draft <draft-ietf-dhc-
+failover-08.txt>, July 2000.
+
+[RFC 3074] Volz B., Gonczi S., Lemon T., Stevens R., "DHC Load Balancing
+Algorithm", February 2001
+
+[AGENT] Patrick, M., "DHCP Relay Agent Information Option", Internet
+Draft <draft-ietf-dhc-agent-options-09.txt>, March 2000.
+
+[DHCPOPT] Carney, M., "New Option Review Guidelines and Additional
+Option Namespace", Internet Draft <draft-ietf-dhc-
+option_review_and_namespace-01.txt>, October 1999.
+
+[POLICY] Strassner, J., Elleson, E., Moore, B., "Policy Framework LDAP
+Core Schema", Internet Draft <draft-ietf-policy-core-schema-06.txt>,
+November 1999.
+
+[RFC2251] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access
+Protocol (v3)", RFC 2251, December 1997.
+
+[RFC2252] Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight
+Directory Access Protocol (v3) Attribute Syntax Definitions", RFC 2252,
+December 1997.
+
+[RFC2255] Howes, T., Smith, M., "The LDAP URL Format", RFC 2255,
+December 1997.
+
+[RFC951] Croft, B., Gilmore, J., "Bootstrap Protocol (BOOTP)", RFC 951,
+September 1985.
+
+[RFC2119] Bradner, S. "Key words for use in RFCs to Indicate Requirement
+Levels", RFC 2119, March 1997.
+
+13. Acknowledgments
+
+This work is partially based on a previous draft draft-ietf-dhc-
+schema-02.doc.
+
+
+
+
+
+M. Meredith et al. Expires December 2001 [Page 17]
+
+
+
+
+
+INTERNET-DRAFT LDAP Schema for DHCP 16 June 2001
+
+
+14. Author's Addresses
+
+Comments regarding this draft may be sent to the authors at the
+following address:
+
+Mark Meredith
+Mark Hinckley
+Novell Inc.
+1800 S. Novell Place
+Provo, Utah 84606
+
+Vijay K. Nanjundaswamy
+Novell Software Development (I) Ltd
+49/1 & 49/3, Garvebhavi Palya,
+7th Mile, Hosur Road
+Bangalore 560068
+
+email: mark_meredith at novell.com
+email: knvijay at novell.com
+email: mhinckley at novell.com
+
+This Internet Draft expires December 16, 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+M. Meredith et al. Expires December 2001 [Page 18]
+
+
+
+
Index: dhcrelay.init
===================================================================
RCS file: dhcrelay.init
diff -N dhcrelay.init
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ dhcrelay.init 11 Jan 2008 00:14:20 -0000 1.9
@@ -0,0 +1,125 @@
+#!/bin/sh
+#
+### BEGIN INIT INFO
+# Provides: dhcrelay
+# Default-Start:
+# Default-Stop:
+# Should-Start:
+# Required-Start: $network
+# Required-Stop:
+# Short-Description: Start and stop the DHCP relay server
+# Description: dhcrelay provides the Dynamic Host Configuration Protocol (DHCP)
+# relay server. This is required when your DHCP server is on
+# another network segment from the clients.
+### END INIT INFO
+#
+# The fields below are left around for legacy tools (will remove later).
+#
+# chkconfig: - 65 35
+# description: dhcrelay provides a relay for Dynamic Host Control Protocol.
+# processname: dhcrelay
+# # pidfile: /var/run/dhcrelay.pid
+
+. /etc/init.d/functions
+
+RETVAL=0
+
+prog=dhcrelay
+dhcrelay=/usr/sbin/dhcrelay
+lockfile=/var/lock/subsys/dhcrelay
+pidfile=/var/run/dhcrelay.pid
+conf=/etc/sysconfig/dhcrelay
+
+# The dhcrelay daemon uses the sysconfig file for configuration information.
+# There is no native configuration file for this program and you must specify
+# its settings on the command line.
+[ -f /etc/sysconfig/dhcrelay ] && . /etc/sysconfig/dhcrelay
+
+configtest() {
+ [ -x $dhcrelay ] || exit 5
+ [ -f $conf ] || exit 6
+ [ -z "$DHCPSERVERS" ] && exit 6
+ RETVAL=0
+ return $RETVAL
+}
+
+start() {
+ [ -x $dhcrelay ] || exit 5
+ [ -f $conf ] || exit 6
+
+ pidofproc $prog >/dev/null 2>&1
+ RETVAL=$?
+ [ $RETVAL -eq 0 ] && return $RETVAL
+
+ echo -n $"Starting $prog: "
+ daemon $dhcrelay $([ -n "$INTERFACES" ] && for int in $INTERFACES ; do echo -n " -i $int" ; done) $DHCPSERVERS 2>/dev/null
+ RETVAL=$?
+ echo
+ [ $RETVAL -eq 0 ] && touch $lockfile
+ return $RETVAL
+}
+
+stop() {
+ pidofproc $prog >/dev/null 2>&1
+ if [ $? -ne 0 ]; then
+ RETVAL=7
+ return $RETVAL
+ fi
+
+ echo -n $"Shutting down $prog: "
+ killproc $prog -TERM
+ RETVAL=$?
+
+ [ $RETVAL = 0 ] && success || failure
+ echo
+ [ $RETVAL = 0 ] && rm -f $lockfile
+ return $RETVAL
+}
+
+if [ ! -x $dhcrelay ]; then
+ RETVAL=5
+ exit $RETVAL
+fi
+
+if [ $# -gt 1 ]; then
+ RETVAL=2
+ exit $RETVAL
+fi
+
+case "$1" in
+ start)
+ start
+ RETVAL=$?
+ ;;
+ stop)
+ stop
+ RETVAL=$?
+ ;;
+ restart|force-reload)
+ stop && start
+ RETVAL=$?
+ ;;
+ try-restart|reload)
+ RETVAL=3
+ ;;
+ condrestart)
+ if [ -f $lockfile ]; then
+ stop && start
+ RETVAL=$?
+ fi
+ ;;
+ configtest)
+ configtest
+ RETVAL=$?
+ ;;
+ status)
+ status $prog
+ RETVAL=$?
+ ;;
+ *)
+ echo $"Usage: $0 {start|stop|restart|condrestart|configtest|status}"
+ RETVAL=3
+ ;;
+esac
+
+exit $RETVAL
Index: dhcpd.init
===================================================================
RCS file: dhcpd.init
diff -N dhcpd.init
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ dhcpd.init 11 Jan 2008 00:14:20 -0000 1.25
@@ -0,0 +1,142 @@
+#!/bin/sh
+#
+### BEGIN INIT INFO
+# Provides: dhcpd
+# Default-Start:
+# Default-Stop:
+# Should-Start:
+# Required-Start: $network
+# Required-Stop:
+# Short-Description: Start and stop the DHCP server
+# Description: dhcpd provides the Dynamic Host Configuration Protocol (DHCP)
+# server.
+### END INIT INFO
+#
+# The fields below are left around for legacy tools (will remove later).
+#
+# chkconfig: - 65 35
+# description: dhcpd provides the Dynamic Host Configuration Protocol (DHCP) \
+# server
+# processname: dhcpd
+# config: /etc/dhcpd.conf
+# config: /var/lib/dhcpd/dhcpd.leases
+# pidfile: /var/run/dhcpd.pid
+
+. /etc/init.d/functions
+
+RETVAL=0
+
+prog=dhcpd
+dhcpd=/usr/sbin/dhcpd
+lockfile=/var/lock/subsys/dhcpd
+pidfile=/var/run/dhcpd.pid
+statedir=/var/lib/dhcpd
+
+[ -f /etc/sysconfig/dhcpd ] && . /etc/sysconfig/dhcpd
+
+# if the user specified a different config file, make sure we reference it
+findConfig() {
+ for arg in $DHCPDARGS ; do
+ if [ "$found" = 1 ]; then
+ [ -f "$arg" ] && echo "$arg"
+ return
+ fi
+ if [ "$arg" = "-cf" ]; then
+ found=1
+ continue
+ fi
+ done
+ echo "/etc/dhcpd.conf"
+}
+
+conf="$(findConfig "$DHCPDARGS")"
+
+if [ ! -f $statedir/dhcpd.leases ] ; then
+ mkdir -p $statedir
+ touch $statedir/dhcpd.leases
+ [ -x /sbin/restorecon ] && [ -d /selinux ] && /sbin/restorecon $statedir/dhcpd.leases >/dev/null 2>&1
+fi
+
+configtest() {
+ [ -x $dhcpd ] || return 5
+ [ -f $conf ] || return 6
+ $dhcpd -q -t -cf $conf
+ RETVAL=$?
+ return $RETVAL
+}
+
+start() {
+ [ -x $dhcpd ] || return 5
+ [ -f $conf ] || return 6
+
+ pidofproc $prog >/dev/null 2>&1
+ RETVAL=$?
+ [ $RETVAL -eq 0 ] && return $RETVAL
+
+ echo -n $"Starting $prog: "
+ daemon $dhcpd $DHCPDARGS 2>/dev/null
+ RETVAL=$?
+ echo
+ [ $RETVAL = 0 ] && touch $lockfile
+ return $RETVAL
+}
+
+stop() {
+ pidofproc $prog >/dev/null 2>&1
+ if [ $? -ne 0 ]; then
+ RETVAL=7
+ return $RETVAL
+ fi
+
+ echo -n $"Shutting down $prog: "
+ killproc $prog
+ RETVAL=$?
+
+ [ $RETVAL = 0 ] && success || failure
+ echo
+ [ $RETVAL = 0 ] && rm -f $lockfile
+ return $RETVAL
+}
+
+if [ $# -gt 1 ]; then
+ RETVAL=2
+ exit $RETVAL
+fi
+
+case "$1" in
+ start)
+ start
+ RETVAL=$?
+ ;;
+ stop)
+ stop
+ RETVAL=$?
+ ;;
+ restart|force-reload)
+ stop ; start
+ RETVAL=$?
+ ;;
+ try-restart|reload)
+ RETVAL=3
+ ;;
+ condrestart)
+ if [ -f $lockfile ]; then
+ stop ; start
+ RETVAL=$?
+ fi
+ ;;
+ configtest)
+ configtest
+ RETVAL=$?
+ ;;
+ status)
+ status $dhcpd
+ RETVAL=$?
+ ;;
+ *)
+ echo $"Usage: $0 {start|stop|restart|condrestart|configtest|status}"
+ RETVAL=3
+ ;;
+esac
+
+exit $RETVAL
Index: dhcpd.conf.sample
===================================================================
RCS file: dhcpd.conf.sample
diff -N dhcpd.conf.sample
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ dhcpd.conf.sample 11 Jan 2008 00:14:20 -0000 1.6
@@ -0,0 +1,31 @@
+ddns-update-style interim;
+ignore client-updates;
+
+subnet 192.168.0.0 netmask 255.255.255.0 {
+
+# --- default gateway
+ option routers 192.168.0.1;
+ option subnet-mask 255.255.255.0;
+
+ option nis-domain "domain.org";
+ option domain-name "domain.org";
+ option domain-name-servers 192.168.1.1;
+
+ option time-offset -18000; # Eastern Standard Time
+# option ntp-servers 192.168.1.1;
+# option netbios-name-servers 192.168.1.1;
+# --- Selects point-to-point node (default is hybrid). Don't change this unless
+# -- you understand Netbios very well
+# option netbios-node-type 2;
+
+ range dynamic-bootp 192.168.0.128 192.168.0.254;
+ default-lease-time 21600;
+ max-lease-time 43200;
+
+ # we want the nameserver to appear at a fixed address
+ host ns {
+ next-server marvin.redhat.com;
+ hardware ethernet 12:34:56:78:AB:CD;
+ fixed-address 207.175.42.254;
+ }
+}
Index: dhclient-script.8
===================================================================
RCS file: dhclient-script.8
diff -N dhclient-script.8
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ dhclient-script.8 11 Jan 2008 00:14:20 -0000 1.4
@@ -0,0 +1,255 @@
+.\" dhclient-script.8
+.\"
+.\" Copyright (c) 2004-2005 by Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (c) 1996-2003 by Internet Software Consortium
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
+.\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.\" Internet Systems Consortium, Inc.
+.\" 950 Charter Street
+.\" Redwood City, CA 94063
+.\" <info at isc.org>
+.\" http://www.isc.org/
+.\"
+.\" This software has been written for Internet Systems Consortium
+.\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc.
+.\" To learn more about Internet Systems Consortium, see
+.\" ``http://www.isc.org/''. To learn more about Vixie Enterprises,
+.\" see ``http://www.vix.com''. To learn more about Nominum, Inc., see
+.\" ``http://www.nominum.com''.
+.\"
+.\" $Id$
+.\"
+.TH dhclient-script 8
+.SH NAME
+dhclient-script - DHCP client network configuration script
+.SH DESCRIPTION
+The DHCP client network configuration script is invoked from time to
+time by \fBdhclient(8)\fR. This script is used by the dhcp client to
+set each interface's initial configuration prior to requesting an
+address, to test the address once it has been offered, and to set the
+interface's final configuration once a lease has been acquired. If 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.
+.PP
+This script is not meant to be customized by the end user. If local
+customizations are needed, they should be possible using the enter and
+exit hooks provided (see HOOKS for details). These hooks will allow the
+user to override the default behaviour of the client in creating a
+.B /etc/resolv.conf
+file, and to handle DHCP options not handled by default.
+.PP
+No standard client script exists for some operating systems, even though
+the actual client may work, so a pioneering user may well need to create
+a new script or modify an existing one. In general, customizations specific
+to a particular computer should be done in the
+.B ETCDIR/dhclient.conf
+file. If you find that you can't make such a customization without
+customizing
+.B ETCDIR/dhclient.conf
+or using the enter and exit hooks, please submit a bug report.
+.SH HOOKS
+When it starts, the client script first defines a shell function,
+.B make_resolv_conf ,
+which is later used to create the
+.B /etc/resolv.conf
+file. To override the default behaviour, redefine this function in
+the enter hook script.
+.PP
+On after defining the make_resolv_conf function, the client script checks
+for the presence of an executable
+.B ETCDIR/dhclient-enter-hooks
+script, and if present, it invokes the script inline, using the Bourne
+shell '.' command. The entire environment documented under OPERATION
+is available to this script, which may modify the environment if needed
+to change the behaviour of the script. If an error occurs during the
+execution of the script, it can set the exit_status variable to a nonzero
+value, and
+.B CLIENTBINDIR/dhclient-script
+will exit with that error code immediately after the client script exits.
+.PP
+After all processing has completed,
+.B CLIENTBINDIR/dhclient-script
+checks for the presence of an executable
+.B ETCDIR/dhclient-exit-hooks
+script, which if present is invoked using the '.' command. The exit
+status of dhclient-script will be passed to dhclient-exit-hooks in the
+exit_status shell variable, and will always be zero if the script
+succeeded at the task for which it was invoked. The rest of the
+environment as described previously for dhclient-enter-hooks is also
+present. The
+.B ETCDIR/dhclient-exit-hooks
+script can modify the valid of exit_status to change the exit status
+of dhclient-script.
+.PP
+Immediately after dhclient brings an interface UP with a new IP address,
+subnet mask, and routes, in the REBOOT/BOUND states, it will check for the
+existence of an executable
+.B ETCDIR/dhclient-up-hooks
+script, and source it if found. This script can handle DHCP options in
+the environment that are not handled by default. A per-interface.
+.B ETCDIR/dhclient-${IF}-up-hooks
+script will override the generic script and be sourced when interface
+$IF has been brought up.
+.PP
+Immediately before dhclient brings an interface DOWN, removing its IP
+address, subnet mask, and routes, in the STOP/RELEASE states, it will
+check for the existence of an executable
+.B ETCDIR/dhclient-down-hooks
+script, and source it if found. This script can handle DHCP options in
+the environment that are not handled by default. A per-interface
+.B ETCDIR/dhclient-${IF}-down-hooks
+script will override the generic script and be sourced when interface
+$IF is about to be brought down.
+
+.SH OPERATION
+When dhclient needs to invoke the client configuration script, it
+defines a set of variables in the environment, and then invokes
+.B CLIENTBINDIR/dhclient-script.
+In all cases, $reason is set to the name of the reason why the script
+has been invoked. The following reasons are currently defined:
+MEDIUM, PREINIT, BOUND, RENEW, REBIND, REBOOT, EXPIRE, FAIL, STOP, RELEASE,
+NBI and TIMEOUT.
+.PP
+.SH MEDIUM
+The DHCP client is requesting that an interface's media type
+be set. The interface name is passed in $interface, and the media
+type is passed in $medium.
+.SH PREINIT
+The DHCP client is requesting that an interface be configured as
+required in order to send packets prior to receiving an actual
+address. For clients which use the BSD socket library, this means
+configuring the interface with an IP address of 0.0.0.0 and a
+broadcast address of 255.255.255.255. For other clients, it may be
+possible to simply configure the interface up without actually giving
+it an IP address at all. The interface name is passed in $interface,
+and the media type in $medium.
+.PP
+If an IP alias has been declared in dhclient.conf, its address will be
+passed in $alias_ip_address, and that ip alias should be deleted from
+the interface, along with any routes to it.
+.SH BOUND
+The DHCP client has done an initial binding to a new address. The
+new ip address is passed in $new_ip_address, and the interface name is
+passed in $interface. The media type is passed in $medium. Any
+options acquired from the server are passed using the option name
+described in \fBdhcp-options\fR, except that dashes ('-') are replaced
+by underscores ('_') in order to make valid shell variables, and the
+variable names start with new_. So for example, the new subnet mask
+would be passed in $new_subnet_mask.
+.PP
+Before actually configuring the address, dhclient-script should
+somehow ARP for it and exit with a nonzero status if it receives a
+reply. In this case, the client will send a DHCPDECLINE message to
+the server and acquire a different address. This may also be done in
+the RENEW, REBIND, or REBOOT states, but is not required, and indeed
+may not be desirable.
+.PP
+When a binding has been completed, a lot of network parameters are
+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,
+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
+If an IP alias has been declared, it must be set up here. The alias
+IP address will be written as $alias_ip_address, and other DHCP
+options that are set for the alias (e.g., subnet mask) will be passed
+in variables named as described previously except starting with
+$alias_ instead of $new_. Care should be taken that the alias IP
+address not be used if it is identical to the bound IP address
+($new_ip_address), since the other alias parameters may be incorrect
+in this case.
+.SH RENEW
+When a binding has been renewed, the script is called as in BOUND,
+except that in addition to all the variables starting with $new_,
+there is another set of variables starting with $old_. Persistent
+settings that may have changed need to be deleted - for example, if a
+local route to the bound address is being configured, the old local
+route should be deleted. If the default route has changed, the old default
+route should be deleted. If the static routes have changed, the old
+ones should be deleted. Otherwise, processing can be done as with
+BOUND.
+.SH REBIND
+The DHCP client has rebound to a new DHCP server. This can be handled
+as with RENEW, except that if the IP address has changed, the ARP
+table should be cleared.
+.SH REBOOT
+The DHCP client has successfully reacquired its old address after a
+reboot. This can be processed as with BOUND.
+.SH EXPIRE
+The DHCP client has failed to renew its lease or acquire a new one,
+and the lease has expired. The IP address must be relinquished, and
+all related parameters should be deleted, as in RENEW and REBIND.
+.SH FAIL
+The DHCP client has been unable to contact any DHCP servers, and any
+leases that have been tested have not proved to be valid. The
+parameters from the last lease tested should be deconfigured. This
+can be handled in the same way as EXPIRE.
+.SH STOP
+The dhclient has been informed to shut down gracefully, the
+dhclient-script should unconfigure or shutdown the interface as
+appropriate.
+.SH RELEASE
+The dhclient has been executed using the -r flag, indicating that the
+administrator wishes it to release its lease(s). dhclient-script should
+unconfigure or shutdown the interface.
+.SH NBI
+No-Broadcast-Interfaces...dhclient was unable to find any interfaces
+upon which it believed it should commence DHCP. What dhclient-script
+should do in this situation is entirely up to the implementor.
+.SH TIMEOUT
+The DHCP client has been unable to contact any DHCP servers.
+However, an old lease has been identified, and its parameters have
+been passed in as with BOUND. The client configuration script should
+test these parameters and, if it has reason to believe they are valid,
+should exit with a value of zero. If not, it should exit with a
+nonzero value.
+.PP
+The usual way to test a lease is to set up the network as with REBIND
+(since this may be called to test more than one lease) and then ping
+the first router defined in $routers. If a response is received, the
+lease must be valid for the network to which the interface is
+currently connected. It would be more complete to try to ping all of
+the routers listed in $new_routers, as well as those listed in
+$new_static_routes, but current scripts do not do this.
+.SH FILES
+Each operating system should generally have its own script file,
+although the script files for similar operating systems may be similar
+or even identical. The script files included in Internet
+Systems Consortium DHCP distribution appear in the distribution tree
+under client/scripts, and bear the names of the operating systems on
+which they are intended to work.
+.SH BUGS
+If more than one interface is being used, there's no obvious way to
+avoid clashes between server-supplied configuration parameters - for
+example, the stock dhclient-script rewrites /etc/resolv.conf. If
+more than one interface is being configured, /etc/resolv.conf will be
+repeatedly initialized to the values provided by one server, and then
+the other. Assuming the information provided by both servers is
+valid, this shouldn't cause any real problems, but it could be
+confusing.
+.SH SEE ALSO
+dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) and
+dhclient.leases(5).
+.SH AUTHOR
+.B dhclient-script(8)
+has been written for Internet Systems Consortium
+by Ted Lemon in cooperation with Vixie
+Enterprises. To learn more about Internet Systems Consortium,
+see
+.B http://www.isc.org.
+To learn more about Vixie
+Enterprises, see
+.B http://www.vix.com.
Index: dhclient.8
===================================================================
RCS file: dhclient.8
diff -N dhclient.8
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ dhclient.8 11 Jan 2008 00:14:20 -0000 1.4
@@ -0,0 +1,428 @@
+.\" dhclient.8
+.\"
+.\" Copyright (c) 2004,2007 by Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (c) 1996-2003 by Internet Software Consortium
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
+.\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.\" Internet Systems Consortium, Inc.
+.\" 950 Charter Street
+.\" Redwood City, CA 94063
+.\" <info at isc.org>
+.\" http://www.isc.org/
+.\"
+.\" Support and other services are available for ISC products - see
+.\" http://www.isc.org for more information.
+.\"
+.\" $Id$
+.\"
+.TH dhclient 8
+.SH NAME
+dhclient - Dynamic Host Configuration Protocol Client
+.SH SYNOPSIS
+.B dhclient
+[
+.B -p
+.I port
+]
+[
+.B -d
+]
+[
+.B -e
+.I VAR=value
+]
+[
+.B -q
+]
+[
+.B -1
+]
+[
+.B -r
+]
+[
+.B -x
+]
+[
+.B -lf
+.I lease-file
+]
+[
+.B -pf
+.I pid-file
+]
+[
+.B -cf
+.I config-file
+]
+[
+.B -sf
+.I script-file
+]
+[
+.B -s
+server
+]
+[
+.B -g
+relay
+]
+[
+.B -n
+]
+[
+.B -nw
+]
+[
+.B -w
+]
+[
+.B -B
+]
+[
+.B -I
+.I dhcp-client-identifier
+]
+[
+.B -H
+.I host-name
+.R |
+.B -F fqdn.fqdn
+]
+[
+.B -V
+.I vendor-class-identifier
+]
+[
+.B -R
+.I request option list
+]
+[
+.B -T
+.I timeout
+]
+[
+.I if0
+[
+.I ...ifN
+]
+]
+.SH DESCRIPTION
+The Internet Systems Consortium DHCP Client, dhclient, provides a
+means for configuring one or more network interfaces using the Dynamic
+Host Configuration Protocol, BOOTP protocol, or if these protocols
+fail, by statically assigning an address.
+.SH OPERATION
+.PP
+The DHCP protocol allows a host to contact a central server which
+maintains a list of IP addresses which may be assigned on one or more
+subnets. A DHCP client may request an address from this pool, and
+then use it on a temporary basis for communication on network. The
+DHCP protocol also provides a mechanism whereby a client can learn
+important details about the network to which it is attached, such as
+the location of a default router, the location of a name server, and
+so on.
+.PP
+On startup, dhclient reads the
+.IR dhclient.conf
+for configuration instructions. It then gets a list of all the
+network interfaces that are configured in the current system. For
+each interface, it attempts to configure the interface using the DHCP
+protocol.
+.PP
+In order to keep track of leases across system reboots and server
+restarts, dhclient keeps a list of leases it has been assigned in the
+dhclient.leases(5) file. On startup, after reading the dhclient.conf
+file, dhclient reads the dhclient.leases file to refresh its memory
+about what leases it has been assigned.
+.PP
+When a new lease is acquired, it is appended to the end of the
+dhclient.leases file. In order to prevent the file from becoming
+arbitrarily large, from time to time dhclient creates a new
+dhclient.leases file from its in-core lease database. The old version
+of the dhclient.leases file is retained under the name
+.IR dhclient.leases~
+until the next time dhclient rewrites the database.
+.PP
+Old leases are kept around in case the DHCP server is unavailable when
+dhclient is first invoked (generally during the initial system boot
+process). In that event, old leases from the dhclient.leases file
+which have not yet expired are tested, and if they are determined to
+be valid, they are used until either they expire or the DHCP server
+becomes available.
+.PP
+A mobile host which may sometimes need to access a network on which no
+DHCP server exists may be preloaded with a lease for a fixed
+address on that network. When all attempts to contact a DHCP server
+have failed, dhclient will try to validate the static lease, and if it
+succeeds, will use that lease until it is restarted.
+.PP
+A mobile host may also travel to some networks on which DHCP is not
+available but BOOTP is. In that case, it may be advantageous to
+arrange with the network administrator for an entry on the BOOTP
+database, so that the host can boot quickly on that network rather
+than cycling through the list of old leases.
+.PP
+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 normally identify all
+network interfaces, eliminating non-broadcast interfaces if
+possible, and attempt to configure each interface.
+.PP
+It is also possible to specify interfaces by name in the
+.B dhclient.conf(5)
+file. If interfaces are specified in this way, then the client will
+only configure interfaces that are either specified in the
+configuration file or on the command line, and will ignore all other
+interfaces.
+.SH OPTIONS
+.TP
+.BI \-p\ <port\ number>
+The UDP port number the DHCP client should listen and transmit on. If
+unspecified,
+.B dhclient
+uses the default port 68. This option is mostly useful for debugging
+purposes. If a different port is specified for the client to listen and
+transmit on, the client will also use a different destination port - one
+greater than the specified destination port.
+
+.TP
+.BI \-d
+Force
+.B dhclient
+to run as a foreground process. This is useful when running the client
+under a debugger, or when running it out of inittab on System V systems.
+
+.TP
+.BI \-e\ VAR=value
+Define additional environment variables for the environment where
+dhclient-script executes. You may specify multiple
+.B \-e
+options on the command line.
+
+.TP
+.BI \-q
+Suppress all terminal and log output except error messages.
+
+.TP
+.BI \-1
+Try one to get a lease. On failure, exit with code 2.
+
+.TP
+.BI \-r
+Tell
+.B dhclient
+to release the current lease it has from the server. This is not required
+by the DHCP protocol, but some ISPs require their clients to notify the
+server if they wish to release an assigned IP address.
+
+.TP
+.BI \-lf\ <lease-file>
+Path to the lease database file. If unspecified, the default
+.B DBDIR/dhclient.leases
+is used.
+
+.TP
+.BI \-pf\ <pid-file>
+Path to the process ID file. If unspecified, the default
+.B RUNDIR/dhclient.pid
+is used.
+
+.TP
+.BI \-cf\ <config-file>
+Path to the client configuration file. If unspecified, the default
+.B ETCDIR/dhclient.conf
+is used.
+
+.TP
+.BI \-sf\ <script-file>
+Path to the network configuration script invoked by
+.B dhclient
+when it gets a lease. If unspecified, the default
+.B CLIENTBINDIR/dhclient-script
+is used.
+
+.TP
+.BI \-s\ <server>
+Specifiy the server IP address or fully qualified domain name to transmit
+DHCP protocol messages to. Normally,
+.B dhclient
+transmits these messages to 255.255.255.255 (the IP limited broadcast
+address). Overriding this is mostly useful for debugging purposes.
+
+.TP
+.BI \-g\ <relay>
+Only for debugging. Set the giaddr field of all packets the client
+sends to the IP address specified. This should not be expected to work
+in any consistent or useful way.
+
+.TP
+.BI \-n
+Do not configure any interfaces. Most useful combined with the
+.B -w
+option.
+
+.TP
+.BI \-nw
+Become a daemon process immediately (nowait) rather than waiting until an IP
+address has been acquired.
+
+.TP
+.BI \-w
+Keep running even if no network interfaces are found. The
+.B omshell
+program can be used to notify the client when a network interface has been
+added or removed so it can attempt to configure an IP address on that
+interface.
+
+.TP
+.BI \-B
+Set the BOOTP broadcast flag in request packets so servers will always
+broadcast replies.
+
+.TP
+.BI \-I\ <dhcp-client-identifier>
+Specify the dhcp-client-identifier option to send to the DHCP server.
+
+.TP
+.BI \-H\ <host-name>
+Specify the host-name option to send to the DHCP server. The host-name
+string only contains the client's hostname prefix, to which the server will
+append the ddns-domainname or domain-name options, if any, to derive the
+fully qualified domain name of the client. The
+.B -H
+option cannot be used with the
+.B -F
+option.
+
+.TP
+.BI \-F\ <fqdn.fqdn>
+Specify the fqdn.fqdn option to send to the DHCP server. This option cannot
+be used with the
+.B -H
+option. The fqdn.fqdn option must specify the complete domain name of the
+client host, which the server may use for dynamic DNS updates.
+
+.TP
+.BI \-V\ <vendor-class-identifier>
+Specify the vendor-class-identifier option to send to the DHCP server.
+
+.TP
+.BI \-R\ <option>[,<option>...]
+Specify the list of options the client is to request from the server. The
+option list must be a single string consisting of option names separated
+by at least one command and optional space characters. The default option
+list is:
+
+.BR
+ subnet-mask, broadcast-address, time-offset, routers,
+.BR
+ domain-name, domain-name-servers, host-name, nis-domain,
+.BR
+ nis-servers, ntp-servers
+
+The
+.B -R
+option does not append options to the default request, it overrides the
+default request list. Keep this in mind if you want to request an
+additional option besides the default request list. You will have to
+specify all option names for the
+.B -R
+parameter.
+
+.TP
+.BI \-T\ <timeout>
+Specify the time after which
+.B dhclient
+will decide that no DHCP servers can be contacted when no responses have been
+received.
+
+.PP
+If the client is killed by a signal (for example at shutdown or reboot)
+it won't execute the
+.B dhclient-script (8)
+at exit. However if you shut the client down gracefully with
+.B -r
+or
+.B -x
+it will execute
+.B dhclient-script (8)
+at shutdown with the specific reason for calling the script set.
+
+.PP
+.SH CONFIGURATION
+The syntax of the dhclient.conf(5) file is discussed separately.
+.SH OMAPI
+The DHCP client provides some ability to control it while it is
+running, without stopping it. This capability is provided using OMAPI,
+an API for manipulating remote objects. OMAPI clients connect to the
+client using TCP/IP, authenticate, and can then examine the client's
+current status and make changes to it.
+.PP
+Rather than implementing the underlying OMAPI protocol directly, user
+programs should use the dhcpctl API or OMAPI itself. Dhcpctl is a
+wrapper that handles some of the housekeeping chores that OMAPI does
+not do automatically. Dhcpctl and OMAPI are documented in \fBdhcpctl(3)\fR
+and \fBomapi(3)\fR. Most things you'd want to do with the client can
+be done directly using the \fBomshell(1)\fR command, rather than
+having to write a special program.
+.SH THE CONTROL OBJECT
+The control object allows you to shut the client down, releasing all
+leases that it holds and deleting any DNS records it may have added.
+It also allows you to pause the client - this unconfigures any
+interfaces the client is using. You can then restart it, which
+causes it to reconfigure those interfaces. You would normally pause
+the client prior to going into hibernation or sleep on a laptop
+computer. You would then resume it after the power comes back.
+This allows PC cards to be shut down while the computer is hibernating
+or sleeping, and then reinitialized to their previous state once the
+computer comes out of hibernation or sleep.
+.PP
+The control object has one attribute - the state attribute. To shut
+the client down, set its state attribute to 2. It will automatically
+do a DHCPRELEASE. To pause it, set its state attribute to 3. To
+resume it, set its state attribute to 4.
+.PP
+.SH FILES
+.B CLIENTBINDIR/dhclient-script,
+.B ETCDIR/dhclient.conf, DBDIR/dhclient.leases, RUNDIR/dhclient.pid,
+.B DBDIR/dhclient.leases~.
+.SH SEE ALSO
+dhcpd(8), dhcrelay(8), dhclient-script(8), dhclient.conf(5),
+dhclient.leases(5), dhcp-eval(5).
+.SH AUTHOR
+.B dhclient(8)
+has been written for Internet Systems Consortium
+by Ted Lemon in cooperation with Vixie
+Enterprises. To learn more about Internet Systems Consortium,
+see
+.B http://www.isc.org
+To learn more about Vixie
+Enterprises, see
+.B http://www.vix.com.
+.PP
+This client was substantially modified and enhanced by Elliot Poger
+for use on Linux while he was working on the MosquitoNet project at
+Stanford.
+.PP
+The current version owes much to Elliot's Linux enhancements, but
+was substantially reorganized and partially rewritten by Ted Lemon
+so as to use the same networking framework that the Internet Systems
+Consortium DHCP server uses. Much system-specific configuration code
+was moved into a shell script so that as support for more operating
+systems is added, it will not be necessary to port and maintain
+system-specific configuration code to these operating systems - instead,
+the shell script can invoke the native tools to accomplish the same
+purpose.
+.PP
Index: dhclient.conf.5
===================================================================
RCS file: dhclient.conf.5
diff -N dhclient.conf.5
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ dhclient.conf.5 11 Jan 2008 00:14:20 -0000 1.4
@@ -0,0 +1,660 @@
+.\" $Id$
+.\"
+.\" Copyright (c) 2004,2007 by Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (c) 1996-2003 by Internet Software Consortium
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
+.\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.\" Internet Systems Consortium, Inc.
+.\" 950 Charter Street
+.\" Redwood City, CA 94063
+.\" <info at isc.org>
+.\" http://www.isc.org/
+.\"
+.\" This software has been written for Internet Software Consortium
+.\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc.
+.\" To learn more about Internet Software Consortium, see
+.\" ``http://www.isc.org/''. To learn more about Vixie Enterprises,
+.\" see ``http://www.vix.com''. To learn more about Nominum, Inc., see
+.\" ``http://www.nominum.com''.
+.\"
+.\" $Id$
+.\"
+.TH dhclient.conf 5
+.SH NAME
+dhclient.conf - DHCP client configuration file
+.SH DESCRIPTION
+The dhclient.conf file contains configuration information for
+.IR dhclient,
+the Internet Systems Consortium DHCP Client.
+.PP
+The dhclient.conf file is a free-form ASCII text file. It is parsed by
+the recursive-descent parser built into dhclient. The file may contain
+extra tabs and newlines for formatting purposes. Keywords in the file
+are case-insensitive. Comments may be placed anywhere within the
+file (except within quotes). Comments begin with the # character and
+end at the end of the line.
+.PP
+The dhclient.conf file can be used to configure the behaviour of the
+client in a wide variety of ways: protocol timing, information
+requested from the server, information required of the server,
+defaults to use if the server does not provide certain information,
+values with which to override information provided by the server, or
+values to prepend or append to information provided by the server.
+The configuration file can also be preinitialized with addresses to
+use on networks that don't have DHCP servers.
+.SH PROTOCOL TIMING
+The timing behaviour of the client need not be configured by the user.
+If no timing configuration is provided by the user, a fairly
+reasonable timing behaviour will be used by default - one which
+results in fairly timely updates without placing an inordinate load on
+the server.
+.PP
+The following statements can be used to adjust the timing behaviour of
+the DHCP client if required, however:
+.PP
+.I The
+.B timeout
+.I statement
+.PP
+.B timeout
+.I time
+.B ;
+.PP
+The
+.I timeout
+statement determines the amount of time that must pass between the
+time that the client begins to try to determine its address and the
+time that it decides that it's not going to be able to contact a
+server. By default, this timeout is sixty seconds. After the
+timeout has passed, if there are any static leases defined in the
+configuration file, or any leases remaining in the lease database that
+have not yet expired, the client will loop through these leases
+attempting to validate them, and if it finds one that appears to be
+valid, it will use that lease's address. If there are no valid
+static leases or unexpired leases in the lease database, the client
+will restart the protocol after the defined retry interval.
+.PP
+.I The
+.B retry
+.I statement
+.PP
+ \fBretry \fItime\fR\fB;\fR
+.PP
+The
+.I retry
+statement determines the time that must pass after the client has
+determined that there is no DHCP server present before it tries again
+to contact a DHCP server. By default, this is five minutes.
+.PP
+.I The
+.B select-timeout
+.I statement
+.PP
+ \fBselect-timeout \fItime\fR\fB;\fR
+.PP
+It is possible (some might say desirable) for there to be more than
+one DHCP server serving any given network. In this case, it is
+possible that a client may be sent more than one offer in response to
+its initial lease discovery message. It may be that one of these
+offers is preferable to the other (e.g., one offer may have the
+address the client previously used, and the other may not).
+.PP
+The
+.I select-timeout
+is the time after the client sends its first lease discovery request
+at which it stops waiting for offers from servers, assuming that it
+has received at least one such offer. If no offers have been
+received by the time the
+.I select-timeout
+has expired, the client will accept the first offer that arrives.
+.PP
+By default, the select-timeout is zero seconds - that is, the client
+will take the first offer it sees.
+.PP
+.I The
+.B reboot
+.I statement
+.PP
+ \fBreboot \fItime\fR\fB;\fR
+.PP
+When the client is restarted, it first tries to reacquire the last
+address it had. This is called the INIT-REBOOT state. If it is
+still attached to the same network it was attached to when it last
+ran, this is the quickest way to get started. The
+.I reboot
+statement sets the time that must elapse after the client first tries
+to reacquire its old address before it gives up and tries to discover
+a new address. By default, the reboot timeout is ten seconds.
+.PP
+.I The
+.B backoff-cutoff
+.I statement
+.PP
+ \fBbackoff-cutoff \fItime\fR\fB;\fR
+.PP
+The client uses an exponential backoff algorithm with some randomness,
+so that if many clients try to configure themselves at the same time,
+they will not make their requests in lockstep. The
+.I backoff-cutoff
+statement determines the maximum amount of time that the client is
+allowed to back off, the actual value will be evaluated randomly between
+1/2 to 1 1/2 times the \fItime\fR specified. It defaults to two minutes.
+.PP
+.I The
+.B initial-interval
+.I statement
+.PP
+ \fBinitial-interval \fItime\fR\fB;\fR
+.PP
+The
+.I initial-interval
+statement sets the amount of time between the first attempt to reach a
+server and the second attempt to reach a server. Each time a message
+is sent, the interval between messages is incremented by twice the
+current interval multiplied by a random number between zero and one.
+If it is greater than the backoff-cutoff amount, it is set to that
+amount. It defaults to ten seconds.
+.SH LEASE REQUIREMENTS AND REQUESTS
+The DHCP protocol allows the client to request that the server send it
+specific information, and not send it other information that it is not
+prepared to accept. The protocol also allows the client to reject
+offers from servers if they don't contain information the client
+needs, or if the information provided is not satisfactory.
+.PP
+There is a variety of data contained in offers that DHCP servers send
+to DHCP clients. The data that can be specifically requested is what
+are called \fIDHCP Options\fR. DHCP Options are defined in
+ \fBdhcp-options(5)\fR.
+.PP
+.I The
+.B request
+.I statement
+.PP
+ \fBrequest [ \fIoption\fR ] [\fB,\fI ... \fIoption\fR ]\fB;\fR
+.PP
+The request statement causes the client to request that any server
+responding to the client send the client its values for the specified
+options. Only the option names should be specified in the request
+statement - not option parameters. By default, the DHCP server
+requests the subnet-mask, broadcast-address, time-offset, routers,
+domain-name, domain-name-servers, host-name, nis-domain, nis-servers,
+and ntp-servers options.
+.PP
+In some cases, it may be desirable to send no parameter request list
+at all. To do this, simply write the request statement but specify
+no parameters:
+.PP
+.nf
+ request;
+.fi
+.PP
+.I The
+.B require
+.I statement
+.PP
+ \fBrequire [ \fIoption\fR ] [\fB,\fI ... \fIoption ]\fB;\fR
+.PP
+The require statement lists options that must be sent in order for an
+offer to be accepted. Offers that do not contain all the listed
+options will be ignored.
+.PP
+.I The
+.B send
+.I statement
+.PP
+ \fBsend { [ \fIoption declaration\fR ]
+[\fB,\fI ... \fIoption declaration\fR ]\fB}\fR
+.PP
+The send statement causes the client to send the specified options to
+the server with the specified values. These are full option
+declarations as described in \fBdhcp-options(5)\fR. Options that are
+always sent in the DHCP protocol should not be specified here, except
+that the client can specify a \fBrequested-lease-time\fR option other
+than the default requested lease time, which is two hours. The other
+obvious use for this statement is to send information to the server
+that will allow it to differentiate between this client and other
+clients or kinds of clients.
+.SH DYNAMIC DNS
+The client now has some very limited support for doing DNS updates
+when a lease is acquired. This is prototypical, and probably doesn't
+do what you want. It also only works if you happen to have control
+over your DNS server, which isn't very likely.
+.PP
+To make it work, you have to declare a key and zone as in the DHCP
+server (see \fBdhcpd.conf\fR(5) for details). You also need to
+configure the fqdn option on the client, as follows:
+.PP
+.nf
+ send fqdn.fqdn "grosse.fugue.com.";
+ send fqdn.encoded on;
+ send fqdn.server-update off;
+.fi
+.PP
+The \fIfqdn.fqdn\fR option \fBMUST\fR be a fully-qualified domain
+name. You \fBMUST\fR define a zone statement for the zone to be
+updated. The \fIfqdn.encoded\fR option may need to be set to
+\fIon\fR or \fIoff\fR, depending on the DHCP server you are using.
+.PP
+.I The
+.B do-forward-updates
+.I statement
+.PP
+ \fBdo-forward-updates [ \fIflag\fR ] \fB;\fR
+.PP
+If you want to do DNS updates in the DHCP client
+script (see \fBdhclient-script(8)\fR) rather than having the
+DHCP client do the update directly (for example, if you want to
+use SIG(0) authentication, which is not supported directly by the
+DHCP client, you can instruct the client not to do the update using
+the \fBdo-forward-updates\fR statement. \fIFlag\fR should be \fBtrue\fR
+if you want the DHCP client to do the update, and \fBfalse\fR if
+you don't want the DHCP client to do the update. By default, the DHCP
+client will do the DNS update.
+.SH OPTION MODIFIERS
+In some cases, a client may receive option data from the server which
+is not really appropriate for that client, or may not receive
+information that it needs, and for which a useful default value
+exists. It may also receive information which is useful, but which
+needs to be supplemented with local information. To handle these
+needs, several option modifiers are available.
+.PP
+.I The
+.B default
+.I statement
+.PP
+ \fBdefault [ \fIoption declaration\fR ] \fB;\fR
+.PP
+If for some option the client should use the value supplied by
+the server, but needs to use some default value if no value was supplied
+by the server, these values can be defined in the
+.B default
+statement.
+.PP
+.I The
+.B supersede
+.I statement
+.PP
+ \fBsupersede [ \fIoption declaration\fR ] \fB;\fR
+.PP
+If for some option the client should always use a locally-configured
+value or values rather than whatever is supplied by the server, these
+values can be defined in the
+.B supersede
+statement.
+.PP
+.I The
+.B prepend
+.I statement
+.PP
+ \fBprepend [ \fIoption declaration\fR ] \fB;\fR
+.PP
+If for some set of options the client should use a value you
+supply, and then use the values supplied by
+the server, if any, these values can be defined in the
+.B prepend
+statement. The
+.B prepend
+statement can only be used for options which
+allow more than one value to be given. This restriction is not
+enforced - if you ignore it, the behaviour will be unpredictable.
+.PP
+.I The
+.B append
+.I statement
+.PP
+ \fBappend [ \fIoption declaration\fR ] \fB;\fR
+.PP
+If for some set of options the client should first use the values
+supplied by the server, if any, and then use values you supply, these
+values can be defined in the
+.B append
+statement. The
+.B append
+statement can only be used for options which
+allow more than one value to be given. This restriction is not
+enforced - if you ignore it, the behaviour will be unpredictable.
+.SH LEASE DECLARATIONS
+.PP
+.I The
+.B lease
+.I declaration
+.PP
+ \fBlease {\fR \fIlease-declaration\fR [ ... \fIlease-declaration ] \fB}\fR
+.PP
+The DHCP client may decide after some period of time (see \fBPROTOCOL
+TIMING\fR) that it is not going to succeed in contacting a
+server. At that time, it consults its own database of old leases and
+tests each one that has not yet timed out by pinging the listed router
+for that lease to see if that lease could work. It is possible to
+define one or more \fIfixed\fR leases in the client configuration file
+for networks where there is no DHCP or BOOTP service, so that the
+client can still automatically configure its address. This is done
+with the
+.B lease
+statement.
+.PP
+NOTE: the lease statement is also used in the dhclient.leases file in
+order to record leases that have been received from DHCP servers.
+Some of the syntax for leases as described below is only needed in the
+dhclient.leases file. Such syntax is documented here for
+completeness.
+.PP
+A lease statement consists of the lease keyword, followed by a left
+curly brace, followed by one or more lease declaration statements,
+followed by a right curly brace. The following lease declarations
+are possible:
+.PP
+ \fBbootp;\fR
+.PP
+The
+.B bootp
+statement is used to indicate that the lease was acquired using the
+BOOTP protocol rather than the DHCP protocol. It is never necessary
+to specify this in the client configuration file. The client uses
+this syntax in its lease database file.
+.PP
+ \fBinterface\fR \fB"\fR\fIstring\fR\fB";\fR
+.PP
+The
+.B interface
+lease statement is used to indicate the interface on which the lease
+is valid. If set, this lease will only be tried on a particular
+interface. When the client receives a lease from a server, it always
+records the interface number on which it received that lease.
+If predefined leases are specified in the dhclient.conf file, the
+interface should also be specified, although this is not required.
+.PP
+ \fBfixed-address\fR \fIip-address\fR\fB;\fR
+.PP
+The
+.B fixed-address
+statement is used to set the ip address of a particular lease. This
+is required for all lease statements. The IP address must be
+specified as a dotted quad (e.g., 12.34.56.78).
+.PP
+ \fBfilename "\fR\fIstring\fR\fB";\fR
+.PP
+The
+.B filename
+statement specifies the name of the boot filename to use. This is
+not used by the standard client configuration script, but is included
+for completeness.
+.PP
+ \fBserver-name "\fR\fIstring\fR\fB";\fR
+.PP
+The
+.B server-name
+statement specifies the name of the boot server name to use. This is
+also not used by the standard client configuration script.
+.PP
+ \fBoption\fR \fIoption-declaration\fR\fB;\fR
+.PP
+The
+.B option
+statement is used to specify the value of an option supplied by the
+server, or, in the case of predefined leases declared in
+dhclient.conf, the value that the user wishes the client configuration
+script to use if the predefined lease is used.
+.PP
+ \fBscript "\fIscript-name\fB";\fR
+.PP
+The
+.B script
+statement is used to specify the pathname of the dhcp client
+configuration script. This script is used by the dhcp client to set
+each interface's initial configuration prior to requesting an address,
+to test the address once it has been offered, and to set the
+interface's final configuration once a lease has been acquired. If
+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-script(8).
+.PP
+ \fBvendor option space "\fIname\fB";\fR
+.PP
+The
+.B vendor option space
+statement is used to specify which option space should be used for
+decoding the vendor-encapsulate-options option if one is received.
+The \fIdhcp-vendor-identifier\fR can be used to request a specific
+class of vendor options from the server. See
+.B dhcp-options(5)
+for details.
+.PP
+ \fBmedium "\fImedia setup\fB";\fR
+.PP
+The
+.B medium
+statement can be used on systems where network interfaces cannot
+automatically determine the type of network to which they are
+connected. The media setup string is a system-dependent parameter
+which is passed to the dhcp client configuration script when
+initializing the interface. On Unix and Unix-like systems, the
+argument is passed on the ifconfig command line when configuring the
+interface.
+.PP
+The dhcp client automatically declares this parameter if it uses a
+media type (see the
+.B media
+statement) when configuring the interface in order to obtain a lease.
+This statement should be used in predefined leases only if the network
+interface requires media type configuration.
+.PP
+ \fBrenew\fR \fIdate\fB;\fR
+.PP
+ \fBrebind\fR \fIdate\fB;\fR
+.PP
+ \fBexpire\fR \fIdate\fB;\fR
+.PP
+The \fBrenew\fR statement defines the time at which the dhcp client
+should begin trying to contact its server to renew a lease that it is
+using. The \fBrebind\fR statement defines the time at which the dhcp
+client should begin to try to contact \fIany\fR dhcp server in order
+to renew its lease. The \fBexpire\fR statement defines the time at
+which the dhcp client must stop using a lease if it has not been able
+to contact a server in order to renew it.
+.PP
+These declarations are automatically set in leases acquired by the
+DHCP client, but must also be configured in predefined leases - a
+predefined lease whose expiry time has passed will not be used by the
+DHCP client.
+.PP
+Dates are specified as follows:
+.PP
+ \fI<weekday> <year>\fB/\fI<month>\fB/\fI<day>
+<hour>\fB:\fI<minute>\fB:\fI<second>\fR
+.PP
+The weekday is present to make it easy for a human to tell when a
+lease expires - it's specified as a number from zero to six, with zero
+being Sunday. When declaring a predefined lease, it can always be
+specified as zero. The year is specified with the century, so it
+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 59, and the
+second also a number between 0 and 59.
+.SH ALIAS DECLARATIONS
+ \fBalias { \fI declarations ... \fB}\fR
+.PP
+Some DHCP clients running TCP/IP roaming protocols may require that in
+addition to the lease they may acquire via DHCP, their interface also
+be configured with a predefined IP alias so that they can have a
+permanent IP address even while roaming. The Internet Systems
+Consortium DHCP client doesn't support roaming with fixed addresses
+directly, but in order to facilitate such experimentation, the dhcp
+client can be set up to configure an IP alias using the
+.B alias
+declaration.
+.PP
+The alias declaration resembles a lease declaration, except that
+options other than the subnet-mask option are ignored by the standard
+client configuration script, and expiry times are ignored. A typical
+alias declaration includes an interface declaration, a fixed-address
+declaration for the IP alias address, and a subnet-mask option
+declaration. A medium statement should never be included in an alias
+declaration.
+.SH OTHER DECLARATIONS
+ \fBreject \fIcidr-ip-address\fR [\fB,\fR \fI...\fB \fIcidr-ip-address\fR ] \fB;\fR
+.PP
+The
+.B reject
+statement causes the DHCP client to reject offers from
+servers whose server identifier matches any of the specified hosts or
+subnets. This can be used to avoid being configured by rogue or
+misconfigured dhcp servers, although it should be a last resort -
+better to track down the bad DHCP server and fix it.
+.PP
+The \fIcidr-ip-address\fR configuration type is of the
+form \fIip-address\fR[\fB/\fIprefixlen\fR], where \fIip-address\fR is a
+dotted quad IP address, and \fRprefixlen\fR is the CIDR prefix length of
+the subnet, counting the number of significant bits in the netmask starting
+from the leftmost end. Example configuration syntax:
+.PP
+ \fIreject\fR 192.168.0.0\fB/\fR16\fB,\fR 10.0.0.5\fB;\fR
+.PP
+The above example would cause offers from any server identifier in the
+entire RFC 1918 "Class C" network 192.168.0.0/16, or the specific
+single address 10.0.0.5, to be rejected.
+.PP
+ \fBinterface "\fIname\fB" { \fIdeclarations ... \fB }
+.PP
+A client with more than one network interface may require different
+behaviour depending on which interface is being configured. All
+timing parameters and declarations other than lease and alias
+declarations can be enclosed in an interface declaration, and those
+parameters will then be used only for the interface that matches the
+specified name. Interfaces for which there is no interface
+declaration will use the parameters declared outside of any interface
+declaration, or the default settings.
+.PP
+.B Note well:
+ISC dhclient only maintains one list of interfaces, which is either
+determined at startup from command line arguments, or otherwise is
+autodetected. If you supplied the list of interfaces on the command
+line, this configuration clause will add the named interface to the
+list in such a way that will cause it to be configured by DHCP. Which
+may not be the result you had intended. This is an undesirable side
+effect that will be addressed in a future release.
+.PP
+ \fBpseudo "\fIname\fR" "\fIreal-name\fB" { \fIdeclarations ... \fB }
+.PP
+Under some circumstances it can be useful to declare a pseudo-interface
+and have the DHCP client acquire a configuration for that interface.
+Each interface that the DHCP client is supporting normally has a DHCP
+client state machine running on it to acquire and maintain its lease.
+A pseudo-interface is just another state machine running on the
+interface named \fIreal-name\fR, with its own lease and its own
+state. If you use this feature, you must provide a client identifier
+for both the pseudo-interface and the actual interface, and the two
+identifiers must be different. You must also provide a separate
+client script for the pseudo-interface to do what you want with the IP
+address. For example:
+.PP
+.nf
+ interface "ep0" {
+ send dhcp-client-identifier "my-client-ep0";
+ }
+ pseudo "secondary" "ep0" {
+ send dhcp-client-identifier "my-client-ep0-secondary";
+ script "/etc/dhclient-secondary";
+ }
+.fi
+.PP
+The client script for the pseudo-interface should not configure the
+interface up or down - essentially, all it needs to handle are the
+states where a lease has been acquired or renewed, and the states
+where a lease has expired. See \fBdhclient-script(8)\fR for more
+information.
+.PP
+ \fBmedia "\fImedia setup\fB"\fI [ \fB, "\fImedia setup\fB", \fI... ]\fB;\fR
+.PP
+The
+.B media
+statement defines one or more media configuration parameters which may
+be tried while attempting to acquire an IP address. The dhcp client
+will cycle through each media setup string on the list, configuring
+the interface using that setup and attempting to boot, and then trying
+the next one. This can be used for network interfaces which aren't
+capable of sensing the media type unaided - whichever media type
+succeeds in getting a request to the server and hearing the reply is
+probably right (no guarantees).
+.PP
+The media setup is only used for the initial phase of address
+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
+media type. The lease must expire before the client will go back to
+cycling through media types.
+.PP
+ \fBbootp-broadcast-always;\fR
+.PP
+The
+.B bootp-broadcast-always
+statement instructs dhclient to always set the bootp broadcast flag in
+request packets, so that servers will always broadcast replies.
+This is equivalent to supplying the dhclient -B argument, and has
+the same effect as specifying 'always-broadcast' in the server's dhcpd.conf.
+This option is provided as an extension to enable dhclient to work
+on IBM s390 Linux guests.
+.PP
+.SH SAMPLE
+The following configuration file is used on a laptop running NetBSD
+1.3. The laptop has an IP alias of 192.5.5.213, and has one
+interface, ep0 (a 3com 3C589C). Booting intervals have been
+shortened somewhat from the default, because the client is known to
+spend most of its time on networks with little DHCP activity. The
+laptop does roam to multiple networks.
+
+.nf
+
+timeout 60;
+retry 60;
+reboot 10;
+select-timeout 5;
+initial-interval 2;
+reject 192.33.137.209;
+
+interface "ep0" {
+ 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 rc.vix.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;
+ script "CLIENTBINDIR/dhclient-script";
+ media "media 10baseT/UTP", "media 10base2/BNC";
+}
+
+alias {
+ interface "ep0";
+ fixed-address 192.5.5.213;
+ option subnet-mask 255.255.255.255;
+}
+.fi
+This is a very complicated dhclient.conf file - in general, yours
+should be much simpler. In many cases, it's sufficient to just
+create an empty dhclient.conf file - the defaults are usually fine.
+.SH SEE ALSO
+dhcp-options(5), dhcp-eval(5), dhclient.leases(5), dhcpd(8), dhcpd.conf(5),
+RFC2132, RFC2131.
+.SH AUTHOR
+.B dhclient(8)
+was written by Ted Lemon
+under a contract with Vixie Labs. Funding
+for this project was provided by Internet Systems Consortium.
+Information about Internet Systems Consortium can be found at
+.B http://www.isc.org.
Index: dhcp-options.5
===================================================================
RCS file: dhcp-options.5
diff -N dhcp-options.5
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ dhcp-options.5 11 Jan 2008 00:14:20 -0000 1.4
@@ -0,0 +1,1642 @@
+.\" $Id$
+.\"
+.\" Copyright (c) 2004-2007 by Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (c) 1996-2003 by Internet Software Consortium
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
+.\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.\" Internet Systems Consortium, Inc.
+.\" 950 Charter Street
+.\" Redwood City, CA 94063
+.\" <info at isc.org>
+.\" http://www.isc.org/
+.\"
+.\" This software has been written for Internet Systems Consortium
+.\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc.
+.\" To learn more about Internet Systems Consortium, see
+.\" ``http://www.isc.org/''. To learn more about Vixie Enterprises,
+.\" see ``http://www.vix.com''. To learn more about Nominum, Inc., see
+.\" ``http://www.nominum.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 text
+data type specifies an NVT ASCII string, which must be
+enclosed in double quotes - for example, to specify a root-path
+option, the syntax would be
+.nf
+.sp 1
+option root-path "10.0.1.4:/var/tmp/rootfs";
+.fi
+.PP
+The
+.B domain-name
+data type specifies a domain name, which must not
+enclosed in double quotes. This data type is not used for any
+existing DHCP options. The domain name is stored just as if it were
+a text option.
+.PP
+The
+.B domain-list
+data type specifies a list of domain names, a space between each name and
+the entire string enclosed in double quotes. These types of data are used
+for the domain-search option for example, and encodes an RFC1035 compressed
+DNS label list on the wire.
+.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 string
+data type specifies either an NVT ASCII string
+enclosed in double quotes, or a series of octets specified in
+hexadecimal, separated 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
+.SH SETTING OPTION VALUES USING EXPRESSIONS
+Sometimes it's helpful to be able to set the value of a DHCP option
+based on some value that the client has sent. To do this, you can
+use expression evaluation. The
+.B dhcp-eval(5)
+manual page describes how to write expressions. To assign the result
+of an evaluation to an option, define the option as follows:
+.nf
+.sp 1
+ \fBoption \fImy-option \fB= \fIexpression \fB;\fR
+.fi
+.PP
+For example:
+.nf
+.sp 1
+ option hostname = binary-to-ascii (16, 8, "-",
+ substring (hardware, 1, 6));
+.fi
+.SH STANDARD DHCP OPTIONS
+The documentation for the various options mentioned below is taken
+from the latest IETF draft document on DHCP options. Options not
+listed below may not yet be implemented, but it is possible to use
+such options by defining them in the configuration file. Please see
+the DEFINING NEW OPTIONS heading later in this document for more
+information.
+.PP
+Some of the options documented here are automatically generated by
+the DHCP server or by clients, and cannot be configured by the user.
+The value of such an option can be used in the configuration file of
+the receiving DHCP protocol agent (server or client), for example in
+conditional expressions. However, the value of the option cannot be
+used in the configuration file of the sending agent, because the value
+is determined only \fIafter\fR the configuration file has been
+processed. In the following documentation, such options will be shown
+as "not user configurable"
+.PP
+The standard options are:
+.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 true indicates that all subnets share
+the same MTU. A value of false means that the client should assume that
+some subnets of the directly connected network may have smaller MTUs.
+.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 \fBbcms-controller-address\fR \fIip-address\fR [\fB,\fR
+\fIip-address\fR... ]\fB;\fR
+.RS 0.25i
+.PP
+This option configures a list of IPv4 addresses for use as Broadcast and
+Multicast Controller Servers ("BCMS").
+.RE
+.PP
+.B option \fBbootfile-name\fR \fItext\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 \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 \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 \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 \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 \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 \fBdefault-url\fR \fIstring\fR\fB;\fR
+.RS 0.25i
+.PP
+The format and meaning of this option is not described in any standards
+document, but is claimed to be in use by Apple Computer. It is not known
+what clients may reasonably do if supplied with this option. Use at your
+own risk.
+.RE
+.PP
+.B option \fBdhcp-client-identifier\fR \fIstring\fR\fB;\fR
+.RS 0.25i
+.PP
+This option can be used to specify a DHCP client identifier in a
+host declaration, so that dhcpd can find the host record by matching
+against the client identifier.
+.PP
+Please be aware that some DHCP clients, when configured with client
+identifiers that are ASCII text, will prepend a zero to the ASCII
+text. So you may need to write:
+.nf
+
+ option dhcp-client-identifier "\\0foo";
+
+rather than:
+
+ option dhcp-client-identifier "foo";
+.fi
+.RE
+.PP
+.B option \fBdhcp-lease-time\fR \fIuint32\fR\fB;\fR
+.RS 0.25i
+.PP
+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.
+.PP
+This option is not directly user configurable in the server; refer to the
+\fImax-lease-time\fR and \fIdefault-lease-time\fR server options in
+.B dhcpd.conf(5).
+.RE
+.PP
+.B option \fBdhcp-max-message-size\fR \fIuint16\fR\fB;\fR
+.RS 0.25i
+.PP
+This option, when sent by the client, specifies the maximum size of
+any response that the server sends to the client. When specified on
+the server, if the client did not send a dhcp-max-message-size option,
+the size specified on the server is used. This works for BOOTP as
+well as DHCP responses.
+.RE
+.PP
+.B option \fBdhcp-message\fR \fItext\fR\fB;\fR
+.RS 0.25i
+.PP
+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 why the
+client declined the offered parameters.
+.PP
+This option is not user configurable.
+.RE
+.PP
+.B option \fBdhcp-message-type\fR \fIuint8\fR\fB;\fR
+.RS 0.25i
+.PP
+This option, sent by both client and server, specifies the type of DHCP
+message contained in the DHCP packet. Possible values (taken directly from
+RFC2132) are:
+.PP
+.nf
+ 1 DHCPDISCOVER
+ 2 DHCPOFFER
+ 3 DHCPREQUEST
+ 4 DHCPDECLINE
+ 5 DHCPACK
+ 6 DHCPNAK
+ 7 DHCPRELEASE
+ 8 DHCPINFORM
+.fi
+.PP
+This option is not user configurable.
+.PP
+.RE
+.B option \fBdhcp-option-overload\fR \fIuint8\fR\fB;\fR
+.RS 0.25i
+.PP
+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.
+.PP
+If this option is present, the client interprets the specified
+additional fields after it concludes interpretation of the standard
+option fields.
+.PP
+Legal values for this option are:
+.PP
+.nf
+ 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
+.fi
+.PP
+This option is not user configurable.
+.PP
+.RE
+.PP
+.B option \fBdhcp-parameter-request-list\fR \fIuint16\fR\fB;\fR
+.RS 0.25i
+.PP
+This option, when sent by the client, specifies which options the
+client wishes the server to return. Normally, in the ISC DHCP
+client, this is done using the \fIrequest\fR statement. If this
+option is not specified by the client, the DHCP server will normally
+return every option that is valid in scope and that fits into the
+reply. When this option is specified on the server, the server
+returns the specified options. This can be used to force a client to
+take options that it hasn't requested, and it can also be used to
+tailor the response of the DHCP server for clients that may need a
+more limited set of options than those the server would normally
+return.
+.RE
+.PP
+.B option \fBdhcp-rebinding-time\fR \fIuint32\fR\fB;\fR
+.RS 0.25i
+.PP
+This option specifies the number of seconds from the time a client gets
+an address until the client transitions to the REBINDING state.
+.PP
+This option is not user configurable.
+.PP
+.RE
+.PP
+.B option \fBdhcp-renewal-time\fR \fIuint32\fR\fB;\fR
+.RS 0.25i
+.PP
+This option specifies the number of seconds from the time a client gets
+an address until the client transitions to the RENEWING state.
+.PP
+This option is not user configurable.
+.PP
+.RE
+.PP
+.B option \fBdhcp-requested-address\fR \fIip-address\fR\fB;\fR
+.RS 0.25i
+.PP
+This option is used by the client in a DHCPDISCOVER to
+request that a particular IP address be assigned.
+.PP
+This option is not user configurable.
+.PP
+.RE
+.PP
+.B option \fBdhcp-server-identifier\fR \fIip-address\fR\fB;\fR
+.RS 0.25i
+.PP
+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.
+.PP
+The value of this option is the IP address of the server.
+.PP
+This option is not directly user configurable. See the
+\fIserver-identifier\fR server option in
+.B \fIdhcpd.conf(5).
+.PP
+.RE
+.PP
+.B option \fBdomain-name\fR \fItext\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 \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 \fBdomain-search\fR \fIstring\fR\fB;\fR
+.RS 0.25i
+.PP
+The domain-search option specifies a 'search list' of Domain Names to be
+used by the client to locate not-fully-qualified domain names. The difference
+between this option and historic use of the domain-name option for the same
+ends is that this option is encoded in RFC1035 compressed labels on the wire.
+.RE
+.PP
+.B option \fBextensions-path\fR \fItext\fR\fB;\fR
+.RS 0.25i
+.PP
+This option specifies the name of a file containing additional options
+to be interpreted according to the DHCP option format as specified in
+RFC2132.
+.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 servers available
+to the client. Servers should be listed in order of preference.
+.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 \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. This option is only honored by
+.B dhclient-script(8)
+if the hostname for the client machine is not set.
+.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 false indicates that the client
+should use RFC 894 encapsulation. A value of true means that the client
+should use RFC 1042 encapsulation.
+.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 \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 \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 \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 false means disable IP
+forwarding, and a value of true means enable IP forwarding.
+.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 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 \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 \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 false indicates that the
+client should not respond. A value of true means that the client should
+respond.
+.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 legal value is
+576.
+.RE
+.PP
+.B option \fBmerit-dump\fR \fItext\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 \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 \fBnds-context\fR \fIstring\fR\fB;\fR
+.RS 0.25i
+.PP
+The nds-context option specifies the name of the initial Netware
+Directory Service for an NDS client.
+.RE
+.PP
+.B option \fBnds-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR
+.RS 0.25i
+.PP
+The nds-servers option specifies a list of IP addresses of NDS servers.
+.RE
+.PP
+.B option \fBnds-tree-name\fR \fIstring\fR\fB;\fR
+.RS 0.25i
+.PP
+The nds-tree-name option specifies NDS tree name that the NDS client
+should use.
+.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-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-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 \fBnetbios-scope\fR \fIstring\fR\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 \fBnetinfo-server-address\fR \fIip-address\fR [\fB,\fR
+\fIip-address\fR... ]\fB;\fR
+.RS 0.25i
+.PP
+The \fBnetinfo-server-address\fR option has not been described in any
+RFC, but has been allocated (and is claimed to be in use) by Apple
+Computers. It's hard to say if the above is the correct format, or
+what clients might be expected to do if values were configured. Use
+at your own risk.
+.RE
+.PP
+.B option \fBnetinfo-server-tag\fR \fItext\fR\fB;\fR
+.RS 0.25i
+.PP
+The \fBnetinfo-server-tag\fR option has not been described in any
+RFC, but has been allocated (and is claimed to be in use) by Apple
+Computers. It's hard to say if the above is the correct format,
+or what clients might be expected to do if values were configured. Use
+at your own risk.
+.RE
+.PP
+.B option \fBnis-domain\fR \fItext\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 \fBnisplus-domain\fR \fItext\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
+.PP
+.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 \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 servesr available
+to the client. Servers should be listed in order of preference.
+.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 false means disallow forwarding of such datagrams, and a value of true
+means allow forwarding.
+.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 1035)
+servers available to the client. Servers should be listed in order
+of preference.
+.RE
+.PP
+.B option \fBnwip-domain\fR \fIstring\fR\fB;\fR
+.RS 0.25i
+.PP
+The name of the NetWare/IP domain that a NetWare/IP client should
+use.
+.RE
+.PP
+.B option \fBnwip-suboptions\fR \fIstring\fR\fB;\fR
+.RS 0.25i
+.PP
+A sequence of suboptions for NetWare/IP clients - see RFC2242 for
+details. Normally this option is set by specifying specific
+NetWare/IP suboptions - see the NETWARE/IP SUBOPTIONS section for more
+information.
+.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 \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 false indicates that the client
+should not perform mask discovery. A value of true means that the
+client should perform mask discovery.
+.RE
+.PP
+.nf
+.B option \fBpolicy-filter\fR \fIip-address ip-address\fR
+ [\fB,\fR \fIip-address ip-address\fR...]\fB;\fR
+.RE
+.fi
+.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 \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 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
+.fi
+.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 \fBroot-path\fR \fItext\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 \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 false indicates that the client should not perform
+router discovery. A value of true 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 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 slp-directory-agent \fIboolean ip-address
+[\fB,\fR \fIip-address\fR... ]\fB;\fR
+.RS 0.25i
+.PP
+This option specifies two things: the IP addresses of one or more
+Service Location Protocol Directory Agents, and whether the use of
+these addresses is mandatory. If the initial boolean value is true,
+the SLP agent should just use the IP addresses given. If the value
+is false, the SLP agent may additionally do active or passive
+multicast discovery of SLP agents (see RFC2165 for details).
+.PP
+Please note that in this option and the slp-service-scope option, the
+term "SLP Agent" is being used to refer to a Service Location Protocol
+agent running on a machine that is being configured using the DHCP
+protocol.
+.PP
+Also, please be aware that some companies may refer to SLP as NDS.
+If you have an NDS directory agent whose address you need to
+configure, the slp-directory-agent option should work.
+.RE
+.PP
+.B option slp-service-scope \fIboolean text\fR\fB;\fR
+.RS 0.25i
+.PP
+The Service Location Protocol Service Scope Option specifies two
+things: a list of service scopes for SLP, and whether the use of this
+list is mandatory. If the initial boolean value is true, the SLP
+agent should only use the list of scopes provided in this option;
+otherwise, it may use its own static configuration in preference to
+the list provided in this option.
+.PP
+The text string should be a comma-separated list of scopes that the
+SLP agent should use. It may be omitted, in which case the SLP Agent
+will use the aggregated list of scopes of all directory agents known
+to the SLP 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
+.nf
+.B option \fBstatic-routes\fR \fIip-address ip-address\fR
+ [\fB,\fR \fIip-address ip-address\fR...]\fB;\fR
+.fi
+.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. Also, please note that this option is not intended for
+classless IP routing - it does not include a subnet mask. Since
+classless IP routing is now the most widely deployed routing standard,
+this option is virtually useless, and is not implemented by any of the
+popular DHCP clients, for example the Microsoft DHCP client.
+.PP
+NOTE to @PRODUCTNAME@ dhclient users:
+.br
+dhclient-script interprets trailing 0 octets of the target
+as indicating the subnet class of the route - so for this
+static-routes value:
+.br
+ option static-routes 172.0.0.0 172.16.2.254,
+.br
+ 192.168.0.0 192.168.2.254;
+.br
+dhclient-script will create routes:
+.br
+ 172/8 via 172.16.2.254 dev $interface
+.br
+ 192.168/16 via 192.168.2.254 dev $interface
+.br
+which slightly increases the usefulness of the static-routes option.
+.RE
+.PP
+.nf
+.B option \fBstreettalk-directory-assistance-server\fR \fIip-address\fR
+ [\fB,\fR \fIip-address\fR...]\fB;\fR
+.fi
+.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
+.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 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 \fBsubnet-selection\fR \fIstring\fR\fB;\fR
+.RS 0.25i
+.PP
+Sent by the client if an address is required in a subnet other than the one
+that would normally be selected (based on the relaying address of the
+connected subnet the request is obtained from). See RFC3011. Note that the
+option number used by this server is 118; this has not always been the
+defined number, and some clients may use a different value. Use of this
+option should be regarded as slightly experimental!
+.RE
+.PP
+This option is not user configurable in the server.
+.PP
+.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 \fBtcp-keepalive-garbage\fR \fIflag\fR\fB;\fR
+.RS 0.25i
+.PP
+This option specifies whether or not the client should send TCP
+keepalive messages with an octet of garbage for compatibility with
+older implementations. A value of false indicates that a garbage octet
+should not be sent. A value of true indicates that a garbage octet
+should be sent.
+.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 \fBtftp-server-name\fR \fItext\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 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 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 \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 false indicates that the client should not attempt to use trailers. A
+value of true means that the client should attempt to use trailers.
+.RE
+.PP
+.B option \fBuap-servers\fR \fItext\fR\fB;\fR
+.RS 0.25i
+.PP
+This option specifies a list of URLs, each pointing to a user
+authentication service that is capable of processing authentication
+requests encapsulated in the User Authentication Protocol (UAP). UAP
+servers can accept either HTTP 1.1 or SSLv3 connections. If the list
+includes a URL that does not contain a port component, the normal
+default port is assumed (i.e., port 80 for http and port 443 for
+https). If the list includes a URL that does not contain a path
+component, the path /uap is assumed. If more than one URL is
+specified in this list, the URLs are separated by spaces.
+.RE
+.PP
+.B option \fBuser-class\fR \fIstring\fR\fB;\fR
+.RS 0.25i
+.PP
+This option is used by some DHCP clients as a way for users to
+specify identifying information to the client. This can be used in a
+similar way to the vendor-class-identifier option, but the value of
+the option is specified by the user, not the vendor. Most recent
+DHCP clients have a way in the user interface to specify the value for
+this identifier, usually as a text string.
+.RE
+.PP
+.B option \fBvendor-class-identifier\fR \fIstring\fR\fB;\fR
+.RS 0.25i
+.PP
+This option is used by some DHCP clients to identify the vendor
+type and possibly the configuration of a DHCP client. The information
+is a string of bytes whose contents are specific to the vendor and are
+not specified in a standard. To see what vendor class identifier
+clients are sending, you can write the following in your DHCP server
+configuration file:
+.nf
+.PP
+set vendor-string = option vendor-class-identifier;
+.fi
+.PP
+This will result in all entries in the DHCP server lease database file
+for clients that sent vendor-class-identifier options having a set
+statement that looks something like this:
+.nf
+.PP
+set vendor-string = "SUNW.Ultra-5_10";
+.fi
+.PP
+The vendor-class-identifier option is normally used by the DHCP server
+to determine the options that are returned in the
+.B vendor-encapsulated-options
+option. Please see the VENDOR ENCAPSULATED OPTIONS section later in this
+manual page for further information.
+.RE
+.PP
+.B option \fBvendor-encapsulated-options\fR \fIstring\fR\fB;\fR
+.RS 0.25i
+.PP
+The \fBvendor-encapsulated-options\fR option can contain either a
+single vendor-specific value or one or more vendor-specific
+suboptions. This option is not normally specified in the DHCP server
+configuration file - instead, a vendor class is defined for each
+vendor, vendor class suboptions are defined, values for those
+suboptions are defined, and the DHCP server makes up a response on
+that basis.
+.PP
+Some default behaviours for well-known DHCP client vendors (currently,
+the Microsoft Windows 2000 DHCP client) are configured automatically,
+but otherwise this must be configured manually - see the VENDOR
+ENCAPSULATED OPTIONS section later in this manual page for details.
+.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 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
+.SH RELAY AGENT INFORMATION OPTION
+An IETF draft, draft-ietf-dhc-agent-options-11.txt, defines a series
+of encapsulated options that a relay agent can add to a DHCP packet
+when relaying it to the DHCP server. The server can then make
+address allocation decisions (or whatever other decisions it wants)
+based on these options. The server also returns these options in any
+replies it sends through the relay agent, so that the relay agent can
+use the information in these options for delivery or accounting
+purposes.
+.PP
+The current draft defines two options. To reference
+these options in the dhcp server, specify the option space name,
+"agent", followed by a period, followed by the option name. It is
+not normally useful to define values for these options in the server,
+although it is permissible. These options are not supported in the
+client.
+.PP
+.B option \fBagent.circuit-id\fR \fIstring\fR\fB;\fR
+.RS 0.25i
+.PP
+The circuit-id suboption encodes an agent-local identifier of the
+circuit from which a DHCP client-to-server packet was received. It is
+intended for use by agents in relaying DHCP responses back to the
+proper circuit. The format of this option is currently defined to be
+vendor-dependent, and will probably remain that way, although the
+current draft allows for for the possibility of standardizing the
+format in the future.
+.RE
+.PP
+.B option \fBagent.remote-id\fR \fIstring\fR\fB;\fR
+.RS 0.25i
+.PP
+The remote-id suboption encodes information about the remote host end
+of a circuit. Examples of what it might contain include caller ID
+information, username information, remote ATM address, cable modem ID,
+and similar things. In principal, the meaning is not well-specified,
+and it should generally be assumed to be an opaque object that is
+administratively guaranteed to be unique to a particular remote end of
+a circuit.
+.RE
+.PP
+.B option \fBagent.DOCSIS-device-class\fR \fIuint32\fR\fB;\fR
+.RS 0.25i
+.PP
+The DOCSIS-device-class suboption is intended to convey information about
+the host endpoint, hardware, and software, that either the host operating
+system or the DHCP server may not otherwise be aware of (but the relay is
+able to distinguish). This is implemented as a 32-bit field (4 octets),
+each bit representing a flag describing the host in one of these ways.
+So far, only bit zero (being the least significant bit) is defined in
+RFC3256. If this bit is set to one, the host is considered a CPE
+Controlled Cable Modem (CCCM). All other bits are reserved.
+.RE
+.PP
+.B option \fBagent.link-selection\fR \fIip-address\fR\fB;\fR
+.RS 0.25i
+.PP
+The link-selection suboption is provided by relay agents to inform servers
+what subnet the client is actually attached to. This is useful in those
+cases where the giaddr (where responses must be sent to the relay agent)
+is not on the same subnet as the client. When this option is present in
+a packet from a relay agent, the DHCP server will use its contents to find
+a subnet declared in configuration, and from here take one step further
+backwards to any shared-network the subnet may be defined within...the
+client may be given any address within that shared network, as normally
+appropriate.
+.RE
+.SH THE CLIENT FQDN SUBOPTIONS
+The Client FQDN option, currently defined in the Internet Draft
+draft-ietf-dhc-fqdn-option-00.txt is not a standard yet, but is in
+sufficiently wide use already that we have implemented it. Due to
+the complexity of the option format, we have implemented it as a
+suboption space rather than a single option. In general this
+option should not be configured by the user - instead it should be
+used as part of an automatic DNS update system.
+.PP
+.B option fqdn.no-client-update \fIflag\fB;
+.RS 0.25i
+.PP
+When the client sends this, if it is true, it means the client will not
+attempt to update its A record. When sent by the server to the client,
+it means that the client \fIshould not\fR update its own A record.
+.RE
+.PP
+.B option fqdn.server-update \fIflag\fB;
+.RS 0.25i
+.PP
+When the client sends this to the server, it is requesting that the server
+update its A record. When sent by the server, it means that the server
+has updated (or is about to update) the client's A record.
+.RE
+.PP
+.B option fqdn.encoded \fIflag\fB;
+.RS 0.25i
+.PP
+If true, this indicates that the domain name included in the option is
+encoded in DNS wire format, rather than as plain ASCII text. The client
+normally sets this to false if it doesn't support DNS wire format in the
+FQDN option. The server should always send back the same value that the
+client sent. When this value is set on the configuration side, it controls
+the format in which the \fIfqdn.fqdn\fR suboption is encoded.
+.RE
+.PP
+.B option fqdn.rcode1 \fIflag\fB;
+.PP
+.B option fqdn.rcode2 \fIflag\fB;
+.RS 0.25i
+.PP
+These options specify the result of the updates of the A and PTR records,
+respectively, and are only sent by the DHCP server to the DHCP client.
+The values of these fields are those defined in the DNS protocol specification.
+.RE
+.PP
+.B option fqdn.fqdn \fItext\fB;
+.RS 0.25i
+.PP
+Specifies the domain name that the client wishes to use. This can be a
+fully-qualified domain name, or a single label. If there is no trailing
+'.' character in the name, it is not fully-qualified, and the server will
+generally update that name in some locally-defined domain.
+.RE
+.PP
+.B option fqdn.hostname \fI--never set--\fB;
+.RS 0.25i
+.PP
+This option should never be set, but it can be read back using the \fBoption\fR
+and \fBconfig-option\fR operators in an expression, in which case it returns
+the first label in the \fBfqdn.fqdn\fR suboption - for example, if
+the value of \fBfqdn.fqdn\fR is "foo.example.com.", then \fBfqdn.hostname\fR
+will be "foo".
+.RE
+.PP
+.B option fqdn.domainname \fI--never set--\fB;
+.RS 0.25i
+.PP
+This option should never be set, but it can be read back using the \fBoption\fR
+and \fBconfig-option\fR operators in an expression, in which case it returns
+all labels after the first label in the \fBfqdn.fqdn\fR suboption - for
+example, if the value of \fBfqdn.fqdn\fR is "foo.example.com.",
+then \fBfqdn.hostname\fR will be "example.com.". If this suboption value
+is not set, it means that an unqualified name was sent in the fqdn option,
+or that no fqdn option was sent at all.
+.RE
+.PP
+If you wish to use any of these suboptions, we strongly recommend that you
+refer to the Client FQDN option draft (or standard, when it becomes a
+standard) - the documentation here is sketchy and incomplete in comparison,
+and is just intended for reference by people who already understand the
+Client FQDN option specification.
+.SH THE NETWARE/IP SUBOPTIONS
+RFC2242 defines a set of encapsulated options for Novell NetWare/IP
+clients. To use these options in the dhcp server, specify the option
+space name, "nwip", followed by a period, followed by the option name.
+The following options can be specified:
+.PP
+.B option \fBnwip.nsq-broadcast\fR \fIflag\fR\fB;\fR
+.RS 0.25i
+.PP
+If true, the client should use the NetWare Nearest Server Query to
+locate a NetWare/IP server. The behaviour of the Novell client if
+this suboption is false, or is not present, is not specified.
+.PP
+.RE
+.B option \fBnwip.preferred-dss\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fR\fB;\fR
+.RS 0.25i
+.PP
+This suboption specifies a list of up to five IP addresses, each of
+which should be the IP address of a NetWare Domain SAP/RIP server
+(DSS).
+.RE
+.PP
+.B option \fBnwip.nearest-nwip-server\fR \fI\fIip-address\fR
+ [\fB,\fR \fIip-address\fR...]\fR\fB;\fR
+.RS 0.25i
+.PP
+This suboption specifies a list of up to five IP addresses, each of
+which should be the IP address of a Nearest NetWare IP server.
+.RE
+.PP
+.B option \fBnwip.autoretries\fR \fIuint8\fR\fB;\fR
+.RS 0.25i
+.PP
+Specifies the number of times that a NetWare/IP client should attempt
+to communicate with a given DSS server at startup.
+.RE
+.PP
+.B option \fBnwip.autoretry-secs\fR \fIuint8\fR\fB;\fR
+.RS 0.25i
+.PP
+Specifies the number of seconds that a Netware/IP client should wait
+between retries when attempting to establish communications with a DSS
+server at startup.
+.RE
+.PP
+.B option \fBnwip.nwip-1-1\fR \fIuint8\fR\fB;\fR
+.RS 0.25i
+.PP
+If true, the NetWare/IP client should support NetWare/IP version 1.1
+compatibility. This is only needed if the client will be contacting
+Netware/IP version 1.1 servers.
+.RE
+.PP
+.B option \fBnwip.primary-dss\fR \fIip-address\fR\fB;\fR
+.RS 0.25i
+.PP
+Specifies the IP address of the Primary Domain SAP/RIP Service server
+(DSS) for this NetWare/IP domain. The NetWare/IP administration
+utility uses this value as Primary DSS server when configuring a
+secondary DSS server.
+.RE
+.SH DEFINING NEW OPTIONS
+The Internet Systems Consortium DHCP client and server provide the
+capability to define new options. Each DHCP option has a name, a
+code, and a structure. The name is used by you to refer to the
+option. The code is a number, used by the DHCP server and client to
+refer to an option. The structure describes what the contents of an
+option looks like.
+.PP
+To define a new option, you need to choose a name for it that is not
+in use for some other option - for example, you can't use "host-name"
+because the DHCP protocol already defines a host-name option, which is
+documented earlier in this manual page. If an option name doesn't
+appear in this manual page, you can use it, but it's probably a good
+idea to put some kind of unique string at the beginning so you can be
+sure that future options don't take your name. For example, you
+might define an option, "local-host-name", feeling some confidence
+that no official DHCP option name will ever start with "local".
+.PP
+Once you have chosen a name, you must choose a code. All codes between
+224 and 254 are reserved as 'site-local' DHCP options, so you can pick
+any one of these for your site (not for your product/application). In
+RFC3942, site-local space was moved from starting at 128 to starting at
+224. In practice, some vendors have interpreted the protocol rather
+loosely and have used option code values greater than 128 themselves.
+There's no real way to avoid this problem, and it was thought to be
+unlikely to cause too much trouble in practice. If you come across
+a vendor-documented option code in either the new or old site-local
+spaces, please contact your vendor and inform them about rfc3942.
+.PP
+The structure of an option is simply the format in which the option
+data appears. The ISC DHCP server currently supports a few simple
+types, like integers, booleans, strings and IP addresses, and it also
+supports the ability to define arrays of single types or arrays of
+fixed sequences of types.
+.PP
+New options are declared as follows:
+.PP
+.B option
+.I new-name
+.B code
+.I new-code
+.B =
+.I definition
+.B ;
+.PP
+The values of
+.I new-name
+and
+.I new-code
+should be the name you have chosen for the new option and the code you
+have chosen. The
+.I definition
+should be the definition of the structure of the option.
+.PP
+The following simple option type definitions are supported:
+.PP
+.B BOOLEAN
+.PP
+.B option
+.I new-name
+.B code
+.I new-code
+.B =
+.B boolean
+.B ;
+.PP
+An option of type boolean is a flag with a value of either on or off
+(or true or false). So an example use of the boolean type would be:
+.nf
+
+option use-zephyr code 180 = boolean;
+option use-zephyr on;
+
+.fi
+.B INTEGER
+.PP
+.B option
+.I new-name
+.B code
+.I new-code
+.B =
+.I sign
+.B integer
+.I width
+.B ;
+.PP
+The \fIsign\fR token should either be blank, \fIunsigned\fR
+or \fIsigned\fR. The width can be either 8, 16 or 32, and refers to
+the number of bits in the integer. So for example, the following two
+lines show a definition of the sql-connection-max option and its use:
+.nf
+
+option sql-connection-max code 192 = unsigned integer 16;
+option sql-connection-max 1536;
+
+.fi
+.B IP-ADDRESS
+.PP
+.B option
+.I new-name
+.B code
+.I new-code
+.B =
+.B ip-address
+.B ;
+.PP
+An option whose structure is an IP address can be expressed either as
+a domain name or as a dotted quad. So the following is an example use
+of the ip-address type:
+.nf
+
+option sql-server-address code 193 = ip-address;
+option sql-server-address sql.example.com;
+
+.fi
+.PP
+.B TEXT
+.PP
+.B option
+.I new-name
+.B code
+.I new-code
+.B =
+.B text
+.B ;
+.PP
+An option whose type is text will encode an ASCII text string. For
+example:
+.nf
+
+option sql-default-connection-name code 194 = text;
+option sql-default-connection-name "PRODZA";
+
+.fi
+.PP
+.B DATA STRING
+.PP
+.B option
+.I new-name
+.B code
+.I new-code
+.B =
+.B string
+.B ;
+.PP
+An option whose type is a data string is essentially just a collection
+of bytes, and can be specified either as quoted text, like the text
+type, or as a list of hexadecimal contents separated by colons whose
+values must be between 0 and FF. For example:
+.nf
+
+option sql-identification-token code 195 = string;
+option sql-identification-token 17:23:19:a6:42:ea:99:7c:22;
+
+.fi
+.PP
+.B ENCAPSULATION
+.PP
+.B option
+.I new-name
+.B code
+.I new-code
+.B =
+.B encapsulate
+.I identifier
+.B ;
+.PP
+An option whose type is \fBencapsulate\fR will encapsulate the
+contents of the option space specified in \fIidentifier\fR. Examples
+of encapsulated options in the DHCP protocol as it currently exists
+include the vendor-encapsulated-options option, the netware-suboptions
+option and the relay-agent-information option.
+.nf
+
+option space local;
+option local.demo code 1 = text;
+option local-encapsulation code 197 = encapsulate local;
+option local.demo "demo";
+
+.fi
+.PP
+.B ARRAYS
+.PP
+Options can contain arrays of any of the above types except for the
+text and data string types, which aren't currently supported in
+arrays. An example of an array definition is as follows:
+.nf
+
+option kerberos-servers code 200 = array of ip-address;
+option kerberos-servers 10.20.10.1, 10.20.11.1;
+
+.fi
+.B RECORDS
+.PP
+Options can also contain data structures consisting of a sequence of
+data types, which is sometimes called a record type. For example:
+.nf
+
+option contrived-001 code 201 = { boolean, integer 32, text };
+option contrived-001 on 1772 "contrivance";
+
+.fi
+It's also possible to have options that are arrays of records, for
+example:
+.nf
+
+option new-static-routes code 201 = array of {
+ ip-address, ip-address, ip-address, integer 8 };
+option static-routes
+ 10.0.0.0 255.255.255.0 net-0-rtr.example.com 1,
+ 10.0.1.0 255.255.255.0 net-1-rtr.example.com 1,
+ 10.2.0.0 255.255.224.0 net-2-0-rtr.example.com 3;
+
+.fi
+.SH VENDOR ENCAPSULATED OPTIONS
+The DHCP protocol defines the \fB vendor-encapsulated-options\fR
+option, which allows vendors to define their own options that will be
+sent encapsulated in a standard DHCP option. The format of the
+.B vendor-encapsulated-options
+option is either a series of bytes whose format is not specified, or
+a sequence of options, each of which consists of a single-byte
+vendor-specific option code, followed by a single-byte length,
+followed by as many bytes of data as are specified in the length (the
+length does not include itself or the option code).
+.PP
+The value of this option can be set in one of two ways. The first
+way is to simply specify the data directly, using a text string or a
+colon-separated list of hexadecimal values. For example:
+.PP
+.nf
+option vendor-encapsulated-options
+ 2:4:AC:11:41:1:
+ 3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
+ 4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;
+.fi
+.PP
+The second way of setting the value of this option is to have the DHCP
+server generate a vendor-specific option buffer. To do this, you
+must do four things: define an option space, define some options in
+that option space, provide values for them, and specify that that
+option space should be used to generate the
+.B vendor-encapsulated-options
+option.
+.PP
+To define a new option space in which vendor options can be stored,
+use the \fRoption space\fP statement:
+.PP
+.B option
+.B space
+.I name
+.B [ [ code width
+.I number
+.B ] [ length width
+.I number
+.B ] [ hash size
+.I number
+.B ] ] ;
+.PP
+Where the numbers following \fBcode width\fR, \fBlength width\fR,
+and \fBhash size\fR respectively identify the number of bytes used to
+describe option codes, option lengths, and the size in buckets of the
+hash tables to hold options in this space.
+.PP
+The code and length widths are used in DHCP protocol - you must configure
+these numbers to match the applicable option space you are configuring.
+They each default to 1. Valid values for code widths are 1, 2 or 4.
+Valid values for length widths are 1 or 2.
+.PP
+The hash size defaults depend upon the \fBcode width\fR selected, and
+may be 254 or 1009. Valid values range between 1 and 65535. Note
+that the higher you configure this value, the more memory will be used. It
+is considered good practice to configure a value that is slightly larger
+than the estimated number of options you plan to configure within the
+space. Due to limitations in previous versions of ISC DHCP (up to and
+including DHCP 3.0.*), this value was fixed at 9973.
+.PP
+The name can then be used in option definitions, as described earlier in
+this document. For example:
+.nf
+
+option space SUNW code width 1 length width 1 hash size 3;
+option SUNW.server-address code 2 = ip-address;
+option SUNW.server-name code 3 = text;
+option SUNW.root-path code 4 = text;
+
+.fi
+Once you have defined an option space and the format of some options,
+you can set up scopes that define values for those options, and you
+can say when to use them. For example, suppose you want to handle
+two different classes of clients. Using the option space definition
+shown in the previous example, you can send different option values to
+different clients based on the vendor-class-identifier option that the
+clients send, as follows:
+.PP
+.nf
+class "vendor-classes" {
+ match option vendor-class-identifier;
+}
+
+option SUNW.server-address 172.17.65.1;
+option SUNW.server-name "sundhcp-server17-1";
+
+subclass "vendor-classes" "SUNW.Ultra-5_10" {
+ vendor-option-space SUNW;
+ option SUNW.root-path "/export/root/sparc";
+}
+
+subclass "vendor-classes" "SUNW.i86pc" {
+ vendor-option-space SUNW;
+ option SUNW.root-path "/export/root/i86pc";
+}
+.fi
+.PP
+As you can see in the preceding example, regular scoping rules apply,
+so you can define values that are global in the global scope, and only
+define values that are specific to a particular class in the local
+scope. The \fBvendor-option-space\fR declaration tells the DHCP
+server to use options in the SUNW option space to construct the
+.B vendor-encapsulated-options
+option.
+.SH SEE ALSO
+dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-eval(5), dhcpd(8),
+dhclient(8), RFC2132, RFC2131, draft-ietf-dhc-agent-options-??.txt.
+.SH AUTHOR
+The Internet Systems Consortium DHCP Distribution was written by Ted
+Lemon under a contract with Vixie Labs. Funding for
+this project was provided through Internet Systems Consortium.
+Information about Internet Systems Consortium can be found at
+.B http://www.isc.org.
View full diff with command:
/usr/bin/cvs -f diff -kk -u -N -r 1.3 -r 1.4 dhcpd.conf.5
Index: dhcpd.conf.5
===================================================================
RCS file: dhcpd.conf.5
diff -N dhcpd.conf.5
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ dhcpd.conf.5 11 Jan 2008 00:14:20 -0000 1.4
@@ -0,0 +1,2682 @@
+.\" dhcpd.conf.5
+.\"
+.\" Copyright (c) 2004-2007 by Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (c) 1996-2003 by Internet Software Consortium
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
+.\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.\" Internet Systems Consortium, Inc.
+.\" 950 Charter Street
+.\" Redwood City, CA 94063
+.\" <info at isc.org>
+.\" http://www.isc.org/
+.\"
+.\" This software has been written for Internet Systems Consortium
+.\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc.
+.\" To learn more about Internet Systems Consortium, see
+.\" ``http://www.isc.org/''. To learn more about Vixie Enterprises,
+.\" see ``http://www.vix.com''. To learn more about Nominum, Inc., see
+.\" ``http://www.nominum.com''.
+.\"
+.\" $Id$
+.\"
+.TH dhcpd.conf 5
+.SH NAME
+dhcpd.conf - dhcpd configuration file
+.SH DESCRIPTION
+The dhcpd.conf file contains configuration information for
+.IR dhcpd,
+the Internet Systems Consortium DHCP Server.
+.PP
+The dhcpd.conf file is a free-form ASCII text file. It is parsed by
+the recursive-descent parser built into dhcpd. The file may contain
+extra tabs and newlines for formatting purposes. Keywords in the file
+are case-insensitive. Comments may be placed anywhere within the
+file (except within quotes). Comments begin with the # character and
+end at the end of the line.
+.PP
+The file essentially consists of a list of statements. Statements
+fall into two broad categories - parameters and declarations.
+.PP
+Parameter statements either say how to do something (e.g., how long a
+lease to offer), whether to do something (e.g., should dhcpd provide
+addresses to unknown clients), or what parameters to provide to the
+client (e.g., use gateway 220.177.244.7).
+.PP
+Declarations are used to describe the topology of the
+network, to describe clients on the network, to provide addresses that
+can be assigned to clients, or to apply a group of parameters to a
+group of declarations. In any group of parameters and declarations,
+all parameters must be specified before any declarations which depend
+on those parameters may be specified.
+.PP
+Declarations about network topology include the \fIshared-network\fR
+and the \fIsubnet\fR declarations. If clients on a subnet are to be
+assigned addresses
+dynamically, a \fIrange\fR declaration must appear within the
+\fIsubnet\fR declaration. For clients with statically assigned
+addresses, or for installations where only known clients will be
+served, each such client must have a \fIhost\fR declaration. If
+parameters are to be applied to a group of declarations which are not
+related strictly on a per-subnet basis, the \fIgroup\fR declaration
+can be used.
+.PP
+For every subnet which will be served, and for every subnet
+to which the dhcp server is connected, there must be one \fIsubnet\fR
+declaration, which tells dhcpd how to recognize that an address is on
+that subnet. A \fIsubnet\fR declaration is required for each subnet
+even if no addresses will be dynamically allocated on that subnet.
+.PP
+Some installations have physical networks on which more than one IP
+subnet operates. For example, if there is a site-wide requirement
+that 8-bit subnet masks be used, but a department with a single
+physical ethernet network expands to the point where it has more than
+254 nodes, it may be necessary to run two 8-bit subnets on the same
+ethernet until such time as a new physical network can be added. In
+this case, the \fIsubnet\fR declarations for these two networks must be
+enclosed in a \fIshared-network\fR declaration.
+.PP
+Some sites may have departments which have clients on more than one
+subnet, but it may be desirable to offer those clients a uniform set
+of parameters which are different than what would be offered to
+clients from other departments on the same subnet. For clients which
+will be declared explicitly with \fIhost\fR declarations, these
+declarations can be enclosed in a \fIgroup\fR declaration along with
+the parameters which are common to that department. For clients
+whose addresses will be dynamically assigned, class declarations and
+conditional declarations may be used to group parameter assignments
+based on information the client sends.
+.PP
+When a client is to be booted, its boot parameters are determined by
+consulting that client's \fIhost\fR declaration (if any), and then
+consulting any \fIclass\fR declarations matching the client,
+followed by the \fIpool\fR, \fIsubnet\fR and \fIshared-network\fR
+declarations for the IP address assigned to the client. Each of
+these declarations itself appears within a lexical scope, and all
+declarations at less specific lexical scopes are also consulted for
+client option declarations. Scopes are never considered
+twice, and if parameters are declared in more than one scope, the
+parameter declared in the most specific scope is the one that is
+used.
+.PP
+When dhcpd tries to find a \fIhost\fR declaration for a client, it
+first looks for a \fIhost\fR declaration which has a
+\fIfixed-address\fR declaration that lists an IP address that is valid
+for the subnet or shared network on which the client is booting. If
+it doesn't find any such entry, it tries to find an entry which has
+no \fIfixed-address\fR declaration.
+.SH EXAMPLES
+.PP
+A typical dhcpd.conf file will look something like this:
+.nf
+
+.I global parameters...
+
+subnet 204.254.239.0 netmask 255.255.255.224 {
+ \fIsubnet-specific parameters...\fR
+ range 204.254.239.10 204.254.239.30;
+}
+
+subnet 204.254.239.32 netmask 255.255.255.224 {
+ \fIsubnet-specific parameters...\fR
+ range 204.254.239.42 204.254.239.62;
+}
+
+subnet 204.254.239.64 netmask 255.255.255.224 {
+ \fIsubnet-specific parameters...\fR
+ range 204.254.239.74 204.254.239.94;
+}
+
+group {
+ \fIgroup-specific parameters...\fR
+ host zappo.test.isc.org {
+ \fIhost-specific parameters...\fR
+ }
+ host beppo.test.isc.org {
+ \fIhost-specific parameters...\fR
+ }
+ host harpo.test.isc.org {
+ \fIhost-specific parameters...\fR
+ }
+}
+
+.ce 1
+Figure 1
+
+.fi
+.PP
+Notice that at the beginning of the file, there's a place
+for global parameters. These might be things like the organization's
+domain name, the addresses of the name servers (if they are common to
+the entire organization), and so on. So, for example:
+.nf
+
+ option domain-name "isc.org";
+ option domain-name-servers ns1.isc.org, ns2.isc.org;
+
+.ce 1
+Figure 2
+.fi
+.PP
+As you can see in Figure 2, you can specify host addresses in
+parameters using their domain names rather than their numeric IP
+addresses. If a given hostname resolves to more than one IP address
+(for example, if that host has two ethernet interfaces), then where
+possible, both addresses are supplied to the client.
+.PP
+The most obvious reason for having subnet-specific parameters as
+shown in Figure 1 is that each subnet, of necessity, has its own
+router. So for the first subnet, for example, there should be
+something like:
+.nf
+
+ option routers 204.254.239.1;
+.fi
+.PP
+Note that the address here is specified numerically. This is not
+required - if you have a different domain name for each interface on
+your router, it's perfectly legitimate to use the domain name for that
+interface instead of the numeric address. However, in many cases
+there may be only one domain name for all of a router's IP addresses, and
+it would not be appropriate to use that name here.
+.PP
+In Figure 1 there is also a \fIgroup\fR statement, which provides
[...2289 lines suppressed...]
+subsequent DHCPREQUEST messages sent in the RENEWING state. This
+works around a problem with relay agent information options, which is
+that they usually not appear in DHCPREQUEST messages sent by the
+client in the RENEWING state, because such messages are unicast
+directly to the server and not sent through a relay agent.
+.RE
+.PP
+The
+.I update-conflict-detection
+statement
+.RS 0.25i
+.PP
+.B update-conflict-detection \fIflag\fB;\fR
+.PP
+If the \fIupdate-conflict-detection\fR parameter is true, the server will
+perform standard DHCID multiple-client, one-name conflict detection. If
+the parameter has been set false, the server will skip this check and
+instead simply tear down any previous bindings to install the new
+binding without question. The default is true.
+.RE
+.PP
+The
+.I update-optimization
+statement
+.RS 0.25i
+.PP
+.B update-optimization \fIflag\fB;\fR
+.PP
+If the \fIupdate-optimization\fR parameter is false for a given client,
+the server will attempt a DNS update for that client each time the
+client renews its lease, rather than only attempting an update when it
+appears to be necessary. This will allow the DNS to heal from
+database inconsistencies more easily, but the cost is that the DHCP
+server must do many more DNS updates. We recommend leaving this option
+enabled, which is the default. This option only affects the behavior of
+the interim DNS update scheme, and has no effect on the ad-hoc DNS update
+scheme. If this parameter is not specified, or is true, the DHCP server
+will only update when the client information changes, the client gets a
+different lease, or the client's lease expires.
+.RE
+.PP
+The
+.I update-static-leases
+statement
+.RS 0.25i
+.PP
+.B update-static-leases \fIflag\fB;\fR
+.PP
+The \fIupdate-static-leases\fR flag, if enabled, causes the DHCP
+server to do DNS updates for clients even if those clients are being
+assigned their IP address using a \fIfixed-address\fR statement - that
+is, the client is being given a static assignment. This can only
+work with the \fIinterim\fR DNS update scheme. It is not
+recommended because the DHCP server has no way to tell that the update
+has been done, and therefore will not delete the record when it is not
+in use. Also, the server must attempt the update each time the
+client renews its lease, which could have a significant performance
+impact in environments that place heavy demands on the DHCP server.
+.RE
+.PP
+The
+.I use-host-decl-names
+statement
+.RS 0.25i
+.PP
+.B use-host-decl-names \fIflag\fB;\fR
+.PP
+If the \fIuse-host-decl-names\fR parameter is true in a given scope,
+then for every host declaration within that scope, the name provided
+for the host declaration will be supplied to the client as its
+hostname. So, for example,
+.PP
+.nf
+ group {
+ use-host-decl-names on;
+
+ host joe {
+ hardware ethernet 08:00:2b:4c:29:32;
+ fixed-address joe.fugue.com;
+ }
+ }
+
+is equivalent to
+
+ host joe {
+ hardware ethernet 08:00:2b:4c:29:32;
+ fixed-address joe.fugue.com;
+ option host-name "joe";
+ }
+.fi
+.PP
+An \fIoption host-name\fR statement within a host declaration will
+override the use of the name in the host declaration.
+.PP
+It should be noted here that most DHCP clients completely ignore the
+host-name option sent by the DHCP server, and there is no way to
+configure them not to do this. So you generally have a choice of
+either not having any hostname to client IP address mapping that the
+client will recognize, or doing DNS updates. It is beyond
+the scope of this document to describe how to make this
+determination.
+.RE
+.PP
+The
+.I use-lease-addr-for-default-route
+statement
+.RS 0.25i
+.PP
+.B use-lease-addr-for-default-route \fIflag\fR\fB;\fR
+.PP
+If the \fIuse-lease-addr-for-default-route\fR parameter is true in a
+given scope, then instead of sending the value specified in the
+routers option (or sending no value at all), the IP address of the
+lease being assigned is sent to the client. This supposedly causes
+Win95 machines to ARP for all IP addresses, which can be helpful if
+your router is configured for proxy ARP. The use of this feature is
+not recommended, because it won't work for many DHCP clients.
+.RE
+.PP
+The
+.I vendor-option-space
+statement
+.RS 0.25i
+.PP
+.B vendor-option-space \fIstring\fR\fB;\fR
+.PP
+The \fIvendor-option-space\fR parameter determines from what option
+space vendor options are taken. The use of this configuration
+parameter is illustrated in the \fBdhcp-options(5)\fR manual page, in
+the \fIVENDOR ENCAPSULATED OPTIONS\fR section.
+.RE
+.SH SETTING PARAMETER VALUES USING EXPRESSIONS
+Sometimes it's helpful to be able to set the value of a DHCP server
+parameter based on some value that the client has sent. To do this,
+you can use expression evaluation. The
+.B dhcp-eval(5)
+manual page describes how to write expressions. To assign the result
+of an evaluation to an option, define the option as follows:
+.nf
+.sp 1
+ \fImy-parameter \fB= \fIexpression \fB;\fR
+.fi
+.PP
+For example:
+.nf
+.sp 1
+ ddns-hostname = binary-to-ascii (16, 8, "-",
+ substring (hardware, 1, 6));
+.fi
+.RE
+.SH RESERVED LEASES
+It's often useful to allocate a single address to a single client, in
+approximate perpetuity. Host statements with \fBfixed-address\fR clauses
+exist to a certain extent to serve this purpose, but because host statements
+are intended to approximate 'static configuration', they suffer from not being
+referenced in a littany of other Server Services, such as dynamic DNS,
+failover, 'on events' and so forth.
+.PP
+If a standard dynamic lease, as from any range statement, is marked 'reserved',
+then the server will only allocate this lease to the client it is identified
+by (be that by client identifier or hardware address).
+.PP
+In practice, this means that the lease follows the normal state engine, enters
+ACTIVE state when the client is bound to it, expires, or is released, and any
+events or services that would normally be supplied during these events are
+processed normally, as with any other dynamic lease. The only difference
+is that failover servers treat reserved leases as special when they enter
+the FREE or BACKUP states - each server applies the lease into the state it
+may allocate from - and the leases are not placed on the queue for allocation
+to other clients. Instead they may only be 'found' by client identity. The
+result is that the lease is only offered to the returning client.
+.PP
+Care should probably be taken to ensure that the client only has one lease
+within a given subnet that it is identified by.
+.PP
+Leases may be set 'reserved' either through OMAPI, or through the
+\'infinite-is-reserved' configuration option (if this is applicable to your
+environment and mixture of clients).
+.PP
+It should also be noted that leases marked 'reserved' are effectively treated
+the same as leases marked 'bootp'.
+.RE
+.SH REFERENCE: OPTION STATEMENTS
+DHCP option statements are documented in the
+.B dhcp-options(5)
+manual page.
+.SH REFERENCE: EXPRESSIONS
+Expressions used in DHCP option statements and elsewhere are
+documented in the
+.B dhcp-eval(5)
+manual page.
+.SH SEE ALSO
+dhcpd(8), dhcpd.leases(5), dhcp-options(5), dhcp-eval(5), RFC2132, RFC2131.
+.SH AUTHOR
+.B dhcpd.conf(5)
+was written by Ted Lemon
+under a contract with Vixie Labs. Funding
+for this project was provided by Internet Systems Consortium.
+Information about Internet Systems Consortium can be found at
+.B http://www.isc.org.
Index: dhcpctl.3
===================================================================
RCS file: dhcpctl.3
diff -N dhcpctl.3
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ dhcpctl.3 11 Jan 2008 00:14:20 -0000 1.3
@@ -0,0 +1,488 @@
+.\" -*- nroff -*-
+.\"
+.\" Project: DHCP
+.\" File: dhcpctl.3
+.\" RCSId: $Id$
+.\"
+.\" Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (c) 2000-2003 by Internet Software Consortium
+.\" Copyright (c) 2000 Nominum, Inc.
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
+.\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.\" Internet Systems Consortium, Inc.
+.\" 950 Charter Street
+.\" Redwood City, CA 94063
+.\" <info at isc.org>
+.\" http://www.isc.org/
+.\"
+.\" Description: dhcpctl man page.
+.\"
+.\"
+.Dd Nov 15, 2000
+.Dt DHCPCTL 3
+.Os DHCP 3
+.ds vT DHCP Programmer's Manual
+.\"
+.\"
+.\"
+.Sh NAME
+.Nm dhcpctl_initialize
+.Nd dhcpctl library initialization.
+.\"
+.\"
+.\"
+.Sh SYNOPSIS
+.Fd #include <dhcpctl.h>
+.Ft dhcpctl_status
+.Fo dhcpctl_initialize
+.Fa void
+.Fc
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_connect
+.Fa "dhcpctl_handle *cxn"
+.Fa "const char *host"
+.Fa "int port"
+.Fa "dhcpctl_handle auth"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_wait_for_completion
+.Fa "dhcpctl_handle object"
+.Fa "dhcpctl_status *status"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_get_value
+.Fa "dhcpctl_data_string *value"
+.Fa "dhcpctl_handle object"
+.Fa "const char *name"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_get_boolean
+.Fa "int *value"
+.Fa "dhcpctl_handle object"
+.Fa "const char *name"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_set_value
+.Fa "dhcpctl_handle object"
+.Fa "dhcpctl_data_string value"
+.Fa "const char *name"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_set_string_value
+.Fa "dhcpctl_handle object"
+.Fa "const char *value"
+.Fa "const char *name"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_set_boolean_value
+.Fa "dhcpctl_handle object"
+.Fa "int value"
+.Fa "const char *name"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_set_int_value
+.Fa "dhcpctl_handle object"
+.Fa "int value"
+.Fa "const char *name"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_object_update
+.Fa "dhcpctl_handle connection"
+.Fa "dhcpctl_handle object"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_object_refresh
+.Fa "dhcpctl_handle connection"
+.Fa "dhcpctl_handle object"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_object_remove
+.Fa "dhcpctl_handle connection"
+.Fa "dhcpctl_handle object"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_set_callback
+.Fa "dhcpctl_handle object"
+.Fa "void *data"
+.Fa "void (*function) (dhcpctl_handle, dhcpctl_status, void *)"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_new_authenticator
+.Fa "dhcpctl_handle *object"
+.Fa "const char *name"
+.Fa "const char *algorithm"
+.Fa "const char *secret"
+.Fa "unsigned secret_len"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_new_object
+.Fa "dhcpctl_handle *object"
+.Fa "dhcpctl_handle connection"
+.Fa "const char *object_type"
+.Fc
+.\"
+.\"
+.\"
+.Ft dhcpctl_status
+.Fo dhcpctl_open_object
+.Fa "dhcpctl_handle object"
+.Fa "dhcpctl_handle connection"
+.Fa "int flags"
+.Fc
+.\"
+.\"
+.\"
+.Ft isc_result_t
+.Fo omapi_data_string_new
+.Fa dhcpctl_data_string *data
+.Fa unsigned int length
+.Fa const char *filename,
+.Fa int lineno
+.Fc
+.\"
+.\"
+.\"
+.Ft isc_result_t
+.Fo dhcpctl_data_string_dereference
+.Fa "dhcpctl_data_string *"
+.Fa "const char *"
+.Fa "int"
+.Fc
+.Sh DESCRIPTION
+The dhcpctl set of functions provide an API that can be used to communicate
+with and manipulate a running ISC DHCP server. All functions return a value of
+.Dv isc_result_t .
+The return values reflects the result of operations to local data
+structures. If an operation fails on the server for any reason, then the error
+result will be returned through the
+second parameter of the
+.Fn dhcpctl_wait_for_completion
+call.
+.\"
+.\"
+.\"
+.Pp
+.Fn dhcpctl_initialize
+sets up the data structures the library needs to do its work. This function
+must be called once before any other.
+.Pp
+.Fn dhcpctl_connect
+opens a connection to the DHCP server at the given host and port. If an
+authenticator has been created for the connection, then it is given as the 4th
+argument. On a successful return the address pointed at by the first
+argument will have a new connection object assigned to it.
+.Pp
+For example:
+.Bd -literal -offset indent
+s = dhcpctl_connect(&cxn, "127.0.0.1", 7911, NULL);
+.Ed
+.Pp
+connects to the DHCP server on the localhost via port 7911 (the standard
+OMAPI port). No authentication is used for the connection.
+.\"
+.\"
+.\"
+.Pp
+.Fn dhcpctl_wait_for_completion
+flushes a pending message to the server and waits for the response. The result
+of the request as processed on the server is returned via the second
+parameter.
+.Bd -literal -offset indent
+s = dhcpctl_wait_for_completion(cxn, &wv);
+if (s != ISC_R_SUCCESS)
+ local_failure(s);
+else if (wv != ISC_R_SUCCESS)
+ server_failure(wc);
+.Ed
+.Pp
+The call to
+.Fn dhcpctl_wait_for_completion
+won't return until the remote message processing completes or the connection
+to the server is lost.
+.\"
+.\"
+.\"
+.Pp
+.Fn dhcpctl_get_value
+extracts a value of an attribute from the handle. The value can be of any
+length and is treated as a sequence of bytes. The handle must have been
+created first with
+.Fn dhcpctl_new_object
+and opened with
+.Fn dhcpctl_open_object .
+The value is returned via the parameter named
+.Dq value .
+The last parameter is the name of attribute to retrieve.
+.Bd -literal -offset indent
+dhcpctl_data_string value = NULL;
+dhcpctl_handle lease;
+time_t thetime;
+
+s = dhcpctl_get_value (&value, lease, "ends");
+assert(s == ISC_R_SUCCESS && value->len == sizeof(thetime));
+memcpy(&thetime, value->value, value->len);
+.Ed
+.\"
+.\"
+.\"
+.Pp
+.Fn dhcpctl_get_boolean
+extracts a boolean valued attribute from the object handle.
+.\"
+.\"
+.\"
+.Pp
+The
+.Fn dhcpctl_set_value ,
+.Fn dhcpctl_set_string_value ,
+.Fn dhcpctl_set_boolean_value ,
+and
+.Fn dhcpctl_set_int_value
+functions all set a value on the object handle.
+.\"
+.\"
+.\"
+.Pp
+.Fn dhcpctl_object_update
+function queues a request for
+all the changes made to the object handle be be sent to the remote
+for processing. The changes made to the atributes on the handle will be
+applied to remote object if permitted.
+.\"
+.\"
+.\"
+.Pp
+.Fn dhcpctl_object_refresh
+queues up a request for a fresh copy of all the attribute values to be sent
+from the remote to
+refresh the values in the local object handle.
+.\"
+.\"
+.\"
+.Pp
+.Fn dhcpctl_object_remove
+queues a request for the removal on the server of the object referenced by the
+handle.
+.\"
+.\"
+.\"
+.Pp
+The
+.Fn dhcpctl_set_callback
+function sets up a user-defined function to be called when an event completes
+on the given object handle. This is needed for asynchronous handling of
+events, versus the synchronous handling given by
+.Fn dhcpctl_wait_for_completion .
+When the function is called the first parameter is the object the event
+arrived for, the second is the status of the message that was processed, the
+third is the same value as the second parameter given to
+.Fn dhcpctl_set_callback .
+.\"
+.\"
+.\"
+.Pp
+The
+.Fn dhcpctl_new_authenticator
+creates a new authenticator object to be used for signing the messages
+that cross over the network. The
+.Dq name ,
+.Dq algorithm ,
+and
+.Dq secret
+values must all match what the server uses and are defined in its
+configuration file. The created object is returned through the first parameter
+and must be used as the 4th parameter to
+.Fn dhcpctl_connect .
+Note that the 'secret' value must not be base64 encoded, which is different
+from how the value appears in the dhcpd.conf file.
+.\"
+.\"
+.\"
+.Pp
+.Fn dhcpctl_new_object
+creates a local handle for an object on the the server. The
+.Dq object_type
+parameter is the ascii name of the type of object being accessed. e.g.
+.Qq lease .
+This function only sets up local data structures, it does not queue any
+messages
+to be sent to the remote side,
+.Fn dhcpctl_open_object
+does that.
+.\"
+.\"
+.\"
+.Pp
+.Fn dhcpctl_open_object
+builds and queues the request to the remote side. This function is used with
+handle created via
+.Fn dhcpctl_new_object .
+The flags argument is a bit mask with the following values available for
+setting:
+.Bl -tag -offset indent -width 20
+.It DHCPCTL_CREATE
+if the object does not exist then the remote will create it
+.It DHCPCTL_UPDATE
+update the object on the remote side using the
+attributes already set in the handle.
+.It DHCPCTL_EXCL
+return and error if the object exists and DHCPCTL_CREATE
+was also specified
+.El
+.\"
+.\"
+.\"
+.Pp
+The
+.Fn omapi_data_string_new
+function allocates a new
+.Ft dhcpctl_data_string
+object. The data string will be large enough to hold
+.Dq length
+bytes of data. The
+.Dq file
+and
+.Dq lineno
+arguments are the source file location the call is made from, typically by
+using the
+.Dv __FILE__
+and
+.Dv __LINE__
+macros or the
+.Dv MDL
+macro defined in
+.
+.\"
+.\"
+.\"
+.Pp
+.Fn dhcpctl_data_string_dereference
+deallocates a data string created by
+.Fn omapi_data_string_new .
+The memory for the object won't be freed until the last reference is
+released.
+.Sh EXAMPLES
+.Pp
+The following program will connect to the DHCP server running on the local
+host and will get the details of the existing lease for IP address
+10.0.0.101. It will then print out the time the lease is due to expire. Note
+that most error checking has been ommitted for brevity.
+.Bd -literal -offset indent
+#include <stdarg.h>
+#include <sys/time.h>
+#include <sys/socket.h>
+#include <stdio.h>
+#include <netinet/in.h>
+
+#include <isc/result.h>
+#include <dhcpctl.h>
+
+int main (int argc, char **argv) {
+ dhcpctl_data_string ipaddrstring = NULL;
+ dhcpctl_data_string value = NULL;
+ dhcpctl_handle connection = NULL;
+ dhcpctl_handle lease = NULL;
+ isc_result_t waitstatus;
+ struct in_addr convaddr;
+ time_t thetime;
+
+ dhcpctl_initialize ();
+
+ dhcpctl_connect (&connection, "127.0.0.1",
+ 7911, 0);
+
+ dhcpctl_new_object (&lease, connection,
+ "lease");
+
+ memset (&ipaddrstring, 0, sizeof
+ ipaddrstring);
+
+ inet_pton(AF_INET, "10.0.0.101",
+ &convaddr);
+
+ omapi_data_string_new (&ipaddrstring,
+ 4, MDL);
+ memcpy(ipaddrstring->value, &convaddr.s_addr, 4);
+
+ dhcpctl_set_value (lease, ipaddrstring,
+ "ip-address");
+
+ dhcpctl_open_object (lease, connection, 0);
+
+ dhcpctl_wait_for_completion (lease,
+ &waitstatus);
+ if (waitstatus != ISC_R_SUCCESS) {
+ /* server not authoritative */
+ exit (0);
+ }
+
+ dhcpctl_data_string_dereference(&ipaddrstring,
+ MDL);
+
+ dhcpctl_get_value (&value, lease, "ends");
+
+ memcpy(&thetime, value->value, value->len);
+
+ dhcpctl_data_string_dereference(&value, MDL);
+
+ fprintf (stdout, "ending time is %s",
+ ctime(&thetime));
+}
+.Ed
+.Sh SEE ALSO
+omapi(3), omshell(3), dhcpd(8), dhclient(8), dhcpd.conf(5), dhclient.conf(5).
+.Sh AUTHOR
+.Em dhcpctl
+was written by Ted Lemon of Nominum, Inc.
+This preliminary documentation was written by James Brister of Nominum, Inc.
Index: dhcp4client.h
===================================================================
RCS file: dhcp4client.h
diff -N dhcp4client.h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ dhcp4client.h 11 Jan 2008 00:14:20 -0000 1.5
@@ -0,0 +1,30 @@
+/* dhcp4client.h
+ *
+ * Interface to the ISC dhcp IPv4 client libdhcp4client library.
+ *
+ * Copyright (C) 2006 Red Hat, Inc. All rights reserved.
+ *
+ * This copyrighted material is made available to anyone wishing to use,
+ * modify, copy, or redistribute it subject to the terms and conditions of
+ * the GNU General Public License v.2, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY expressed or implied, including the implied warranties of
+ * MERCHANTABILITY or FITNESS FOR A * PARTICULAR PURPOSE. See the GNU General
+ * Public License for more details. You should have received a copy of the
+ * GNU General Public License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA. Any Red Hat trademarks that are incorporated in the
+ * source code or documentation are not subject to the GNU General Public
+ * License and may only be used or replicated with the express permission of
+ * Red Hat, Inc.
+ *
+ * Red Hat Author(s): Jason Vas Dias
+ * David Cantrell <dcantrell at redhat.com>
+ */
+
+/* include libdhcp_control.h or libdhcp.h for this */
+extern struct libdhcp_control_s;
+
+/* The ISC IPv4 DHCP client main() function */
+extern int dhcpv4_client(struct libdhcp_control_s *dhc_ctl,
+ int argc, char **argv, char **envp);
Index: dhcp.schema
===================================================================
RCS file: dhcp.schema
diff -N dhcp.schema
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ dhcp.schema 11 Jan 2008 00:14:20 -0000 1.4
@@ -0,0 +1,462 @@
+attributetype ( 2.16.840.1.113719.1.203.4.1
+ NAME 'dhcpPrimaryDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The DN of the dhcpServer which is the primary server for the configuration.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.2
+ NAME 'dhcpSecondaryDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The DN of dhcpServer(s) which provide backup service for the configuration.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.3
+ NAME 'dhcpStatements'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'Flexible storage for specific data depending on what object this exists in. Like conditional statements, server parameters, etc. This allows the standard to evolve without needing to adjust the schema.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.4
+ NAME 'dhcpRange'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'The starting & ending IP Addresses in the range (inclusive), separated by a hyphen; if the range only contains one address, then just the address can be specified with no hyphen. Each range is defined as a separate value.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.5
+ NAME 'dhcpPermitList'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'This attribute contains the permit lists associated with a pool. Each permit list is defined as a separate value.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.6
+ NAME 'dhcpNetMask'
+ EQUALITY integerMatch
+ DESC 'The subnet mask length for the subnet. The mask can be easily computed from this length.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.7
+ NAME 'dhcpOption'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'Encoded option values to be sent to clients. Each value represents a single option and contains (OptionTag, Length, OptionValue) encoded in the format used by DHCP.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.8
+ NAME 'dhcpClassData'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'Encoded text string or list of bytes expressed in hexadecimal, separated by colons. Clients match subclasses based on matching the class data with the results of match or spawn with statements in the class name declarations.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.9
+ NAME 'dhcpOptionsDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The distinguished name(s) of the dhcpOption objects containing the configuration options provided by the server.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.10
+ NAME 'dhcpHostDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'the distinguished name(s) of the dhcpHost objects.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.11
+ NAME 'dhcpPoolDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The distinguished name(s) of pools.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.12
+ NAME 'dhcpGroupDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The distinguished name(s) of the groups.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.13
+ NAME 'dhcpSubnetDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The distinguished name(s) of the subnets.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.14
+ NAME 'dhcpLeaseDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The distinguished name of a client address.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE)
+
+attributetype ( 2.16.840.1.113719.1.203.4.15
+ NAME 'dhcpLeasesDN'
+ DESC 'The distinguished name(s) client addresses.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.16
+ NAME 'dhcpClassesDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The distinguished name(s) of a class(es) in a subclass.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.17
+ NAME 'dhcpSubclassesDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The distinguished name(s) of subclass(es).'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.18
+ NAME 'dhcpSharedNetworkDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The distinguished name(s) of sharedNetworks.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.19
+ NAME 'dhcpServiceDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The DN of dhcpService object(s)which contain the configuration information. Each dhcpServer object has this attribute identifying the DHCP configuration(s) that the server is associated with.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.20
+ NAME 'dhcpVersion'
+ DESC 'The version attribute of this object.'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.21
+ NAME 'dhcpImplementation'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'Description of the DHCP Server implementation e.g. DHCP Servers vendor.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.22
+ NAME 'dhcpAddressState'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'This stores information about the current binding-status of an address. For dynamic addresses managed by DHCP, the values should be restricted to the following: "FREE", "ACTIVE", "EXPIRED", "RELEASED", "RESET", "ABANDONED", "BACKUP". For other addresses, it SHOULD be one of the following: "UNKNOWN", "RESERVED" (an address that is managed by DHCP that is reserved for a specific client), "RESERVED-ACTIVE" (same as reserved, but address is currently in use), "ASSIGNED" (assigned manually or by some other mechanism), "UNASSIGNED", "NOTASSIGNABLE".'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.23
+ NAME 'dhcpExpirationTime'
+ EQUALITY generalizedTimeMatch
+ DESC 'This is the time the current lease for an address expires.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.24
+ NAME 'dhcpStartTimeOfState'
+ EQUALITY generalizedTimeMatch
+ DESC 'This is the time of the last state change for a leased address.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.25
+ NAME 'dhcpLastTransactionTime'
+ EQUALITY generalizedTimeMatch
+ DESC 'This is the last time a valid DHCP packet was received from the client.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.26
+ NAME 'dhcpBootpFlag'
+ EQUALITY booleanMatch
+ DESC 'This indicates whether the address was assigned via BOOTP.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.27
+ NAME 'dhcpDomainName'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'This is the name of the domain sent to the client by the server. It is essentially the same as the value for DHCP option 15 sent to the client, and represents only the domain - not the full FQDN. To obtain the full FQDN assigned to the client you must prepend the "dhcpAssignedHostName" to this value with a ".".'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.28
+ NAME 'dhcpDnsStatus'
+ EQUALITY integerMatch
+ DESC 'This indicates the status of updating DNS resource records on behalf of the client by the DHCP server for this address. The value is a 16-bit bitmask.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.29
+ NAME 'dhcpRequestedHostName'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'This is the hostname that was requested by the client.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.30
+ NAME 'dhcpAssignedHostName'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'This is the actual hostname that was assigned to a client. It may not be the name that was requested by the client. The fully qualified domain name can be determined by appending the value of "dhcpDomainName" (with a dot separator) to this name.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.31
+ NAME 'dhcpReservedForClient'
+ EQUALITY distinguishedNameMatch
+ DESC 'The distinguished name of a "dhcpClient" that an address is reserved for. This may not be the same as the "dhcpAssignedToClient" attribute if the address is being reassigned but the current lease has not yet expired.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.32
+ NAME 'dhcpAssignedToClient'
+ EQUALITY distinguishedNameMatch
+ DESC 'This is the distinguished name of a "dhcpClient" that an address is currently assigned to. This attribute is only present in the class when the address is leased.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.33
+ NAME 'dhcpRelayAgentInfo'
+ EQUALITY octetStringMatch
+ DESC 'If the client request was received via a relay agent, this contains information about the relay agent that was available from the DHCP request. This is a hex-encoded option value.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.34
+ NAME 'dhcpHWAddress'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'The clients hardware address that requested this IP address.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.35
+ NAME 'dhcpHashBucketAssignment'
+ EQUALITY octetStringMatch
+ DESC 'HashBucketAssignment bit map for the DHCP Server, as defined in DHC Load Balancing Algorithm [RFC 3074].'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.36
+ NAME 'dhcpDelayedServiceParameter'
+ EQUALITY integerMatch
+ DESC 'Delay in seconds corresponding to Delayed Service Parameter configuration, as defined in DHC Load Balancing Algorithm [RFC 3074]. '
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.37
+ NAME 'dhcpMaxClientLeadTime'
+ EQUALITY integerMatch
+ DESC 'Maximum Client Lead Time configuration in seconds, as defined in DHCP Failover Protocol [FAILOVR]'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.38
+ NAME 'dhcpFailOverEndpointState'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'Server (Failover Endpoint) state, as defined in DHCP Failover Protocol [FAILOVR]'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.39
+ NAME 'dhcpErrorLog'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'Generic error log attribute that allows logging error conditions within a dhcpService or a dhcpSubnet, like no IP addresses available for lease.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.40
+ NAME 'dhcpLocatorDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The DN of dhcpLocator object which contain the DNs of all DHCP configuration objects. There will be a single dhcpLocator object in the tree with links to all the DHCP objects in the tree'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.41
+ NAME 'dhcpKeyAlgorithm'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'Algorithm to generate TSIG Key'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.42
+ NAME 'dhcpKeySecret'
+ EQUALITY octetStringMatch
+ DESC 'Secret to generate TSIG Key' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.43
+ NAME 'dhcpDnsZoneServer'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'Master server of the DNS Zone'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+attributetype ( 2.16.840.1.113719.1.203.4.44
+ NAME 'dhcpKeyDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The DNs of TSIG Key to use in secure dynamic updates. In case of locator object, this will be list of TSIG keys. In case of DHCP Service, Shared Network, Subnet and DNS Zone, it will be a single key.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12)
+
+attributetype ( 2.16.840.1.113719.1.203.4.45
+ NAME 'dhcpZoneDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The DNs of DNS Zone. In case of locator object, this will be list of DNS Zones in the tree. In case of DHCP Service, Shared Network and Subnet, it will be a single DNS Zone.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12)
+
+attributetype ( 2.16.840.1.113719.1.203.4.46
+ NAME 'dhcpFailOverPrimaryServer'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'IP address or DNS name of the server playing primary role in DHC Load Balancing and Fail over.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.47
+ NAME 'dhcpFailOverSecondaryServer'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'IP address or DNS name of the server playing secondary role in DHC Load Balancing and Fail over.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.48
+ NAME 'dhcpFailOverPrimaryPort'
+ EQUALITY integerMatch
+ DESC 'Port on which primary server listens for connections from its fail over peer (secondary server)'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.49
+ NAME 'dhcpFailOverSecondaryPort'
+ EQUALITY integerMatch
+ DESC 'Port on which secondary server listens for connections from its fail over peer (primary server)'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.50
+ NAME 'dhcpFailOverResponseDelay'
+ EQUALITY integerMatch
+ DESC 'Maximum response time in seconds, before Server assumes that connection to fail over peer has failed'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.51
+ NAME 'dhcpFailOverUnackedUpdates'
+ EQUALITY integerMatch
+ DESC 'Number of BNDUPD messages that server can send before it receives BNDACK from its fail over peer'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.52
+ NAME 'dhcpFailOverSplit'
+ EQUALITY integerMatch
+ DESC 'Split between the primary and secondary servers for fail over purpose'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.53
+ NAME 'dhcpFailOverLoadBalanceTime'
+ EQUALITY integerMatch
+ DESC 'Cutoff time in seconds, after which load balance is disabled'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.54
+ NAME 'dhcpFailOverPeerDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'The DNs of Fail over peers. In case of locator object, this will be list of fail over peers in the tree. In case of Subnet and pool, it will be a single Fail Over Peer'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+#List of all servers in the tree
+attributetype ( 2.16.840.1.113719.1.203.4.55
+ NAME 'dhcpServerDN'
+ EQUALITY distinguishedNameMatch
+ DESC 'List of all DHCP Servers in the tree. Used by dhcpLocatorObject'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.16.840.1.113719.1.203.4.56
+ NAME 'dhcpComments'
+ EQUALITY caseIgnoreIA5Match
+ DESC 'Generic attribute that allows coments within any DHCP object'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+# Classes
+
+objectclass ( 2.16.840.1.113719.1.203.6.1
+ NAME 'dhcpService'
+ DESC 'Service object that represents the actual DHCP Service configuration. This is a container object.'
+ SUP top
+ MUST (cn)
+ MAY ( dhcpPrimaryDN $ dhcpSecondaryDN $ dhcpServerDN $ dhcpSharedNetworkDN $ dhcpSubnetDN $ dhcpGroupDN $ dhcpHostDN $ dhcpClassesDN $ dhcpOptionsDN $ dhcpZoneDN $ dhcpKeyDN $ dhcpFailOverPeerDN $ dhcpStatements $dhcpComments $ dhcpOption) )
+
+objectclass ( 2.16.840.1.113719.1.203.6.2
+ NAME 'dhcpSharedNetwork'
+ DESC 'This stores configuration information for a shared network.'
+ SUP top
+ MUST cn
+ MAY ( dhcpSubnetDN $ dhcpPoolDN $ dhcpOptionsDN $ dhcpZoneDN $ dhcpStatements $dhcpComments $ dhcpOption) X-NDS_CONTAINMENT ('dhcpService' ) )
+
+objectclass ( 2.16.840.1.113719.1.203.6.3
+ NAME 'dhcpSubnet'
+ DESC 'This class defines a subnet. This is a container object.'
+ SUP top
+ MUST ( cn $ dhcpNetMask )
+ MAY ( dhcpRange $ dhcpPoolDN $ dhcpGroupDN $ dhcpHostDN $ dhcpClassesDN $ dhcpLeasesDN $ dhcpOptionsDN $ dhcpZoneDN $ dhcpKeyDN $ dhcpFailOverPeerDN $ dhcpStatements $ dhcpComments $ dhcpOption ) X-NDS_CONTAINMENT ('dhcpService' 'dhcpSharedNetwork') )
+
+objectclass ( 2.16.840.1.113719.1.203.6.4
+ NAME 'dhcpPool'
+ DESC 'This stores configuration information about a pool.'
+ SUP top
+ MUST ( cn $ dhcpRange )
+ MAY ( dhcpClassesDN $ dhcpPermitList $ dhcpLeasesDN $ dhcpOptionsDN $ dhcpZoneDN $dhcpKeyDN $ dhcpStatements $ dhcpComments $ dhcpOption )
+ X-NDS_CONTAINMENT ('dhcpSubnet' 'dhcpSharedNetwork') )
+
+objectclass ( 2.16.840.1.113719.1.203.6.5
+ NAME 'dhcpGroup'
+ DESC 'Group object that lists host DNs and parameters. This is a container object.'
+ SUP top
+ MUST cn
+ MAY ( dhcpHostDN $ dhcpOptionsDN $ dhcpStatements $ dhcpComments $ dhcpOption )
+ X-NDS_CONTAINMENT ('dhcpSubnet' 'dhcpService' ) )
+
+objectclass ( 2.16.840.1.113719.1.203.6.6
+ NAME 'dhcpHost'
+ DESC 'This represents information about a particular client'
+ SUP top
+ MUST cn
+ MAY (dhcpLeaseDN $ dhcpHWAddress $ dhcpOptionsDN $ dhcpStatements $ dhcpComments $ dhcpOption)
+ X-NDS_CONTAINMENT ('dhcpService' 'dhcpSubnet' 'dhcpGroup') )
+
+objectclass ( 2.16.840.1.113719.1.203.6.7
+ NAME 'dhcpClass'
+ DESC 'Represents information about a collection of related clients.'
+ SUP top
+ MUST cn
+ MAY (dhcpSubClassesDN $ dhcpOptionsDN $ dhcpStatements $ dhcpComments $ dhcpOption)
+ X-NDS_CONTAINMENT ('dhcpService' 'dhcpSubnet' ) )
+
+objectclass ( 2.16.840.1.113719.1.203.6.8
+ NAME 'dhcpSubClass'
+ DESC 'Represents information about a collection of related classes.'
+ SUP top
+ MUST cn
+ MAY (dhcpClassData $ dhcpOptionsDN $ dhcpStatements $ dhcpComments $ dhcpOption) X-NDS_CONTAINMENT 'dhcpClass' )
+
+objectclass ( 2.16.840.1.113719.1.203.6.9
+ NAME 'dhcpOptions'
+ DESC 'Represents information about a collection of options defined.'
+ SUP top AUXILIARY
+ MUST cn
+ MAY ( dhcpOption $ dhcpComments )
+ X-NDS_CONTAINMENT ('dhcpService' 'dhcpSharedNetwork' 'dhcpSubnet' 'dhcpPool' 'dhcpGroup' 'dhcpHost' 'dhcpClass' ) )
+
+objectclass ( 2.16.840.1.113719.1.203.6.10
+ NAME 'dhcpLeases'
+ DESC 'This class represents an IP Address, which may or may not have been leased.'
+ SUP top
+ MUST ( cn $ dhcpAddressState )
+ MAY ( dhcpExpirationTime $ dhcpStartTimeOfState $ dhcpLastTransactionTime $ dhcpBootpFlag $ dhcpDomainName $ dhcpDnsStatus $ dhcpRequestedHostName $ dhcpAssignedHostName $ dhcpReservedForClient $ dhcpAssignedToClient $ dhcpRelayAgentInfo $ dhcpHWAddress )
+ X-NDS_CONTAINMENT ( 'dhcpService' 'dhcpSubnet' 'dhcpPool') )
+
+objectclass ( 2.16.840.1.113719.1.203.6.11
+ NAME 'dhcpLog'
+ DESC 'This is the object that holds past information about the IP address. The cn is the time/date stamp when the address was assigned or released, the address state at the time, if the address was assigned or released.'
+ SUP top
+ MUST ( cn )
+ MAY ( dhcpAddressState $ dhcpExpirationTime $ dhcpStartTimeOfState $ dhcpLastTransactionTime $ dhcpBootpFlag $ dhcpDomainName $ dhcpDnsStatus $ dhcpRequestedHostName $ dhcpAssignedHostName $ dhcpReservedForClient $ dhcpAssignedToClient $ dhcpRelayAgentInfo $ dhcpHWAddress $ dhcpErrorLog)
+ X-NDS_CONTAINMENT ('dhcpLeases' 'dhcpPool' 'dhcpSubnet' 'dhcpSharedNetwork' 'dhcpService' ) )
+
+objectclass ( 2.16.840.1.113719.1.203.6.12
+ NAME 'dhcpServer'
+ DESC 'DHCP Server Object'
+ SUP top
+ MUST ( cn )
+ MAY (dhcpServiceDN $ dhcpLocatorDN $ dhcpVersion $ dhcpImplementation $ dhcpHashBucketAssignment $ dhcpDelayedServiceParameter $ dhcpMaxClientLeadTime $ dhcpFailOverEndpointState $ dhcpStatements $ dhcpComments $ dhcpOption)
+ X-NDS_CONTAINMENT ('organization' 'organizationalunit' 'domain') )
+
+objectclass ( 2.16.840.1.113719.1.203.6.13
+ NAME 'dhcpTSigKey'
+ DESC 'TSIG key for secure dynamic updates'
+ SUP top
+ MUST (cn $ dhcpKeyAlgorithm $ dhcpKeySecret )
+ MAY ( dhcpComments )
+ X-NDS_CONTAINMENT ('dhcpService' 'dhcpSharedNetwork' 'dhcpSubnet') )
+
+objectclass ( 2.16.840.1.113719.1.203.6.14
+ NAME 'dhcpDnsZone'
+ DESC 'DNS Zone for updating leases'
+ SUP top
+ MUST (cn $ dhcpDnsZoneServer )
+ MAY (dhcpKeyDN $ dhcpComments)
+ X-NDS_CONTAINMENT ('dhcpService' 'dhcpSharedNetwork' 'dhcpSubnet') )
+
+objectclass ( 2.16.840.1.113719.1.203.6.15
+ NAME 'dhcpFailOverPeer'
+ DESC 'This class defines the Fail over peer'
+ SUP top
+ MUST ( cn $ dhcpFailOverPrimaryServer $ dhcpFailOverSecondaryServer $ dhcpFailoverPrimaryPort $ dhcpFailOverSecondaryPort) MAY (dhcpFailOverResponseDelay $ dhcpFailOverUnackedUpdates $ dhcpMaxClientLeadTime $ dhcpFailOverSplit $ dhcpHashBucketAssignment $ dhcpFailOverLoadBalanceTime $ dhcpComments )
+ X-NDS_CONTAINMENT ('dhcpService' 'dhcpSharedNetwork' 'dhcpSubnet') )
+
+objectclass ( 2.16.840.1.113719.1.203.6.16
+ NAME 'dhcpLocator'
+ DESC 'Locator object for DHCP configuration in the tree. There will be a single dhcpLocator object in the tree with links to all the DHCP objects in the tree'
+ SUP top
+ MUST ( cn )
+ MAY ( dhcpServiceDN $dhcpServerDN $ dhcpSharedNetworkDN $ dhcpSubnetDN $ dhcpPoolDN $ dhcpGroupDN $ dhcpHostDN $ dhcpClassesDN $ dhcpKeyDN $ dhcpZoneDN $ dhcpFailOverPeerDN $ dhcpOption $ dhcpComments)
+ X-NDS_CONTAINMENT ('organization' 'organizationalunit' 'domain') )
+
+
Index: sources
===================================================================
RCS file: /cvs/pkgs/rpms/dhcp/devel/sources,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- sources 3 Jan 2008 20:40:53 -0000 1.21
+++ sources 11 Jan 2008 00:14:20 -0000 1.22
@@ -1 +1 @@
-31d79b27ce4a94089a0b9ce7f72307fa dhcp-4.0.0.tar.gz
+27d179a3c3fbef576566b456a1168246 dhcp-3.1.0.tar.gz
- Previous message (by thread): rpms/soundconverter/F-8 .cvsignore, 1.10, 1.11 soundconverter.spec, 1.15, 1.16 sources, 1.10, 1.11
- Next message (by thread): rpms/dhcp/devel dhcpd-conf-to-ldap, 1.7, 1.8 dhcpd.conf, 1.2, 1.3 dhcp-3.1.0-xen-checksum.patch, 1.2, 1.3 dhcp-3.1.0-warnings.patch, 1.3, 1.4 dhcp-3.1.0-options.patch, 1.2, 1.3 dhcp-3.1.0-ldap-configuration.patch, 1.3, 1.4 dhcp-3.1.0-dhclient-usage.patch, 1.2, 1.3 dhcp-3.1.0-dhclient-anycast.patch, 1.2, 1.3 dhcp-3.0.6-memory.patch, 1.2, 1.3 dhcp-3.0.6-ignore-hyphen-x.patch, 1.2, 1.3 dhcp-3.0.5-unicast-bootp.patch, 1.2, 1.3 dhcp-3.0.5-selinux.patch, 1.2, 1.3 dhcp-3.0.5-release-by-ifup.patch, 1.2, 1.3 dhcp-3.0.5-prototypes.patch, 1.2, 1.3 dhcp-3.0.5-inherit-leases.patch, 1.2, 1.3 dhcp-3.0.5-fast-timeout.patch, 1.2, 1.3
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the fedora-extras-commits
mailing list