From c4a13b4e0fb1d954a15d47bc45e23fa34181f044 Mon Sep 17 00:00:00 2001 From: obrien Date: Sun, 28 Feb 1999 20:34:40 +0000 Subject: Virgin import of ISC-DHCP v2.0b1pl17 --- contrib/isc-dhcp/README | 46 +- contrib/isc-dhcp/RELNOTES | 109 +- contrib/isc-dhcp/client/dhclient-script.8 | 4 +- contrib/isc-dhcp/client/dhclient.c | 33 +- contrib/isc-dhcp/common/bpf.c | 18 +- contrib/isc-dhcp/common/dispatch.c | 67 +- contrib/isc-dhcp/common/lpf.c | 20 +- contrib/isc-dhcp/common/nit.c | 20 +- contrib/isc-dhcp/common/print.c | 8 +- contrib/isc-dhcp/common/raw.c | 15 +- contrib/isc-dhcp/common/socket.c | 25 +- contrib/isc-dhcp/common/upf.c | 22 +- contrib/isc-dhcp/doc/rfc2131.txt | 2523 +++++++++++++++++++++++++++++ contrib/isc-dhcp/doc/rfc2132.txt | 1907 ++++++++++++++++++++++ contrib/isc-dhcp/doc/rfc951.txt | 684 ++++++++ contrib/isc-dhcp/includes/osdep.h | 39 +- 16 files changed, 5430 insertions(+), 110 deletions(-) create mode 100644 contrib/isc-dhcp/doc/rfc2131.txt create mode 100644 contrib/isc-dhcp/doc/rfc2132.txt create mode 100644 contrib/isc-dhcp/doc/rfc951.txt (limited to 'contrib/isc-dhcp') diff --git a/contrib/isc-dhcp/README b/contrib/isc-dhcp/README index 83c03bb..cef3d38 100644 --- a/contrib/isc-dhcp/README +++ b/contrib/isc-dhcp/README @@ -1,7 +1,7 @@ Internet Software Consortium Dynamic Host Configuration Protocol Distribution - Version 2, Beta 1, Patchlevel 11 - February 8, 1998 + Version 2, Beta 1, Patchlevel 17 + February 27, 1998 This is the first Beta release of Version 2 of the Internet Software Consortium DHCP Distribution. In version 2.0, this distribution @@ -47,9 +47,9 @@ information. On Digital Unix, type ``man pfilt''. To build the DHCP Distribution, unpack the compressed tar file using the tar utility and the gzip command - type something like: - zcat dhcp-2.0b1pl11.tar.gz |tar xvf - + zcat dhcp-2.0b1pl17.tar.gz |tar xvf - -Now, cd to the dhcp-2.0b1pl11 subdirectory that you've just created and +Now, cd to the dhcp-2.0b1pl17 subdirectory that you've just created and configure the source tree by typing: ./configure @@ -232,14 +232,36 @@ must install this extension in order to get dhcpd or dhclient to work. SOLARIS -One problem which has been observed and is not fixed in this patchlevel -has to do with using DLPI on Solaris 2.6 machines, probably only on Intel, -but possibly also on SPARC. The symptom of this problem is that you never -receive any DHCP packets. If you are running Solaris 2.6, and you -encounter this symptom, and you are running the DHCP server on a machine -with a single broadcast network interface, you may wish to edit the -includes/site.h file and uncomment the #define USE_SOCKETS line. Then -type ``make clean; make''. +One problem which has been observed and is not fixed in this +patchlevel has to do with using DLPI on Solaris machines. The symptom +of this problem is that the DHCP server never receives any requests. +If you are using Solaris 2.6, and you encounter this symptom, and +you are running the DHCP server on a machine with a single broadcast +network interface, you may wish to edit the includes/site.h file and +uncomment the #define USE_SOCKETS line. Then type ``make clean; +make''. + +The DHCP client on Solaris will only work with DLPI. If you run it +and it just keeps saying it's sending DHCPREQUEST packets, but never +gets a response, you may be having DLPI trouble as described above. +If so, you are SOL. Also, because Solaris requires you to "plumb" an +interface before it can be detected by the DHCP client, you must +either specify the name(s) of the interface(s) you want to configure +on the command line, or must plumb the interfaces prior to invoking +the DHCP client. This can be done with ``ifconfig iface plumb'', +where iface is the name of the interface (e.g., ``ifconfig hme0 +plumb''). + +It should be noted that Solaris versions from 2.6 onward include a +DHCP client that you can run with ``/sbin/ifconfig iface dhcp start'' +rather than using the ISC DHCP client. The feature set of the Solaris +client is different (not necessarily better or worse) than that of the +ISC client, but in most cases it will be a lot easier for you to just +use that. Please do not ask for help in using the Solaris DHCP client +on Internet Software Consortium mailing lists - that's why you're +paying Sun the big bucks. If you're having a problem with the +Solaris client interoperating with the ISC dhcp server, that's another +matter, but please check with Sun first. SUPPORT diff --git a/contrib/isc-dhcp/RELNOTES b/contrib/isc-dhcp/RELNOTES index c136fd7..84d9c40 100644 --- a/contrib/isc-dhcp/RELNOTES +++ b/contrib/isc-dhcp/RELNOTES @@ -1,7 +1,7 @@ Internet Software Consortium Dynamic Host Configuration Protocol Distribution - Version 2, Beta 1, Patchlevel 10 - February 8, 1998 + Version 2, Beta 1, Patchlevel 18 + February 27, 1998 Release Notes @@ -53,6 +53,110 @@ running in producion at the ISC, but is not expected to be stable in the near future, and is intended for sites that are in a position to experiment, or for sites that desperately need the new features. + CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 16 + +- Fix linux man page install location. + +- Fix some confusion in the dhclient-script man page. + +- Fix error in includes/cf/linux.h that would have made network API + selections in site.h work incorrectly. + +- Fix some major stupidity in the code that figures out where or not a + client owns a particular lease. + + CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 15 + +- Fix Makefile.conf on Linux to refer to /var/state/dhcp instead of + /var/state/dhcpd. + +- Eliminate redundant #defines in includes/cf/linux.h (for neatness). + +- Fix an obscure case where dhcpd is started by the /etc/rc system + with exactly the same pid each time, dhcpd.pid is not erased on + reboot, and therefore dhcpd would detect a server (itself) with the + pid in dhcpd.pid and decide that another server was running and + exit. + + CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 14 + +- Install the dhcp databases in /var/state/dhcp instead of /etc or + /var/dhcpd, as suggested in the Linux Filesystem Hierarchy + Standard. + +- Fix an endianness bug in dlpi.c. As a consequence, make the + Solaris/i386 use dlpi again. + +- Fix a bunch of bugs in the Solaris client script. + +- Add some more information about Solaris to the README file. + +- Adjust startup message in interface probe so that the relay agent + and client's unattached status will not trigger questions. + +- Update some error messages to provide more help to new users for + some common mistakes. + +- Create an interface alias on Solaris when setting up IP aliases, + rather than trying to do things the *BSD way. + +- Fix a null pointer dereference bug (this time I went through the + whole function and audited it for more null pointer dereferences, + and I didn't find any, for what that's worth). + +- Don't ever release leases in response to a DHCPDISCOVER (I think + this was unlikely anyway, but why not be correct?). + +- Remove the shared-network example from the sample dhcpd.conf file. + +- Make ``make install'' make all first. + + CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 13 + +- Support DESTDIR on installs. + +- Fix a bug in dhcp.c where a store through a null pointer would + be made under some reasonably common circumstances. + +- Add test for ARPHRD_TUNNEL so that client and server do not fail on + versions of Linux running IPsec implementations or the like. + +- Move tests for constants defined in O.S. headers into osdep.h - test + for HAVE_whatever in .c files. Define relevant HAVE_whatevers in + linux.h, so that versions of linux that define these constants as + enums will still work. + + CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 12 + +- Initialize the "quiet" variable in dhclient.c to zero (it was used + without first having been initialized). + +- Fix the parser code for the authoritative keyword. + +- Adjust lease discovery code to NAK more aggressively for addresses + the server knows it owns. + +- Add several new messages for DHCPNAK. + + CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 11 + +- Use DLPI only on sparcs running Solaris, since it seems not to work + on i386 boxes running Solaris for reasons yet to be determined. + +- In the client, close standard I/O descriptors when forking a daemon. + +- Don't let large lease lengths wrap lease expiry times - just use + what fits into a TIME value. + +- Fix a bug in the SIOCGIFCONF interface scanning code. + +- Fix a core dump in the interface scanner that crops up on Linux when + an interface is specified on the command line. + +- Don't use %D in strftime because egcs complains about it. + +- Print the error message if SO_BINDTODEVICE fails. + CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 10 - Update top-level Makefile so that it exits correctly on errors in @@ -249,7 +353,6 @@ experiment, or for sites that desperately need the new features. - Fix up dhcp-options man page to make it more readable. Note that netbios-name-server is the same thing as WINS. - CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 5 diff --git a/contrib/isc-dhcp/client/dhclient-script.8 b/contrib/isc-dhcp/client/dhclient-script.8 index bae59b4..6d1c9b7 100644 --- a/contrib/isc-dhcp/client/dhclient-script.8 +++ b/contrib/isc-dhcp/client/dhclient-script.8 @@ -55,7 +55,7 @@ modify an existing one. In general, customizations specific to a particular computer should be done in the .B ETCDIR/dhclient.conf script. If you find that you can't make such a customization without -customizing dhclient.conf, please submit a bug report. +customizing dhclient-script, please submit a bug report. .SH OPERATION When dhclient needs to invoke the client configuration script, it writes a shell script into /tmp which defines a variety of variables. @@ -89,7 +89,7 @@ no examples exist yet. The IP address to check is passed in $new_ip_address, and the interface name is passed in $interface. .SH ARPCHECK The DHCP client wants to know if a response to the ARP request send -using ARPCHECK has been received. If one has, the script should exit +using ARPSEND has been received. If one has, the script should exit with a nonzero status, indicating that the offered address has already been requested and should be declined. $new_ip_address and $interface are set as with ARPSEND. diff --git a/contrib/isc-dhcp/client/dhclient.c b/contrib/isc-dhcp/client/dhclient.c index 08fa4fc..d9a1b9f 100644 --- a/contrib/isc-dhcp/client/dhclient.c +++ b/contrib/isc-dhcp/client/dhclient.c @@ -56,7 +56,7 @@ #ifndef lint static char ocopyright[] = -"$Id: dhclient.c,v 1.44.2.14 1999/02/09 04:59:50 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; +"$Id: dhclient.c,v 1.44.2.24 1999/02/27 21:51:35 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -92,7 +92,7 @@ int save_scripts; static char copyright[] = "Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium."; static char arr [] = "All rights reserved."; -static char message [] = "Internet Software Consortium DHCP Client V2.0b1pl11"; +static char message [] = "Internet Software Consortium DHCP Client V2.0b1pl17"; static char contrib [] = "\nPlease contribute if you find this software useful."; static char url [] = "For info, please visit http://www.isc.org/dhcp-contrib.html\n"; @@ -106,7 +106,7 @@ int main (argc, argv, envp) struct servent *ent; struct interface_info *ip; int seed; - int quiet; + int quiet = 0; #ifdef SYSLOG_4_2 openlog ("dhclient", LOG_NDELAY); @@ -498,6 +498,10 @@ void dhcpack (packet) ip -> client -> new -> expiry = getULong (ip -> client -> new -> options [DHO_DHCP_LEASE_TIME].data); + /* A number that looks negative here is really just very large, + because the lease expiry offset is unsigned. */ + if (ip -> client -> new -> expiry < 0) + ip -> client -> new -> expiry = TIME_MAX; /* Take the server-provided renewal time if there is one; otherwise figure it out according to the spec. */ @@ -521,8 +525,15 @@ void dhcpack (packet) ip -> client -> new -> renewal / 4; ip -> client -> new -> expiry += cur_time; + /* Lease lengths can never be negative. */ + if (ip -> client -> new -> expiry < cur_time) + ip -> client -> new -> expiry = TIME_MAX; ip -> client -> new -> renewal += cur_time; + if (ip -> client -> new -> renewal < cur_time) + ip -> client -> new -> renewal = TIME_MAX; ip -> client -> new -> rebind += cur_time; + if (ip -> client -> new -> rebind < cur_time) + ip -> client -> new -> rebind = TIME_MAX; bind_lease (ip); } @@ -1038,8 +1049,6 @@ void send_discover (ipp) ip -> client -> packet_length, inaddr_any, &sockaddr_broadcast, (struct hardware *)0); - if (result < 0) - warn ("send_packet: %m"); add_timeout (cur_time + ip -> client -> interval, send_discover, ip); } @@ -1292,9 +1301,6 @@ void send_request (ipp) from, &destination, (struct hardware *)0); - if (result < 0) - warn ("send_packet: %m"); - add_timeout (cur_time + ip -> client -> interval, send_request, ip); } @@ -1316,8 +1322,6 @@ void send_decline (ipp) ip -> client -> packet_length, inaddr_any, &sockaddr_broadcast, (struct hardware *)0); - if (result < 0) - warn ("send_packet: %m"); } void send_release (ipp) @@ -1337,8 +1341,6 @@ void send_release (ipp) ip -> client -> packet_length, inaddr_any, &sockaddr_broadcast, (struct hardware *)0); - if (result < 0) - warn ("send_packet: %m"); } void make_discover (ip, lease) @@ -1690,7 +1692,7 @@ void make_release (ip, lease) ip -> client -> packet.htype = ip -> hw_address.htype; ip -> client -> packet.hlen = ip -> hw_address.hlen; ip -> client -> packet.hops = 0; - ip -> client -> packet.xid = ip -> client -> xid; + ip -> client -> packet.xid = random (); ip -> client -> packet.secs = 0; ip -> client -> packet.flags = 0; memcpy (&ip -> client -> packet.ciaddr, @@ -2096,6 +2098,11 @@ void go_daemon () /* Become session leader and get pid... */ pid = setsid (); + /* Close standard I/O descriptors. */ + close(0); + close(1); + close(2); + write_client_pid_file (); } diff --git a/contrib/isc-dhcp/common/bpf.c b/contrib/isc-dhcp/common/bpf.c index ba42a43..3823406 100644 --- a/contrib/isc-dhcp/common/bpf.c +++ b/contrib/isc-dhcp/common/bpf.c @@ -42,7 +42,7 @@ #ifndef lint static char copyright[] = -"$Id: bpf.c,v 1.19.2.6 1999/02/09 04:46:59 mellon Exp $ Copyright (c) 1995, 1996, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; +"$Id: bpf.c,v 1.19.2.8 1999/02/23 22:09:56 mellon Exp $ Copyright (c) 1995, 1996, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -142,13 +142,14 @@ void if_register_send (info) info -> wfdesc = info -> rfdesc; #endif if (!quiet_interface_discovery) - note ("Sending on BPF/%s/%s/%s", + note ("Sending on BPF/%s/%s%s%s", info -> name, print_hw_addr (info -> hw_address.htype, info -> hw_address.hlen, info -> hw_address.haddr), + (info -> shared_network ? "/" : ""), (info -> shared_network ? - info -> shared_network -> name : "unattached")); + info -> shared_network -> name : "")); } #endif /* USE_BPF_SEND */ @@ -250,13 +251,14 @@ void if_register_receive (info) if (ioctl (info -> rfdesc, BIOCSETF, &p) < 0) error ("Can't install packet filter program: %m"); if (!quiet_interface_discovery) - note ("Listening on BPF/%s/%s/%s", + note ("Listening on BPF/%s/%s%s%s", info -> name, print_hw_addr (info -> hw_address.htype, info -> hw_address.hlen, info -> hw_address.haddr), + (info -> shared_network ? "/" : ""), (info -> shared_network ? - info -> shared_network -> name : "unattached")); + info -> shared_network -> name : "")); } #endif /* USE_BPF_RECEIVE */ @@ -273,6 +275,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) int bufp = 0; unsigned char buf [256]; struct iovec iov [2]; + int result; if (!strcmp (interface -> name, "fallback")) return send_fallback (interface, packet, raw, @@ -290,7 +293,10 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) iov [1].iov_base = (char *)raw; iov [1].iov_len = len; - return writev(interface -> wfdesc, iov, 2); + result = writev(interface -> wfdesc, iov, 2); + if (result < 0) + warn ("send_packet: %m"); + return result; } #endif /* USE_BPF_SEND */ diff --git a/contrib/isc-dhcp/common/dispatch.c b/contrib/isc-dhcp/common/dispatch.c index 0a383a0..becf4da 100644 --- a/contrib/isc-dhcp/common/dispatch.c +++ b/contrib/isc-dhcp/common/dispatch.c @@ -3,8 +3,8 @@ Network input dispatcher... */ /* - * Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. - * All rights reserved. + * Copyright (c) 1995, 1996, 1997, 1998, 1999 + * 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 @@ -42,7 +42,7 @@ #ifndef lint static char copyright[] = -"$Id: dispatch.c,v 1.47.2.9 1999/02/05 20:23:50 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; +"$Id: dispatch.c,v 1.47.2.12 1999/02/23 17:37:00 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -79,6 +79,7 @@ void discover_interfaces (state) struct shared_network *share; struct sockaddr_in foo; int ir; + struct ifreq *tif; #ifdef ALIAS_NAMES_PERMUTED char *s; #endif @@ -110,7 +111,7 @@ void discover_interfaces (state) for (i = 0; i < ic.ifc_len;) { struct ifreq *ifp = (struct ifreq *)((caddr_t)ic.ifc_req + i); #ifdef HAVE_SA_LEN - if (ifp -> ifr_addr.sa_len) + if (ifp -> ifr_addr.sa_len > sizeof (struct sockaddr)) i += (sizeof ifp -> ifr_name) + ifp -> ifr_addr.sa_len; else #endif @@ -139,7 +140,7 @@ void discover_interfaces (state) except don't skip down interfaces if we're trying to get a list of configurable interfaces. */ if ((ifr.ifr_flags & IFF_LOOPBACK) || -#ifdef IFF_POINTOPOINT +#ifdef HAVE_IFF_POINTOPOINT (ifr.ifr_flags & IFF_POINTOPOINT) || #endif (!(ifr.ifr_flags & IFF_UP) && @@ -167,7 +168,7 @@ void discover_interfaces (state) /* If we have the capability, extract link information and record it in a linked list. */ -#ifdef AF_LINK +#ifdef HAVE_AF_LINK if (ifp -> ifr_addr.sa_family == AF_LINK) { struct sockaddr_dl *foo = ((struct sockaddr_dl *) (&ifp -> ifr_addr)); @@ -194,7 +195,6 @@ void discover_interfaces (state) found, keep a pointer to ifreq structure in which we found it. */ if (!tmp -> ifp) { - struct ifreq *tif; #ifdef HAVE_SA_LEN int len = ((sizeof ifp -> ifr_name) + ifp -> ifr_addr.sa_len); @@ -276,7 +276,6 @@ void discover_interfaces (state) if (state == DISCOVER_UNCONFIGURED) { FILE *proc_dev; char buffer [256]; - struct ifreq *tif; int skip = 2; proc_dev = fopen (PROCDEV_DEVICE, "r"); @@ -306,25 +305,10 @@ void discover_interfaces (state) if (!strcmp (tmp -> name, name)) break; - /* If we found one, and it already has an ifreq - structure, nothing more to do.. */ - if (tmp && tmp -> ifp) + /* If we found one, nothing more to do.. */ + if (tmp) continue; - /* Make up an ifreq structure. */ - tif = (struct ifreq *)malloc (sizeof (struct ifreq)); - if (!tif) - error ("no space to remember ifp."); - memset (tif, 0, sizeof (struct ifreq)); - strcpy (tif -> ifr_name, name); - - /* Now, if we just needed the ifreq structure, hook - it in and move on. */ - if (tmp) { - tmp -> ifp = tif; - continue; - } - /* Otherwise, allocate one. */ tmp = ((struct interface_info *) dmalloc (sizeof *tmp, "discover_interfaces")); @@ -334,7 +318,6 @@ void discover_interfaces (state) memset (tmp, 0, sizeof *tmp); strcpy (tmp -> name, name); - tmp -> ifp = tif; tmp -> flags = ir; tmp -> next = interfaces; interfaces = tmp; @@ -345,12 +328,22 @@ void discover_interfaces (state) /* Now cycle through all the interfaces we found, looking for hardware addresses. */ -#if defined (SIOCGIFHWADDR) && !defined (AF_LINK) +#if defined (HAVE_SIOCGIFHWADDR) && !defined (HAVE_AF_LINK) for (tmp = interfaces; tmp; tmp = tmp -> next) { struct ifreq ifr; struct sockaddr sa; int b, sk; + if (!tmp -> ifp) { + /* Make up an ifreq structure. */ + tif = (struct ifreq *)malloc (sizeof (struct ifreq)); + if (!tif) + error ("no space to remember ifp."); + memset (tif, 0, sizeof (struct ifreq)); + strcpy (tif -> ifr_name, tmp -> name); + tmp -> ifp = tif; + } + /* Read the hardware address from this interface. */ ifr = *tmp -> ifp; if (ioctl (sock, SIOCGIFHWADDR, &ifr) < 0) @@ -359,7 +352,11 @@ void discover_interfaces (state) sa = *(struct sockaddr *)&ifr.ifr_hwaddr; switch (sa.sa_family) { -#ifdef ARPHRD_LOOPBACK +#ifdef HAVE_ARPHRD_TUNNEL + case ARPHRD_TUNNEL: + /* ignore tunnel interfaces. */ +#endif +#ifdef HAVE_ARPHRD_LOOPBACK case ARPHRD_LOOPBACK: /* ignore loopback interface */ break; @@ -389,7 +386,7 @@ void discover_interfaces (state) memcpy (tmp -> hw_address.haddr, sa.sa_data, 16); break; -#ifdef ARPHRD_METRICOM +#ifdef HAVE_ARPHRD_METRICOM case ARPHRD_METRICOM: tmp -> hw_address.hlen = 6; tmp -> hw_address.htype = ARPHRD_METRICOM; @@ -402,7 +399,7 @@ void discover_interfaces (state) ifr.ifr_name, sa.sa_family); } } -#endif /* defined (SIOCGIFHWADDR) && !defined (AF_LINK) */ +#endif /* defined (HAVE_SIOCGIFHWADDR) && !defined (HAVE_AF_LINK) */ /* If we're just trying to get a list of interfaces that we might be able to configure, we can quit now. */ @@ -437,9 +434,13 @@ void discover_interfaces (state) sizeof tmp -> ifp -> ifr_addr); /* We must have a subnet declaration for each interface. */ - if (!tmp -> shared_network && (state == DISCOVER_SERVER)) - error ("No subnet declaration for %s (%s).", - tmp -> name, inet_ntoa (foo.sin_addr)); + if (!tmp -> shared_network && (state == DISCOVER_SERVER)) { + warn ("No subnet declaration for %s (%s).", + tmp -> name, inet_ntoa (foo.sin_addr)); + warn ("Please write a subnet declaration for the %s", + "network segment to"); + error ("which interface %s is attached.", tmp -> name); + } /* Find subnets that don't have valid interface addresses... */ diff --git a/contrib/isc-dhcp/common/lpf.c b/contrib/isc-dhcp/common/lpf.c index 7c6ff74..d31d6f3 100644 --- a/contrib/isc-dhcp/common/lpf.c +++ b/contrib/isc-dhcp/common/lpf.c @@ -43,7 +43,7 @@ #ifndef lint static char copyright[] = -"$Id: lpf.c,v 1.1.2.4 1999/02/09 04:51:05 mellon Exp $ Copyright (c) 1995, 1996, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; +"$Id: lpf.c,v 1.1.2.6 1999/02/23 22:09:55 mellon Exp $ Copyright (c) 1995, 1996, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -129,13 +129,14 @@ void if_register_send (info) info -> wfdesc = info -> rfdesc; #endif if (!quiet_interface_discovery) - note ("Sending on LPF/%s/%s/%s", + note ("Sending on LPF/%s/%s%s%s", info -> name, print_hw_addr (info -> hw_address.htype, info -> hw_address.hlen, info -> hw_address.haddr), + (info -> shared_network ? "/" : ""), (info -> shared_network ? - info -> shared_network -> name : "unattached")); + info -> shared_network -> name : "")); } #endif /* USE_LPF_SEND */ @@ -174,13 +175,14 @@ void if_register_receive (info) error ("Can't install packet filter program: %m"); } if (!quiet_interface_discovery) - note ("Listening on LPF/%s/%s/%s", + note ("Listening on LPF/%s/%s%s%s", info -> name, print_hw_addr (info -> hw_address.htype, info -> hw_address.hlen, info -> hw_address.haddr), + (info -> shared_network ? "/" : ""), (info -> shared_network ? - info -> shared_network -> name : "unattached")); + info -> shared_network -> name : "")); } #endif /* USE_LPF_RECEIVE */ @@ -197,6 +199,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) int bufp = 0; unsigned char buf [1500]; struct sockaddr sa; + int result; if (!strcmp (interface -> name, "fallback")) return send_fallback (interface, packet, raw, @@ -216,8 +219,11 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) strncpy (sa.sa_data, (const char *)interface -> ifp, sizeof sa.sa_data); - return sendto (interface -> wfdesc, buf, bufp + len, 0, - &sa, sizeof sa); + result = sendto (interface -> wfdesc, buf, bufp + len, 0, + &sa, sizeof sa); + if (result < 0) + warn ("send_packet: %m"); + return result; } #endif /* USE_LPF_SEND */ diff --git a/contrib/isc-dhcp/common/nit.c b/contrib/isc-dhcp/common/nit.c index 1801bb9..047f2a1 100644 --- a/contrib/isc-dhcp/common/nit.c +++ b/contrib/isc-dhcp/common/nit.c @@ -4,7 +4,7 @@ with one crucial tidbit of help from Stu Grossmen. */ /* - * Copyright (c) 1996 The Internet Software Consortium. + * Copyright (c) 1996, 1998, 1999 The Internet Software Consortium. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -42,7 +42,7 @@ #ifndef lint static char copyright[] = -"$Id: nit.c,v 1.15.2.1 1998/12/20 18:27:44 mellon Exp $ Copyright (c) 1996 The Internet Software Consortium. All rights reserved.\n"; +"$Id: nit.c,v 1.15.2.3 1999/02/23 22:09:54 mellon Exp $ Copyright (c) 1996 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -155,12 +155,13 @@ void if_register_send (info) info -> wfdesc = info -> rfdesc; #endif if (!quiet_interface_discovery) - note ("Sending on NIT/%s/%s", + note ("Sending on NIT/%s%s%s", print_hw_addr (info -> hw_address.htype, info -> hw_address.hlen, info -> hw_address.haddr), + (info -> shared_network ? "/" : ""), (info -> shared_network ? - info -> shared_network -> name : "unattached")); + info -> shared_network -> name : "")); } #endif /* USE_NIT_SEND */ @@ -238,12 +239,13 @@ void if_register_receive (info) error ("Can't set NIT filter on %s: %m", info -> name); if (!quiet_interface_discovery) - note ("Listening on NIT/%s/%s", + note ("Listening on NIT/%s%s%s", print_hw_addr (info -> hw_address.htype, info -> hw_address.hlen, info -> hw_address.haddr), + (info -> shared_network ? "/" : ""), (info -> shared_network ? - info -> shared_network -> name : "unattached")); + info -> shared_network -> name : "")); } #endif /* USE_NIT_RECEIVE */ @@ -263,6 +265,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) struct strbuf ctl, data; int hw_end; struct sockaddr_in foo; + int result; if (!strcmp (interface -> name, "fallback")) return send_fallback (interface, packet, raw, @@ -298,7 +301,10 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) data.buf = (char *)&buf [hw_end]; data.maxlen = data.len = bufp + len - hw_end; - return putmsg (interface -> wfdesc, &ctl, &data, 0); + result = putmsg (interface -> wfdesc, &ctl, &data, 0); + if (result < 0) + warn ("send_packet: %m"); + return result; } #endif /* USE_NIT_SEND */ diff --git a/contrib/isc-dhcp/common/print.c b/contrib/isc-dhcp/common/print.c index 4a2b464..d05af8d 100644 --- a/contrib/isc-dhcp/common/print.c +++ b/contrib/isc-dhcp/common/print.c @@ -42,7 +42,7 @@ #ifndef lint static char copyright[] = -"$Id: print.c,v 1.16.2.2 1998/11/24 22:39:35 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998 The Internet Software Consortium. All rights reserved.\n"; +"$Id: print.c,v 1.16.2.3 1999/02/13 19:19:03 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -80,15 +80,15 @@ void print_lease (lease) piaddr (lease -> ip_addr)); t = gmtime (&lease -> starts); - strftime (tbuf, sizeof tbuf, "%D %H:%M:%S", t); + strftime (tbuf, sizeof tbuf, "%Y/%m/%d %H:%M:%S", t); debug (" start %s", tbuf); t = gmtime (&lease -> ends); - strftime (tbuf, sizeof tbuf, "%D %H:%M:%S", t); + strftime (tbuf, sizeof tbuf, "%Y/%m/%d %H:%M:%S", t); debug (" end %s", tbuf); t = gmtime (&lease -> timestamp); - strftime (tbuf, sizeof tbuf, "%D %H:%M:%S", t); + strftime (tbuf, sizeof tbuf, "%Y/%m/%d %H:%M:%S", t); debug (" stamp %s", tbuf); debug (" hardware addr = %s", diff --git a/contrib/isc-dhcp/common/raw.c b/contrib/isc-dhcp/common/raw.c index 973ede1..2740c49 100644 --- a/contrib/isc-dhcp/common/raw.c +++ b/contrib/isc-dhcp/common/raw.c @@ -16,7 +16,7 @@ Sigh. */ /* - * Copyright (c) 1995, 1996 The Internet Software Consortium. + * Copyright (c) 1995, 1996, 1997, 1999 The Internet Software Consortium. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -54,7 +54,7 @@ #ifndef lint static char copyright[] = -"$Id: raw.c,v 1.11 1997/10/20 21:47:14 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; +"$Id: raw.c,v 1.11.2.2 1999/02/23 22:09:54 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -97,10 +97,11 @@ void if_register_send (info) info -> wfdesc = sock; if (!quiet_interface_discovery) - note ("Sending on Raw/%s/%s", + note ("Sending on Raw/%s%s%s", info -> name, + (info -> shared_network ? "/" : ""), (info -> shared_network ? - info -> shared_network -> name : "unattached")); + info -> shared_network -> name : "")); } size_t send_packet (interface, packet, raw, len, from, to, hto) @@ -115,6 +116,7 @@ size_t send_packet (interface, packet, raw, len, from, to, hto) unsigned char buf [256]; int bufp = 0; struct iovec iov [2]; + int result; /* Assemble the headers... */ assemble_udp_ip_header (interface, buf, &bufp, from.s_addr, @@ -127,6 +129,9 @@ size_t send_packet (interface, packet, raw, len, from, to, hto) iov [1].iov_base = (char *)raw; iov [1].iov_len = len; - return writev(interface -> wfdesc, iov, 2); + result = writev(interface -> wfdesc, iov, 2); + if (result < 0) + warn ("send_packet: %m"); + return result; } #endif /* USE_SOCKET_SEND */ diff --git a/contrib/isc-dhcp/common/socket.c b/contrib/isc-dhcp/common/socket.c index b2ae5b4..8e1b274 100644 --- a/contrib/isc-dhcp/common/socket.c +++ b/contrib/isc-dhcp/common/socket.c @@ -50,7 +50,7 @@ #ifndef lint static char copyright[] = -"$Id: socket.c,v 1.26.2.6 1999/02/03 19:46:04 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; +"$Id: socket.c,v 1.26.2.10 1999/02/23 22:09:55 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -102,7 +102,7 @@ int if_register_socket (info) int sock; int flag; -#if !defined (SO_BINDTODEVICE) && !defined (USE_FALLBACK) +#if !defined (HAVE_SO_BINDTODEVICE) && !defined (USE_FALLBACK) /* Make sure only one interface is registered. */ if (once) error ("The standard socket API can only support %s", @@ -136,12 +136,12 @@ int if_register_socket (info) if (bind (sock, (struct sockaddr *)&name, sizeof name) < 0) error ("Can't bind to dhcp address: %m"); -#if defined (SO_BINDTODEVICE) +#if defined (HAVE_SO_BINDTODEVICE) /* Bind this socket to this interface. */ if (info -> ifp && setsockopt (sock, SOL_SOCKET, SO_BINDTODEVICE, (char *)(info -> ifp), sizeof *(info -> ifp)) < 0) { - error("setting SO_BINDTODEVICE"); + error("setsockopt: SO_BINDTODEVICE: %m"); } #endif @@ -159,11 +159,11 @@ void if_register_send (info) info -> wfdesc = info -> rfdesc; #endif if (!quiet_interface_discovery) - note ("Sending on Socket/%s/%s", + note ("Sending on Socket/%s%s%s", info -> name, + (info -> shared_network ? "/" : ""), (info -> shared_network ? - info -> shared_network -> name : "unattached")); - + info -> shared_network -> name : "")); } #endif /* USE_SOCKET_SEND */ @@ -175,10 +175,11 @@ void if_register_receive (info) we don't need to register this interface twice. */ info -> rfdesc = if_register_socket (info); if (!quiet_interface_discovery) - note ("Listening on Socket/%s/%s", + note ("Listening on Socket/%s%s%s", info -> name, + (info -> shared_network ? "/" : ""), (info -> shared_network ? - info -> shared_network -> name : "unattached")); + info -> shared_network -> name : "")); } #endif /* USE_SOCKET_RECEIVE */ @@ -206,6 +207,12 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) errno == ECONNREFUSED) && retry++ < 10); #endif + if (result < 0) { + warn ("send_packet: %m"); + if (errno == ENETUNREACH) + warn ("send_packet: please consult README file %s", + "regarding broadcast address."); + } return result; } #endif /* USE_SOCKET_SEND */ diff --git a/contrib/isc-dhcp/common/upf.c b/contrib/isc-dhcp/common/upf.c index 7da9aff..c172c62 100644 --- a/contrib/isc-dhcp/common/upf.c +++ b/contrib/isc-dhcp/common/upf.c @@ -3,8 +3,8 @@ Ultrix PacketFilter interface code. /* - * Copyright (c) 1995, 1996, 1997 The Internet Software Consortium. - * All rights reserved. + * Copyright (c) 1995, 1996, 1997, 1998, 1999 + * 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 @@ -42,7 +42,7 @@ #ifndef lint static char copyright[] = -"$Id: upf.c,v 1.3.2.1 1998/12/20 18:29:48 mellon Exp $ Copyright (c) 1995, 1996 The Internet Software Consortium. All rights reserved.\n"; +"$Id: upf.c,v 1.3.2.3 1999/02/23 22:09:56 mellon Exp $ Copyright (c) 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved.\n"; #endif /* not lint */ #include "dhcpd.h" @@ -143,13 +143,14 @@ void if_register_send (info) info -> wfdesc = info -> rfdesc; #endif if (!quiet_interface_discovery) - note ("Sending on UPF/%s/%s/%s", + note ("Sending on UPF/%s/%s%s%s", info -> name, print_hw_addr (info -> hw_address.htype, info -> hw_address.hlen, info -> hw_address.haddr), + (info -> shared_network ? "/" : ""), (info -> shared_network ? - info -> shared_network -> name : "unattached")); + info -> shared_network -> name : "")); } #endif /* USE_UPF_SEND */ @@ -208,13 +209,14 @@ void if_register_receive (info) if (ioctl (info -> rfdesc, EIOCSETF, &pf) < 0) error ("Can't install packet filter program: %m"); if (!quiet_interface_discovery) - note ("Listening on UPF/%s/%s/%s", + note ("Listening on UPF/%s/%s%s%s", info -> name, print_hw_addr (info -> hw_address.htype, info -> hw_address.hlen, info -> hw_address.haddr), + (info -> shared_network ? "/" : ""), (info -> shared_network ? - info -> shared_network -> name : "unattached")); + info -> shared_network -> name : "")); } #endif /* USE_UPF_RECEIVE */ @@ -231,6 +233,7 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) int bufp = 0; unsigned char buf [256]; struct iovec iov [2]; + int result; if (!strcmp (interface -> name, "fallback")) return send_fallback (interface, packet, raw, @@ -248,7 +251,10 @@ ssize_t send_packet (interface, packet, raw, len, from, to, hto) iov [1].iov_base = (char *)raw; iov [1].iov_len = len; - return writev(interface -> wfdesc, iov, 2); + result = writev(interface -> wfdesc, iov, 2); + if (result < 0) + warn ("send_packet: %m"); + return result; } #endif /* USE_UPF_SEND */ diff --git a/contrib/isc-dhcp/doc/rfc2131.txt b/contrib/isc-dhcp/doc/rfc2131.txt new file mode 100644 index 0000000..f45d9b8 --- /dev/null +++ b/contrib/isc-dhcp/doc/rfc2131.txt @@ -0,0 +1,2523 @@ + + + + + + +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 new file mode 100644 index 0000000..e9c4f4b --- /dev/null +++ b/contrib/isc-dhcp/doc/rfc2132.txt @@ -0,0 +1,1907 @@ + + + + + + +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 new file mode 100644 index 0000000..86cd69e --- /dev/null +++ b/contrib/isc-dhcp/doc/rfc951.txt @@ -0,0 +1,684 @@ + + +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/osdep.h b/contrib/isc-dhcp/includes/osdep.h index ca40e8a..f3c6b2f 100644 --- a/contrib/isc-dhcp/includes/osdep.h +++ b/contrib/isc-dhcp/includes/osdep.h @@ -3,7 +3,7 @@ Operating system dependencies... */ /* - * Copyright (c) 1996, 1997, 1998 The Internet Software Consortium. + * Copyright (c) 1996, 1997, 1998, 1999 The Internet Software Consortium. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -123,6 +123,10 @@ # endif #endif +#if !defined (TIME_MAX) +# define TIME_MAX 2147483647 +#endif + /* Porting:: If you add a new network API, and have it set up so that it can be @@ -226,3 +230,36 @@ #ifndef BPF_FORMAT # define BPF_FORMAT "/dev/bpf%d" #endif + +#if defined (IFF_POINTOPOINT) && !defined (HAVE_IFF_POINTOPOINT) +# define HAVE_IFF_POINTOPOINT +#endif + +#if defined (AF_LINK) && !defined (HAVE_AF_LINK) +# define HAVE_AF_LINK +#endif + +#if defined (ARPHRD_TUNNEL) && !defined (HAVE_ARPHRD_TUNNEL) +# define HAVE_ARPHRD_TUNNEL +#endif + +#if defined (ARPHRD_LOOPBACK) && !defined (HAVE_ARPHRD_LOOPBACK) +# define HAVE_ARPHRD_LOOPBACK +#endif + +#if defined (ARPHRD_METRICOM) && !defined (HAVE_ARPHRD_METRICOM) +# define HAVE_ARPHRD_METRICOM +#endif + +#if defined (SO_BINDTODEVICE) && !defined (HAVE_SO_BINDTODEVICE) +# define HAVE_SO_BINDTODEVICE +#endif + +#if defined (SIOCGIFHWADDR) && !defined (HAVE_SIOCGIFHWADDR) +# define HAVE_SIOCGIFHWADDR +#endif + +#if defined (AF_LINK) && !defined (HAVE_AF_LINK) +# define HAVE_AF_LINK +#endif + -- cgit v1.1