diff options
| author | Ted Lemon <source@isc.org> | 2001-11-02 01:10:18 +0000 |
|---|---|---|
| committer | Ted Lemon <source@isc.org> | 2001-11-02 01:10:18 +0000 |
| commit | 2fff0918e4f0286c954f21c56ec39b4b9f2f8080 (patch) | |
| tree | d51951b7541a4c85f88291e8754dc4f642042126 | |
| parent | 50e9dad124cd19239007981127b6ea1324fcbfc9 (diff) | |
| download | isc-dhcp-2fff0918e4f0286c954f21c56ec39b4b9f2f8080.tar.gz | |
Obsolete
| -rw-r--r-- | client/dhclient-script.cat8 | 264 | ||||
| -rw-r--r-- | client/dhclient.cat8 | 264 | ||||
| -rw-r--r-- | client/dhclient.conf.cat5 | 660 | ||||
| -rw-r--r-- | client/dhclient.leases.cat5 | 66 | ||||
| -rw-r--r-- | common/dhcp-contrib.cat5 | 330 | ||||
| -rw-r--r-- | common/dhcp-eval.cat5 | 462 | ||||
| -rw-r--r-- | common/dhcp-options.cat5 | 1188 | ||||
| -rw-r--r-- | relay/dhcrelay.cat8 | 264 | ||||
| -rw-r--r-- | server/dhcpd.cat8 | 396 | ||||
| -rw-r--r-- | server/dhcpd.conf.cat5 | 1716 | ||||
| -rw-r--r-- | server/dhcpd.leases.cat5 | 198 |
11 files changed, 0 insertions, 5808 deletions
diff --git a/client/dhclient-script.cat8 b/client/dhclient-script.cat8 deleted file mode 100644 index 40271b27..00000000 --- a/client/dhclient-script.cat8 +++ /dev/null @@ -1,264 +0,0 @@ - - - -dhclient-script(8) dhclient-script(8) - - -NNAAMMEE - dhclient-script - DHCP client network configuration script - -DDEESSCCRRIIPPTTIIOONN - The DHCP client network configuration script is invoked - from time to time by ddhhcclliieenntt((88)). This script is used by - the dhcp client to set each interface's initial configura - tion prior to requesting an address, to test the address - once it has been offered, and to set the interface's final - configuration once a lease has been acquired. If no lease - is acquired, the script is used to test predefined leases, - if any, and also called once if no valid lease can be - identified. - - This script is not meant to be customized by the end user. - If local customizations are needed, they should be possi - ble using the enter and exit hooks provided (see HOOKS for - details). These hooks will allow the user to override - the default behaviour of the client in creating a - //eettcc//rreessoollvv..ccoonnff file. - - No standard client script exists for some operating sys - tems, even though the actual client may work, so a pio - neering user may well need to create a new script or mod - ify an existing one. In general, customizations specific - to a particular computer should be done in the - //eettcc//ddhhcclliieenntt..ccoonnff file. If you find that you can't make - such a customization without customizing - //eettcc//ddhhcclliieenntt..ccoonnff or using the enter and exit hooks, - please submit a bug report. - -HHOOOOKKSS - When it starts, the client script first defines a shell - function, mmaakkee__rreessoollvv__ccoonnff ,, which is later used to create - the //eettcc//rreessoollvv..ccoonnff file. To override the default - behaviour, redefine this function in the enter hook - script. - - On after defining the make_resolv_conf function, the - client script checks for the presence of an executable - //eettcc//ddhhcclliieenntt--eenntteerr--hhooookkss script, and if present, it - invokes the script inline, using the Bourne shell '.' com - mand. The entire environment documented under OPERATION - is available to this script, which may modify the environ - ment if needed to change the behaviour of the script. If - an error occurs during the execution of the script, it can - set the exit_status variable to a nonzero value, and - //eettcc//ddhhcclliieenntt--ssccrriipptt will exit with that error code imme - diately after the client script exits. - - After all processing has completed, //eettcc//ddhhcclliieenntt--ssccrriipptt - checks for the presence of an executable //eettcc//ddhhcclliieenntt-- - eexxiitt--hhooookkss script, which if present is invoked using the - '.' command. The exit status is passed in the - - - - 1 - - - - - -dhclient-script(8) dhclient-script(8) - - - exit_status shell variable, and will always be zero if the - script succeeded at the task for which it was invoked. - -OOPPEERRAATTIIOONN - When dhclient needs to invoke the client configuration - script, it writes a shell script into /tmp which defines a - variety of variables. In all cases, $reason is set to the - name of the reason why the script has been invoked. The - following reasons are currently defined: MEDIUM, PREINIT, - BOUND, RENEW, REBIND, REBOOT, EXPIRE, FAIL and TIMEOUT. - - -MMEEDDIIUUMM - The DHCP client is requesting that an interface's media - type be set. The interface name is passed in $interface, - and the media type is passed in $medium. - -PPRREEIINNIITT - The DHCP client is requesting that an interface be config - ured as required in order to send packets prior to receiv - ing an actual address. For clients which use the BSD - socket library, this means configuring the interface with - an IP address of 0.0.0.0 and a broadcast address of - 255.255.255.255. For other clients, it may be possible - to simply configure the interface up without actually giv - ing it an IP address at all. The interface name is - passed in $interface, and the media type in $medium. - - If an IP alias has been declared in dhclient.conf, its - address will be passed in $alias_ip_address, and that ip - alias should be deleted from the interface, along with any - routes to it. - -BBOOUUNNDD - The DHCP client has done an initial binding to a new - address. The new ip address is passed in - $new_ip_address, and the interface name is passed in - $interface. The media type is passed in $medium. Any - options acquired from the server are passed using the - option name described in ddhhccpp--ooppttiioonnss, except that dashes - ('-') are replaced by underscores ('_') in order to make - valid shell variables, and the variable names start with - new_. So for example, the new subnet mask would be - passed in $new_subnet_mask. - - Before actually configuring the address, dhclient-script - should somehow ARP for it and exit with a nonzero status - if it receives a reply. In this case, the client will - send a DHCPDECLINE message to the server and acquire a - different address. This may also be done in the RENEW, - REBIND, or REBOOT states, but is not required, and indeed - may not be desirable. - - When a binding has been completed, a lot of network - - - - 2 - - - - - -dhclient-script(8) dhclient-script(8) - - - parameters are likely to need to be set up. A new - /etc/resolv.conf needs to be created, using the values of - $new_domain_name and $new_domain_name_servers (which may - list more than one server, seperated by spaces). A - default route should be set using $new_routers, and static - routes may need to be set up using $new_static_routes. - - If an IP alias has been declared, it must be set up here. - The alias IP address will be written as $alias_ip_address, - and other DHCP options that are set for the alias (e.g., - subnet mask) will be passed in variables named as - described previously except starting with $alias_ instead - of $new_. Care should be taken that the alias IP address - not be used if it is identical to the bound IP address - ($new_ip_address), since the other alias parameters may be - incorrect in this case. - -RREENNEEWW - When a binding has been renewed, the script is called as - in BOUND, except that in addition to all the variables - starting with $new_, there is another set of variables - starting with $old_. Persistent settings that may have - changed need to be deleted - for example, if a local route - to the bound address is being configured, the old local - route should be deleted. If the default route has - changed, the old default route should be deleted. If the - static routes have changed, the old ones should be - deleted. Otherwise, processing can be done as with BOUND. - -RREEBBIINNDD - The DHCP client has rebound to a new DHCP server. This - can be handled as with RENEW, except that if the IP - address has changed, the ARP table should be cleared. - -RREEBBOOOOTT - The DHCP client has successfully reacquired its old - address after a reboot. This can be processed as with - BOUND. - -EEXXPPIIRREE - The DHCP client has failed to renew its lease or acquire a - new one, and the lease has expired. The IP address must - be relinquished, and all related parameters should be - deleted, as in RENEW and REBIND. - -FFAAIILL - The DHCP client has been unable to contact any DHCP - servers, and any leases that have been tested have not - proved to be valid. The parameters from the last lease - tested should be deconfigured. This can be handled in - the same way as EXPIRE. - -TTIIMMEEOOUUTT - The DHCP client has been unable to contact any DHCP - - - - 3 - - - - - -dhclient-script(8) dhclient-script(8) - - - servers. However, an old lease has been identified, and - its parameters have been passed in as with BOUND. The - client configuration script should test these parameters - and, if it has reason to believe they are valid, should - exit with a value of zero. If not, it should exit with a - nonzero value. - - The usual way to test a lease is to set up the network as - with REBIND (since this may be called to test more than - one lease) and then ping the first router defined in - $routers. If a response is received, the lease must be - valid for the network to which the interface is currently - connected. It would be more complete to try to ping all - of the routers listed in $new_routers, as well as those - listed in $new_static_routes, but current scripts do not - do this. - -FFIILLEESS - Each operating system should generally have its own script - file, although the script files for similar operating sys - tems may be similar or even identical. The script files - included in the Internet Software Consortium DHCP distri - bution appear in the distribution tree under - client/scripts, and bear the names of the operating sys - tems on which they are intended to work. - -BBUUGGSS - If more than one interface is being used, there's no obvi - ous way to avoid clashes between server-supplied configu - ration parameters - for example, the stock dhclient-script - rewrites /etc/resolv.conf. If more than one interface is - being configured, /etc/resolv.conf will be repeatedly ini - tialized to the values provided by one server, and then - the other. Assuming the information provided by both - servers is valid, this shouldn't cause any real problems, - but it could be confusing. - -SSEEEE AALLSSOO - dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) and - dhclient.leases(5). - -AAUUTTHHOORR - ddhhcclliieenntt--ssccrriipptt((88)) has been written for the Internet Soft - ware Consortium by Ted Lemon <mellon@fugue.com> in cooper - ation with Vixie Enterprises. To learn more about the - Internet Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc.. - To learn more about Vixie Enterprises, see - hhttttpp::////wwwwww..vviixx..ccoomm.. - - - - - - - - - - 4 - - diff --git a/client/dhclient.cat8 b/client/dhclient.cat8 deleted file mode 100644 index eb274700..00000000 --- a/client/dhclient.cat8 +++ /dev/null @@ -1,264 +0,0 @@ - - - -dhclient(8) dhclient(8) - - -NNAAMMEE - dhclient - Dynamic Host Configuration Protocol Client - -SSYYNNOOPPSSIISS - ddhhcclliieenntt [ --pp _p_o_r_t ] [ --dd ] [ --DD ] [ --qq ] [ --cc ] [ --llff - _l_e_a_s_e_-_f_i_l_e ] [ --ppff _p_i_d_-_f_i_l_e ] [ --ccff _c_o_n_f_i_g_-_f_i_l_e ] [ --ss - server ] [ --ww ] [ _i_f_0 [ _._._._i_f_N ] ] - -DDEESSCCRRIIPPTTIIOONN - The Internet Software Consortium DHCP Client, dhclient, - provides a means for configuring one or more network - interfaces using the Dynamic Host Configuration Protocol, - BOOTP protocol, or if these protocols fail, by statically - assigning an address. - -OOPPEERRAATTIIOONN - The DHCP protocol allows a host to contact a central - server which maintains a list of IP addresses which may be - assigned on one or more subnets. A DHCP client may - request an address from this pool, and then use it on a - temporary basis for communication on network. The DHCP - protocol also provides a mechanism whereby a client can - learn important details about the network to which it is - attached, such as the location of a default router, the - location of a name server, and so on. - - On startup, dhclient reads the _d_h_c_l_i_e_n_t_._c_o_n_f for configu - ration instructions. It then gets a list of all the net - work interfaces that are configured in the current system. - For each interface, it attempts to configure the interface - using the DHCP protocol. - - In order to keep track of leases across system reboots and - server restarts, dhclient keeps a list of leases it has - been assigned in the dhclient.leases(5) file. On - startup, after reading the dhclient.conf file, dhclient - reads the dhclient.leases file to refresh its memory about - what leases it has been assigned. - - When a new lease is acquired, it is appended to the end of - the dhclient.leases file. In order to prevent the file - from becoming arbitrarily large, from time to time - dhclient creates a new dhclient.leases file from its in- - core lease database. The old version of the - dhclient.leases file is retained under the name - _d_h_c_l_i_e_n_t_._l_e_a_s_e_s_~ until the next time dhclient rewrites the - database. - - Old leases are kept around in case the DHCP server is - unavailable when dhclient is first invoked (generally dur - ing the initial system boot process). In that event, old - leases from the dhclient.leases file which have not yet - expired are tested, and if they are determined to be - valid, they are used until either they expire or the DHCP - - - - 1 - - - - - -dhclient(8) dhclient(8) - - - server becomes available. - - A mobile host which may sometimes need to access a network - on which no DHCP server exists may be preloaded with a - lease for a fixed address on that network. When all - attempts to contact a DHCP server have failed, dhclient - will try to validate the static lease, and if it succeeds, - will use that lease until it is restarted. - - A mobile host may also travel to some networks on which - DHCP is not available but BOOTP is. In that case, it may - be advantageous to arrange with the network administrator - for an entry on the BOOTP database, so that the host can - boot quickly on that network rather than cycling through - the list of old leases. - -CCOOMMMMAANNDD LLIINNEE - The names of the network interfaces that dhclient should - attempt to configure may be specified on the command line. - If no interface names are specified on the command line - dhclient will normally identify all network interfaces, - elimininating non-broadcast interfaces if possible, and - attempt to configure each interface. - - It is also possible to specify interfaces by name in the - ddhhcclliieenntt..ccoonnff((55)) file. If interfaces are specified in - this way, then the client will only configure interfaces - that are either specified in the configuration file or on - the command line, and will ignore all other interfaces. - - If the DHCP client should listen and transmit on a port - other than the standard (port 68), the --pp flag may used. - It should be followed by the udp port number that dhclient - should use. This is mostly useful for debugging purposes. - If a different port is specified for the client to listen - on and transmit on, the client will also use a different - destination port - one greater than the specified destina - tion port. - - The DHCP client normally transmits any protocol messages - it sends before acquiring an IP address to, - 255.255.255.255, the IP limited broadcast address. For - debugging purposes, it may be useful to have the server - transmit these messages to some other address. This can - be specified with the --ss flag, followed by the IP address - or domain name of the destination. - - The DHCP client will normally run in the foreground until - it has configured an interface, and then will revert to - running in the background. To run force dhclient to - always run as a foreground process, the --dd flag should be - specified. This is useful when running the client under a - debugger, or when running it out of inittab on System V - systems. - - - - 2 - - - - - -dhclient(8) dhclient(8) - - - The client writes a temporary shell script whenever it - invokes dhclient-script. This script is normally deleted - after the client runs, but it can be helpful when debug - ging the client script to see what the client wrote. The - client can be configured not to delete these scripts by - specifying the --DD flag. - - The client normally prints a startup message and displays - the protocol sequence to the standard error descriptor - until it has acquired an address, and then only logs mes - sages using the ssyysslloogg ((33)) facility. The --qq flag pre - vents any messages other than errors from being printed to - the standard error descriptor. - - The DHCP client normally gets its configuration informa - tion from //eettcc//ddhhcclliieenntt..ccoonnff,, its lease database from - //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess and stores its process ID in a - file called //vvaarr//rruunn//ddhhcclliieenntt..ppiidd.. To specify different - names and/or locations for these files, use the --ccff,, --llff - and --ppff flags, respectively, followed by the name of the - file. This can be particularly useful if, for example, - //vvaarr//ddbb or //vvaarr//rruunn has not yet been mounted when the DHCP - client is started. - - The DHCP client normally exits if it isn't able to iden - tify any network interfaces to configure. On laptop com - puters and other computers with hot-swappable I/O buses, - it is possible that a broadcast interface may be added - after system startup. The --ww flag can be used to cause - the client not to exit when it doesn't find any such - interfaces. The ddhhccppccccpp ((88)) program can then be used to - notify the client when a network interface has been added - or removed, so that the client can configure an IP address - on that interface. - -CCOONNFFIIGGUURRAATTIIOONN - The syntax of the dhclient.conf(8) file is discussed - seperately. - -FFIILLEESS - //eettcc//ddhhcclliieenntt..ccoonnff,, //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess,, - //vvaarr//rruunn//ddhhcclliieenntt..ppiidd,, //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess~~.. - -SSEEEE AALLSSOO - dhcpd(8), dhcrelay(8), dhclient.conf(5), - dhclient.leases(5) - -AAUUTTHHOORR - ddhhcclliieenntt((88)) has been written for the Internet Software - Consortium by Ted Lemon <mellon@fugue.com> in cooperation - with Vixie Enterprises. To learn more about the Internet - Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc.. To learn - more about Vixie Enterprises, see hhttttpp::////wwwwww..vviixx..ccoomm.. - - - - - 3 - - - - - -dhclient(8) dhclient(8) - - - This client was substantially modified and enhanced by - Elliot Poger for use on Linux while he was working on the - MosquitoNet project at Stanford. - - The current version owes much to Elliot's Linux enhance - ments, but was substantially reorganized and partially - rewritten by Ted Lemon so as to use the same networking - framework that the Internet Software Consortium DHCP - server uses. Much system-specific configuration code was - moved into a shell script so that as support for more - operating systems is added, it will not be necessary to - port and maintain system-specific configuration code to - these operating systems - instead, the shell script can - invoke the native tools to accomplish the same purpose. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4 - - diff --git a/client/dhclient.conf.cat5 b/client/dhclient.conf.cat5 deleted file mode 100644 index 66d525d2..00000000 --- a/client/dhclient.conf.cat5 +++ /dev/null @@ -1,660 +0,0 @@ - - - -dhclient.conf(5) dhclient.conf(5) - - -NNAAMMEE - dhclient.conf - DHCP client configuration file - -DDEESSCCRRIIPPTTIIOONN - The dhclient.conf file contains configuration information - for _d_h_c_l_i_e_n_t_, the Internet Software Consortium DHCP - Client. - - The dhclient.conf file is a free-form ASCII text file. - It is parsed by the recursive-descent parser built into - dhclient. The file may contain extra tabs and newlines - for formatting purposes. Keywords in the file are case- - insensitive. Comments may be placed anywhere within the - file (except within quotes). Comments begin with the # - character and end at the end of the line. - - The dhclient.conf file can be used to configure the - behaviour of the client in a wide variety of ways: proto - col timing, information requested from the server, infor - mation required of the server, defaults to use if the - server does not provide certain information, values with - which to override information provided by the server, or - values to prepend or append to information provided by the - server. The configuration file can also be preinitialized - with addresses to use on networks that don't have DHCP - servers. - -PPRROOTTOOCCOOLL TTIIMMIINNGG - The timing behaviour of the client need not be configured - by the user. If no timing configuration is provided by - the user, a fairly reasonable timing behaviour will be - used by default - one which results in fairly timely - updates without placing an inordinate load on the server. - - The following statements can be used to adjust the timing - behaviour of the DHCP client if required, however: - - _T_h_e ttiimmeeoouutt _s_t_a_t_e_m_e_n_t - - ttiimmeeoouutt _t_i_m_e ;; - - The _t_i_m_e_o_u_t statement determines the amount of time that - must pass between the time that the client begins to try - to determine its address and the time that it decides that - it's not going to be able to contact a server. By - default, this timeout is sixty seconds. After the time - out has passed, if there are any static leases defined in - the configuration file, or any leases remaining in the - lease database that have not yet expired, the client will - loop through these leases attempting to validate them, and - if it finds one that appears to be valid, it will use that - lease's address. If there are no valid static leases or - unexpired leases in the lease database, the client will - restart the protocol after the defined retry interval. - - - - 1 - - - - - -dhclient.conf(5) dhclient.conf(5) - - - _T_h_e rreettrryy _s_t_a_t_e_m_e_n_t - - rreettrryy _t_i_m_e;; - - The _r_e_t_r_y statement determines the time that must pass - after the client has determined that there is no DHCP - server present before it tries again to contact a DHCP - server. By default, this is five minutes. - - _T_h_e sseelleecctt--ttiimmeeoouutt _s_t_a_t_e_m_e_n_t - - sseelleecctt--ttiimmeeoouutt _t_i_m_e;; - - It is possible (some might say desirable) for there to be - more than one DHCP server serving any given network. In - this case, it is possible that a client may be sent more - than one offer in response to its initial lease discovery - message. It may be that one of these offers is prefer - able to the other (e.g., one offer may have the address - the client previously used, and the other may not). - - The _s_e_l_e_c_t_-_t_i_m_e_o_u_t is the time after the client sends its - first lease discovery request at which it stops waiting - for offers from servers, assuming that it has received at - least one such offer. If no offers have been received by - the time the _s_e_l_e_c_t_-_t_i_m_e_o_u_t has expired, the client will - accept the first offer that arrives. - - By default, the select-timeout is zero seconds - that is, - the client will take the first offer it sees. - - _T_h_e rreebboooott _s_t_a_t_e_m_e_n_t - - rreebboooott _t_i_m_e;; - - When the client is restarted, it first tries to reacquire - the last address it had. This is called the INIT-REBOOT - state. If it is still attached to the same network it - was attached to when it last ran, this is the quickest way - to get started. The _r_e_b_o_o_t statement sets the time that - must elapse after the client first tries to reacquire its - old address before it gives up and tries to discover a new - address. By default, the reboot timeout is ten seconds. - - _T_h_e bbaacckkooffff--ccuuttooffff _s_t_a_t_e_m_e_n_t - - bbaacckkooffff--ccuuttooffff _t_i_m_e;; - - The client uses an exponential backoff algorithm with some - randomness, so that if many clients try to configure them - selves at the same time, they will not make their requests - in lockstep. The _b_a_c_k_o_f_f_-_c_u_t_o_f_f statement determines the - maximum amount of time that the client is allowed to back - off. It defaults to two minutes. - - - - 2 - - - - - -dhclient.conf(5) dhclient.conf(5) - - - _T_h_e iinniittiiaall--iinntteerrvvaall _s_t_a_t_e_m_e_n_t - - iinniittiiaall--iinntteerrvvaall _t_i_m_e;; - - The _i_n_i_t_i_a_l_-_i_n_t_e_r_v_a_l statement sets the amount of time - between the first attempt to reach a server and the second - attempt to reach a server. Each time a message is sent, - the interval between messages is incremented by twice the - current interval multiplied by a random number between - zero and one. If it is greater than the backoff-cutoff - amount, it is set to that amount. It defaults to ten sec - onds. - -LLEEAASSEE RREEQQUUIIRREEMMEENNTTSS AANNDD RREEQQUUEESSTTSS - The DHCP protocol allows the client to request that the - server send it specific information, and not send it other - information that it is not prepared to accept. The pro - tocol also allows the client to reject offers from servers - if they don't contain information the client needs, or if - the information provided is not satisfactory. - - There is a variety of data contained in offers that DHCP - servers send to DHCP clients. The data that can be - specifically requested is what are called _D_H_C_P _O_p_t_i_o_n_s. - DHCP Options are defined in - ddhhccpp--ooppttiioonnss((55)). - - _T_h_e rreeqquueesstt _s_t_a_t_e_m_e_n_t - - rreeqquueesstt [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n ];; - - The request statement causes the client to request that - any server responding to the client send the client its - values for the specified options. Only the option names - should be specified in the request statement - not option - parameters. By default, the DHCP server requests the - subnet-mask, broadcast-address, time-offset, routers, - domain-name, domain-name-servers and host-name options. - - In some cases, it may be desirable to send no parameter - request list at all. To do this, simply write the - request statement but specify no parameters: - - request; - - _T_h_e rreeqquuiirree _s_t_a_t_e_m_e_n_t - - rreeqquuiirree [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _];; - - The require statement lists options that must be sent in - order for an offer to be accepted. Offers that do not - contain all the listed options will be ignored. - - _T_h_e sseenndd _s_t_a_t_e_m_e_n_t - - - - 3 - - - - - -dhclient.conf(5) dhclient.conf(5) - - - sseenndd {{ [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n - ]}} - - The send statement causes the client to send the specified - options to the server with the specified values. These - are full option declarations as described in ddhhccpp-- - ooppttiioonnss((55)). Options that are always sent in the DHCP pro - tocol should not be specified here, except that the client - can specify a rreeqquueesstteedd--lleeaassee--ttiimmee option other than the - default requested lease time, which is two hours. The - other obvious use for this statement is to send informa - tion to the server that will allow it to differentiate - between this client and other clients or kinds of clients. - -OOPPTTIIOONN MMOODDIIFFIIEERRSS - In some cases, a client may receive option data from the - server which is not really appropriate for that client, or - may not receive information that it needs, and for which a - useful default value exists. It may also receive infor - mation which is useful, but which needs to be supplemented - with local information. To handle these needs, several - option modifiers are available. - - _T_h_e ddeeffaauulltt _s_t_a_t_e_m_e_n_t - - ddeeffaauulltt [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;; - - If for some option the client should use the value sup - plied by the server, but needs to use some default value - if no value was supplied by the server, these values can - be defined in the ddeeffaauulltt statement. - - _T_h_e ssuuppeerrsseeddee _s_t_a_t_e_m_e_n_t - - ssuuppeerrsseeddee [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;; - - If for some option the client should always use a locally- - configured value or values rather than whatever is sup - plied by the server, these values can be defined in the - ssuuppeerrsseeddee statement. - - _T_h_e pprreeppeenndd _s_t_a_t_e_m_e_n_t - - pprreeppeenndd [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;; - - If for some set of options the client should use a value - you supply, and then use the values supplied by the - server, if any, these values can be defined in the pprreeppeenndd - statement. The pprreeppeenndd statement can only be used for - options which allow more than one value to be given. - This restriction is not enforced - if you ignore it, the - behaviour will be unpredictable. - - _T_h_e aappppeenndd _s_t_a_t_e_m_e_n_t - - - - 4 - - - - - -dhclient.conf(5) dhclient.conf(5) - - - aappppeenndd [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;; - - If for some set of options the client should first use the - values supplied by the server, if any, and then use values - you supply, these values can be defined in the aappppeenndd - statement. The aappppeenndd statement can only be used for - options which allow more than one value to be given. - This restriction is not enforced - if you ignore it, the - behaviour will be unpredictable. - -LLEEAASSEE DDEECCLLAARRAATTIIOONNSS - _T_h_e lleeaassee _d_e_c_l_a_r_a_t_i_o_n - - lleeaassee {{ _l_e_a_s_e_-_d_e_c_l_a_r_a_t_i_o_n [ ... _l_e_a_s_e_-_d_e_c_l_a_r_a_t_i_o_n _] }} - - The DHCP client may decide after some period of time (see - PPRROOTTOOCCOOLL TTIIMMIINNGG) decide that it is not going to succeed in - contacting a server. At that time, it consults its own - database of old leases and tests each one that has not yet - timed out by pinging the listed router for that lease to - see if that lease could work. It is possible to define - one or more _f_i_x_e_d leases in the client configuration file - for networks where there is no DHCP or BOOTP service, so - that the client can still automatically configure its - address. This is done with the lleeaassee statement. - - NOTE: the lease statement is also used in the - dhclient.leases file in order to record leases that have - been received from DHCP servers. Some of the syntax for - leases as described below is only needed in the - dhclient.leases file. Such syntax is documented here for - completeness. - - A lease statement consists of the lease keyword, followed - by a left curly brace, followed by one or more lease dec - laration statements, followed by a right curly brace. - The following lease declarations are possible: - - bboooottpp;; - - The bboooottpp statement is used to indicate that the lease was - acquired using the BOOTP protocol rather than the DHCP - protocol. It is never necessary to specify this in the - client configuration file. The client uses this syntax - in its lease database file. - - iinntteerrffaaccee ""_s_t_r_i_n_g"";; - - The iinntteerrffaaccee lease statement is used to indicate the - interface on which the lease is valid. If set, this - lease will only be tried on a particular interface. When - the client receives a lease from a server, it always - records the interface number on which it received that - lease. If predefined leases are specified in the - - - - 5 - - - - - -dhclient.conf(5) dhclient.conf(5) - - - dhclient.conf file, the interface should also be speci - fied, although this is not required. - - ffiixxeedd--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; - - The ffiixxeedd--aaddddrreessss statement is used to set the ip address - of a particular lease. This is required for all lease - statements. The IP address must be specified as a dotted - quad (e.g., 12.34.56.78). - - ffiilleennaammee ""_s_t_r_i_n_g"";; - - The ffiilleennaammee statement specifies the name of the boot - filename to use. This is not used by the standard client - configuration script, but is included for completeness. - - sseerrvveerr--nnaammee ""_s_t_r_i_n_g"";; - - The sseerrvveerr--nnaammee statement specifies the name of the boot - server name to use. This is also not used by the stan - dard client configuration script. - - ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n;; - - The ooppttiioonn statement is used to specify the value of an - option supplied by the server, or, in the case of prede - fined leases declared in dhclient.conf, the value that the - user wishes the client configuration script to use if the - predefined lease is used. - - ssccrriipptt ""_s_c_r_i_p_t_-_n_a_m_e"";; - - The ssccrriipptt statement is used to specify the pathname of - the dhcp client configuration script. This script is used - by the dhcp client to set each interface's initial config - uration prior to requesting an address, to test the - address once it has been offered, and to set the inter - face's final configuration once a lease has been acquired. - If no lease is acquired, the script is used to test prede - fined leases, if any, and also called once if no valid - lease can be identified. For more information, see - ddhhcclliieenntt--ssccrriipptt((88)).. - - mmeeddiiuumm ""_m_e_d_i_a _s_e_t_u_p"";; - - The mmeeddiiuumm statement can be used on systems where network - interfaces cannot automatically determine the type of net - work to which they are connected. The media setup string - is a system-dependent parameter which is passed to the - dhcp client configuration script when initializing the - interface. On Unix and Unix-like systems, the argument is - passed on the ifconfig command line when configuring te - interface. - - - - - 6 - - - - - -dhclient.conf(5) dhclient.conf(5) - - - The dhcp client automatically declares this parameter if - it used a media type (see the mmeeddiiaa statement) when con - figuring the interface in order to obtain a lease. This - statement should be used in predefined leases only if the - network interface requires media type configuration. - - rreenneeww _d_a_t_e;; - - rreebbiinndd _d_a_t_e;; - - eexxppiirree _d_a_t_e;; - - The rreenneeww statement defines the time at which the dhcp - client should begin trying to contact its server to renew - a lease that it is using. The rreebbiinndd statement defines - the time at which the dhcp client should begin to try to - contact _a_n_y dhcp server in order to renew its lease. The - eexxppiirree statement defines the time at which the dhcp client - must stop using a lease if it has not been able to contact - a server in order to renew it. - - These declarations are automatically set in leases - acquired by the DHCP client, but must also be configured - in predefined leases - a predefined lease whose expiry - time has passed will not be used by the DHCP client. - - Dates are specified as follows: - - _<_w_e_e_k_d_a_y_> _<_y_e_a_r_>//_<_m_o_n_t_h_>//_<_d_a_y_> _<_h_o_u_r_>::_<_m_i_n_u_t_e_>::_<_s_e_c_o_n_d_> - - The weekday is present to make it easy for a human to tell - when a lease expires - it's specified as a number from - zero to six, with zero being Sunday. When declaring a - predefined lease, it can always be specified as zero. The - year is specified with the century, so it should generally - be four digits except for really long leases. The month - is specified as a number starting with 1 for January. The - day of the month is likewise specified starting with 1. - The hour is a number between 0 and 23, the minute a number - between 0 and 59, and the second also a number between 0 - and 59. - -AALLIIAASS DDEECCLLAARRAATTIIOONNSS - aalliiaass {{ _d_e_c_l_a_r_a_t_i_o_n_s _._._. }} - - Some DHCP clients running TCP/IP roaming protocols may - require that in addition to the lease they may acquire via - DHCP, their interface also be configured with a predefined - IP alias so that they can have a permanent IP address even - while roaming. The Internet Software Consortium DHCP - client doesn't support roaming with fixed addresses - directly, but in order to facilitate such experimentation, - the dhcp client can be set up to configure an IP alias - using the aalliiaass declaration. - - - - 7 - - - - - -dhclient.conf(5) dhclient.conf(5) - - - The alias declaration resembles a lease declaration, - except that options other than the subnet-mask option are - ignored by the standard client configuration script, and - expiry times are ignored. A typical alias declaration - includes an interface declaration, a fixed-address decla - ration for the IP alias address, and a subnet-mask option - declaration. A medium statement should never be included - in an alias declaration. - -OOTTHHEERR DDEECCLLAARRAATTIIOONNSS - rreejjeecctt _i_p_-_a_d_d_r_e_s_s;; - - The reject statement causes the DHCP client to reject - offers from servers who use the specified address as a - server identifier. This can be used to avoid being con - figured by rogue or misconfigured dhcp servers, although - it should be a last resort - better to track down the bad - DHCP server and fix it. - - iinntteerrffaaccee ""_n_a_m_e"" {{ _d_e_c_l_a_r_a_t_i_o_n_s _._._. }} - - A client with more than one network interface may require - different behaviour depending on which interface is being - configured. All timing parameters and declarations other - than lease and alias declarations can be enclosed in an - interface declaration, and those parameters will then be - used only for the interface that matches the specified - name. Interfaces for which there is no interface decla - ration will use the parameters declared outside of any - interface declaration, or the default settings. - - ppsseeuuddoo ""_n_a_m_e" "_r_e_a_l_-_n_a_m_e"" {{ _d_e_c_l_a_r_a_t_i_o_n_s _._._. }} - - Under some circumstances it can be useful to declare a - pseudo-interface and have the DHCP client acquire a con - figuration for that interface. Each interface that the - DHCP client is supporting normally has a DHCP client state - machine running on it to acquire and maintain its lease. - A pseudo-interface is just another state machine running - on the interface named _r_e_a_l_-_n_a_m_e, with its own lease and - its own state. If you use this feature, you must provide - a client identifier for both the pseudo-interface and the - actual interface, and the two identifiers must be differ - ent. You must also provide a seperate client script for - the pseudo-interface to do what you want with the IP - address. For example: - - interface "ep0" { - send dhcp-client-identifier "my-client-ep0"; - } - pseudo "secondary" "ep0" { - send dhcp-client-identifier "my-client-ep0-secondary"; - script "/etc/dhclient-secondary"; - } - - - - 8 - - - - - -dhclient.conf(5) dhclient.conf(5) - - - The client script for the pseudo-interface should not con - figure the interface up or down - essentially, all it - needs to handle are the states where a lease has been - acquired or renewed, and the states where a lease has - expired. See ddhhcclliieenntt--ssccrriipptt((88)) for more information. - - mmeeddiiaa ""_m_e_d_i_a _s_e_t_u_p"" _[ ,, ""_m_e_d_i_a _s_e_t_u_p"",, _._._. _];; - - The mmeeddiiaa statement defines one or more media configura - tion parameters which may be tried while attempting to - acquire an IP address. The dhcp client will cycle - through each media setup string on the list, configuring - the interface using that setup and attempting to boot, and - then trying the next one. This can be used for network - interfaces which aren't capable of sensing the media type - unaided - whichever media type succeeds in getting a - request to the server and hearing the reply is probably - right (no guarantees). - - The media setup is only used for the initial phase of - address acquisition (the DHCPDISCOVER and DHCPOFFER pack - tes). Once an address has been acquired, the dhcp client - will record it in its lease database and will record the - media type used to acquire the address. Whenever the - client tries to renew the lease, it will use that same - media type. The lease must expire before the client will - go back to cycling through media types. - -SSAAMMPPLLEE - The following configuration file is used on a laptop run - ning NetBSD 1.3. The laptop has an IP alias of - 192.5.5.213, and has one interface, ep0 (a 3com 3C589C). - Booting intervals have been shortened somewhat from the - default, because the client is known to spend most of its - time on networks with little DHCP activity. The laptop - does roam to multiple networks. - - - timeout 60; - retry 60; - reboot 10; - select-timeout 5; - initial-interval 2; - reject 192.33.137.209; - - interface "ep0" { - send host-name "andare.fugue.com"; - send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; - send dhcp-lease-time 3600; - supersede domain-name "fugue.com rc.vix.com home.vix.com"; - prepend domain-name-servers 127.0.0.1; - request subnet-mask, broadcast-address, time-offset, routers, - domain-name, domain-name-servers, host-name; - require subnet-mask, domain-name-servers; - - - - 9 - - - - - -dhclient.conf(5) dhclient.conf(5) - - - script "/etc/dhclient-script"; - media "media 10baseT/UTP", "media 10base2/BNC"; - } - - alias { - interface "ep0"; - fixed-address 192.5.5.213; - option subnet-mask 255.255.255.255; - } - This is a very complicated dhclient.conf file - in gen - eral, yours should be much simpler. In many cases, it's - sufficient to just create an empty dhclient.conf file - - the defaults are usually fine. - -SSEEEE AALLSSOO - dhcp-options(5), dhclient.leases(5), dhcpd(8), - dhcpd.conf(5), RFC2132, RFC2131. - -AAUUTTHHOORR - ddhhcclliieenntt((88)) was written by Ted Lemon <mellon@vix.com> - under a contract with Vixie Labs. Funding for this pro - ject was provided by the Internet Software Consortium. - Information about the Internet Software Consortium can be - found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 10 - - diff --git a/client/dhclient.leases.cat5 b/client/dhclient.leases.cat5 deleted file mode 100644 index 1add3996..00000000 --- a/client/dhclient.leases.cat5 +++ /dev/null @@ -1,66 +0,0 @@ - - - -dhclient.leases(5) dhclient.leases(5) - - -NNAAMMEE - dhclient.leases - DHCP client lease database - -DDEESSCCRRIIPPTTIIOONN - The Internet Software Consortium DHCP client keeps a per - sistent database of leases that it has acquired that are - still valid. The database is a free-form ASCII file con - taining one valid declaration per lease. If more than - one declaration appears for a given lease, the last one in - the file is used. The file is written as a log, so this - is not an unusual occurrance. - - The format of the lease declarations is described in - ddhhcclliieenntt..ccoonnff((55)).. - -FFIILLEESS - //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess - -SSEEEE AALLSSOO - dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8), - dhcpd.conf(5), RFC2132, RFC2131. - -AAUUTTHHOORR - ddhhcclliieenntt((88)) was written by Ted Lemon <mellon@vix.com> - under a contract with Vixie Labs. Funding for this pro - ject was provided by the Internet Software Consortium. - Information about the Internet Software Consortium can be - found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1 - - diff --git a/common/dhcp-contrib.cat5 b/common/dhcp-contrib.cat5 deleted file mode 100644 index 9b81be98..00000000 --- a/common/dhcp-contrib.cat5 +++ /dev/null @@ -1,330 +0,0 @@ - - - -dhcp-contrib(5) dhcp-contrib(5) - - -NNAAMMEE - Contributing to the Internet Software Consortium DHCP Dis - tribution - -EEXXHHOORRTTAATTIIOONN - The Internet Software Consortium DHCP Distribution has - historically been funded through the donation of various - charitable and non-charitable organizations, as well as by - individual contributions. To some degree, support for the - distribution has been done on a volunteer basis, but by - and large the reason that you have this distribution in - your hands right now is because people like you have pro - vided funding for it. - - We would like to encourage you to continue to provide such - support, or to begin providing it if you have not in the - past. You are in no way obliged to provide us with any - support at all, and this message is not intended to guilt- - trip you about providing support. If you choose not to - provide support, for whatever reason, you aren't going to - be treated differently on the mailing lists, and your - requests for features aren't going to be prioritized any - differently. If you want to be treated differently, you - can buy a formal support contract, of course, but this - document is about contributions, not support contracts. - -FFRREEQQUUEENNTTLLYY AASSKKEEDD QQUUEESSTTIIOONNSS - Q: So if I won't be treated differently, why contribute? - - A: The obvious answer is self-interest. If you con - tribute, it means that the author will have time to work - on stuff that's not of the utmost high priority. People - are constantly asking for things that we would really like - to provide, but for which we have no time. By contribut - ing, you are literally giving us time to do these things. - The amount of time varies with the contribution, of - course, but if everybody contributes a little bit, it can - add up to a lot. - - Q: But everybody isn't required to contribute. If I con - tribute and nobody else does, doesn't that make me kind of - a sucker? - - A: Obviously, we don't think so, but think about this: if - you contribute, then we can point out to others that we've - received contributions, and this will make the idea of - contributing seem more legitimate to them, making it more - likely that they will contribute. So your contribution - has more value than just the money you provide - it also - helps us to raise funds from others. - - Q: If I contribute, I want a say in what work gets done. - - A: We do sell support contracts, and we will also do - - - - 1 - - - - - -dhcp-contrib(5) dhcp-contrib(5) - - - development work on specification if we feel it is rele - vant (although you won't get to own it). This can be - quite expensive, though - much more than even the maximum - we'd expect you to donate. So no, contributing doesn't - buy you a say in what work gets done. - - Q: I work for a charity that feeds the homeless. Should - my charity contribute? - - A: Absolutely not! The idea here is not to take food out - of the mouths of poor people. If donating to us would - mean that somebody in need that you could have helped will - go without help, keep the money. It's not worth it to us. - This goes for providing shelter, psychiatric aid, legal - assistance, and any other similar charity work. - - Q: Cool! I work for a university, helping students who - are in need of an education, so we shouldn't contribute, - right? - - A: No, that's not quite what we mean. Sure, if you work - for an organization that provides free education to needy - people, at whatever level, then we'd rather you did that - than support us. But if your university has a big budget - for running the computer center, can afford to plant nice - gardens and maintain nice lawns, and maybe has all its - dorms wired for ethernet, then even if you qualify as a - nonprofit under federal law (or the law in your own coun - try) you should still contribute. DHCP is just as much a - part of your infrastructure as your campus wiring. - - Q: This software came on a CD that I bought. Haven't I - already contributed? - - A: If you're seeing this notice, and you didn't see a - notice saying that the people who sold you your CD con - tributed to us, then no, you haven't already contributed. - In general, we encourage people to include this software - on their distributions if they feel it would be useful, - and we do not require them to contribute in exchange for - that privilege. - - Q: I've contributed to the development of this software by - submitting bug reports and patches. Why should I also - contribute money? - - A: When you contributed these bug reports and patches, was - there zero effort involved on our part in integrating the - patches or figuring out what was wrong? Probably not. - Bug reports and patches can be extremely valuable, and we - can't say that in no event do they qualify you to get out - of contributing - after all, we're leaving that up to your - judgement anyway, aren't we? But unless your contribution - was pretty massive, and is actually in this distribution, - - - - 2 - - - - - -dhcp-contrib(5) dhcp-contrib(5) - - - we aren't likely to agree with you about this. - - Q: Software should be free. You have no right to ask for - money to support this effort. - - A: You are entitled to that opinion, but please don't - raise it on the mailing list, as it will tend to get peo - ple excited. Please remember that while copying software - is generally a very cheap process, creating it is not. - The amount of work that's gone into this software package - is quite significant, and there's plenty more work to do. - If you happen to be in college, working toward your - degree, and have no social life (and yes, I've been there - and done that) then it can seem like there's no additional - cost to hacking on software - after all, it's fun, isn't - it? While this is true, it is also true that you're a lot - better off with this software than you would have been - with the software I wrote in college. Enough said? - - Q: Can't I contribute work instead of software? - - A: We'd like to encourage that to some extent, and are - indeed trying to bring some developers into the fold, but - you shouldn't expect that your willingness to do this - translates directly into an opportunity. For example, you - may want very much to work for [insert the name of your - favorite commercial Linux vendor here], but unless you - have the appropriate skills, they like you, they're will - ing to pay what you need, and they have work that's appro - priate to your skills, you're not going to get hired - there. - - Q: I don't contribute to the Free Software Foundation - - why do you rate? - - A: You should contribute to the Free Software Foundation - too! - - Q: I don't contribute to [insert name of your local food - bank here]. Why do you rate? - - A: If you feel bad about not contributing to the local - food bank, this is a very easy problem to solve, and we - encourage you to do so. - - Q: Once I've contributed once, am I done? - - A: We'd like to encourage you to contribute once a year. - If you want, we can send you a reminder notice on the year - anniversary of your original contribution. If you don't - specifically ask for this, we won't force it on you. No - salesperson will call. No spam will be sent. We defi - nitely won't try to convince you that it's been a year - since you last contributed when it hasn't been a year yet. - - - - 3 - - - - - -dhcp-contrib(5) dhcp-contrib(5) - - - Q: I don't have you in my budget this year. - - A: Fine, put us in your budget for next year! - - Q: It's really hard to do charitable contributions at my - organization. - - A: We'd be happy to sell you a product instead. If you - choose to go down this route, what we'l sell you is a - license for some number of clients and a CD. Just let us - know how many DHCP clients you have, and we'll use the - following schedule to figure out how much to invoice you - (shipping is included on orders of $100 or more). Even if - you can do charitable contributions, you might want to use - this schedule as a guideline for figuring out how much to - donate. It is only a guideline, of course - if the - amounts listed feel like too much or too little to you, do - what seems appropriate. - - $10k for businesses supporting >10k nodes - $5k for charities supporting >10k nodes - $2.5k for businesses supporting >1k nodes - $1k for charities supporting >1k nodes - $500 for businesses with >500 nodes - $250 for charities with >500 nodes - $200 for businesses with >150 nodes - $100 for charities with >150 nodes - $100 for businesses with <150 nodes - $50 for charities with <150 nodes - $25 for home use, client or server - $0.10 to $1 per client for businesses that are reselling the - client, depending on volume. - - Q: Are you nuts? I live in [insert your country name - here] and the typical annual salary for a programmer is - less than what you're asking me to contribute! - - A: We leave the choice of how much to contribute up to - you. Really. We aren't kidding. - - Q: Can I contribute with my credit card? - - A: Yes. The details haven't been ironed out at this - writing, but if you send mail to dhcp-contribu - tions@isc.org, we'll work it out. By the time you read - this, we may have a web interface set up - if so, it will - be linked in at http://www.isc.org/dhcp-contrib.html. - -SSEEEE AALLSSOO - dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), - dhcpd(8), dhclient(8), RFC2132, RFC2131. - -AAUUTTHHOORR - The Internet Software Consortium DHCP Distribution was - - - - 4 - - - - - -dhcp-contrib(5) dhcp-contrib(5) - - - written by Ted Lemon <mellon@isc.org> under a contract - with Vixie Labs. Funding for this project was provided - through the Internet Software Consortium. Information - about the Internet Software Consortium can be found at - hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 5 - - diff --git a/common/dhcp-eval.cat5 b/common/dhcp-eval.cat5 deleted file mode 100644 index ada5beb4..00000000 --- a/common/dhcp-eval.cat5 +++ /dev/null @@ -1,462 +0,0 @@ - - - -dhcpd-options(5) dhcpd-options(5) - - -NNAAMMEE - dhcp-conditionals - ISC DHCP conditional evaluation - -DDEESSCCRRIIPPTTIIOONN - The Internet Software Consortium DHCP client and server - both provide the ability to perform conditional behavior - depending on the contents of packets they receive. The - syntax for specifying this conditional behaviour is docu - mented here. - -RREEFFEERREENNCCEE:: CCOONNDDIITTIIOONNAALL BBEEHHAAVVIIOOUURR - Conditional behaviour is specified using the if statement - and the else or elsif statements. A conditional state - ment can appear anywhere that a regular statement (e.g., - an option statement) can appear, and can enclose one or - more such statements. A typical conditional statement in - a server might be: - - if option dhcp-user-class = "accounting" { - max-lease-time 17600; - option domain-name "accounting.example.org"; - option domain-name-servers ns1.accounting.example.org, - ns2.accounting.example.org; - } elsif option dhcp-user-class = "sales" { - max-lease-time 17600; - option domain-name "sales.example.org"; - option domain-name-servers ns1.sales.example.org, - ns2.sales.example.org; - } elsif option dhcp-user-class = "engineering" { - max-lease-time 17600; - option domain-name "engineering.example.org"; - option domain-name-servers ns1.engineering.example.org, - ns2.engineering.example.org; - } else { - max-lease-time 600; - option domain-name "misc.example.org"; - option domain-name-servers ns1.misc.example.org, - ns2.misc.example.org; - } - - On the client side, an example of conditional evaluation - might be: - - # example.org filters DNS at its firewall, so we have to use their DNS - # servers when we connect to their network. If we are not at - # example.org, prefer our own DNS server. - if not option domain-name = "example.org" { - prepend domain-name-servers 127.0.0.1; - } - - The iiff statement and the eellssiiff continuation statement both - take boolean expressions as their arguments. That is, - they take expressions that, when evaluated, produce a - boolean result. If the expression evaluates to true, - - - - 1 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - then the statements enclosed in braces following the iiff - statement are executed, and all subsequent eellssiiff and eellssee - clauses are skipped. Otherwise, each subsequent eellssiiff - clause's expression is checked, until an elsif clause is - encountered whose test evaluates to true. If such a - clause is found, the statements in braces following it are - executed, and then any subsequent eellssiiff and eellssee clauses - are skipped. If all the iiff and eellssiiff clauses are checked - but none of their expressions evaluate true, then if there - is an eellssee clause, the statements enclosed in braces fol - lowing the eellssee are evaluated. Boolean expressions that - evaluate to null are treated as false in conditionals. - -BBOOOOLLEEAANN EEXXPPRREESSSSIIOONNSS - The following is the current list of boolean expressions - that are supported by the DHCP distribution. - - cchheecckk _c_l_a_s_s_-_n_a_m_e - - The check operator returns a true value if the packet - being considered comes from a client that falls into - the specified class. _C_l_a_s_s_-_n_a_m_e must be a string that - corresponds to the name of a defined class. Classes - are only supported in the DHCP server. - - _d_a_t_a_-_e_x_p_r_e_s_s_i_o_n_-_1 == _d_a_t_a_-_e_x_p_r_e_s_s_i_o_n_-_2 - - The == operator compares the values of two data expres - sions, returning true if they are the same, false if - they are not. If either the left-hand side or the - right-hand side are null, the result is also null. - - _b_o_o_l_e_a_n_-_e_x_p_r_e_s_s_i_o_n_-_1 aanndd _b_o_o_l_e_a_n_-_e_x_p_r_e_s_s_i_o_n_-_2 - - The aanndd operator evaluates to true if the boolean - expression on the left-hand side and the boolean - expression on the right-hand side both evaluate to - true. Otherwise, it evaluates to false. If either the - expression on the left-hand side or the expression on - the right-hand side are null, the result is null. - - _b_o_o_l_e_a_n_-_e_x_p_r_e_s_s_i_o_n_-_1 oorr _b_o_o_l_e_a_n_-_e_x_p_r_e_s_s_i_o_n_-_2 - - The oorr operator evaluates to true if either the boolean - expression on the left-hand side or the boolean expres - sion on the right-hand side evaluate to true. Other - wise, it evaluates to false. If either the expression - on the left-hand side or the expression on the right- - hand side are null, the result is null. - - nnoott _b_o_o_l_e_a_n_-_e_x_p_r_e_s_s_i_o_n - - The nnoott operator evaluates to true if _b_o_o_l_e_a_n_-_e_x_p_r_e_s_ - _s_i_o_n evaluates to false, and returns false if _b_o_o_l_e_a_n_- - - - - 2 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - _e_x_p_r_e_s_s_i_o_n evaluates to true. If _b_o_o_l_e_a_n_-_e_x_p_r_e_s_s_i_o_n - evaluates to null, the result is also null. - - eexxiissttss _o_p_t_i_o_n_-_n_a_m_e - - The eexxiissttss expression returns true if the specified - option exists in the incoming DHCP packet being pro - cessed. - kknnoowwnn - - The kknnoowwnn expression returns true if the client whose - request is currently being processed is known - that - is, if there's a host declaration for it. - ssttaattiicc - - The ssttaattiicc expression returns true if the lease - assigned to the client whose request is currently being - processed is derived from a static address assignment. - -DDAATTAA EEXXPPRREESSSSIIOONNSS - Several of the boolean expressions above depend on the - results of evaluating data expressions. A list of these - expressions is provided here. - - ssuubbssttrriinngg ((_d_a_t_a_-_e_x_p_r,, _o_f_f_s_e_t,, _l_e_n_g_t_h)) - - The ssuubbssttrriinngg operator evaluates the data expression - and returns the substring of the result of that evalua - tion that starts _o_f_f_s_e_t bytes from the beginning, con - tinuing for _l_e_n_g_t_h bytes. _O_f_f_s_e_t and _l_e_n_g_t_h are both - numeric expressions. If _d_a_t_a_-_e_x_p_r, _o_f_f_s_e_t or _l_e_n_g_t_h - evaluate to null, then the result is also null. If - _o_f_f_s_e_t is greater than or equal to the length of the - evaluated data, then a zero-length data string is - returned. If _l_e_n_g_t_h _i_s _g_r_e_a_t_e_r _t_h_e_n _t_h_e _r_e_m_a_i_n_i_n_g - _l_e_n_g_t_h _o_f _t_h_e _e_v_a_l_u_a_t_e_d _d_a_t_a _a_f_t_e_r _o_f_f_s_e_t, then a data - string containing all data from _o_f_f_s_e_t to the end of - the evaluated data is returned. - - ssuuffffiixx ((_d_a_t_a_-_e_x_p_r,, _l_e_n_g_t_h)) - - The ssuuffffiixx operator evaluates _d_a_t_a_-_e_x_p_r and returns the - last _l_e_n_g_t_h bytes of the result of that evaluation. - _L_e_n_g_t_h is a numeric expression. If _d_a_t_a_-_e_x_p_r or _l_e_n_g_t_h - evaluate to null, then the result is also null. If - _s_u_f_f_i_x evaluates to a number greater than the length of - the evaluated data, then the evaluated data is - returned. - - ooppttiioonn _o_p_t_i_o_n_-_n_a_m_e - - The ooppttiioonn operator returns the contents of the speci - fied option in the packet to which the server is - responding. - - - - 3 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - hhaarrddwwaarree - - The hhaarrddwwaarree operator returns a data string whose first - element is the type of network interface indicated in - packet being considered, and whose subsequent elements - are client's link-layer address. If there is no - packet, or if the RFC2131 _h_l_e_n field is invalid, then - the result is null. Hardware types include ethernet - (1), token-ring (6), and fddi (8). Hardware types are - specified by the IETF, and details on how the type num - bers are defined can be found in RFC2131 (in the ISC - DHCP distribution, this is included in the doc/ subdi - rectory). - - ppaacckkeett ((_o_f_f_s_e_t,, _l_e_n_g_t_h)) - - The ppaacckkeett operator returns the specified portion of - the packet being considered, or null in contexts where - no packet is being considered. _O_f_f_s_e_t and _l_e_n_g_t_h are - applied to the contents packet as in the ssuubbssttrriinngg - operator. - - _s_t_r_i_n_g - - A string, enclosed in quotes, may be specified as a - data expression, and returns the text between the - quotes, encoded in ASCII. - - _c_o_l_o_n_-_s_e_p_e_r_a_t_e_d _h_e_x_a_d_e_c_i_m_a_l _l_i_s_t - - A list of hexadecimal octet values, seperated by - colons, may be specified as a data expression. - - ccoonnccaatt ((_d_a_t_a_-_e_x_p_r_1,, ......,, _d_a_t_a_-_e_x_p_r_N)) - The expressions are evaluated, and the results of each - evaluation are concatenated in the sequence that the - subexpressions are listed. If any subexpression eval - uates to null, the result of the concatenation is null. - - rreevveerrssee ((_n_u_m_e_r_i_c_-_e_x_p_r_1,, _d_a_t_a_-_e_x_p_r_2)) - The two expressions are evaluated, and then the result - of evaluating the data expression is reversed in place, - using hunks of the size specified in the numeric - expression. For example, if the numeric expression - evaluates to four, and the data expression evaluates to - twelve bytes of data, then the reverse expression will - evaluate to twelve bytes of data, consisting of the - last four bytes of the the input data, followed by the - middle four bytes, followed by the first four bytes. - - lleeaasseedd--aaddddrreessss - In any context where the client whose request is being - processed has been assigned an IP address, this data - expression returns that IP address. - - - - 4 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - bbiinnaarryy--ttoo--aasscciiii ((_n_u_m_e_r_i_c_-_e_x_p_r_1,, _n_u_m_e_r_i_c_-_e_x_p_r_2,, _d_a_t_a_-_e_x_p_r_1,, - _d_a_t_a_-_e_x_p_r_2)) - Converts the result of evaluating data-expr2 into a - text string containing one number for each element of - the result of evaluating data-expr2. Each number is - seperated from the other by the result of evaluating - data-expr1. The result of evaluating numeric-expr1 - specifies the base (2 through 16) into which the num - bers should be converted. The result of evaluating - numeric-expr2 specifies the width in bits of each num - ber, which may be either 8, 16 or 32. - - As an example of the preceding three types of expres - sions, to produce the name of a PTR record for the IP - address being assigned to a client, one could write the - following expression: - - concat (binary-to-ascii (10, 8, ".", - reverse (1, leased-address)), - ".in-addr.arpa."); - - - eennccooddee--iinntt ((_n_u_m_e_r_i_c_-_e_x_p_r,, _w_i_d_t_h)) - Numeric-expr is evaluated and encoded as a data string - of the specified width, in network byte order (most - significant byte first). If the numeric expression - evaluates to the null value, the result is also null. - - ppiicckk--ffiirrsstt--vvaalluuee ((_d_a_t_a_-_e_x_p_r_1 [ ... _e_x_p_rn ] )) - The pick-first-value function takes any number of - data expressions as its arguments. Each expression - is evaluated, starting with the first in the list, - until an expression is found that does not evaluate - to a null value. That expression is returned, and - none of the subsequent expressions are evaluated. - If all expressions evaluate to a null value, the null - value is returned. - - hhoosstt--ddeeccll--nnaammee - The host-decl-name function returns the name of the - host declaration that matched the client whose - request is currently being processed, if any. If no - host declaration matched, the result is the null - value. - -NNUUMMEERRIICC EEXXPPRREESSSSIIOONNSS - Numeric expressions are expressions that evaluate to an - integer. In general, the maximum size of such an integer - should not be assumed to be representable in fewer than 32 - bits, but the precision of such integers may be more than - 32 bits. - - eexxttrraacctt--iinntt ((_d_a_t_a_-_e_x_p_r,, _w_i_d_t_h)) - - - - - 5 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - The eexxttrraacctt--iinntt operator extracts an integer value in - network byte order from the result of evaluating the - specified data expression. Width is the width in bits - of the integer to extract. Currently, the only sup - ported widths are 8, 16 and 32. If the evaluation of - the data expression doesn't provide sufficient bits to - extract an integer of the specified size, the null - value is returned. - - lleeaassee--ttiimmee - - The duration of the current lease - that is, the dif - ference between the current time and the time that the - lease expires. - - _n_u_m_b_e_r - - Any number between zero and the maximum representable - size may be specified as a numeric expression. - -RREEFFEERREENNCCEE:: DDYYNNAAMMIICC DDNNSS UUPPDDAATTEESS - The DHCP client and server have the ability to dynamically - update the Domain Name System. Within the configuration - files, you can define how you want the Domain Name System - to be updated. These updates are RFC 2136 compliant so - any DNS server supporting RFC 2136 should be able to - accept updates from the DHCP server. - -SSEECCUURRIITTYY - Support for TSIG and DNSSEC is not yet available. When - you set your DNS server up to allow updates from the DHCP - server or client, you may be exposing it to unauthorized - updates. To avoid this, the best you can do right now is - to use IP address-based packet filtering to prevent unau - thorized hosts from submitting update requests. Obvi - ously, there is currently no way to provide security for - client updates - this will require TSIG or DNSSEC, neither - of which is yet available in the DHCP distribution. - - Dynamic DNS (DDNS) updates are performed by using the ddnnss-- - uuppddaattee expression. The ddnnss--uuppddaattee expression is a boolean - expression that takes four parameters. If the update suc - ceeds, the result is true. If it fails, the result is - false. The four parameters that the are the resource - record type (RR), the left hand side of the RR, the right - hand side of the RR and the ttl that should be applied to - the record. The simplest example of the use of the func - tion can be found in the reference section of the - dhcpd.conf file, where events are described. In this - example several statements are being used to make the - arguments to the ddnnss--uuppddaatteeRR.. - - In the example, the first argument to the first Bdns- - update expression is a data expression that evaluates to - - - - 6 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - the A RR type. The second argument is constructed by con - catenating the DHCP host-name option with a text string - containing the local domain, in this case "ssd.exam - ple.net". The third argument is constructed by converting - the address the client has been assigned from a 32-bit - number into an ascii string with each byte separated by a - ".". The fourth argument, the TTL, specifies the amount - of time remaining in the lease (note that this isn't - really correct, since the DNS server will pass this TTL - out whenever a request comes in, even if that is only a - few seconds before the lease expires). - - If the first ddnnss--uuppddaattee statement succeeds, it is followed - up with a second update to install a PTR RR. The instal - lation of a PTR record is similar to installing an A RR - except that the left hand side of the record is the leased - address, reversed, with ".in-addr.arpa" concatenated. The - right hand side is the fully qualified domain name of the - client to which the address is being leased. - -SSEEEE AALLSSOO - dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp- - eval(5), dhcpd(8), dhclient(8), RFC2132, RFC2131. - -AAUUTTHHOORR - The Internet Software Consortium DHCP Distribution was - written by Ted Lemon <mellon@isc.org> under a contract - with Vixie Labs. Funding for this project was provided - through the Internet Software Consortium. Information - about the Internet Software Consortium can be found at - hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - - - - - - - - - - - - 7 - - diff --git a/common/dhcp-options.cat5 b/common/dhcp-options.cat5 deleted file mode 100644 index c87cb22e..00000000 --- a/common/dhcp-options.cat5 +++ /dev/null @@ -1,1188 +0,0 @@ - - - -dhcpd-options(5) dhcpd-options(5) - - -NNAAMMEE - dhcp-options - Dynamic Host Configuration Protocol options - -DDEESSCCRRIIPPTTIIOONN - The Dynamic Host Configuration protocol allows the client - to receive ooppttiioonnss from the DHCP server describing the - network configuration and various services that are avail - able on the network. When configuring ddhhccppdd((88)) or - ddhhcclliieenntt((88)) ,, options must often be declared. The syntax - for declaring options, and the names and formats of the - options that can be declared, are documented here. - -RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS - DHCP _o_p_t_i_o_n statements always start with the _o_p_t_i_o_n key - word, followed by an option name, followed by option data. - The option names and data formats are described below. - It is not necessary to exhaustively specify all DHCP - options - only those options which are needed by clients - must be specified. - - Option data comes in a variety of formats, as defined - below: - - The iipp--aaddddrreessss data type can be entered either as an - explicit IP address (e.g., 239.254.197.10) or as a domain - name (e.g., haagen.isc.org). When entering a domain name, - be sure that that domain name resolves to a single IP - address. - - The iinntt3322 data type specifies a signed 32-bit integer. - The uuiinntt3322 data type specifies an unsigned 32-bit integer. - The iinntt1166 and uuiinntt1166 data types specify signed and - unsigned 16-bit integers. The iinntt88 and uuiinntt88 data types - specify signed and unsigned 8-bit integers. Unsigned - 8-bit integers are also sometimes referred to as octets. - - The tteexxtt data type specifies an NVT ASCII string, which - must be enclosed in double quotes - for example, to spec - ify a domain-name option, the syntax would be - - option domain-name "isc.org"; - - The ffllaagg data type specifies a boolean value. Booleans - can be either true or false (or on or off, if that makes - more sense to you). - - The ssttrriinngg data type specifies either an NVT ASCII string - enclosed in double quotes, or a series of octets specified - in hexadecimal, seperated by colons. For example: - - option dhcp-client-identifier "CLIENT-FOO"; - or - option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f; - - - - - 1 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - The documentation for the various options mentioned below - is taken from the latest IETF draft document on DHCP - options. Options which are not listed by name may be - defined by the name option-_n_n_n, where _n_n_n is the decimal - number of the option code. These options may be followed - either by a string, enclosed in quotes, or by a series of - octets, expressed as two-digit hexadecimal numbers seper - ated by colons. For example: - - option option-133 "my-option-133-text"; - option option-129 1:54:c9:2b:47; - - Because dhcpd does not know the format of these undefined - option codes, no checking is done to ensure the correct - ness of the entered data. - - The standard options are: - - ooppttiioonn aallll--ssuubbnneettss--llooccaall _f_l_a_g;; - - This option specifies whether or not the client may - assume that all subnets of the IP network to which the - client is connected use the same MTU as the subnet of - that network to which the client is directly connected. - A value of true indicates that all subnets share the - same MTU. A value of false means that the client - should assume that some subnets of the directly con - nected network may have smaller MTUs. - - ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2;; - - This option specifies the timeout in seconds for ARP - cache entries. - - ooppttiioonn bboooottffiillee--nnaammee _t_e_x_t;; - - This option is used to identify a bootstrap file. If - supported by the client, it should have the same effect - as the ffiilleennaammee declaration. BOOTP clients are - unlikely to support this option. Some DHCP clients - will support it, and others actually require it. - - ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6;; - - This option specifies the length in 512-octet blocks of - the default boot image for the client. - - ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; - - This option specifies the broadcast address in use on - the client's subnet. Legal values for broadcast - addresses are specified in section 3.2.1.3 of STD 3 - (RFC1122). - - - - - 2 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The cookie server option specifies a list of RFC 865 - cookie servers available to the client. Servers should - be listed in order of preference. - - ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8_; - - This option specifies the default time-to-live that the - client should use on outgoing datagrams. - - ooppttiioonn ddeeffaauulltt--ttccpp--ttttll _u_i_n_t_8;; - - This option specifies the default TTL that the client - should use when sending TCP segments. The minimum - value is 1. - - ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _s_t_r_i_n_g;; - - This option can be used to specify the a DHCP client - identifier in a host declaration, so that dhcpd can - find the host record by matching against the client - identifier. - - ooppttiioonn ddhhccpp--mmaaxx--mmeessssaaggee--ssiizzee _u_i_n_t_1_6;; - - This option, when sent by the client, specifies the - maximum size of any response that the server sends to - the client. When specified on the server, if the - client did not send a dhcp-max-message-size option, the - size specified on the server is used. This works for - BOOTP as well as DHCP responses. - - ooppttiioonn ddhhccpp--ppaarraammeetteerr--rreeqquueesstt--lliisstt _u_i_n_t_1_6;; - - This option, when sent by the client, specifies which - options the client wishes the server to return. Nor - mally, in the ISC DHCP client, this is done using the - _r_e_q_u_e_s_t statement. If this option is not specified by - the client, the DHCP server will normally return every - option that is valid in scope and that fits into the - reply. When this option is specified on the server, - the server returns the specified options. This can be - used to force a client to take options that it hasn't - requested, and it can also be used to tailor the - response of the DHCP server for clients that may need a - more limited set of options than those the server would - normally return. - - ooppttiioonn ddoommaaiinn--nnaammee _t_e_x_t;; - - This option specifies the domain name that client - should use when resolving hostnames via the Domain Name - System. - - - - 3 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - ooppttiioonn ddoommaaiinn--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The domain-name-servers option specifies a list of - Domain Name System (STD 13, RFC 1035) name servers - available to the client. Servers should be listed in - order of preference. - - ooppttiioonn eexxtteennssiioonnss--ppaatthh--nnaammee _t_e_x_t;; - - This option specifies the name of a file containing - additional options to be interpreted according to the - DHCP option format as specified in RFC2132. - - ooppttiioonn ffiinnggeerr--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The Finger server option specifies a list of Finger - available to the client. Servers should be listed in - order of preference. - - ooppttiioonn ffoonntt--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This option specifies a list of X Window System Font - servers available to the client. Servers should be - listed in order of preference. - - ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g;; - - This option specifies the name of the client. The name - may or may not be qualified with the local domain name - (it is preferable to use the domain-name option to - specify the domain name). See RFC 1035 for character - set restrictions. - - ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g;; - - This option specifies whether or not the client should - use Ethernet Version 2 (RFC 894) or IEEE 802.3 (RFC - 1042) encapsulation if the interface is an Ethernet. A - value of false indicates that the client should use RFC - 894 encapsulation. A value of true means that the - client should use RFC 1042 encapsulation. - - ooppttiioonn iieenn111166--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ]; - - The ien116-name-servers option specifies a list of IEN - 116 name servers available to the client. Servers - should be listed in order of preference. - - ooppttiioonn iimmpprreessss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The impress-server option specifies a list of Imagen - Impress servers available to the client. Servers - should be listed in order of preference. - - - - - 4 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - ooppttiioonn iinntteerrffaaccee--mmttuu _u_i_n_t_1_6;; - - This option specifies the MTU to use on this interface. - The minimum legal value for the MTU is 68. - - ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g;; - - This option specifies whether the client should config - ure its IP layer for packet forwarding. A value of - false means disable IP forwarding, and a value of true - means enable IP forwarding. - - ooppttiioonn iirrcc--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The IRC server option specifies a list of IRC available - to the client. Servers should be listed in order of - preference. - - ooppttiioonn lloogg--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - 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. - - ooppttiioonn llpprr--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The LPR server option specifies a list of RFC 1179 line - printer servers available to the client. Servers - should be listed in order of preference. - - ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g;; - - This option specifies whether or not the client should - respond to subnet mask requests using ICMP. A value of - false indicates that the client should not respond. A - value of true means that the client should respond. - - ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6;; - - This option specifies the maximum size datagram that - the client should be prepared to reassemble. The mini - mum value legal value is 576. - - ooppttiioonn mmeerriitt--dduummpp _t_e_x_t;; - - 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 charac - ter string consisting of characters from the NVT ASCII - character set. - - ooppttiioonn mmoobbiillee--iipp--hhoommee--aaggeenntt _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This option specifies a list of IP addresses indicating - - - - 5 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - mobile IP home agents available to the client. Agents - should be listed in order of preference, although nor - mally there will be only one such agent. - - ooppttiioonn nnddss--ccoonntteexxtt _s_t_r_i_n_g;; - - The nds-context option specifies the name of the ini - tial Netware Directory Service for an NDS client. - - ooppttiioonn nnddss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The nds-servers option specifies a list of IP addresses - of NDS servers. - - ooppttiioonn nnddss--ttrreeee--nnaammee _s_t_r_i_n_g;; - - The nds-context option specifies NDS tree name that the - NDS client should use. - - ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The NetBIOS datagram distribution server (NBDD) option - specifies a list of RFC 1001/1002 NBDD servers listed - in order of preference. - - ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s...];; - - The NetBIOS name server (NBNS) option specifies a list - of RFC 1001/1002 NBNS name servers listed in order of - preference. NetBIOS Name Service is currently more - commonly referred to as WINS. WINS servers can be - specified using the netbios-name-servers option. - - ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8;; - - The NetBIOS node type option allows NetBIOS over TCP/IP - clients which are configurable to be configured as - described in RFC 1001/1002. The value is specified as - a single octet which identifies the client type. - - Possible node types are: - - - _1 B-node: Broadcast - no WINS - - _2 P-node: Peer - WINS only. - - _4 M-node: Mixed - broadcast, then WINS - - _8 H-node: Hybrid - WINS, then broadcast - - ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g;; - - The NetBIOS scope option specifies the NetBIOS over - - - - 6 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - TCP/IP scope parameter for the client as specified in - RFC 1001/1002. See RFC1001, RFC1002, and RFC1035 for - character-set restrictions. - - ooppttiioonn nnwwiipp--ddoommaaiinn _s_t_r_i_n_g;; - - The name of the NetWare/IP domain that a NetWare/IP - client should use. - - ooppttiioonn nnwwiipp--ssuubbooppttiioonnss _s_t_r_i_n_g;; - - A sequence of suboptions for NetWare/IP clients - see - RFC2242 for details. Normally this option is set by - specifying specific NetWare/IP suboptions - see the - NETWARE/IP SUBOPTIONS section for more information. - - ooppttiioonn nniiss--ddoommaaiinn _t_e_x_t;; - - This option specifies the name of the client's NIS (Sun - Network Information Services) domain. The domain is - formatted as a character string consisting of charac - ters from the NVT ASCII character set. - - ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This option specifies a list of IP addresses indicating - NIS servers available to the client. Servers should be - listed in order of preference. - - ooppttiioonn nniisspplluuss--ddoommaaiinn _t_e_x_t;; - - This option specifies the name of the client's NIS+ - domain. The domain is formatted as a character string - consisting of characters from the NVT ASCII character - set. - - ooppttiioonn nniisspplluuss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This option specifies a list of IP addresses indicating - NIS+ servers available to the client. Servers should - be listed in order of preference. - - ooppttiioonn nnnnttpp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The NNTP server option specifies a list of NNTP avail - able to the client. Servers should be listed in order - of preference. - - ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g;; - - This option specifies whether the client should config - ure 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 - - - - 7 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - forwarding of such datagrams, and a value of true means - allow forwarding. - - ooppttiioonn nnttpp--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This option specifies a list of IP addresses indicating - NTP (RFC 1035) servers available to the client. - Servers should be listed in order of preference. - - ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2;; - - This option specifies the timeout (in seconds) to use - when aging Path MTU values discovered by the mechanism - defined in RFC 1191. - - ooppttiioonn ppaatthh--mmttuu--ppllaatteeaauu--ttaabbllee _u_i_n_t_1_6 [,, _u_i_n_t_1_6... ];; - - 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 mini - mum MTU value cannot be smaller than 68. - - ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g;; - - This option specifies whether or not the client should - perform subnet mask discovery using ICMP. A value of - false indicates that the client should not perform mask - discovery. A value of true means that the client - should perform mask discovery. - - ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s - [,, _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s...];; - - 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. - - See STD 3 (RFC1122) for further information. - - ooppttiioonn ppoopp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The POP3 server option specifies a list of POP3 avail - able to the client. Servers should be listed in order - of preference. - - ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s - [,, _i_p_-_a_d_d_r_e_s_s...];; - - - - - 8 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - This option specifies a list of RFC 887 Resource Loca - tion servers available to the client. Servers should - be listed in order of preference. - - ooppttiioonn rroooott--ppaatthh _t_e_x_t;; - - This option specifies the path-name that contains the - client's root disk. The path is formatted as a charac - ter string consisting of characters from the NVT ASCII - character set. - - ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g;; - - This option specifies whether or not the client should - solicit routers using the Router Discovery mechanism - defined in RFC 1256. A value of false indicates that - the client should not perform router discovery. A - value of true means that the client should perform - router discovery. - - ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; - - This option specifies the address to which the client - should transmit router solicitation requests. - - ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The routers option specifies a list of IP addresses for - routers on the client's subnet. Routers should be - listed in order of preference. - - ooppttiioonn ssmmttpp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The SMTP server option specifies a list of SMTP servers - available to the client. Servers should be listed in - order of preference. - - ooppttiioonn ssttaattiicc--rroouutteess _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s - [,, _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s...];; - - This option specifies a list of static routes that the - client should install in its routing cache. If multi - ple 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 sec - ond address is the router for the destination. - - The default route (0.0.0.0) is an illegal destination - for a static route. To specify the default route, use - the rroouutteerrss option. Also, please note that this - option is not intended for classless IP routing - it - does not include a subnet mask. Since classless IP - - - - 9 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - routing is now the most widely deployed routing stan - dard, this option is virtually useless, and is not - implemented by any of the popular DHCP clients, for - example the Microsoft DHCP client. - - ooppttiioonn ssttrreeeettttaallkk--ddiirreeccttoorryy--aassssiissttaannccee--sseerrvveerr _i_p_-_a_d_d_r_e_s_s - [,, _i_p_-_a_d_d_r_e_s_s...];; - - The StreetTalk Directory Assistance (STDA) server - option specifies a list of STDA servers available to - the client. Servers should be listed in order of pref - erence. - - ooppttiioonn ssttrreeeettttaallkk--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The StreetTalk server option specifies a list of - StreetTalk servers available to the client. Servers - should be listed in order of preference. - - ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s;; - - The subnet mask option specifies the client's subnet - mask as per RFC 950. If no subnet mask option is pro - vided anywhere in scope, as a last resort dhcpd will - use the subnet mask from the subnet declaration for the - network on which an address is being assigned. How - ever, _a_n_y subnet-mask option declaration that is in - scope for the address being assigned will override the - subnet mask specified in the subnet declaration. - - ooppttiioonn sswwaapp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s;; - - This specifies the IP address of the client's swap - server. - - ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g;; - - This option specifies the whether or not the client - should send TCP keepalive messages with a octet of - garbage for compatibility with older implementations. - A value of false indicates that a garbage octet should - not be sent. A value of true indicates that a garbage - octet should be sent. - - ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2;; - - This option specifies the interval (in seconds) that - the client TCP should wait before sending a keepalive - message on a TCP connection. The time is specified as - a 32-bit unsigned integer. A value of zero indicates - that the client should not generate keepalive messages - on connections unless specifically requested by an - application. - - - - - 10 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - ooppttiioonn ttffttpp--sseerrvveerr--nnaammee _t_e_x_t;; - - This option is used to identify a TFTP server and, if - supported by the client, should have the same effect as - the sseerrvveerr--nnaammee declaration. BOOTP clients are - unlikely to support this option. Some DHCP clients - will support it, and others actually require it. - - ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2;; - - The time-offset option specifies the offset of the - client's subnet in seconds from Coordinated Universal - Time (UTC). - - ooppttiioonn ttiimmee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [, _i_p_-_a_d_d_r_e_s_s... ];; - - The time-server option specifies a list of RFC 868 time - servers available to the client. Servers should be - listed in order of preference. - - ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g;; - - 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 - true means that the client should attempt to use trail - ers. - - ooppttiioonn uuaapp--sseerrvveerrss _t_e_x_t;; - - This option specifies a list of URLs, each pointing to - a user authentication service that is capable of pro - cessing authentication requests encapsulated in the - User Authentication Protocol (UAP). UAP servers can - accept either HTTP 1.1 or SSLv3 connections. If the - list includes a URL that does not contain a port compo - nent, the normal default port is assumed (i.e., port 80 - for http and port 443 for https). If the list includes - a URL that does not contain a path component, the path - /uap is assumed. If more than one URL is specified in - this list, the URLs are seperated by spaces. - - ooppttiioonn vveennddoorr--ccllaassss--iiddeennttiiffiieerr _s_t_r_i_n_g;; - - This option is used by some DHCP clients to identify - the vendor type and possibly the configuration of a - DHCP client. The information is a string of bytes - whose contents are specific to the vendor and are not - specified in a standard. To see what vendor class - identifier a clients are sending, you can write the - following in your DHCP server configuration file: - - set vendor-class option vendor-class-identifier; - - - - 11 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - This will result in all entries in the DHCP server - lease database file for clients that sent vendor-class- - identifier options having a set statement that looks - something like this: - - set vendor-class "SUNW.Ultra-5_10"; - - The vendor-class-identifier option is normally used by - the DHCP server to determine the options that are - returned in the vveennddoorr--eennccaappssuullaatteedd--ooppttiioonnss option. - Please see the VENDOR ENCAPSULATED OPTIONS section of - the dhcpd.conf manual page for further information. - - ooppttiioonn vveennddoorr--eennccaappssuullaatteedd--ooppttiioonnss _s_t_r_i_n_g;; - - The vveennddoorr--eennccaappssuullaatteedd--ooppttiioonnss option can contain - either a single vendor-specific value or one or more - vendor-specific suboptions. This option is not nor - mally specified in the DHCP server configuration file - - instead, a vendor class is defined for each vendor, - vendor class suboptions are defined, values for those - suboptions are defined, and the DHCP server makes up a - response on that basis. - - Some default behaviours for well-known DHCP client ven - dors (currently, the Microsoft Windows 2000 DHCP - client) are configured automatically, but otherwise - this must be configured manually - see the VENDOR - ENCAPSULATED OPTIONS section of the _d_h_c_p_d_._c_o_n_f _m_a_n_u_a_l - _p_a_g_e _f_o_r _d_e_t_a_i_l_s_. - - ooppttiioonn xx--ddiissppllaayy--mmaannaaggeerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This option specifies a list of systems that are run - ning the X Window System Display Manager and are avail - able to the client. Addresses should be listed in - order of preference. - - ooppttiioonn wwwwww--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - The WWW server option specifies a list of WWW available - to the client. Servers should be listed in order of - preference. - -RREELLAAYY AAGGEENNTT IINNFFOORRMMAATTIIOONN OOPPTTIIOONN - An IETF draft, draft-ietf-dhc-agent-options-03.txt, - defines a series of encapsulated options that a relay - agent can add to a DHCP packet when relaying it to the - DHCP server. The server can then make address allocation - decisions (or whatever other decisions it wants) based on - these options. The server also returns these options in - any replies it sends through the relay agent, so that the - relay agent can use the information in these options for - delivery or accounting purposes. - - - - 12 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - The current draft defines two options. To reference - these options in the dhcp server, specify the option space - name, "agent", followed by a period, followed by the - option name. It isn't useful to specify these options to - be sent, nor is it useful to reference them at all in the - client. - - ooppttiioonn aaggeenntt..cciirrccuuiitt--iidd _s_t_r_i_n_g;; - - The circuit-id suboption encodes an agent-local identi - fier of the circuit from which a DHCP client-to-server - packet was received. It is intended for use by agents - in relaying DHCP responses back to the proper circuit. - The format of this option is currently defined to be - vendor-dependent, and will probably remain that way, - although the current draft allows for for the possibil - ity of standardizing the format in the future. - - ooppttiioonn aaggeenntt..rreemmoottee--iidd _s_t_r_i_n_g;; - - The remote-id suboption encodes information about the - remote host end of a circuit. Examples of what it - might contain include caller ID information, username - information, remote ATM address, cable modem ID, and - similar things. In principal, the meaning is not - well-specified, and it should generally be assumed to - be an opaque object that is administratively guaranteed - to be unique to a particular remote end of a circuit. - -TTHHEE NNEETTWWAARREE//IIPP SSUUBBOOPPTTIIOONNSS - RFC2242 defines a set of encapsulated options for Novell - NetWare/IP clients. To use these options in the dhcp - server, specify the option space name, "nwip", followed by - a period, followed by the option name. The following - options can be specified: - - ooppttiioonn nnwwiipp..nnssqq--bbrrooaaddccaasstt _f_l_a_g;; - - If true, the client should use the NetWare Nearest - Server Query to locate a NetWare/IP server. The - behaviour of the Novell client if this suboption is - false, or is not present, is not specified. - - ooppttiioonn nnwwiipp..pprreeffeerrrreedd--ddssss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; - - This suboption specifies a list of up to five IP - addresses, each of which should be the IP address of a - NetWare Domain SAP/RIP server (DSS). - - ooppttiioonn nnwwiipp..nneeaarreesstt--nnwwiipp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s - [,, _i_p_-_a_d_d_r_e_s_s...];; - - This suboption specifies a list of up to five IP - addresses, each of which should be the IP address of a - - - - 13 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - Nearest NetWare IP server. - - ooppttiioonn nnwwiipp..aauuttoorreettrriieess _u_i_n_t_8;; - - Specifies the number of times that a NetWare/IP client - should attempt to communicate with a given DSS server - at startup. - - ooppttiioonn nnwwiipp..aauuttoorreettrryy--sseeccss _u_i_n_t_8;; - - Specifies the number of seconds that a Netware/IP - client should wait between retries when attempting to - establish communications with a DSS server at startup. - - ooppttiioonn nnwwiipp..nnwwiipp--11--11 _u_i_n_t_8;; - - If true, the NetWare/IP client should support Net - Ware/IP version 1.1 compatibility. This is only - needed if the client will be contacting Netware/IP ver - sion 1.1 servers. - - ooppttiioonn nnwwiipp..pprriimmaarryy--ddssss _i_p_-_a_d_d_r_e_s_s;; - - Specifies the IP address of the Primary Domain SAP/RIP - Service server (DSS) for this NetWare/IP domain. The - NetWare/IP administration utility uses this value as - Primary DSS server when configuring a secondary DSS - server. - -DDEEFFIINNIINNGG NNEEWW OOPPTTIIOONNSS - The Internet Software Consortium DHCP client and server - provide the capability to define new options. Each DHCP - option has a name, a code, and a structure. The name is - used by you to refer to the option. The code is a num - ber, used by the DHCP server and client to refer to an - option. The structure describes what the contents of an - option looks like. - - To define a new option, you need to choose a name for it - that is not in use for some other option - for example, - you can't use "host-name" because the DHCP protocol - already defines a host-name option, which is documented - earlier in this manual page. If an option name doesn't - appear in this manual page, you can use it, but it's prob - ably a good idea to put some kind of unique string at the - beginning so you can be sure that future options don't - take your name. For example, you might define an option, - "local-host-name", feeling some confidence that no offi - cial DHCP option name will ever start with "local". - - Once you have chosen a name, you must choose a code. For - site-local options, all codes between 128 and 254 are - reserved for DHCP options, so you can pick any one of - these. In practice, some vendors have interpreted the - - - - 14 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - protocol rather loosely and have used option code values - greater than 128 themselves. There's no real way to - avoid this problem, but it's not likely to cause too much - trouble in practice. - - The structure of an option is simply the format in which - the option data appears. The ISC DHCP server currently - supports a few simple types, like integers, booleans, - strings and IP addresses, and it also supports the ability - to define arrays of single types or arrays of fixed - sequences of types. - - New options are declared as follows: - - ooppttiioonn _n_e_w_-_n_a_m_e ccooddee _n_e_w_-_c_o_d_e == _d_e_f_i_n_i_t_i_o_n ;; - - The values of _n_e_w_-_n_a_m_e and _n_e_w_-_c_o_d_e should be the name you - have chosen for the new option and the code you have cho - sen. The _d_e_f_i_n_i_t_i_o_n should be the definition of the - structure of the option. - - The following simple option type definitions are sup - ported: - - BBOOOOLLEEAANN - - ooppttiioonn _n_e_w_-_n_a_m_e ccooddee _n_e_w_-_c_o_d_e == bboooolleeaann ;; - - An option of type boolean is a flag with a value of either - on or off (or true or false). So an example use of the - boolean type would be: - - option use-zephyr code 180 = boolean; - option use-zephyr on; - - IINNTTEEGGEERR - - ooppttiioonn _n_e_w_-_n_a_m_e ccooddee _n_e_w_-_c_o_d_e == _s_i_g_n iinntteeggeerr _w_i_d_t_h ;; - - The _s_i_g_n token should either be blank, _u_n_s_i_g_n_e_d or _s_i_g_n_e_d. - The width can be either 8, 16 or 32, and refers to the - number of bits in the integer. So for example, the fol - lowing two lines show a definition of the sql-connection- - max option and its use: - - option sql-connection-max code 192 = unsigned integer 16; - option sql-connection-max 1536; - - IIPP--AADDDDRREESSSS - - ooppttiioonn _n_e_w_-_n_a_m_e ccooddee _n_e_w_-_c_o_d_e == iipp--aaddddrreessss ;; - - An option whose structure is an IP address can be - expressed either as a domain name or as a dotted quad. So - - - - 15 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - the following is an example use of the ip-address type: - - option sql-server-address code 193 = ip-address; - option sql-server-address sql.example.com; - - - TTEEXXTT - - ooppttiioonn _n_e_w_-_n_a_m_e ccooddee _n_e_w_-_c_o_d_e == tteexxtt ;; - - An option whose type is text will encode an ASCII text - string. For example: - - option sql-default-connection-name code 194 = text; - option sql-default-connection-name "PRODZA"; - - - DDAATTAA SSTTRRIINNGG - - ooppttiioonn _n_e_w_-_n_a_m_e ccooddee _n_e_w_-_c_o_d_e == ssttrriinngg ;; - - An option whose type is a data string is essentially just - a collection of bytes, and can be specified either as - quoted text, like the text type, or as a list of hexadeci - mal contents seperated by colons whose values must be - between 0 and FF. For example: - - option sql-identification-token code 195 = string; - option sql-identification-token 17:23:19:a6:42:ea:99:7c:22; - - - AARRRRAAYYSS - - Options can contain arrays of any of the above types - except for the text and data string types, which aren't - currently supported in arrays. An example of an array - definition is as follows: - - option kerberos-servers code 200 = array of ip-address; - option kerberos-servers 10.20.10.1, 10.20.11.1; - - RREECCOORRDDSS - - Options can also contain data structures consisting of a - sequence of data types, which is sometimes called a record - type. For example: - - option contrived-001 code 201 = { boolean, integer 32, text }; - option contrived-001 on 1772 "contrivance"; - - It's also possible to have options that are arrays of - records, for example: - - option new-static-routes code 201 = array of { - - - - 16 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - ip-address, ip-address, ip-address, integer 8 }; - option static-routes - 10.0.0.0 255.255.255.0 net-0-rtr.example.com 1, - 10.0.1.0 255.255.255.0 net-1-rtr.example.com 1, - 10.2.0.0 255.255.224.0 net-2-0-rtr.example.com 3; - - -VVEENNDDOORR EENNCCAAPPSSUULLAATTEEDD OOPPTTIIOONNSS - The DHCP protocol defines the vveennddoorr--eennccaappssuullaatteedd--ooppttiioonnss - option, which allows vendors to define their own options - that will be sent encapsulated in a standard DHCP option. - The format of the vveennddoorr--eennccaappssuullaatteedd--ooppttiioonnss option is - either a series of bytes whose format is not specified, or - a sequence of options, each of which consists of a single- - byte vendor-specific option code, followed by a single- - byte length, followed by as many bytes of data as are - specified in the length (the length does not include - itself or the option code). - - The value of this option can be set in one of two ways. - The first way is to simply specify the data directly, - using a text string or a colon-seperated list of hexadeci - mal values. For example: - - option vendor-encapsulated-options - 2:4:AC:11:41:1: - 3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31: - 4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63; - - The second way of setting the value of this option is to - have the DHCP server generate a vendor-specific option - buffer. To do this, you must do four things: define an - option space, define some options in that option space, - provide values for them, and specify that that option - space should be used to generate the vveennddoorr--eennccaappssuullaatteedd-- - ooppttiioonnss option. - - To define a new option space in which vendor options can - be stored, use the option space statement: - - ooppttiioonn ssppaaccee _n_a_m_e ;; - - The name can then be used in option definitions, as - described earlier in this document. For example: - - option space SUNW; - option SUNW.server-address code 2 = ip-address; - option SUNW.server-name code 3 = text; - option SUNW.root-path code 4 = text; - - Once you have defined an option space and the format of - some options, you can set up scopes that define values for - those options, and you can say when to use them. For - example, suppose you want to handle two different classes - - - - 17 - - - - - -dhcpd-options(5) dhcpd-options(5) - - - of clients. Using the option space definition shown in - the previous example, you can send different option values - to different clients based on the vendor-class-identifier - option that the clients send, as follows: - - class "vendor-classes" { - match option vendor-class-identifier; - } - - option SUNW.server-address 172.17.65.1; - option SUNW.server-name "sundhcp-server17-1"; - - subclass "vendor-classes" "SUNW.Ultra-5_10" { - vendor-option-space SUNW; - option SUNW.root-path "/export/root/sparc"; - } - - subclass "vendor-classes" "SUNW.i86pc" { - vendor-option-space SUNW; - option SUNW.root-path "/export/root/i86pc"; - } - - As you can see in the preceding example, regular scoping - rules apply, so you can define values that are global in - the global scope, and only define values that are specific - to a particular class in the local scope. The vveennddoorr-- - ooppttiioonn--ssppaaccee declaration tells the DHCP server to use - options in the SUNW option space to construct the vveennddoorr-- - eennccaappssuullaatteedd--ooppttiioonnss option. - -SSEEEE AALLSSOO - dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp- - eval(5), dhcpd(8), dhclient(8), RFC2132, RFC2131, draft- - ietf-dhc-agent-options-??.txt. - -AAUUTTHHOORR - The Internet Software Consortium DHCP Distribution was - written by Ted Lemon <mellon@isc.org> under a contract - with Vixie Labs. Funding for this project was provided - through the Internet Software Consortium. Information - about the Internet Software Consortium can be found at - hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - 18 - - diff --git a/relay/dhcrelay.cat8 b/relay/dhcrelay.cat8 deleted file mode 100644 index 7fc01a72..00000000 --- a/relay/dhcrelay.cat8 +++ /dev/null @@ -1,264 +0,0 @@ - - - -dhcrelay(8) dhcrelay(8) - - -NNAAMMEE - dhcrelay - Dynamic Host Configuration Protocol Relay Agent - -SSYYNNOOPPSSIISS - ddhhccrreellaayy [ --pp _p_o_r_t ] [ --dd ] [ --qq ] [ --ii _i_f_0 [ ...... --ii _i_f_N - ] ] [ --aa ] [ --AA _l_e_n_g_t_h ] [ --DD ] [ --mm _a_p_p_e_n_d | _r_e_p_l_a_c_e | - _f_o_r_w_a_r_d | _d_i_s_c_a_r_d ] _s_e_r_v_e_r_0 [ _._._._s_e_r_v_e_r_N ] - -DDEESSCCRRIIPPTTIIOONN - The Internet Software Consortium DHCP Relay Agent, dhcre - lay, provides a means for relaying DHCP and BOOTP requests - from a subnet to which no DHCP server is directly con - nected to one or more DHCP servers on other subnets. - -OOPPEERRAATTIIOONN - The DHCP Relay Agent listens for DHCP and BOOTP queries - and responses. When a query is received from a client, - dhcrelay forwards it to the list of DHCP servers specified - on the command line. When a reply is received from a - server, it is broadcast or unicast (according to the relay - agent's ability or the client's request) on the network - from which the original request came. - -CCOOMMMMAANNDD LLIINNEE - The names of the network interfaces that dhcrelay should - attempt to configure may be specified on the command line - using the --ii option. If no interface names are specified - on the command line dhcrelay will identify all network - interfaces, elimininating non-broadcast interfaces if pos - sible, and attempt to configure each interface. - - If a relay agent is running on a system that is connected - to one or more networks on which no DHCP servers are pre - sent, and is also connected to one or more networks on - which DHCP servers _a_r_e connected, it is may not be helpful - for the relay agent to relay requests from those networks - on which a DHCP server already exists. To avoid such a - situation, the interfaces on which the relay agent should - listen should be specified with the --ii flag. - - Note that in some cases it _i_s helpful for the relay agent - to forward requests from networks on which a DHCP server - is running to other DHCP servers. This would be the case - if two DHCP servers on different networks were being used - to provide backup service for each other's networks. - - If dhcrelay should listen and transmit on a port other - than the standard (port 67), the --pp flag may used. It - should be followed by the udp port number that dhcrelay - should use. This is mostly useful for debugging purposes. - - Dhcrelay will normally run in the foreground until it has - configured an interface, and then will revert to running - in the background. To run force dhcrelay to always run as - - - - 1 - - - - - -dhcrelay(8) dhcrelay(8) - - - a foreground process, the --dd flag should be specified. - This is useful when running dhcrelay under a debugger, or - when running it out of inittab on System V systems. - - Dhcrelay will normally print its network configuration on - startup. This can be annoying in a system startup script - - to disable this behaviour, specify the --qq flag. - -RREELLAAYY AAGGEENNTT IINNFFOORRMMAATTIIOONN OOPPTTIIOONNSS - If the --aa flag is set the relay agent will append an agent - option field to each request before forwarding it to the - server. Agent option fields in responses sent from - servers to clients will be stripped before forwarding such - responses back to the client. - - The agent option field will contain two agent options: the - Circuit ID suboption and the Agent ID suboption. Cur - rently, the Circuit ID will be the printable name of the - interface on which the client request was received. The - Agent ID will be the value that the relay agent stores in - the DHCP packet's giaddr field. The client supports - inclusion of a Remote ID suboption as well, but this is - not used by default. - - _N_o_t_e_: The Agent ID suboption is not defined in the current - Relay Agent Information Option draft (draft-ietf-dhc- - agent-options-03.txt), but has been proposed for inclusion - in the next draft. - - Relay Agent options are added to a DHCP packet without the - knowledge of the DHCP client. The client may have filled - the DHCP packet option buffer completely, in which case - there theoretically isn't any space to add Agent options. - However, the DHCP server may be able to handle a much - larger packet than most DHCP clients would send. The - current Agent Options draft requires that the relay agent - use a maximum packet size of 576 bytes. - - It is recommended that with the Internet Software Consor - tium DHCP server, the maximum packet size be set to about - 1400, allowing plenty of extra space in which the relay - agent can put the agent option field, while still fitting - into the Ethernet MTU size. This can be done by specify - ing the --AA flag, followed by the desired maximum packet - size (e.g., 1400). - - Note that this is reasonably safe to do even if the MTU - between the server and the client is less than 1500, as - long as the hosts on which the server and client are run - ning support IP fragmentation (and they should). With - some knowledge as to how large the agent options might get - in a particular configuration, this parameter can be tuned - as finely as necessary. - - - - - 2 - - - - - -dhcrelay(8) dhcrelay(8) - - - It is possible for a relay agent to receive a packet which - already contains an agent option field. If this packet - does not have a giaddr set, the standard requires that the - packet be discarded. - - If giaddr is set, the server may handle the situation in - one of four ways: it may _a_p_p_e_n_d its own set of relay - options to the packet, leaving the supplied option field - intact. It may _r_e_p_l_a_c_e the existing agent option field. - It may _f_o_r_w_a_r_d the packet unchanged. Or, it may _d_i_s_c_a_r_d - it. - - Which of these behaviours is followed by the Internet - Software Consortium DHCP Relay Agent may be configured - with the --mm flag, followed by one of the four keywords - specified in _i_t_a_l_i_c_s above. - - When the relay agent receives a reply from a server that - it's supposed to forward to a client, and Relay Agent - Information option processing is enabled, the relay agent - scans the packet for Relay Agent Information options and - removes them. As it's scanning, if it finds a Relay - Agent Information option field containing an Agent ID sub - option that matches one of its IP addresses, that option - is recognized as its own. If no such option is found, - the relay agent can either drop the packet, or relay it - anyway. If the --DD option is specified, all packets that - don't contain a match will be dropped. - -SSPPEECCIIFFYYIINNGG DDHHCCPP SSEERRVVEERRSS - The name or IP address of at least one DHCP server to - which DHCP and BOOTP requests should be relayed must be - specified on the command line. - -SSEEEE AALLSSOO - dhclient(8), dhcpd(8), RFC2132, RFC2131, draft-ietf-dhc- - agent-options-03.txt. - -BBUUGGSS - It should be possible for the user to define the Circuit - ID and Remote ID values on a per-interface basis. - - The relay agent should not relay packets received on a - physical network to DHCP servers on the same physical net - work - if they do, the server will receive duplicate pack - ets. In order to fix this, however, the relay agent - needs to be able to learn about the network topology, - which requires that it have a configuration file. - -AAUUTTHHOORR - ddhhccrreellaayy((88)) has been written for the Internet Software - Consortium by Ted Lemon <mellon@fugue.com> in cooperation - with Vixie Enterprises. To learn more about the Internet - Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc.. To learn - - - - 3 - - - - - -dhcrelay(8) dhcrelay(8) - - - more about Vixie Enterprises, see hhttttpp::////wwwwww..vviixx..ccoomm.. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 4 - - diff --git a/server/dhcpd.cat8 b/server/dhcpd.cat8 deleted file mode 100644 index 282efe63..00000000 --- a/server/dhcpd.cat8 +++ /dev/null @@ -1,396 +0,0 @@ - - - -dhcpd(8) dhcpd(8) - - -NNAAMMEE - dhcpd - Dynamic Host Configuration Protocol Server - -SSYYNNOOPPSSIISS - ddhhccppdd [ --pp _p_o_r_t ] [ --ff ] [ --dd ] [ --qq ] [ --tt | --TT ] [ --ccff - _c_o_n_f_i_g_-_f_i_l_e ] [ --llff _l_e_a_s_e_-_f_i_l_e ] [ _i_f_0 [ _._._._i_f_N ] ] - -DDEESSCCRRIIPPTTIIOONN - The Internet Software Consortium DHCP Server, dhcpd, - implements the Dynamic Host Configuration Protocol (DHCP) - and the Internet Bootstrap Protocol (BOOTP). DHCP allows - hosts on a TCP/IP network to request and be assigned IP - addresses, and also to discover information about the net - work to which they are attached. BOOTP provides similar - functionality, with certain restrictions. - -CCOONNTTRRIIBBUUTTIIOONNSS - Development of this software is funded through contribu - tions and support contracts. Please see ddhhccpp--ccoonnttrriibb((55)) - for information on how you can contribute. - -OOPPEERRAATTIIOONN - The DHCP protocol allows a host which is unknown to the - network administrator to be automatically assigned a new - IP address out of a pool of IP addresses for its network. - In order for this to work, the network administrator allo - cates address pools in each subnet and enters them into - the dhcpd.conf(5) file. - - On startup, dhcpd reads the _d_h_c_p_d_._c_o_n_f file and stores a - list of available addresses on each subnet in memory. - When a client requests an address using the DHCP protocol, - dhcpd allocates an address for it. Each client is - assigned a lease, which expires after an amount of time - chosen by the administrator (by default, one day). Before - leases expire, the clients to which leases are assigned - are expected to renew them in order to continue to use the - addresses. Once a lease has expired, the client to which - that lease was assigned is no longer permitted to use the - leased IP address. - - In order to keep track of leases across system reboots and - server restarts, dhcpd keeps a list of leases it has - assigned in the dhcpd.leases(5) file. Before dhcpd - grants a lease to a host, it records the lease in this - file and makes sure that the contents of the file are - flushed to disk. This ensures that even in the event of - a system crash, dhcpd will not forget about a lease that - it has assigned. On startup, after reading the - dhcpd.conf file, dhcpd reads the dhcpd.leases file to - refresh its memory about what leases have been assigned. - - New leases are appended to the end of the dhcpd.leases - file. In order to prevent the file from becoming - - - - 1 - - - - - -dhcpd(8) dhcpd(8) - - - arbitrarily large, from time to time dhcpd creates a new - dhcpd.leases file from its in-core lease database. Once - this file has been written to disk, the old file is - renamed _d_h_c_p_d_._l_e_a_s_e_s_~, and the new file is renamed - dhcpd.leases. If the system crashes in the middle of - this process, whichever dhcpd.leases file remains will - contain all the lease information, so there is no need for - a special crash recovery process. - - BOOTP support is also provided by this server. Unlike - DHCP, the BOOTP protocol does not provide a protocol for - recovering dynamically-assigned addresses once they are no - longer needed. It is still possible to dynamically - assign addresses to BOOTP clients, but some administrative - process for reclaiming addresses is required. By - default, leases are granted to BOOTP clients in perpetu - ity, although the network administrator may set an earlier - cutoff date or a shorter lease length for BOOTP leases if - that makes sense. - - BOOTP clients may also be served in the old standard way, - which is to simply provide a declaration in the dhcpd.conf - file for each BOOTP client, permanently assigning an - address to each client. - - Whenever changes are made to the dhcpd.conf file, dhcpd - must be restarted. To restart dhcpd, send a SIGTERM - (signal 15) to the process ID contained in - _/_v_a_r_/_r_u_n_/_d_h_c_p_d_._p_i_d, and then re-invoke dhcpd. Because the - DHCP server database is not as lightweight as a BOOTP - database, dhcpd does not automatically restart itself when - it sees a change to the dhcpd.conf file. - - Note: We get a lot of complaints about this. We realize - that it would be nice if one could send a SIGHUP to the - server and have it reload the database. This is not - technically impossible, but it would require a great deal - of work, our resources are extremely limited, and they can - be better spent elsewhere. So please don't complain - about this on the mailing list unless you're prepared to - fund a project to implement this feature, or prepared to - do it yourself. - -CCOOMMMMAANNDD LLIINNEE - The names of the network interfaces on which dhcpd should - listen for broadcasts may be specified on the command - line. This should be done on systems where dhcpd is - unable to identify non-broadcast interfaces, but should - not be required on other systems. If no interface names - are specified on the command line dhcpd will identify all - network interfaces which are up, elimininating non-broad - cast interfaces if possible, and listen for DHCP broad - casts on each interface. - - - - - 2 - - - - - -dhcpd(8) dhcpd(8) - - - If dhcpd should listen on a port other than the standard - (port 67), the --pp flag may used. It should be followed by - the udp port number on which dhcpd should listen. This is - mostly useful for debugging purposes. - - To run dhcpd as a foreground process, rather than allowing - it to run as a daemon in the background, the --ff flag - should be specified. This is useful when running dhcpd - under a debugger, or when running it out of inittab on - System V systems. - - To have dhcpd log to the standard error descriptor, spec - ify the --dd flag. This can be useful for debugging, and - also at sites where a complete log of all dhcp activity - must be kept but syslogd is not reliable or otherwise can - not be used. Normally, dhcpd will log all output using - the syslog(3) function with the log facility set to - LOG_DAEMON. - - Dhcpd can be made to use an alternate configuration file - with the --ccff flag, or an alternate lease file with the --llff - flag. Because of the importance of using the same lease - database at all times when running dhcpd in production, - these options should be used oonnllyy for testing lease files - or database files in a non-production environment. - - When starting dhcpd up from a system startup script (e.g., - /etc/rc), it may not be desirable to print out the entire - copyright message on startup. To avoid printing this - message, the --qq flag may be specified. - - The DHCP server reads two files on startup: a configura - tion file, and a lease database. If the --tt flag is spec - ified, the server will simply test the configuration file - for correct syntax, but will not attempt to perform any - network operations. This can be used to test the a new - configuration file automatically before installing it. - - The --TT flag can be used to test the lease database file in - a similar way. - -CCOONNFFIIGGUURRAATTIIOONN - The syntax of the dhcpd.conf(5) file is discussed seper - ately. This section should be used as an overview of the - configuration process, and the dhcpd.conf(5) documentation - should be consulted for detailed reference information. - - -SSuubbnneettss - dhcpd needs to know the subnet numbers and netmasks of all - subnets for which it will be providing service. In addi - tion, in order to dynamically allocate addresses, it must - be assigned one or more ranges of addresses on each subnet - which it can in turn assign to client hosts as they boot. - - - - 3 - - - - - -dhcpd(8) dhcpd(8) - - - Thus, a very simple configuration providing DHCP support - might look like this: - - subnet 239.252.197.0 netmask 255.255.255.0 { - range 239.252.197.10 239.252.197.250; - } - - Multiple address ranges may be specified like this: - - subnet 239.252.197.0 netmask 255.255.255.0 { - range 239.252.197.10 239.252.197.107; - range 239.252.197.113 239.252.197.250; - } - - If a subnet will only be provided with BOOTP service and - no dynamic address assignment, the range clause can be - left out entirely, but the subnet statement must appear. - - -LLeeaassee LLeennggtthhss - DHCP leases can be assigned almost any length from zero - seconds to infinity. What lease length makes sense for - any given subnet, or for any given installation, will vary - depending on the kinds of hosts being served. - - For example, in an office environment where systems are - added from time to time and removed from time to time, but - move relatively infrequently, it might make sense to allow - lease times of a month of more. In a final test environ - ment on a manufacturing floor, it may make more sense to - assign a maximum lease length of 30 minutes - enough time - to go through a simple test procedure on a network appli - ance before packaging it up for delivery. - - It is possible to specify two lease lengths: the default - length that will be assigned if a client doesn't ask for - any particular lease length, and a maximum lease length. - These are specified as clauses to the subnet command: - - subnet 239.252.197.0 netmask 255.255.255.0 { - range 239.252.197.10 239.252.197.107; - default-lease-time 600; - max-lease-time 7200; - | - - This particular subnet declaration specifies a default - lease time of 600 seconds (ten minutes), and a maximum - lease time of 7200 seconds (two hours). Other common - values would be 86400 (one day), 604800 (one week) and - 2592000 (30 days). - - Each subnet need not have the same lease--in the case of - an office environment and a manufacturing environment - served by the same DHCP server, it might make sense to - - - - 4 - - - - - -dhcpd(8) dhcpd(8) - - - have widely disparate values for default and maximum lease - times on each subnet. - -BBOOOOTTPP SSuuppppoorrtt - Each BOOTP client must be explicitly declared in the - dhcpd.conf file. A very basic client declaration will - specify the client network interface's hardware address - and the IP address to assign to that client. If the - client needs to be able to load a boot file from the - server, that file's name must be specified. A simple - bootp client declaration might look like this: - - host haagen { - hardware ethernet 08:00:2b:4c:59:23; - fixed-address 239.252.197.9; - filename "/tftpboot/haagen.boot"; - } - -OOppttiioonnss - DHCP (and also BOOTP with Vendor Extensions) provide a - mechanism whereby the server can provide the client with - information about how to configure its network interface - (e.g., subnet mask), and also how the client can access - various network services (e.g., DNS, IP routers, and so - on). - - These options can be specified on a per-subnet basis, and, - for BOOTP clients, also on a per-client basis. In the - event that a BOOTP client declaration specifies options - that are also specified in its subnet declaration, the - options specified in the client declaration take prece - dence. An reasonably complete DHCP configuration might - look something like this: - - subnet 239.252.197.0 netmask 255.255.255.0 { - range 239.252.197.10 239.252.197.250; - default-lease-time 600 max-lease-time 7200; - option subnet-mask 255.255.255.0; - option broadcast-address 239.252.197.255; - option routers 239.252.197.1; - option domain-name-servers 239.252.197.2, 239.252.197.3; - option domain-name "isc.org"; - } - - A bootp host on that subnet that needs to be in a differ - ent domain and use a different name server might be - declared as follows: - - host haagen { - hardware ethernet 08:00:2b:4c:59:23; - fixed-address 239.252.197.9; - filename "/tftpboot/haagen.boot"; - option domain-name-servers 192.5.5.1; - option domain-name "vix.com"; - - - - 5 - - - - - -dhcpd(8) dhcpd(8) - - - } - - A more complete description of the dhcpd.conf file syntax - is provided in dhcpd.conf(5). - -FFIILLEESS - //eettcc//ddhhccppdd..ccoonnff,, //vvaarr//ddbb//ddhhccppdd..lleeaasseess,, //vvaarr//rruunn//ddhhccppdd..ppiidd,, - //vvaarr//ddbb//ddhhccppdd..lleeaasseess~~.. - -SSEEEE AALLSSOO - dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5) - -AAUUTTHHOORR - ddhhccppdd((88)) was written by Ted Lemon <mellon@vix.com> under a - contract with Vixie Labs. Funding for this project was - provided by the Internet Software Consortium. Information - about the Internet Software Consortium can be found at - hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6 - - diff --git a/server/dhcpd.conf.cat5 b/server/dhcpd.conf.cat5 deleted file mode 100644 index f104d635..00000000 --- a/server/dhcpd.conf.cat5 +++ /dev/null @@ -1,1716 +0,0 @@ - - - -dhcpd.conf(5) dhcpd.conf(5) - - -NNAAMMEE - dhcpd.conf - dhcpd configuration file - -DDEESSCCRRIIPPTTIIOONN - The dhcpd.conf file contains configuration information for - _d_h_c_p_d_, the Internet Software Consortium DHCP Server. - - The dhcpd.conf file is a free-form ASCII text file. It - is parsed by the recursive-descent parser built into - dhcpd. The file may contain extra tabs and newlines for - formatting purposes. Keywords in the file are case-insen - sitive. Comments may be placed anywhere within the file - (except within quotes). Comments begin with the # char - acter and end at the end of the line. - - The file essentially consists of a list of statements. - Statements fall into two broad categories - parameters and - declarations. - - Parameter statements either say how to do something (e.g., - how long a lease to offer), whether to do something (e.g., - should dhcpd provide addresses to unknown clients), or - what parameters to provide to the client (e.g., use gate - way 220.177.244.7). - - Declarations are used to describe the topology of the net - work, to describe clients on the network, to provide - addresses that can be assigned to clients, or to apply a - group of parameters to a group of declarations. In any - group of parameters and declarations, all parameters must - be specified before any declarations which depend on those - parameters may be specified. - - Declarations about network topology include the - _s_h_a_r_e_d_-_n_e_t_w_o_r_k and the _s_u_b_n_e_t declarations. If clients - on a subnet are to be assigned addresses dynamically, a - _r_a_n_g_e declaration must appear within the _s_u_b_n_e_t declara - tion. For clients with statically assigned addresses, or - for installations where only known clients will be served, - each such client must have a _h_o_s_t declaration. If param - eters are to be applied to a group of declarations which - are not related strictly on a per-subnet basis, the _g_r_o_u_p - declaration can be used. - - For every subnet which will be served, and for every sub - net to which the dhcp server is connected, there must be - one _s_u_b_n_e_t declaration, which tells dhcpd how to recognize - that an address is on that subnet. A _s_u_b_n_e_t declaration - is required for each subnet even if no addresses will be - dynamically allocated on that subnet. - - Some installations have physical networks on which more - than one IP subnet operates. For example, if there is a - site-wide requirement that 8-bit subnet masks be used, but - - - - 1 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - a department with a single physical ethernet network - expands to the point where it has more than 254 nodes, it - may be necessary to run two 8-bit subnets on the same eth - ernet until such time as a new physical network can be - added. In this case, the _s_u_b_n_e_t declarations for these - two networks may be enclosed in a _s_h_a_r_e_d_-_n_e_t_w_o_r_k declara - tion. - - Some sites may have departments which have clients on more - than one subnet, but it may be desirable to offer those - clients a uniform set of parameters which are different - than what would be offered to clients from other depart - ments on the same subnet. For clients which will be - declared explicitly with _h_o_s_t declarations, these declara - tions can be enclosed in a _g_r_o_u_p declaration along with - the parameters which are common to that department. For - clients whose addresses will be dynamically assigned, - class declarations and conditional declarations may be - used to group parameter assignments based on information - the client sends. - - When a client is to be booted, its boot parameters are - determined by consulting that client's _h_o_s_t declaration - (if any), and then consulting the any _c_l_a_s_s declarations - matching the client, followed by the _p_o_o_l, _s_u_b_n_e_t and - _s_h_a_r_e_d_-_n_e_t_w_o_r_k declarations for the IP address assigned to - the client. Each of these declarations itself appears - within a lexical scope, and all declarations at less spe - cific lexical scopes are also consulted for client option - declarations as well. Scopes are never considered twice, - and if parameters are declared in more than one scope, the - parameter declared in the most specific scope is the one - that is used. - - When dhcpd tries to find a _h_o_s_t declaration for a client, - it first looks for a _h_o_s_t declaration which has a _f_i_x_e_d_- - _a_d_d_r_e_s_s parameter which matches the subnet or shared net - work on which the client is booting. If it doesn't find - any such entry, it then tries to find an entry which has - no _f_i_x_e_d_-_a_d_d_r_e_s_s parameter. If no such entry is found, - then dhcpd acts as if there is no entry in the dhcpd.conf - file for that client, even if there is an entry for that - client on a different subnet or shared network. - -EEXXAAMMPPLLEESS - A typical dhcpd.conf file will look something like this: - - _g_l_o_b_a_l _p_a_r_a_m_e_t_e_r_s_._._. - - subnet 204.254.239.0 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.10 204.254.239.30; - } - - - - - 2 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - subnet 204.254.239.32 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.42 204.254.239.62; - } - - subnet 204.254.239.64 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.74 204.254.239.94; - } - - group { - _g_r_o_u_p_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - host zappo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - host beppo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - host harpo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - } - - Figure 1 - - - Notice that at the beginning of the file, there's a place - for global parameters. These might be things like the - organization's domain name, the addresses of the name - servers (if they are common to the entire organization), - and so on. So, for example: - - option domain-name "isc.org"; - option domain-name-servers ns1.isc.org, ns2.isc.org; - - Figure 2 - - As you can see in Figure 2, you can specify host addresses - in parameters using their domain names rather than their - numeric IP addresses. If a given hostname resolves to - more than one IP address (for example, if that host has - two ethernet interfaces), then where possible, both - addresses are supplied to the client. - - The most obvious reason for having subnet-specific parame - ters as shown in Figure 1 is that each subnet, of neces - sity, has its own router. So for the first subnet, for - example, there should be something like: - - option routers 204.254.239.1; - - Note that the address here is specified numerically. - This is not required - if you have a different domain name - for each interface on your router, it's perfectly - - - - 3 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - legitimate to use the domain name for that interface - instead of the numeric address. However, in many cases - there may be only one domain name for all of a router's IP - addresses, and it would not be appropriate to use that - name here. - - In Figure 1 there is also a _g_r_o_u_p statement, which pro - vides common parameters for a set of three hosts - zappo, - beppo and harpo. As you can see, these hosts are all in - the test.isc.org domain, so it might make sense for a - group-specific parameter to override the domain name sup - plied to these hosts: - - option domain-name "test.isc.org"; - - Also, given the domain they're in, these are probably test - machines. If we wanted to test the DHCP leasing mecha - nism, we might set the lease timeout somewhat shorter than - the default: - - max-lease-time 120; - default-lease-time 120; - - You may have noticed that while some parameters start with - the _o_p_t_i_o_n keyword, some do not. Parameters starting - with the _o_p_t_i_o_n keyword correspond to actual DHCP options, - while parameters that do not start with the option keyword - either control the behaviour of the DHCP server (e.g., how - long a lease dhcpd will give out), or specify client - parameters that are not optional in the DHCP protocol (for - example, server-name and filename). - - In Figure 1, each host had _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s. - These could include such things as the _h_o_s_t_n_a_m_e option, - the name of a file to upload (the _f_i_l_e_n_a_m_e _p_a_r_a_m_e_t_e_r_) _a_n_d - _t_h_e _a_d_d_r_e_s_s _o_f _t_h_e _s_e_r_v_e_r _f_r_o_m _w_h_i_c_h _t_o _u_p_l_o_a_d _t_h_e _f_i_l_e - _(_t_h_e _n_e_x_t_-_s_e_r_v_e_r parameter). In general, any parameter - can appear anywhere that parameters are allowed, and will - be applied according to the scope in which the parameter - appears. - - Imagine that you have a site with a lot of NCD X-Termi - nals. These terminals come in a variety of models, and - you want to specify the boot files for each models. One - way to do this would be to have host declarations for each - server and group them by model: - - group { - filename "Xncd19r"; - next-server ncd-booter; - - host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; } - host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; } - host ncd8 { hardware ethernet 0:c0:c3:22:46:81; } - - - - 4 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - } - - group { - filename "Xncd19c"; - next-server ncd-booter; - - host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } - host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } - } - - group { - filename "XncdHMX"; - next-server ncd-booter; - - host ncd1 { hardware ethernet 0:c0:c3:11:90:23; } - host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; } - host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; } - } - -AADDDDRREESSSS PPOOOOLLSS - The ppooooll declaration can be used to specify a pool of - addresses that will be treated differently than another - pool of addresses, even on the same network segment or - subnet. For example, you may want to provide a large set - of addresses that can be assigned to DHCP clients that are - registered to your DHCP server, while providing a smaller - set of addresses, possibly with short lease times, that - are available for unknown clients. If you have a fire - wall, you may be able to arrange for addresses from one - pool to be allowed access to the Internet, while addresses - in another pool are not, thus encouraging users to regis - ter their DHCP clients. To do this, you would set up a - pair of pool declarations: - - subnet 10.0.0.0 netmask 255.255.255.0 { - option routers 10.0.0.254; - - # Unknown clients get this pool. - pool { - option domain-name-servers bogus.example.com; - max-lease-time 300; - range 10.0.0.200 10.0.0.253; - allow unknown clients; - } - - # Known clients get this pool. - pool { - option domain-name-servers ns1.example.com, ns2.example.com; - max-lease-time 28800; - range 10.0.0.5 10.0.0.199; - deny unknown clients; - } - } - - - - - 5 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - It is also possible to set up entirely different subnets - for known and unknown clients - address pools exist at the - level of shared networks, so address ranges within pool - declarations can be on different subnets. - - As you can see in the preceding example, pools can have - permit lists that control which clients are allowed access - to the pool and which aren't. Each entry in a pool's per - mit list is introduced with the _a_l_l_o_w or _d_e_n_y keyword. - If a pool has a permit list, then only those clients that - match specific entries on the permit list will be elegible - to be assigned addresses from the pool. If a pool has a - deny list, then only those clients that do not match any - entries on the deny list will be elegible. If both per - mit and deny lists exist for a pool, then only clients - that match the permit list and do not match the deny list - will be allowed access. - -AADDDDRREESSSS AALLLLOOCCAATTIIOONN - Address allocation is actually only done when a client is - in the INIT state and has sent a DHCPDISCOVER message. If - the client thinks it has a valid lease and sends a DHCPRE - QUEST to initiate or renew that lease, the server has only - three choices - it can ignore the DHCPREQUEST, send a - DHCPNAK to tell the client it should stop using the - address, or send a DHCPACK, telling the client to go ahead - and use the address for a while. If the server finds the - address the client is requesting, and that address is - available to the client, the server will send a DHCPACK. - If the address is no longer available, or the client isn't - permitted to have it, the server will send a DHCPNAK. If - the server knows nothing about the, it will remain silent, - unless the address is incorrect for the network segment to - which the client has been attached and the server is - authoritative for that network segment, in which case the - server will send a DHCPNAK even though it doesn't know - about the address. - - When the DHCP server allocates a new address for a client - (remember, this only happens if the client has sent a - DHCPDISCOVER), it first looks to see if the client already - has a valid lease on an IP address, or if there is an old - IP address the client had before that hasn't yet been - reassigned. In that case, the server will take that - address and check it to see if the client is still permit - ted to use it. If the client is no longer permitted to - use it, the lease is freed if the server thought it was - still in use - the fact that the client has sent a - DHCPDISCOVER proves to the server that the client is no - longer using the lease. - - If no existing lease is found, or if the client is forbid - den to receive the existing lease, then the server will - look in the list of address pools for the network segment - - - - 6 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - to which the client is attached for a lease that is not in - use and that the client is permitted to have. It looks - through each pool declaration in sequence (all _r_a_n_g_e dec - larations that appear outside of pool declarations are - grouped into a single pool with no permit list). If the - permit list for the pool allows the client to be allocated - an address from that pool, the pool is examined to see if - there is an address available. If so, then the client is - tentatively assigned that address. Otherwise, the next - pool is tested. If no addresses are found that can be - assigned to the client, no response is sent to the client. - - If an address is found that the client is permitted to - have, and that has never been assigned to any client - before, the address is immediately allocated to the - client. If the address is available for allocation but - has been previously assigned to a different client, the - server will keep looking in hopes of finding an address - that has never before been assigned to a client. - -CCLLIIEENNTT CCLLAASSSSIINNGG - Clients can be seperated into classes, and treated differ - ently depending on what class they are in. This sepera - tion can be done either with a conditional statement, or - with a match statement within the class declaration. It - is possible to specify a limit on the total number of - clients within a particular class or subclass that may - hold leases at one time, and it is possible to specify - automatic subclassing based on the contents of the client - packet. - - To add clients to classes based on conditional evaluation, - you would write an conditional statement to match the - clients you wanted in the class, and then put an aadddd - statement in the conditional's list of statements: - - if substring (option dhcp-client-identifier, 0, 3) = "RAS" { - add "ras-clients"; - } - - A nearly equivalent way to do this is to simply specify - the conditional expression as a matching expression in the - class statement: - - class "ras-clients" { - match if substring (option dhcp-client-identifier, 0, 3) = "RAS"; - } - Note that whether you use matching expressions or add - statements (or both) to classify clients, you must always - write a class declaration for any class that you use. If - there will be no match statement and no in-scope state - ments for a class, the declaration should look like this: - class "ras-clients" { - } - - - - 7 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - Also, the aadddd statement adds the client to the class as - the client's scopes are being evaluated - after any - address assignment decision has been made. This means - that a client that's a member of a class due to an add - statement will not be affected by pool permits related to - that class - when the pool permit list is computed, the - client will not yet be a member of the pool. This is an - inconsistency that will probably be addressed in later - versions of the DHCP server, but it important to be aware - of it at lease for the time being. - -SSUUBBCCLLAASSSSEESS - In addition to classes, it is possible to declare sub - classes. A subclass is a class with the same name as a - regular class, but with a specific submatch expression - which is hashed for quick matching. This is essentially a - speed hack - the main difference between five classes with - match expressions and one class with five subclasses is - that it will be quicker to find the subclasses. Sub - classes work as follows: - - class "allocation-class-1" { - match pick-first-value (option dhcp-client-identifier, hardware); - } - - class "allocation-class-2" { - match pick-first-value (option dhcp-client-identifier, hardware); - } - - subclass "allocation-class-1" 1:8:0:2b:4c:39:ad; - subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3; - subclass "allocation-class-1" 1:0:0:c4:aa:29:44; - - subnet 10.0.0.0 netmask 255.255.255.0 { - pool { - allow members of "allocation-class-1"; - range 10.0.0.11 10.0.0.50; - } - pool { - allow members of "allocation-class-2"; - range 10.0.0.51 10.0.0.100; - } - } - - The data following the class name in the subclass declara - tion is a constant value to use in matching the match - expression for the class. When class matching is done, - the server will evaluate the match expression and then - look the result up in the hash table. If it finds a - match, the client is considered a member of both the class - and the subclass. - - Subclasses can be declared with or without scope. In the - above example, the sole purpose of the subclass is to - - - - 8 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - allow some clients access to one address pool, while other - clients are given access to the other pool, so these sub - classes are declared without scopes. If part of the pur - pose of the subclass were to define different parameter - values for some clients, you might want to declare some - subclasses with scopes. - - In the above example, if you had a single client that - needed some configuration parameters, while most didn't, - you might write the following subclass declaration for - that client: - - subclass "allocation-class-2" 1:08:00:2b:a1:11:31 { - option root-path "samsara:/var/diskless/alphapc"; - filename "/tftpboot/netbsd.alphapc-diskless"; - } - - In this example, we've used subclassing as a way to con - trol address allocation on a per-client basis. However, - it's also possible to use subclassing in ways that are not - specific to clients - for example, to use the value of the - vendor-class-identifier option to determine what values to - send in the vendor-encapsulated-options option. An exam - ple of this is shown under the VENDOR ENCAPSULATED OPTIONS - head later on in this document. - -PPEERR--CCLLAASSSS LLIIMMIITTSS OONN DDYYNNAAMMIICC AADDDDRREESSSS AALLLLOOCCAATTIIOONN - You may specify a limit to the number of clients in a - class that can be assigned leases. The effect of this - will be to make it difficult for a new client in a class - to get an address. Once a class with such a limit has - reached its limit, the only way a new client in that class - can get a lease is for an existing client to relinquish - its lease, either by letting it expire, or by sending a - DHCPRELEASE packet. Classes with lease limits are speci - fied as follows: - - class "limited-1" { - lease limit 4; - } - - This will produce a class in which a maximum of four mem - bers may hold a lease at one time. - -SSPPAAWWNNIINNGG CCLLAASSSSEESS - It is possible to declare a _s_p_a_w_n_i_n_g _c_l_a_s_s. A spawning - class is a class that automatically produces subclasses - based on what the client sends. The reason that spawning - classes were created was to make it possible to create - lease-limited classes on the fly. The envisioned appli - cation is a cable-modem environment where the ISP wishes - to provide clients at a particular site with more than one - IP address, but does not wish to provide such clients with - their own subnet, nor give them an unlimited number of IP - - - - 9 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - addresses from the network segment to which they are con - nected. - - Many cable modem head-end systems can be configured to add - a Relay Agent Information option to DHCP packets when - relaying them to the DHCP server. These systems typi - cally add a circuit ID or remote ID option that uniquely - identifies the customer site. To take advantage of this, - you can write a class declaration as follows: - - class "customer" { - spawn with option agent.circuit-id; - lease limit 4; - } - - Now whenever a request comes in from a customer site, the - circuit ID option will be checked against the class's hash - table. If a subclass is found that matches the circuit - ID, the client will be classified in that subclass and - treated accordingly. If no subclass is found matching - the circuit ID, a new one will be created and logged in - the ddhhccppdd..lleeaasseess file, and the client will be classified - in this new class. Once the client has been classified, - it will be treated according to the rules of the class, - including, in this case, being subject to the per-site - limit of four leases. - - The use of the subclass spawning mechanism is not - restricted to relay agent options - this particular exam - ple is given only because it is a fairly straightforward - one. - -DDYYNNAAMMIICC DDNNSS UUPPDDAATTEESS - The DHCP server has the ability to dynamically update the - Domain Name System. Within the configuration files, you - can define how you want the Domain Name System to be - updated. These updates are RFC 2136 compliant so any DNS - server supporting RFC 2136 should be able to accept - updates from the DHCP server. The DHCP server will only - perform DNS updates if it has been built with DNS updates - enabled as described in the README file that comes with - the DHCP distribution. - - The Dynamic DNS update scheme implemented in this version - of the ISC DHCP server is an interim implementation, which - does not implement any of the standard update methods that - have been discussed in the working group, but rather - implements some very basic, yet useful, update capabili - ties. - - There are three parameters, which may vary according to - the scope, that control how DDNS updates will be done. - The first two are the _d_d_n_s_-_d_o_m_a_i_n_n_a_m_e and _d_d_n_s_-_r_e_v_-_d_o_m_a_i_n_ - _n_a_m_e statements. The _d_d_n_s_-_d_o_m_a_i_n_n_a_m_e parameter sets the - - - - 10 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - domain name that will be appended to the client's hostname - to form a fully-qualified domain-name (FQDN). For exam - ple, if the client's hostname is "hutson" and the _d_d_n_s_- - _d_o_m_a_i_n_n_a_m_e is set to "sneedville.edu", then the client's - FQDN will be "hutson.sneedville.edu". - - The _d_d_n_s_-_r_e_v_-_d_o_m_a_i_n_n_a_m_e parameter sets the domain name - that will be appended to the client's reversed IP address - to produce a name for use in the client's PTR record. - Normally, you would set this to "in-addr.arpa", but this - is not required. - - A third parameter, _d_d_n_s_-_h_o_s_t_n_a_m_e can be used to specify - the hostname that will be used as the client's hostname. - If no ddns-hostname is specified in scope, then the server - will use a host-name option sent by the client. If the - client did not send a host-name option, then if there is a - host declaration that applies to the client, the name from - that declaration will be used. If none of these applies, - the server will not have a hostname for the client, and - will not be able to do a DDNS update. - -HHOOWW DDNNSS UUPPDDAATTEESS WWOORRKK - The client's FQDN, derived as we have described, is used - as the name on which an "A" record will be stored. The A - record will contain the IP address that the client was - assigned in its lease. If there is already an A record - with the same name in the DNS server, no update of either - the A or PTR records will occur - this prevents a client - from claiming that its hostname is the name of some net - work server. For example, if you have a fileserver - called "fs.sneedville.edu", and the client claims its - hostname is "fs", no DNS update will be done for that - client, and an error message will be logged. - - If the A record update succeeds, a PTR record update for - the assigned IP address will be done, pointing to the A - record. This update is unconditional - it will be done - even if another PTR record of the same name exists. - Since the IP address has been assigned to the DHCP server, - this should be safe. - - Please note that the current implementation assumes - clients only have a single network interface. A client - with two network interfaces will see unpredictable - behaviour. This is considered a bug, and will be fixed - in a later release. It may be helpful to enable the _o_n_e_- - _l_e_a_s_e_-_p_e_r_-_c_l_i_e_n_t parameter so that roaming clients do not - trigger this same behavior. - - The DHCP protocol normally involves a four-packet exchange - - first the client sends a DHCPDISCOVER message, then the - server sends a DHCPOFFER, then the client sends a DHCPRE - QUEST, then the server sends a DHCPACK. In the current - - - - 11 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - version of the server, the server will do a DNS update - after it has received the DHCPREQUEST, and before it has - sent the DHCPOFFER. It only sends the DNS update if it - has not sent one for the client's address before, in order - to minimize the impact on the DHCP server. - - When the client's lease expires, the DHCP server (if it is - operating at the time, or when next it operates) will - remove the client's A and PTR records from the DNS - database. If the client releases its lease by sending a - DHCPRELEASE message, the server will likewise remove the A - and PTR records. - -DDYYNNAAMMIICC DDNNSS UUPPDDAATTEE SSEECCUURRIITTYY - Support for TSIG and DNSSEC is not yet available. When - you set your DNS server up to allow updates from the DHCP - server, you may be exposing it to unauthorized updates. - To avoid this, the best you can do right now is to use IP - address-based packet filtering to prevent unauthorized - hosts from submitting update requests. - - The DNS server must be configured to allow updates for any - zone that the DHCP server will be updating. For example, - let us say that clients in the sneedville.edu domain will - be assigned addresses on the 10.10.17.0/24 subnet. In - that case, assuming you are using ISC BIND 8.2.1 or later, - you would need to have the following declarations in your - /etc/named.conf file: - - zone "sneedville.edu" { - type master; - file "sneedville.edu.db"; - allow-update { localhost; }; - }; - - zone "17.10.10.in-addr.arpa" { - type master; - file "10.10.17.db"; - allow-update { localhost; }; - }; - - This assumes that your DHCP server and your name server - will be running on the same computer - the "localhost" - name is taken in the DNS server as an alias for all of - that host's IP addresses, and updates from any of those - addresses will be accepted. - - You may wish to enable logging of DNS transactions on your - DNS server. To do so, you might write a logging statement - like the following: - - logging { - channel update_debug { - file "/var/log/update-debug.log"; - - - - 12 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - severity debug 3; - print-category yes; - print-severity yes; - print-time yes; - }; - channel security_info { - file "/var/log/named-auth.info"; - severity info; - print-category yes; - print-severity yes; - print-time yes; - }; - - category update { update_debug; }; - category security { security_info; }; - }; - - You must create the /var/log/named-auth.info and - /var/log/update-debug.log files before starting the name - server. For more information on configuring ISC BIND, - consult the documentation that accompanies it. - -RREEFFEERREENNCCEE:: EEVVEENNTTSS - There are three kinds of events that can happen regarding - a lease, and it is possible to declare statements that - occur when any of these events happen. These events are - the commit event, when the server has made a commitment of - a certain lease to a client, the release event, when the - client has released the server from its commitment, and - the expiry event, when the commitment expires. - - To declare a set of statements to execute when an event - happens, you must use the oonn statement, followed by the - name of the event, followed by a series of statements to - execute when the event happens, enclosed in braces. - Events are used to implement dynamic DNS updates, so you - should not define your own event handlers if you are using - the built-in dynamic DNS update mechanism. - -RREEFFEERREENNCCEE:: DDEECCLLAARRAATTIIOONNSS - TThhee _s_h_a_r_e_d_-_n_e_t_w_o_r_k ssttaatteemmeenntt - - sshhaarreedd--nneettwwoorrkk _n_a_m_e {{ - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - The _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement is used to inform the DHCP - server that some IP subnets actually share the same physi - cal network. Any subnets in a shared network should be - declared within a _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement. Parameters - specified in the _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement will be used - when booting clients on those subnets unless parameters - provided at the subnet or host level override them. If - - - - 13 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - any subnet in a shared network has addresses available for - dynamic allocation, those addresses are collected into a - common pool for that shared network and assigned to - clients as needed. There is no way to distinguish on - which subnet of a shared network a client should boot. - - _N_a_m_e should be the name of the shared network. This name - is used when printing debugging messages, so it should be - descriptive for the shared network. The name may have - the syntax of a valid domain name (although it will never - be used as such), or it may be any arbitrary name, - enclosed in quotes. - - TThhee _s_u_b_n_e_t ssttaatteemmeenntt - - ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k {{ - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - The _s_u_b_n_e_t statement is used to provide dhcpd with enough - information to tell whether or not an IP address is on - that subnet. It may also be used to provide subnet-spe - cific parameters and to specify what addresses may be - dynamically allocated to clients booting on that subnet. - Such addresses are specified using the _r_a_n_g_e declaration. - - The _s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or domain name - which resolves to the subnet number of the subnet being - described. The _n_e_t_m_a_s_k should be an IP address or domain - name which resolves to the subnet mask of the subnet being - described. The subnet number, together with the netmask, - are sufficient to determine whether any given IP address - is on the specified subnet. - - Although a netmask must be given with every subnet decla - ration, it is recommended that if there is any variance in - subnet masks at a site, a subnet-mask option statement be - used in each subnet declaration to set the desired subnet - mask, since any subnet-mask option statement will override - the subnet mask declared in the subnet statement. - - TThhee _r_a_n_g_e ssttaatteemmeenntt - - rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w_-_a_d_d_r_e_s_s [ _h_i_g_h_-_a_d_d_r_e_s_s];; - - For any subnet on which addresses will be assigned dynami - cally, there must be at least one _r_a_n_g_e statement. The - range statement gives the lowest and highest IP addresses - in a range. All IP addresses in the range should be in - the subnet in which the _r_a_n_g_e statement is declared. The - _d_y_n_a_m_i_c_-_b_o_o_t_p flag may be specified if addresses in the - specified range may be dynamically assigned to BOOTP - clients as well as DHCP clients. When specifying a - - - - 14 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - single address, _h_i_g_h_-_a_d_d_r_e_s_s can be omitted. - - TThhee _h_o_s_t ssttaatteemmeenntt - - hhoosstt _h_o_s_t_n_a_m_e { - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - There must be at least one hhoosstt statement for every BOOTP - client that is to be served. hhoosstt statements may also be - specified for DHCP clients, although this is not required - unless booting is only enabled for known hosts. - - If it is desirable to be able to boot a DHCP or BOOTP - client on more than one subnet with fixed addresses, more - than one address may be specified in the _f_i_x_e_d_-_a_d_d_r_e_s_s - parameter, or more than one hhoosstt statement may be speci - fied. - - If client-specific boot parameters must change based on - the network to which the client is attached, then multiple - hhoosstt statements should be used. - - If a client is to be booted using a fixed address if it's - possible, but should be allocated a dynamic address other - wise, then a hhoosstt statement must be specified without a - ffiixxeedd--aaddddrreessss clause. _h_o_s_t_n_a_m_e should be a name identify - ing the host. If a _h_o_s_t_n_a_m_e option is not specified for - the host, _h_o_s_t_n_a_m_e is used. - - _H_o_s_t declarations are matched to actual DHCP or BOOTP - clients by matching the dhcp-client-identifier option - specified in the _h_o_s_t declaration to the one supplied by - the client, or, if the _h_o_s_t declaration or the client does - not provide a dhcp-client-identifier option, by matching - the _h_a_r_d_w_a_r_e parameter in the _h_o_s_t declaration to the net - work hardware address supplied by the client. BOOTP - clients do not normally provide a _d_h_c_p_-_c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r, - so the hardware address must be used for all clients that - may boot using the BOOTP protocol. - - TThhee _g_r_o_u_p ssttaatteemmeenntt - - ggrroouupp { - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - The group statement is used simply to apply one or more - parameters to a group of declarations. It can be used to - group hosts, shared networks, subnets, or even other - groups. - - - - - 15 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - -RREEFFEERREENNCCEE:: AALLLLOOWW AANNDD DDEENNYY - The _a_l_l_o_w and _d_e_n_y statements can be used to control the - response of the DHCP server to various sorts of requests. - The allow and deny keywords actually have different mean - ings depending on the context. In a pool context, these - keywords can be used to set up access lists for address - allocation pools. In other contexts, the keywords simply - control general server behaviour with respect to clients - based on scope. In a non-pool context, the _i_g_n_o_r_e key - word can be used in place of the _d_e_n_y keyword to prevent - logging of denied requests. - - -AALLLLOOWW DDEENNYY AANNDD IIGGNNOORREE IINN SSCCOOPPEE - The following usages of allow and deny will work in any - scope, although it is not recommended that they be used in - pool declarations. - - TThhee _u_n_k_n_o_w_n_-_c_l_i_e_n_t_s kkeeyywwoorrdd - - aallllooww uunnkknnoowwnn--cclliieennttss;; - ddeennyy uunnkknnoowwnn--cclliieennttss;; - iiggnnoorree uunnkknnoowwnn--cclliieennttss;; - - The uunnkknnoowwnn--cclliieennttss flag is used to tell dhcpd whether or - not to dynamically assign addresses to unknown clients. - Dynamic address assignment to unknown clients is aalllloowwed - by default. - - TThhee _b_o_o_t_p kkeeyywwoorrdd - - aallllooww bboooottpp;; - ddeennyy bboooottpp;; - iiggnnoorree bboooottpp;; - - The bboooottpp flag is used to tell dhcpd whether or not to - respond to bootp queries. Bootp queries are aalllloowwed by - default. - - TThhee _b_o_o_t_i_n_g kkeeyywwoorrdd - - aallllooww bboooottiinngg;; - ddeennyy bboooottiinngg;; - iiggnnoorree bboooottiinngg;; - - The bboooottiinngg flag is used to tell dhcpd whether or not to - respond to queries from a particular client. This keyword - only has meaning when it appears in a host declaration. - By default, booting is aalllloowwed, but if it is disabled for - a particular client, then that client will not be able to - get and address from the DHCP server. TThhee _d_u_p_l_i_c_a_t_e_s kkeeyy - wwoorrdd - - aallllooww dduupplliiccaatteess;; - - - - 16 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - ddeennyy dduupplliiccaatteess;; - - Host declarations can match client messages based on the - DHCP Client Identifer option or based on the client's net - work hardware type and MAC address. If the MAC address - is used, the host declaration will match any client with - that MAC address - even clients with different client - identifiers. This doesn't normally happen, but is possi - ble when one computer has more than one operating system - installed on it - for example, Microsoft Windows and - NetBSD or Linux. - - The dduupplliiccaatteess flag tells the DHCP server that if a - request is received from a client that matches the MAC - address of a host declaration, any other leases matching - that MAC address should be discarded by the server, even - if the UID is not the same. This is a violation of the - DHCP protocol, but can prevent clients whose client iden - tifiers change regularly from holding many leases at the - same time. By default, duplicates are aalllloowwed. TThhee - _d_e_c_l_i_n_e_s kkeeyywwoorrdd - - aallllooww ddeecclliinneess;; - ddeennyy ddeecclliinneess;; - iiggnnoorree ddeecclliinneess;; - - The DHCPDECLINE message is used by DHCP clients to indi - cate that the lease the server has offered is not valid. - When the server receives a DHCPDECLINE for a particular - address, it normally abandons that address, assuming that - some unauthorized system is using it. Unfortunately, a - malicious or buggy client can, using DHCPDECLINE messages, - completely exhaust the DHCP server's allocation pool. - The server will reclaim these leases, but while the client - is running through the pool, it may cause serious thrash - ing in the DNS, and it will also cause the DHCP server to - forget old DHCP client address allocations. - - The ddeecclliinneess flag tells the DHCP server whether or not to - honor DHCPDECLINE messages. If it is set to ddeennyy or - iiggnnoorree in a particular scope, the DHCP server will not - respond to DHCPDECLINE messages. - -AALLLLOOWW AANNDD DDEENNYY WWIITTHHIINN PPOOOOLL DDEECCLLAARRAATTIIOONNSS - The uses of the allow and deny keyword shown in the previ - ous section work pretty much the same way whether the - client is sending a DHCPDISCOVER or a DHCPREQUEST message - - an address will be allocated to the client (either the - old address it's requesting, or a new address) and then - that address will be tested to see if it's okay to let the - client have it. If the client requested it, and it's not - okay, the server will send a DHCPNAK message. Otherwise, - the server will simply not respond to the client. If it - is okay to give the address to the client, the server will - - - - 17 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - send a DHCPACK message. - - The primary motivation behind pool declarations is to have - address allocation pools whose allocation policies are - different. A client may be denied access to one pool, - but allowed access to another pool on the same network - segment. In order for this to work, access control has - to be done during address allocation, not after address - allocation is done. - - When a DHCPREQUEST message is processed, address alloca - tion simply consists of looking up the address the client - is requesting and seeing if it's still available for the - client. If it is, then the DHCP server checks both the - address pool permit lists and the relevant in-scope allow - and deny statements to see if it's okay to give the lease - to the client. In the case of a DHCPDISCOVER message, the - allocation process is done as described previously in the - ADDRESS ALLOCATION section. - - When declaring permit lists for address allocation pools, - the following syntaxes are recognized following the allow - or deny keyword: - - kknnoowwnn cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to any client that has a host - declaration (i.e., is known). A client is known if it has - a host declaration in _a_n_y scope, not just the current - scope. - - uunnkknnoowwnn cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to any client that has no host - declaration (i.e., is not known). - - mmeemmbbeerrss ooff ""class"";; - - If specified, this statement either allows or prevents - allocation from this pool to any client that is a member - of the named class. - - ddyynnaammiicc bboooottpp cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to any bootp client. - - aauutthheennttiiccaatteedd cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to any client that has been - authenticated using the DHCP authentication protocol. - - - - 18 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - This is not yet supported. - - uunnaauutthheennttiiccaatteedd cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to any client that has not been - authenticated using the DHCP authentication protocol. - This is not yet supported. - - aallll cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to all clients. This can be - used when you want to write a pool declaration for some - reason, but hold it in reserve, or when you want to renum - ber your network quickly, and thus want the server to - force all clients that have been allocated addresses from - this pool to obtain new addresses immediately when they - next renew. - -RREEFFEERREENNCCEE:: PPAARRAAMMEETTEERRSS - TThhee _l_e_a_s_e_-_f_i_l_e_-_n_a_m_e ssttaatteemmeenntt - - lleeaassee--ffiillee--nnaammee _n_a_m_e;; - - _N_a_m_e should be the name of the DHCP server's lease file. - By default, this is /var/db/dhcpd.leases. This statement - mmuusstt appear in the outer scope of the configuration file - - if it appears in some other scope, it will have no effect. - - TThhee _p_i_d_-_f_i_l_e_-_n_a_m_e ssttaatteemmeenntt - - ppiidd--ffiillee--nnaammee _n_a_m_e;; - - _N_a_m_e should be the name of the DHCP server's process ID - file. This is the file in which the DHCP server's pro - cess ID is stored when the server starts. By default, - this is /var/run/dhcpd.pid. Like the lease-file-name - statement, this statement must appear in the outer scope - of the configuration file. - - TThhee _d_e_f_a_u_l_t_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt - - ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;; - - _T_i_m_e should be the length in seconds that will be assigned - to a lease if the client requesting the lease does not ask - for a specific expiration time. - - TThhee _m_a_x_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt - - mmaaxx--lleeaassee--ttiimmee _t_i_m_e;; - - _T_i_m_e should be the maximum length in seconds that will be - - - - 19 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - assigned to a lease. The only exception to this is that - Dynamic BOOTP lease lengths, which are not specified by - the client, are not limited by this maximum. - - TThhee _m_i_n_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt - - mmiinn--lleeaassee--ttiimmee _t_i_m_e;; - - _T_i_m_e should be the minimum length in seconds that will be - assigned to a lease. - - TThhee _m_i_n_-_s_e_c_s ssttaatteemmeenntt - - mmiinn--sseeccss _s_e_c_o_n_d_s;; - - _S_e_c_o_n_d_s should be the minimum number of seconds since a - client began trying to acquire a new lease before the DHCP - server will respond to its request. The number of seconds - is based on what the client reports, and the maximum value - that the client can report is 255 seconds. Generally, - setting this to one will result in the DHCP server not - responding to the client's first request, but always - responding to its second request. - - This can be used to set up a secondary DHCP server which - never offers an address to a client until the primary - server has been given a chance to do so. If the primary - server is down, the client will bind to the secondary - server, but otherwise clients should always bind to the - primary. Note that this does not, by itself, permit a - primary server and a secondary server to share a pool of - dynamically-allocatable addresses. - - TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt - - hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s;; - - In order for a BOOTP client to be recognized, its network - hardware address must be declared using a _h_a_r_d_w_a_r_e clause - in the _h_o_s_t statement. _h_a_r_d_w_a_r_e_-_t_y_p_e must be the name of - a physical hardware interface type. Currently, only the - eetthheerrnneett and ttookkeenn--rriinngg types are recognized, although - support for a ffddddii hardware type (and others) would also - be desirable. The _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s should be a set of - hexadecimal octets (numbers from 0 through ff) seperated - by colons. The _h_a_r_d_w_a_r_e statement may also be used for - DHCP clients. - - TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt - - ffiilleennaammee ""_f_i_l_e_n_a_m_e"";; - - The _f_i_l_e_n_a_m_e statement can be used to specify the name of - the initial boot file which is to be loaded by a client. - - - - 20 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - The _f_i_l_e_n_a_m_e should be a filename recognizable to whatever - file transfer protocol the client can be expected to use - to load the file. - - TThhee _s_e_r_v_e_r_-_n_a_m_e ssttaatteemmeenntt - - sseerrvveerr--nnaammee ""_n_a_m_e"";; - - The _s_e_r_v_e_r_-_n_a_m_e statement can be used to inform the client - of the name of the server from which it is booting. _N_a_m_e - should be the name that will be provided to the client. - - TThhee _n_e_x_t_-_s_e_r_v_e_r ssttaatteemmeenntt - - nneexxtt--sseerrvveerr _s_e_r_v_e_r_-_n_a_m_e;; - - The _n_e_x_t_-_s_e_r_v_e_r statement is used to specify the host - address of the server from which the initial boot file - (specified in the _f_i_l_e_n_a_m_e statement) is to be loaded. - _S_e_r_v_e_r_-_n_a_m_e should be a numeric IP address or a domain - name. If no _n_e_x_t_-_s_e_r_v_e_r parameter applies to a given - client, the DHCP server's IP address is used. - - TThhee _f_i_x_e_d_-_a_d_d_r_e_s_s ssttaatteemmeenntt - - ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];; - - The _f_i_x_e_d_-_a_d_d_r_e_s_s statement is used to assign one or more - fixed IP addresses to a client. It should only appear in - a _h_o_s_t declaration. If more than one address is supplied, - then when the client boots, it will be assigned the - address which corresponds to the network on which it is - booting. If none of the addresses in the _f_i_x_e_d_-_a_d_d_r_e_s_s - statement are on the network on which the client is boot - ing, that client will not match the _h_o_s_t declaration con - taining that _f_i_x_e_d_-_a_d_d_r_e_s_s statement. Each _a_d_d_r_e_s_s should - be either an IP address or a domain name which resolves to - one or more IP addresses. - - TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f ssttaatteemmeenntt - - ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_e;; - - The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f statement sets the ending - time for all leases assigned dynamically to BOOTP clients. - Because BOOTP clients do not have any way of renewing - leases, and don't know that their leases could expire, by - default dhcpd assignes infinite leases to all BOOTP - clients. However, it may make sense in some situations to - set a cutoff date for all BOOTP leases - for example, the - end of a school term, or the time at night when a facility - is closed and all machines are required to be powered off. - - _D_a_t_e should be the date on which all assigned BOOTP leases - - - - 21 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - will end. The date is specified in the form: - - W YYYY/MM/DD HH:MM:SS - - W is the day of the week expressed as a number from zero - (Sunday) to six (Saturday). YYYY is the year, including - the century. MM is the month expressed as a number from 1 - to 12. DD is the day of the month, counting from 1. HH - is the hour, from zero to 23. MM is the minute and SS is - the second. The time is always in Greenwich Mean Time - (GMT), not local time. - - TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h ssttaatteemmeenntt - - ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;; - - The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h statement is used to set - the length of leases dynamically assigned to BOOTP - clients. At some sites, it may be possible to assume - that a lease is no longer in use if its holder has not - used BOOTP or DHCP to get its address within a certain - time period. The period is specified in _l_e_n_g_t_h as a num - ber of seconds. If a client reboots using BOOTP during - the timeout period, the lease duration is reset to _l_e_n_g_t_h, - so a BOOTP client that boots frequently enough will never - lose its lease. Needless to say, this parameter should be - adjusted with extreme caution. - - TThhee _g_e_t_-_l_e_a_s_e_-_h_o_s_t_n_a_m_e_s ssttaatteemmeenntt - - ggeett--lleeaassee--hhoossttnnaammeess _f_l_a_g;; - - The _g_e_t_-_l_e_a_s_e_-_h_o_s_t_n_a_m_e_s statement is used to tell dhcpd - whether or not to look up the domain name corresponding to - the IP address of each address in the lease pool and use - that address for the DHCP _h_o_s_t_n_a_m_e option. If _f_l_a_g is - true, then this lookup is done for all addresses in the - current scope. By default, or if _f_l_a_g is false, no - lookups are done. - - TThhee _u_s_e_-_h_o_s_t_-_d_e_c_l_-_n_a_m_e_s ssttaatteemmeenntt - - uussee--hhoosstt--ddeeccll--nnaammeess _f_l_a_g;; - - If the _u_s_e_-_h_o_s_t_-_d_e_c_l_-_n_a_m_e_s parameter is true in a given - scope, then for every host declaration within that scope, - the name provided for the host declaration will be sup - plied to the client as its hostname. So, for example, - - group { - use-host-decl-names on; - - host joe { - hardware ethernet 08:00:2b:4c:29:32; - - - - 22 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - fixed-address joe.fugue.com; - } - } - - is equivalent to - - host joe { - hardware ethernet 08:00:2b:4c:29:32; - fixed-address joe.fugue.com; - option host-name "joe"; - } - - An _o_p_t_i_o_n _h_o_s_t_-_n_a_m_e statement within a host declaration - will override the use of the name in the host declaration. - - TThhee _a_u_t_h_o_r_i_t_a_t_i_v_e ssttaatteemmeenntt - - aauutthhoorriittaattiivvee;; - - nnoott aauutthhoorriittaattiivvee;; - - The DHCP server will normally assume that the configura - tion information about a given network segment is not - known to be correct and is not authoritative. This is so - that if a naive user installs a DHCP server not fully - understanding how to configure it, it does not send spuri - ous DHCPNAK messages to clients that have obtained - addresses from a legitimate DHCP server on the network. - - Network administrators setting up authoritative DHCP - servers for their networks should always write aauutthhoorriittaa - ttiivvee;; at the top of their configuration file to indicate - that the DHCP server _s_h_o_u_l_d send DHCPNAK messages to mis - configured clients. If this is not done, clients will be - unable to get a correct IP address after changing subnets - until their old lease has expired, which could take quite - a long time. - - Usually, writing aauutthhoorriittaattiivvee;; at the top level of the - file should be sufficient. However, if a DHCP server is - to be set up so that it is aware of some networks for - which it is authoritative and some networks for which it - is not, it may be more appropriate to declare authority on - a per-network-segment basis. - - Note that the most specific scope for which the concept of - authority makes any sense is the physical network segment - - either a shared-network statement or a subnet statement - that is not contained within a shared-network statement. - It is not meaningful to specify that the server is author - itative for some subnets within a shared network, but not - authoritative for others, nor is it meaningful to specify - that the server is authoritative for some host declara - tions and not others. - - - - 23 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - TThhee _a_l_w_a_y_s_-_r_e_p_l_y_-_r_f_c_1_0_4_8 ssttaatteemmeenntt - - aallwwaayyss--rreeppllyy--rrffcc11004488 _f_l_a_g;; - - Some BOOTP clients expect RFC1048-style responses, but do - not follow RFC1048 when sending their requests. You can - tell that a client is having this problem if it is not - getting the options you have configured for it and if you - see in the server log the message "(non-rfc1048)" printed - with each BOOTREQUEST that is logged. - - If you want to send rfc1048 options to such a client, you - can set the aallwwaayyss--rreeppllyy--rrffcc11004488 option in that client's - host declaration, and the DHCP server will respond with an - RFC-1048-style vendor options field. This flag can be - set in any scope, and will affect all clients covered by - that scope. - - TThhee _a_l_w_a_y_s_-_b_r_o_a_d_c_a_s_t ssttaatteemmeenntt - - aallwwaayyss--bbrrooaaddccaasstt _f_l_a_g;; - - The DHCP and BOOTP protocols both require DHCP and BOOTP - clients to set the broadcast bit in the flags field of the - BOOTP message header. Unfortunately, some DHCP and BOOTP - clients do not do this, and therefore may not receive - responses from the DHCP server. The DHCP server can be - made to always broadcast its responses to clients by set - ting this flag to 'on' for the relevant scope. To avoid - creating excess broadcast traffic on your network, we rec - ommend that you restrict the use of this option to as few - clients as possible. For example, the Microsoft DHCP - client is known not to have this problem, as are the Open - Transport and ISC DHCP clients. - - TThhee _o_n_e_-_l_e_a_s_e_-_p_e_r_-_c_l_i_e_n_t ssttaatteemmeenntt - - oonnee--lleeaassee--ppeerr--cclliieenntt _f_l_a_g;; - - If this flag is enabled, whenever a client sends a DHCPRE - QUEST for a particular lease, the server will automati - cally free any other leases the client holds. This pre - sumes that when the client sends a DHCPREQUEST, it has - forgotten any lease not mentioned in the DHCPREQUEST - - i.e., the client has only a single network interface _a_n_d - it does not remember leases it's holding on networks to - which it is not currently attached. Neither of these - assumptions are guaranteed or provable, so we urge caution - in the use of this statement. - - TThhee _u_s_e_-_l_e_a_s_e_-_a_d_d_r_-_f_o_r_-_d_e_f_a_u_l_t_-_r_o_u_t_e ssttaatteemmeenntt - - uussee--lleeaassee--aaddddrr--ffoorr--ddeeffaauulltt--rroouuttee _f_l_a_g;; - - - - - 24 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - If the _u_s_e_-_l_e_a_s_e_-_a_d_d_r_-_f_o_r_-_d_e_f_a_u_l_t_-_r_o_u_t_e parameter is true - in a given scope, then instead of sending the value speci - fied in the routers option (or sending no value at all), - the IP address of the lease being assigned is sent to the - client. This supposedly causes Win95 machines to ARP for - all IP addresses, which can be helpful if your router is - configured for proxy ARP. - - TThhee _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r ssttaatteemmeenntt - - sseerrvveerr--iiddeennttiiffiieerr _h_o_s_t_n_a_m_e;; - - The server-identifier statement can be used to define the - value that is sent in the DHCP Server Identifier option - for a given scope. The value specified mmuusstt be an IP - address for the DHCP server, and must be reachable by all - clients served by a particular scope. - - The use of the server-identifier statement is not recom - mended - the only reason to use it is to force a value - other than the default value to be sent on occasions where - the default value would be incorrect. The default value - is the first IP address associated with the physical net - work interface on which the request arrived. - - The usual case where the _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r statement needs - to be sent is when a physical interface has more than one - IP address, and the one being sent by default isn't appro - priate for some or all clients served by that interface. - Another common case is when an alias is defined for the - purpose of having a consistent IP address for the DHCP - server, and it is desired that the clients use this IP - address when contacting the server. - - Supplying a value for the dhcp-server-identifier option is - equivalent to using the server-identifier statement. - - TThhee _d_d_n_s_-_u_p_d_a_t_e_s ssttaatteemmeenntt - - ddddnnss--uuppddaatteess _f_l_a_g;; - - The _d_d_n_s_-_u_p_d_a_t_e_s parameter controls whether or not the - server will attempt to do a ddns update when a lease is - confirmed. Set this to _o_f_f if the server should not - attempt to do updates within a certain scope. The _d_d_n_s_- - _u_p_d_a_t_e_s parameter is on by default. - -RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS - DHCP option statements are documented in the ddhhccpp-- - ooppttiioonnss((55)) manual page. - -SSEEEE AALLSSOO - dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131. - - - - - 25 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - -AAUUTTHHOORR - ddhhccppdd((88)) was written by Ted Lemon <mellon@vix.com> under a - contract with Vixie Labs. Funding for this project was - provided by the Internet Software Consortium. Information - about the Internet Software Consortium can be found at - hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 26 - - diff --git a/server/dhcpd.leases.cat5 b/server/dhcpd.leases.cat5 deleted file mode 100644 index f509e622..00000000 --- a/server/dhcpd.leases.cat5 +++ /dev/null @@ -1,198 +0,0 @@ - - - -dhcpd.leases(5) dhcpd.leases(5) - - -NNAAMMEE - dhcpd.leases - DHCP client lease database - -DDEESSCCRRIIPPTTIIOONN - The Internet Software Consortium DHCP Server keeps a per - sistent database of leases that it has assigned. This - database is a free-form ASCII file containing a series of - lease declarations. Every time a lease is acquired, - renewed or released, its new value is recorded at the end - of the lease file. So if more than one declaration - appears for a given lease, the last one in the file is the - current one. - - When dhcpd is first installed, there is no lease database. - However, dhcpd requires that a lease database be present - before it will start. To make the initial lease database, - just create an empty file called /var/db/dhcpd.leases. - - In order to prevent the lease database from growing with - out bound, the file is rewritten from time to time. - First, a temporary lease database is created and all known - leases are dumped to it. Then, the old lease database is - renamed /var/db/dhcpd.leases~. Finally, the newly writ - ten lease database is moved into place. - - There is a window of vulnerability where if the dhcpd pro - cess is killed or the system crashes after the old lease - database has been renamed but before the new one has been - moved into place, there will be no /var/db/dhcpd.leases. - In this case, dhcpd will refuse to start, and will require - manual intervention. DDOO NNOOTT simply create a new lease - file when this happens - if you do, you will lose all your - old bindings, and chaos will ensue. Instead, rename - /var/db/dhcpd.leases~ to /var/db/dhcpd.leases, restoring - the old, valid lease file, and then start dhcpd. This - guarantees that a valid lease file will be restored. - -FFOORRMMAATT - Lease descriptions are stored in a format that is parsed - by the same recursive descent parser used to read the - ddhhccppdd..ccoonnff((55)) and ddhhcclliieenntt..ccoonnff((55)) files. Currently, the - only declaration that is used in the dhcpd.leases file is - the lleeaassee declaration. - - lleeaassee _i_p_-_a_d_d_r_e_s_s {{ _s_t_a_t_e_m_e_n_t_s_._._. }} - - Each lease declaration include the single IP address that - has been leased to the client. The statements within the - braces define the duration of the lease and to whom it is - assigned. - - The start and end time of a lease are recorded using the - ``starts'' and ``ends'' statements: - - - - - 1 - - - - - -dhcpd.leases(5) dhcpd.leases(5) - - - ssttaarrttss _d_a_t_e;; - eennddss _d_a_t_e;; - - Dates are specified as follows: - - _w_e_e_k_d_a_y _y_e_a_r//_m_o_n_t_h//_d_a_y _h_o_u_r::_m_i_n_u_t_e::_s_e_c_o_n_d - - The weekday is present to make it easy for a human to tell - when a lease expires - it's specified as a number from - zero to six, with zero being Sunday. The day of week is - ignored on input. The year is specified with the century, - so it should generally be four digits except for really - long leases. The month is specified as a number starting - with 1 for January. The day of the month is likewise - specified starting with 1. The hour is a number between 0 - and 23, the minute a number between 0 and 59, and the sec - ond also a number between 0 and 59. - - Lease times are specified in Greenwich Mean Time (GMT), - not in the local time zone. Since Greenwich is actually - on Daylight Savings Time part of the year, there is proba - bly nowhere in the world where the times recorded on a - lease are always the same as wall clock times. On a unix - machine, one can often figure out the current time in GMT - by typing ddaattee --uu. - - The MAC address of the network interface that was used to - acquire the lease is recorded with the hhaarrddwwaarree statement: - - hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _m_a_c_-_a_d_d_r_e_s_s;; - - The MAC address is specified as a series of hexadecimal - octets, seperated by colons. - - If the client used a client identifier to acquire its - address, the client identifier is recorded using the uuiidd - statement: - - uuiidd _c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r;; - - The client identifier is recorded as a series of hexadeci - mal octets, regardless of whether the client specifies an - ASCII string or uses the newer hardware type/MAC address - format. - - If the client sends a hostname using the _C_l_i_e_n_t _H_o_s_t_n_a_m_e - option, as specified in some versions of the DHCP-DNS - Interaction draft, that hostname is recorded using the - cclliieenntt--hhoossttnnaammee statement. - - cclliieenntt--hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";; - - If the client sends its hostname using the _H_o_s_t_n_a_m_e - option, as Windows 95 does, it is recorded using the - - - - 2 - - - - - -dhcpd.leases(5) dhcpd.leases(5) - - - hhoossttnnaammee statement. - - hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";; - - The DHCP server may determine that a lease has been mis - used in some way, either because a client that has been - assigned a lease NAKs it, or because the server's own - attempt to see if an address is in use prior to reusing it - reveals that the address is in fact already in use. In - that case, the aabbaannddoonneedd statement will be used to indi - cate that the lease should not be reassigned. - - aabbaannddoonneedd;; - - Abandoned leases are reclaimed automatically. When a - client asks for a new address, and the server finds that - there are no new addresses, it checks to see if there are - any abandoned leases, and allocates the least recently - abandoned lease. The standard mechanisms for checking - for lease address conflicts are still followed, so if the - abandoned lease's IP address is still in use, it will be - reabandoned. - - If a client rreeqquueessttss an abandoned address, the server - assumes that the reason the address was abandoned was that - the lease file was corrupted, and that the client is the - machine that responded when the lease was probed, causing - it to be abandoned. In that case, the address is immedi - ately assigned to the client. - -FFIILLEESS - //vvaarr//ddbb//ddhhccppdd..lleeaasseess - -SSEEEE AALLSSOO - dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132, - RFC2131. - -AAUUTTHHOORR - ddhhccppdd((88)) was written by Ted Lemon <mellon@vix.com> under a - contract with Vixie Labs. Funding for this project was - provided by the Internet Software Corporation. Informa - tion about the Internet Software Consortium can be found - at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - 3 - - |