This commit was manufactured by cvs2svn to create tagvendor/isc-dhcp/FBSD_ISC_DHCP_2_0_PL5_+_V3_FIXES

'isc-dhcp-vendor-FBSD_ISC_DHCP_2_0_PL5_+_V3_FIXES'.

15 files changed, 204 insertions, 5272 deletions

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