From: Ted Lemon Date: Thu, 10 Jun 1999 00:13:46 +0000 (+0000) Subject: Regenerate. X-Git-Tag: V3-ALPHA-19990608~2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=285da7c75d7fa3f959c78c2f0e411203bdc6aa8f;p=thirdparty%2Fdhcp.git Regenerate. --- diff --git a/client/dhclient-script.cat8 b/client/dhclient-script.cat8 index c7a4c93dc..40271b27e 100644 --- a/client/dhclient-script.cat8 +++ b/client/dhclient-script.cat8 @@ -1,264 +1,264 @@ -Maintenance Procedures dhclient(8) - - - -NNNNAAAAMMMMEEEE - dhclient-script - DHCP client network configuration script - -DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN - The DHCP client network configuration script is invoked from - time to time by ddddhhhhcccclllliiiieeeennnntttt((((8888)))). This script is used by the - dhcp client to set each interface's initial configuration - prior to requesting an address, to test the address once it - has been offered, and to set the interface's final confi- - guration 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 identi- - fied. - - This script is not meant to be customized by the end user. - However, the script may not work on particular versions of - particular operating systems (indeed, no standard script - exists for some operating systems), so a pioneering user may - well need to create a new script or modify an existing one. - In general, customizations specific to a particular computer - should be done in the ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff script. If you - find that you can't make such a customization without cus- - tomizing dhclient.conf, please submit a bug report. - -OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN - 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. +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. -MMMMEEEEDDDDIIIIUUUUMMMM - 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. +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. -PPPPRRRREEEEIIIINNNNIIIITTTT - The DHCP client is requesting that an interface be config- - ured as required in order to send packets prior to receiving - an actual address. For clients which use the BSD socket - library, this means configuring the interface with an IP - address of 0.0.0.0 and a broadcast address of - 255.255.255.255. For other clients, it may be possible to - simply configure the interface up without actually giving it - an IP address at all. The interface name is passed in - $interface, and the media type in $medium. + 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. - 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. + 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. -SunOS 5.6 Last change: 1 + 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 -Maintenance Procedures dhclient(8) -BBBBOOOOUUUUNNNNDDDD - 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 ddddhhhhccccpppp---- - ooooppppttttiiiioooonnnnssss, except that dashes ('-') are replaced by under- - scores ('_') 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. +dhclient-script(8) dhclient-script(8) - 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 parame- - ters 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. + 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. -RRRREEEENNNNEEEEWWWW - 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. + 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. -RRRREEEEBBBBIIIINNNNDDDD - The DHCP client has rebound to a new DHCP server. This can - be handled as with RENEW, except that if the IP address has +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. -SunOS 5.6 Last change: 2 +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 -Maintenance Procedures dhclient(8) - changed, the ARP table should be cleared. -RRRREEEEBBBBOOOOOOOOTTTT - The DHCP client has successfully reacquired its old address - after a reboot. This can be processed as with BOUND. +dhclient-script(8) dhclient-script(8) -EEEEXXXXPPPPIIIIRRRREEEE - 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. -FFFFAAAAIIIILLLL - 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. + 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. -TTTTIIIIMMMMEEEEOOOOUUUUTTTT - The DHCP client has been unable to contact any DHCP servers. - However, an old lease has been identified, and its parame- - ters have been passed in as with BOUND. The client confi- - guration 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. - 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. -FFFFIIIILLLLEEEESSSS - 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 distribu- - tion appear in the distribution tree under client/scripts, - and bear the names of the operating systems 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. -BBBBUUUUGGGGSSSS - If more than one interface is being used, there's no obvious - way to avoid clashes between server-supplied configuration - parameters - for example, the stock dhclient-script rewrites - /etc/resolv.conf. If more than one interface is being con- - figured, /etc/resolv.conf will be repeatedly initialized to - the values provided by one server, and then the other. +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 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.. -SunOS 5.6 Last change: 3 -Maintenance Procedures dhclient(8) - - - - Assuming the information provided by both servers is valid, - this shouldn't cause any real problems, but it could be - confusing. - -SSSSEEEEEEEE AAAALLLLSSSSOOOO - dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) and - dhclient.leases(5). - -AAAAUUUUTTTTHHHHOOOORRRR - ddddhhhhcccclllliiiieeeennnntttt----ssssccccrrrriiiipppptttt((((8888)))) has been written for the Internet - Software Consortium by Ted Lemon in - cooperation with Vixie Enterprises. To learn more about the - Internet Software Consortium, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm////iiiisssscccc.... To - learn more about Vixie Enterprises, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm.... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -SunOS 5.6 Last change: 4 + 4 diff --git a/client/dhclient.cat8 b/client/dhclient.cat8 index 5dfee4499..a9287f08f 100644 --- a/client/dhclient.cat8 +++ b/client/dhclient.cat8 @@ -1,156 +1,159 @@ -Maintenance Procedures dhclient(8) +dhclient(8) dhclient(8) + +NNAAMMEE + dhclient - Dynamic Host Configuration Protocol Client +SSYYNNOOPPSSIISS + ddhhcclliieenntt [ --pp _p_o_r_t ] [ --dd ] [ _i_f_0 [ _._._._i_f_N ] ] -NNNNAAAAMMMMEEEE - dhclient - Dynamic Host Configuration Protocol Client +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. -SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS - ddddhhhhcccclllliiiieeeennnntttt [ ----pppp _p_o_r_t ] [ ----dddd ] [ _i_f_0 [ ..._i_f_N ] ] +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. -DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN - The Internet Software Consortium DHCP Client, dhclient, pro- - vides a means for configuring one or more network interfaces - using the Dynamic Host Configuration Protocol, BOOTP proto- - col, or if these protocols fail, by statically assigning an - address. + 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. -OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN - 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 pro- - vides 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. + 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. - On startup, dhclient reads the _d_h_c_l_i_e_n_t._c_o_n_f for configura- - tion instructions. It then gets a list of all the network - interfaces that are configured in the current system. For - each interface, it attempts to configure the interface using - the DHCP protocol. + 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_p_d_._l_e_a_s_e_s_~ until the next time dhclient rewrites the + database. - 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. + 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 + server becomes available. - 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_p_d._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 una- - vailable when dhclient is first invoked (generally during - the initial system boot process). In that event, old - leases from the dhclient.leases file which have not yet - expired are tested, and if they are determined to be valid, - they are used until either they expire or the DHCP server - becomes available. + 1 -SunOS 5.6 Last change: 1 +dhclient(8) dhclient(8) -Maintenance Procedures dhclient(8) + 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 identify all network interfaces, elimininat­ + ing non-broadcast interfaces if possible, and attempt to + configure each interface. - 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. + If dhclient 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. - 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. + Dhclient will normally run in the foreground until it has + configured an interface, and then will revert to running + in the background. To run force dhclient to always run as + a foreground process, the --dd flag should be specified. + This is useful when running dhclient under a debugger, or + when running it out of inittab on System V systems. -CCCCOOOOMMMMMMMMAAAANNNNDDDD LLLLIIIINNNNEEEE - The names of the network interfaces that dhclient should - attempt to configure may be specified on the command line. - If no interface names are specified on the command line - dhclient will identify all network interfaces, elimininating - non-broadcast interfaces if possible, and attempt to config- - ure each interface. - If dhclient should listen and transmit on a port other than - the standard (port 68), the ----pppp flag may used. It should be - followed by the udp port number that dhclient should use. - This is mostly useful for debugging purposes. +CCOONNFFIIGGUURRAATTIIOONN + The syntax of the dhclient.conf(8) file is discussed + seperately. - Dhclient will normally run in the foreground until it has - configured an interface, and then will revert to running in - the background. To run force dhclient to always run as a - foreground process, the ----dddd flag should be specified. This - is useful when running dhclient under a debugger, or when - running it out of inittab on System V systems. +FFIILLEESS + //eettcc//ddhhcclliieenntt..ccoonnff,, //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess,, + //vvaarr//rruunn//ddhhcclliieenntt..ppiidd,, //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess~~.. -CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN - The syntax of the dhclient.conf(8) file is discussed - seperately. +SSEEEE AALLSSOO + dhcpd(8), dhcrelay(8), dhclient.conf(5), + dhclient.leases(5) -FFFFIIIILLLLEEEESSSS - ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff,,,, ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....lllleeeeaaaasssseeeessss,,,, ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....ppppiiiidddd,,,, - ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....lllleeeeaaaasssseeeessss~~~~.... +AAUUTTHHOORR + ddhhcclliieenntt((88)) has been written for the Internet Software + Consortium by Ted Lemon in cooperation + with Vixie Enterprises. To learn more about the Internet + Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc.. To learn + more about Vixie Enterprises, see hhttttpp::////wwwwww..vviixx..ccoomm.. -SSSSEEEEEEEE AAAALLLLSSSSOOOO - dhcpd(8), dhcrelay(8), dhclient.conf(5), dhclient.leases(5) -AAAAUUUUTTTTHHHHOOOORRRR - ddddhhhhcccclllliiiieeeennnntttt((((8888)))) has been written for the Internet Software Con- - sortium by Ted Lemon in cooperation with - Vixie Enterprises. To learn more about the Internet - Software Consortium, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm////iiiisssscccc.... To learn - more about Vixie Enterprises, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm.... + 2 -SunOS 5.6 Last change: 2 +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. -Maintenance Procedures dhclient(8) + 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. - 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 main- - tain system-specific configuration code to these operating - systems - instead, the shell script can invoke the native - tools to accomplish the same purpose. @@ -186,13 +189,10 @@ Maintenance Procedures dhclient(8) - - - -SunOS 5.6 Last change: 3 + 3 diff --git a/client/dhclient.conf.cat5 b/client/dhclient.conf.cat5 index 8471f0ae4..c561c2158 100644 --- a/client/dhclient.conf.cat5 +++ b/client/dhclient.conf.cat5 @@ -1,594 +1,594 @@ -Headers, Environments, and Macros dhclient.conf(5) +dhclient.conf(5) dhclient.conf(5) +NNAAMMEE + dhclient.conf - DHCP client configuration file -NNNNAAAAMMMMEEEE - 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. -DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN - 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 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. - The dhclient.conf file can be used to configure the - behaviour of the client in a wide variety of ways: protocol - timing, information requested from the server, information - required of the server, defaults to use if the server does - not provide certain information, values with which to over- - ride 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. -PPPPRRRROOOOTTTTOOOOCCCCOOOOLLLL TTTTIIIIMMMMIIIINNNNGGGG - 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: - 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 - _T_h_e ttttiiiimmmmeeeeoooouuuutttt _s_t_a_t_e_m_e_n_t + ttiimmeeoouutt _t_i_m_e ;; - ttttiiiimmmmeeeeoooouuuutttt _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. - 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 timeout has passed, if - there are any static leases defined in the configuration - file, or any leases remaining in the lease database that - have not yet expired, the client will loop through these - leases attempting to validate them, and if it finds one that - appears to be valid, it will use that lease's address. If - there are no valid static leases or unexpired leases in the - lease database, the client will restart the protocol after - the defined retry interval. + 1 -SunOS 5.6 Last change: 1 +dhclient.conf(5) dhclient.conf(5) -Headers, Environments, and Macros 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 rrrreeeettttrrrryyyy _s_t_a_t_e_m_e_n_t + _T_h_e sseelleecctt--ttiimmeeoouutt _s_t_a_t_e_m_e_n_t - rrrreeeettttrrrryyyy _t_i_m_e;;;; + sseelleecctt--ttiimmeeoouutt _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. + 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). - _T_h_e sssseeeelllleeeecccctttt----ttttiiiimmmmeeeeoooouuuutttt _s_t_a_t_e_m_e_n_t + 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. - sssseeeelllleeeecccctttt----ttttiiiimmmmeeeeoooouuuutttt _t_i_m_e;;;; + By default, the select-timeout is zero seconds - that is, + the client will take the first offer it sees. - It is possible (some might say desirable) for there to be - more than one DHCP server serving any given network. In - this case, it is possible that a client may be sent more - than one offer in response to its initial lease discovery - message. It may be that one of these offers is preferable - to the other (e.g., one offer may have the address the - client previously used, and the other may not). + _T_h_e rreebboooott _s_t_a_t_e_m_e_n_t - 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. + rreebboooott _t_i_m_e;; - By default, the select-timeout is zero seconds - that is, - the client will take the first offer it sees. + 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 rrrreeeebbbbooooooootttt _s_t_a_t_e_m_e_n_t + _T_h_e bbaacckkooffff--ccuuttooffff _s_t_a_t_e_m_e_n_t - rrrreeeebbbbooooooootttt _t_i_m_e;;;; + bbaacckkooffff--ccuuttooffff _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. + 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. - _T_h_e bbbbaaaacccckkkkooooffffffff----ccccuuuuttttooooffffffff _s_t_a_t_e_m_e_n_t - bbbbaaaacccckkkkooooffffffff----ccccuuuuttttooooffffffff _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 + 2 -SunOS 5.6 Last change: 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;; -Headers, Environments, and Macros dhclient.conf(5) + 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)). - maximum amount of time that the client is allowed to back - off. It defaults to two minutes. + _T_h_e rreeqquueesstt _s_t_a_t_e_m_e_n_t - _T_h_e iiiinnnniiiittttiiiiaaaallll----iiiinnnntttteeeerrrrvvvvaaaallll _s_t_a_t_e_m_e_n_t + rreeqquueesstt [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n ];; - iiiinnnniiiittttiiiiaaaallll----iiiinnnntttteeeerrrrvvvvaaaallll _t_i_m_e;;;; + 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. - 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 seconds. + _T_h_e rreeqquuiirree _s_t_a_t_e_m_e_n_t -LLLLEEEEAAAASSSSEEEE RRRREEEEQQQQUUUUIIIIRRRREEEEMMMMEEEENNNNTTTTSSSS AAAANNNNDDDD RRRREEEEQQQQUUUUEEEESSSSTTTTSSSS - 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 proto- - col 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. + rreeqquuiirree [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _];; - There is a variety of data contained in offers that DHCP - servers send to DHCP clients. The data that can be specifi- - cally requested is what are called _D_H_C_P _O_p_t_i_o_n_s. DHCP - Options are defined in - ddddhhhhccccpppp----ooooppppttttiiiioooonnnnssss((((5555)))). + 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 rrrreeeeqqqquuuueeeesssstttt _s_t_a_t_e_m_e_n_t + _T_h_e sseenndd _s_t_a_t_e_m_e_n_t - rrrreeeeqqqquuuueeeesssstttt [[[[ _o_p_t_i_o_n ] [,,,, ... _o_p_t_i_o_n ];;;; + 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 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. + 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 - _T_h_e rrrreeeeqqqquuuuiiiirrrreeee _s_t_a_t_e_m_e_n_t - rrrreeeeqqqquuuuiiiirrrreeee [[[[ _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 con- - tain all the listed options will be ignored. + 3 - _T_h_e sssseeeennnndddd _s_t_a_t_e_m_e_n_t - sssseeeennnndddd {{{{ [[[[ _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 +dhclient.conf(5) dhclient.conf(5) -SunOS 5.6 Last change: 3 + protocol 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 infor­ + mation 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. -Headers, Environments, and Macros dhclient.conf(5) + _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. - full option declarations as described in ddddhhhhccccpppp----ooooppppttttiiiioooonnnnssss((((5555)))). - Options that are always sent in the DHCP protocol should not - be specified here, except that the client can specify a - rrrreeeeqqqquuuueeeesssstttteeeedddd----lllleeeeaaaasssseeee----ttttiiiimmmmeeee option other than the default requested - lease time, which is two hours. The other obvious use for - this statement is to send information to the server that - will allow it to differentiate between this client and other - clients or kinds of clients. + _T_h_e pprreeppeenndd _s_t_a_t_e_m_e_n_t -OOOOPPPPTTTTIIIIOOOONNNN MMMMOOOODDDDIIIIFFFFIIIIEEEERRRRSSSS - 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 informa- - tion which is useful, but which needs to be supplemented - with local information. To handle these needs, several - option modifiers are available. + pprreeppeenndd [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;; - _T_h_e ddddeeeeffffaaaauuuulllltttt _s_t_a_t_e_m_e_n_t + 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. - ddddeeeeffffaaaauuuulllltttt [[[[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;;; + _T_h_e aappppeenndd _s_t_a_t_e_m_e_n_t - If for some option the client should use the value supplied - by the server, but needs to use some default value if no - value was supplied by the server, these values can be - defined in the ddddeeeeffffaaaauuuulllltttt statement. + aappppeenndd [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;; - _T_h_e ssssuuuuppppeeeerrrrsssseeeeddddeeee _s_t_a_t_e_m_e_n_t + 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 - ssssuuuuppppeeeerrrrsssseeeeddddeeee [[[[ _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 supplied - by the server, these values can be defined in the ssssuuuuppppeeeerrrrsssseeeeddddeeee - statement. - _T_h_e pppprrrreeeeppppeeeennnndddd _s_t_a_t_e_m_e_n_t + 4 - pppprrrreeeeppppeeeennnndddd [[[[ _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 both a value it - supplies, and then any values supplied by the server, these - values can be defined in the pppprrrreeeeppppeeeennnndddd statement. The - pppprrrreeeeppppeeeennnndddd statement can only be used for options which allow - more than one value to be given. - _T_h_e aaaappppppppeeeennnndddd _s_t_a_t_e_m_e_n_t - aaaappppppppeeeennnndddd [[[[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] ;;;; - If for some option the client should first any values sup- - plied to it by the server, and then some values it supplies, +dhclient.conf(5) dhclient.conf(5) + options which allow more than one value to be given. + This restriction is not enforced - if you ignore it, the + behaviour will be unpredictable. -SunOS 5.6 Last change: 4 +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;; -Headers, Environments, and Macros dhclient.conf(5) + 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 + dhclient.conf file, the interface should also be speci­ + fied, although this is not required. - those values should be defined in the aaaappppppppeeeennnndddd statement. - The aaaappppppppeeeennnndddd statement can only be used for options which - allow more than one value to be given. + ffiixxeedd--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; -LLLLEEEEAAAASSSSEEEE DDDDEEEECCCCLLLLAAAARRRRAAAATTTTIIIIOOOONNNNSSSS - _T_h_e lllleeeeaaaasssseeee _d_e_c_l_a_r_a_t_i_o_n + The ffiixxeedd--aaddddrreessss statement is used to set the ip address - lllleeeeaaaasssseeee {{{{ _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 - PPPPRRRROOOOTTTTOOOOCCCCOOOOLLLL TTTTIIIIMMMMIIIINNNNGGGG) 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 net- - works where there is no DHCP or BOOTP service, so that the - client can still automatically configure its address. This - is done with the lllleeeeaaaasssseeee 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. + 5 - A lease statement consists of the lease keyword, followed by - a left curly brace, followed by one or more lease declara- - tion statements, followed by a right curly brace. The fol- - lowing lease declarations are possible: - bbbboooooooottttpppp;;;; - The bbbboooooooottttpppp statement is used to indicate that the lease was - acquired using the BOOTP protocol rather than the DHCP pro- - tocol. It is never necessary to specify this in the client - configuration file. The client uses this syntax in its - lease database file. - iiiinnnntttteeeerrrrffffaaaacccceeee """"_s_t_r_i_n_g"""";;;; - The iiiinnnntttteeeerrrrffffaaaacccceeee lease statement is used to indicate the inter- - face 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 inter- - face number on which it received that lease. If predefined - leases are specified in the dhclient.conf file, the inter- - face should also be specified, although this is not - required. +dhclient.conf(5) dhclient.conf(5) + 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. -SunOS 5.6 Last change: 5 + 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--lleeaassee((88)).. -Headers, Environments, and Macros dhclient.conf(5) + 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. + 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. - ffffiiiixxxxeeeedddd----aaaaddddddddrrrreeeessssssss _i_p-_a_d_d_r_e_s_s;;;; - The ffffiiiixxxxeeeedddd----aaaaddddddddrrrreeeessssssss statement is used to set the ip address of - a particular lease. This is required for all lease state- - ments. The IP address must be specified as a dotted quad - (e.g., 12.34.56.78). - ffffiiiilllleeeennnnaaaammmmeeee """"_s_t_r_i_n_g"""";;;; - The ffffiiiilllleeeennnnaaaammmmeeee 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. + 6 - sssseeeerrrrvvvveeeerrrr----nnnnaaaammmmeeee """"_s_t_r_i_n_g"""";;;; - The sssseeeerrrrvvvveeeerrrr----nnnnaaaammmmeeee statement specifies the name of the boot - server name to use. This is also not used by the standard - client configuration script. - ooooppppttttiiiioooonnnn _o_p_t_i_o_n-_d_e_c_l_a_r_a_t_i_o_n;;;; - The ooooppppttttiiiioooonnnn statement is used to specify the value of an - option supplied by the server, or, in the case of predefined - leases declared in dhclient.conf, the value that the user - wishes the client configuration script to use if the prede- - fined lease is used. - ssssccccrrrriiiipppptttt """"_s_c_r_i_p_t-_n_a_m_e"""";;;; +dhclient.conf(5) dhclient.conf(5) - The ssssccccrrrriiiipppptttt 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 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 iden- - tified. For more information, see ddddhhhhcccclllliiiieeeennnntttt----lllleeeeaaaasssseeee((((8888)))).... - mmmmeeeeddddiiiiuuuummmm """"_m_e_d_i_a _s_e_t_u_p"""";;;; + rreenneeww _d_a_t_e;; - The mmmmeeeeddddiiiiuuuummmm 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. + rreebbiinndd _d_a_t_e;; - The dhcp client automatically declares this parameter if it - used a media type (see the mmmmeeeeddddiiiiaaaa statement) when configuring - the interface in order to obtain a lease. This statement + 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. -SunOS 5.6 Last change: 6 + 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. + 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 -Headers, Environments, and Macros dhclient.conf(5) + 7 - should be used in predefined leases only if the network - interface requires media type configuration. - rrrreeeennnneeeewwww _d_a_t_e;;;; - rrrreeeebbbbiiiinnnndddd _d_a_t_e;;;; - eeeexxxxppppiiiirrrreeee _d_a_t_e;;;; - The rrrreeeennnneeeewwww 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 rrrreeeebbbbiiiinnnndddd 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 eeeexxxxppppiiiirrrreeee - 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. +dhclient.conf(5) dhclient.conf(5) - These declarations are automatically set in leases acquired - by the DHCP client, but must also be configured in prede- - fined leases - a predefined lease whose expiry time has - passed will not be used by the DHCP client. - Dates are specified as follows: + declaration for the IP alias address, and a subnet-mask + option declaration. A medium statement should never be + included in an alias declaration. - <_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> +OOTTHHEERR DDEECCLLAARRAATTIIOONNSS + rreejjeecctt _i_p_-_a_d_d_r_e_s_s;; - 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 speci- - fied 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. + 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. -AAAALLLLIIIIAAAASSSS DDDDEEEECCCCLLLLAAAARRRRAAAATTTTIIIIOOOONNNNSSSS - aaaalllliiiiaaaassss {{{{ _d_e_c_l_a_r_a_t_i_o_n_s ... }}}} + iinntteerrffaaccee ""_n_a_m_e"" {{ _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 aaaalllliiiiaaaassss declaration. + 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. + 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 -SunOS 5.6 Last change: 7 + 8 -Headers, Environments, and Macros dhclient.conf(5) +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 declaration for the - IP alias address, and a subnet-mask option declaration. A - medium statement should never be included in an alias - declaration. + time on networks with little DHCP activity. The laptop + does roam to multiple networks. -OOOOTTTTHHHHEEEERRRR DDDDEEEECCCCLLLLAAAARRRRAAAATTTTIIIIOOOONNNNSSSS - rrrreeeejjjjeeeecccctttt _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 iden- - tifier. This can be used to avoid being configured by - rogue or misconfigured dhcp servers, although it should be a - last resort - better to track down the bad DHCP server and - fix it. + timeout 60; + retry 60; + reboot 10; + select-timeout 5; + initial-interval 2; + reject 192.33.137.209; - iiiinnnntttteeeerrrrffffaaaacccceeee """"_n_a_m_e"""" {{{{ _d_e_c_l_a_r_a_t_i_o_n_s ... }}}} + interface "ep0" { + send host-name "andare.fugue.com"; + send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; + send dhcp-lease-time 3600; + supersede domain-name "fugue.com rc.vix.com home.vix.com"; + prepend domain-name-servers 127.0.0.1; + request subnet-mask, broadcast-address, time-offset, routers, + domain-name, domain-name-servers, host-name; + require subnet-mask, domain-name-servers; + script "/etc/dhclient-script"; + media "media 10baseT/UTP", "media 10base2/BNC"; + } - A client with more than one network interface may require - different behaviour depending on which interface is being - configured. All timing parameters and declarations other - than lease and alias declarations can be enclosed in an - interface declaration, and those parameters will then be - used only for the interface that matches the specified name. - Interfaces for which there is no interface declaration will - use the parameters declared outside of any interface - declaration, or the default settings. + 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. - mmmmeeeeddddiiiiaaaa """"_m_e_d_i_a _s_e_t_u_p"""" [ ,,,, """"_m_e_d_i_a _s_e_t_u_p"""",,,, ... ];;;; +SSEEEE AALLSSOO + dhcp-options(5), dhclient.leases(5), dhcpd(8), + dhcpd.conf(5), RFC2132, RFC2131. - The mmmmeeeeddddiiiiaaaa statement defines one or more media configuration - parameters which may be tried while attempting to acquire an - IP address. The dhcp client will cycle through each media - setup string on the list, configuring the interface using - that setup and attempting to boot, and then trying the next - one. This can be used for network interfaces which aren't - capable of sensing the media type unaided - whichever media - type succeeds in getting a request to the server and hearing - the reply is probably right (no guarantees). +AAUUTTHHOORR + ddhhcclliieenntt((88)) was written by Ted Lemon + 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.. - The media setup is only used for the initial phase of - address acquisition (the DHCPDISCOVER and DHCPOFFER - packtes). 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. -SunOS 5.6 Last change: 8 -Headers, Environments, and Macros dhclient.conf(5) - -SSSSAAAAMMMMPPPPLLLLEEEE - The following configuration file is used on a laptop running - NetBSD 1.3. The laptop has an IP alias of 192.5.5.213, and - has one interface, ep0 (a 3com 3C589C). Booting intervals - have been shortened somewhat from the default, because the - client is known to spend most of its time on networks with - little DHCP activity. The laptop does roam to multiple - networks. - - - timeout 60; - retry 60; - reboot 10; - select-timeout 5; - initial-interval 2; - reject 192.33.137.209; - - interface "ep0" { - send host-name "andare.fugue.com"; - send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; - send dhcp-lease-time 3600; - supersede domain-name "fugue.com rc.vix.com home.vix.com"; - prepend domain-name-servers 127.0.0.1; - request subnet-mask, broadcast-address, time-offset, routers, - domain-name, domain-name-servers, host-name; - require subnet-mask, domain-name-servers; - script "/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 general, - yours should be much simpler. In many cases, it's suffi- - cient to just create an empty dhclient.conf file - the - defaults are usually fine. - -SSSSEEEEEEEE AAAALLLLSSSSOOOO - dhcp-options(5), dhclient.leases(5), dhcpd(8), - dhcpd.conf(5), RFC2132, RFC2131. - -AAAAUUUUTTTTHHHHOOOORRRR - ddddhhhhcccclllliiiieeeennnntttt((((8888)))) was written by Ted Lemon 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 - hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc.... - - - - - -SunOS 5.6 Last change: 9 - + 9 diff --git a/client/dhclient.leases.cat5 b/client/dhclient.leases.cat5 index 1aa044c2f..1add3996f 100644 --- a/client/dhclient.leases.cat5 +++ b/client/dhclient.leases.cat5 @@ -1,38 +1,38 @@ -Headers, Environments, and Macros dhclient.leases(5) +dhclient.leases(5) dhclient.leases(5) +NNAAMMEE + dhclient.leases - DHCP client lease database -NNNNAAAAMMMMEEEE - 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. -DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN - 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)).. - The format of the lease declarations is described in - ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff((((5555)))).... +FFIILLEESS + //vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess -FFFFIIIILLLLEEEESSSS - ////eeeettttcccc////ddddhhhhcccclllliiiieeeennnntttt....lllleeeeaaaasssseeeessss +SSEEEE AALLSSOO + dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8), + dhcpd.conf(5), RFC2132, RFC2131. -SSSSEEEEEEEE AAAALLLLSSSSOOOO - dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8), - dhcpd.conf(5), RFC2132, RFC2131. +AAUUTTHHOORR + ddhhcclliieenntt((88)) was written by Ted Lemon + 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.. -AAAAUUUUTTTTHHHHOOOORRRR - ddddhhhhcccclllliiiieeeennnntttt((((8888)))) was written by Ted Lemon 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 - hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc.... @@ -60,7 +60,7 @@ AAAAUUUUTTTTHHHHOOOORRRR -SunOS 5.6 Last change: 1 + 1 diff --git a/common/dhcp-options.cat5 b/common/dhcp-options.cat5 index df8202e3f..08b4297f1 100644 --- a/common/dhcp-options.cat5 +++ b/common/dhcp-options.cat5 @@ -50,14 +50,14 @@ RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS can be either true or false (or on or off, if that makes more sense to you). - The ddaattaa--ssttrriinngg data type specifies either an NVT ASCII - string enclosed in double quotes, or a series of octets - specified in hexadecimal, seperated by colons. For exam­ - ple: + 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 client-identifier "CLIENT-FOO"; + option dhcp-client-identifier "CLIENT-FOO"; or - option client-identifier 43:4c:49:45:54:2d:46:4f:4f; + option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f; + @@ -70,57 +70,57 @@ RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS 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 _i_s _t_h_e _d_e_c_i_m_a_l + The documentation for the various options mentioned below + is taken from the latest IETF draft document on DHCP + options. Options which are not listed by name may be + defined by the name option-_n_n_n, where _n_n_n _i_s _t_h_e _d_e_c_i_m_a_l _n_u_m_b_e_r _o_f _t_h_e _o_p_t_i_o_n _c_o_d_e_. _T_h_e_s_e _o_p_t_i_o_n_s _m_a_y _b_e _f_o_l_l_o_w_e_d - _e_i_t_h_e_r _b_y _a _s_t_r_i_n_g_, _e_n_c_l_o_s_e_d _i_n _q_u_o_t_e_s_, _o_r _b_y _a _s_e_r_i_e_s _o_f - _o_c_t_e_t_s_, _e_x_p_r_e_s_s_e_d _a_s _t_w_o_-_d_i_g_i_t _h_e_x_a_d_e_c_i_m_a_l _n_u_m_b_e_r_s _s_e_p_e_r_­ + _e_i_t_h_e_r _b_y _a _s_t_r_i_n_g_, _e_n_c_l_o_s_e_d _i_n _q_u_o_t_e_s_, _o_r _b_y _a _s_e_r_i_e_s _o_f + _o_c_t_e_t_s_, _e_x_p_r_e_s_s_e_d _a_s _t_w_o_-_d_i_g_i_t _h_e_x_a_d_e_c_i_m_a_l _n_u_m_b_e_r_s _s_e_p_e_r_­ _a_t_e_d _b_y _c_o_l_o_n_s_. _F_o_r _e_x_a_m_p_l_e_: 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­ + 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 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 + 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 + network on which an address is being assigned. How­ + ever, _a_n_y subnet-mask option declaration that is in + scope for the address being assigned will override the subnet mask specified in the subnet declaration. ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2;; - The time-offset option specifies the offset of the - client's subnet in seconds from Coordinated Universal + The time-offset option specifies the offset of the + client's subnet in seconds from Coordinated Universal Time (UTC). ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; The routers option specifies a list of IP addresses for - routers on the client's subnet. Routers should be + routers on the client's subnet. Routers should be listed in order of preference. 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 + servers available to the client. Servers should be listed in order of preference. 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 + 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 ddoommaaiinn--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; @@ -136,20 +136,20 @@ dhcpd-options(5) dhcpd-options(5) dhcpd-options(5) dhcpd-options(5) - 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 + 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 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 + 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 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 + The cookie server option specifies a list of RFC 865 cookie servers available to the client. Servers should be listed in order of preference. @@ -161,23 +161,23 @@ dhcpd-options(5) dhcpd-options(5) 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 + The impress-server option specifies a list of Imagen Impress servers available 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... ];; - This option specifies a list of RFC 887 Resource Loca­ - tion servers available to the client. Servers should + 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 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 + 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 bboooott--ssiizzee _u_i_n_t_1_6;; @@ -187,8 +187,8 @@ dhcpd-options(5) dhcpd-options(5) ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g;; - This option specifies the path-name of a file to which - the client's core image should be dumped in the event + 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 @@ -202,52 +202,52 @@ dhcpd-options(5) dhcpd-options(5) dhcpd-options(5) dhcpd-options(5) - character string consisting of characters from the NVT + character string consisting of characters from the NVT ASCII character set. ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g;; - This option specifies the domain name that client + This option specifies the domain name that client should use when resolving hostnames via the Domain Name System. ooppttiioonn sswwaapp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s;; - This specifies the IP address of the client's swap + This specifies the IP address of the client's swap server. ooppttiioonn rroooott--ppaatthh _s_t_r_i_n_g;; - This option specifies the path-name that contains the + 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 + ter string consisting of characters from the NVT ASCII character set. 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 0 - means disable IP forwarding, and a value of 1 means + ure its IP layer for packet forwarding. A value of 0 + means disable IP forwarding, and a value of 1 means enable IP forwarding. 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 + 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 - forwarding of such datagrams, and a value of 1 means + forwarding of such datagrams, and a value of 1 means allow forwarding. - 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 + 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 + 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 + Any source routed datagram whose next-hop address does not match one of the filters should be discarded by the client. @@ -255,7 +255,7 @@ dhcpd-options(5) dhcpd-options(5) ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6;; - This option specifies the maximum size datagram that + This option specifies the maximum size datagram that @@ -278,16 +278,16 @@ dhcpd-options(5) dhcpd-options(5) 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 + 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­ + 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 iinntteerrffaaccee--mmttuu _u_i_n_t_1_6;; @@ -297,27 +297,27 @@ dhcpd-options(5) dhcpd-options(5) 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 + This option specifies whether or not the client may + assume that all subnets of the IP network to which the + client is connected use the same MTU as the subnet of that network to which the client is directly connected. - A value of 1 indicates that all subnets share the same - MTU. A value of 0 means that the client should assume + A value of 1 indicates that all subnets share the same + MTU. A value of 0 means that the client should assume that some subnets of the directly connected network may have smaller MTUs. ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; - 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 + 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). ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g;; - This option specifies whether or not the client should + This option specifies whether or not the client should perform subnet mask discovery using ICMP. A value of 0 - indicates that the client should not perform mask dis­ + indicates that the client should not perform mask dis­ covery. A value of 1 means that the client should per­ form mask discovery. @@ -334,58 +334,58 @@ dhcpd-options(5) dhcpd-options(5) dhcpd-options(5) dhcpd-options(5) - This option specifies whether or not the client should + This option specifies whether or not the client should respond to subnet mask requests using ICMP. A value of - 0 indicates that the client should not respond. A + 0 indicates that the client should not respond. A value of 1 means that the client should respond. ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g;; - This option specifies whether or not the client should - solicit routers using the Router Discovery mechanism - defined in RFC 1256. A value of 0 indicates that the + This option specifies whether or not the client should + solicit routers using the Router Discovery mechanism + defined in RFC 1256. A value of 0 indicates that the client should not perform router discovery. A value of - 1 means that the client should perform router discov­ + 1 means that the client should perform router discov­ ery. ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;; - This option specifies the address to which the client + This option specifies the address to which the client should transmit router solicitation requests. - 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 + 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 + 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­ + 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 default route (0.0.0.0) is an illegal destination + for a static route. To specify the default route, use the rroouutteerrss option. ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g;; - This option specifies whether or not the client should + 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 + the ARP protocol. A value of 0 indicates that the + client should not attempt to use trailers. A value of 1 means that the client should attempt to use trailers. ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2;; - This option specifies the timeout in seconds for ARP + This option specifies the timeout in seconds for ARP cache entries. 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 + This option specifies whether or not the client should + use Ethernet Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the interface is an Ethernet. A value of 0 indicates that the client should use RFC 894 @@ -400,39 +400,39 @@ dhcpd-options(5) dhcpd-options(5) dhcpd-options(5) dhcpd-options(5) - encapsulation. A value of 1 means that the client + encapsulation. A value of 1 means that the client should use RFC 1042 encapsulation. 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 + This option specifies the default TTL that the client + should use when sending TCP segments. The minimum value is 1. 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 + 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. 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 0 indicates that a garbage octet should not - be sent. A value of 1 indicates that a garbage octet + This option specifies the whether or not the client + should send TCP keepalive messages with a octet of + garbage for compatibility with older implementations. + A value of 0 indicates that a garbage octet should not + be sent. A value of 1 indicates that a garbage octet should be sent. ooppttiioonn nniiss--ddoommaaiinn _s_t_r_i_n_g;; This option specifies the name of the client's NIS (Sun - Network Information Services) domain. The domain is - formatted as a character string consisting of charac­ + 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... ];; @@ -444,16 +444,16 @@ dhcpd-options(5) dhcpd-options(5) 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. + NTP (RFC 1035) servers available to the client. Servers should be listed in order of preference. - ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... + 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 + 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 @@ -470,15 +470,15 @@ dhcpd-options(5) dhcpd-options(5) 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 + The NetBIOS datagram distribution server (NBDD) option + specifies a list of RFC 1001/1002 NBDD servers listed in order of preference. ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8;; 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 + 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: @@ -494,31 +494,31 @@ dhcpd-options(5) dhcpd-options(5) ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g;; - The NetBIOS scope option specifies the NetBIOS over - TCP/IP scope parameter for the client as specified in - RFC 1001/1002. See RFC1001, RFC1002, and RFC1035 for + The NetBIOS scope option specifies the NetBIOS over + TCP/IP scope parameter for the client as specified in + RFC 1001/1002. See RFC1001, RFC1002, and RFC1035 for character-set restrictions. 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 + This option specifies a list of X Window System Font + servers available to the client. Servers should be listed in order of preference. 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­ + 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 + able to the client. Addresses should be listed in order of preference. - ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _d_a_t_a_-_s_t_r_i_n_g;; + 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 + This option can be used to specify the a DHCP client + identifier in a host declaration, so that dhcpd can + find the host record by matching against the client identifier. - + ooppttiioonn nniisspplluuss--ddoommaaiinn _s_t_r_i_n_g;; @@ -532,6 +532,101 @@ dhcpd-options(5) dhcpd-options(5) dhcpd-options(5) dhcpd-options(5) + 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 ttffttpp--sseerrvveerr--nnaammee _s_t_r_i_n_g;; + + This option is used to identify a TFTP server and, if + supported by the client, should have the same effect as + the sseerrvveerr--nnaammee declaration. BOOTP clients are + unlikely to support this option. Some DHCP clients + will support it, and others actually require it. + + ooppttiioonn bboooottffiillee--nnaammee _s_t_r_i_n_g;; + + This option is used to identify a bootstrap file. If + supported by the client, it should have the same effect + as the ffiilleennaammee declaration. BOOTP clients are + unlikely to support this option. Some DHCP clients + will support it, and others actually require it. + + ooppttiioonn mmoobbiillee--iipp--hhoommee--aaggeenntt _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; + + This option specifies a list of IP addresses indicating + mobile IP home agents available to the client. Agents + should be listed in order of preference, although nor­ + mally there will be only one such agent. + + ooppttiioonn ssmmttpp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];; + + The SMTP server option specifies a list of SMTP servers + available to the client. Servers should be listed in + order of preference. + + 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 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 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 + + + + 9 + + + + + +dhcpd-options(5) dhcpd-options(5) + + + to the client. Servers should be listed in order of + preference. + + 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 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 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 ssttrreeeettaallkk--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. + RREELLAAYY AAGGEENNTT IINNFFOORRMMAATTIIOONN OOPPTTIIOONN An IETF draft, draft-ietf-dhc-agent-options-03.txt, defines a series of encapsulated options that a relay @@ -548,18 +643,32 @@ RREELLAAYY AAGGEENNTT IINNFFOORRMMAATTIIOONN OOPPTTIIO 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 _d_a_t_a_-_s_t_r_i_n_g;; + 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 + + + + 10 + + + + + +dhcpd-options(5) dhcpd-options(5) + + 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..cciirrccuuiitt--iidd _d_a_t_a_-_s_t_r_i_n_g;; + 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 @@ -570,17 +679,193 @@ RREELLAAYY AAGGEENNTT IINNFFOORRMMAATTIIOONN OOPPTTIIO be an opaque object that is administratively guaranteed to be unique to a particular remote end of a circuit. +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 + 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: + + + + + 11 + + + + + +dhcpd-options(5) dhcpd-options(5) + + + 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 + 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; + + + + 12 + + + + + +dhcpd-options(5) dhcpd-options(5) + + + 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 { + 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; + + SSEEEE AALLSSOO dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp- - eval(5), dhcpd(8), dhclient(8), RFC2132, RFC2131, draft- + 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 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 + The Internet Software Consortium DHCP Distribution was + + + + 13 + + + + + +dhcpd-options(5) dhcpd-options(5) + + + written by Ted Lemon 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.. @@ -589,6 +874,51 @@ AAUUTTHHOORR - 9 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 14 diff --git a/relay/dhcrelay.cat8 b/relay/dhcrelay.cat8 index 4254a3417..7fc01a729 100644 --- a/relay/dhcrelay.cat8 +++ b/relay/dhcrelay.cat8 @@ -1,214 +1,218 @@ -Maintenance Procedures dhcrelay(8) +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. -NNNNAAAAMMMMEEEE - dhcrelay - Dynamic Host Configuration Protocol Relay Agent +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. -SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS - ddddhhhhccccrrrreeeellllaaaayyyy [ ----pppp _p_o_r_t ] [ ----dddd ] [ ----qqqq ] [ ----iiii _i_f_0 [ ............ ----iiii _i_f_N ] ] - [ ----aaaa ] [ ----AAAA _l_e_n_g_t_h ] [ ----DDDD ] [ ----mmmm _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 ] + 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. -DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN - The Internet Software Consortium DHCP Relay Agent, dhcrelay, - provides a means for relaying DHCP and BOOTP requests from a - subnet to which no DHCP server is directly to one or more - DHCP servers on other subnets. + 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. -OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN - 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 ori- - ginal request came. + 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. -CCCCOOOOMMMMMMMMAAAANNNNDDDD LLLLIIIINNNNEEEE - The names of the network interfaces that dhcrelay should - attempt to configure may be specified on the command line - using the ----iiii option. If no interface names are specified on - the command line dhcrelay will identify all network inter- - faces, elimininating non-broadcast interfaces if possible, - and attempt to configure each interface. + 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 - If a relay agent is running on a system that is connected to - one or more networks on which no DHCP servers are present, - 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 ----iiii 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 ----pppp flag may used. It should be - followed by the udp port number that dhcrelay should use. - This is mostly useful for debugging purposes. + 1 -SunOS 5.6 Last change: 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. -Maintenance Procedures dhcrelay(8) + _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). - Dhcrelay will normally run in the foreground until it has - configured an interface, and then will revert to running in - the background. To run force dhcrelay to always run as a - foreground process, the ----dddd flag should be specified. This - is useful when running dhcrelay under a debugger, or when - running it out of inittab on System V systems. + 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. - Dhcrelay will normally print its network configuration on - startup. This can be annoying in a system startup script - - to disable this behaviour, specify the ----qqqq flag. -RRRREEEELLLLAAAAYYYY AAAAGGGGEEEENNNNTTTT IIIINNNNFFFFOOOORRRRMMMMAAAATTTTIIIIOOOONNNN OOOOPPPPTTTTIIIIOOOONNNNSSSS - If the ----aaaa 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. Currently, - 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. + 2 - 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 max- - imum packet size of 576 bytes. - It is recommended that with the Internet Software Consortium - 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 specifying the ----AAAA - 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 running +dhcrelay(8) dhcrelay(8) -SunOS 5.6 Last change: 2 + 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. -Maintenance Procedures dhcrelay(8) +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. - 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. +AAUUTTHHOORR + ddhhccrreellaayy((88)) has been written for the Internet Software + Consortium by Ted Lemon in cooperation + with Vixie Enterprises. To learn more about the Internet + Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc.. To learn - 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 ----mmmm flag, followed by one of the four keywords specified - in _i_t_a_l_i_c_s above. + 3 - When the relay agent receives a reply from a server that - it's supposed to forward to a client, and Relay Agent Infor- - mation 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 Informa- - tion option field containing an Agent ID suboption 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 ----DDDD - option is specified, all packets that don't contain a match - will be dropped. -SSSSPPPPEEEECCCCIIIIFFFFYYYYIIIINNNNGGGG DDDDHHHHCCCCPPPP SSSSEEEERRRRVVVVEEEERRRRSSSS - 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. -SSSSEEEEEEEE AAAALLLLSSSSOOOO - dhclient(8), dhcpd(8), RFC2132, RFC2131, draft-ietf-dhc- - agent-options-03.txt. -BBBBUUUUGGGGSSSS - 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 phy- - sical network to DHCP servers on the same physical network - - if they do, the server will receive duplicate packets. 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. +dhcrelay(8) dhcrelay(8) + more about Vixie Enterprises, see hhttttpp::////wwwwww..vviixx..ccoomm.. -SunOS 5.6 Last change: 3 -Maintenance Procedures dhcrelay(8) -AAAAUUUUTTTTHHHHOOOORRRR - ddddhhhhccccrrrreeeellllaaaayyyy((((8888)))) has been written for the Internet Software Con- - sortium by Ted Lemon in cooperation with - Vixie Enterprises. To learn more about the Internet - Software Consortium, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm////iiiisssscccc.... To learn - more about Vixie Enterprises, see hhhhttttttttpppp::::////////wwwwwwwwwwww....vvvviiiixxxx....ccccoooommmm.... @@ -255,10 +259,6 @@ AAAAUUUUTTTTHHHHOOOORRRR - - - -SunOS 5.6 Last change: 4 - + 4 diff --git a/server/dhcpd.cat8 b/server/dhcpd.cat8 index 781b42dcb..8d3381d54 100644 --- a/server/dhcpd.cat8 +++ b/server/dhcpd.cat8 @@ -1,353 +1,372 @@ -Maintenance Procedures dhcpd(8) +dhcpd(8) dhcpd(8) + + +NNAAMMEE + dhcpd - Dynamic Host Configuration Protocol Server + +SSYYNNOOPPSSIISS + ddhhccppdd [ --pp _p_o_r_t ] [ --ff ] [ --dd ] [ --qq ] [ --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. -NNNNAAAAMMMMEEEE - dhcpd - Dynamic Host Configuration Protocol Server + 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. -SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS - ddddhhhhccccppppdddd [ ----pppp _p_o_r_t ] [ ----ffff ] [ ----dddd ] [ ----qqqq ] [ ----ccccffff _c_o_n_f_i_g-_f_i_l_e ] [ - ----llllffff _l_e_a_s_e-_f_i_l_e ] [ _i_f_0 [ ..._i_f_N ] ] - -DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN - The Internet Software Consortium DHCP Server, dhcpd, imple- - ments 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 network to which they - are attached. BOOTP provides similar functionality, with - certain restrictions. - -CCCCOOOONNNNTTTTRRRRIIIIBBBBUUUUTTTTIIIIOOOONNNNSSSS - Development of this software is funded through contributions - and support contracts. Please see ddddhhhhccccpppp----ccccoooonnnnttttrrrriiiibbbb((((5555)))) for - information on how you can contribute. - -OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN - The DHCP protocol allows a host which is unknown to the net- - work 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 allocates - address pools in each subnet and enters them into the - dhcpd.conf(5) file. + 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. - 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. + 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. - 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. +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. -SunOS 5.6 Last change: 1 + 2 +dhcpd(8) dhcpd(8) -Maintenance Procedures 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. - New leases are appended to the end of the dhcpd.leases file. - In order to prevent the file from becoming 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 infor- - mation, so there is no need for a special crash recovery - process. + 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. - BOOTP support is also provided by this server. Unlike DHCP, - the BOOTP protocol does not provide a protocol for recover- - ing 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 perpetuity, although the - network administrator may set an earlier cutoff date or a - shorter lease length for BOOTP leases if that makes sense. + 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. - 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. + 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. - 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 /_e_t_c/_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 automati- - cally restart itself when it sees a change to the dhcpd.conf - file. +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. - 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 techn- - ically 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. -CCCCOOOOMMMMMMMMAAAANNNNDDDD LLLLIIIINNNNEEEE - 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 speci- - fied on the command line dhcpd will identify all network - interfaces which are up, elimininating non-broadcast +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. + 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: -SunOS 5.6 Last change: 2 + subnet 239.252.197.0 netmask 255.255.255.0 { + 3 -Maintenance Procedures dhcpd(8) +dhcpd(8) dhcpd(8) - interfaces if possible, and listen for DHCP broadcasts on - each interface. - If dhcpd should listen on a port other than the standard - (port 67), the ----pppp flag may used. It should be followed by - the udp port number on which dhcpd should listen. This is - mostly useful for debugging purposes. + range 239.252.197.10 239.252.197.107; + range 239.252.197.113 239.252.197.250; + } - To run dhcpd as a foreground process, rather than allowing - it to run as a daemon in the background, the ----ffff flag should - be specified. This is useful when running dhcpd under a - debugger, or when running it out of inittab on System V sys- - tems. + 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. - To have dhcpd log to the standard error descriptor, specify - the ----dddd 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 cannot 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 ----ccccffff flag, or an alternate lease file with the ----llllffff - flag. Because of the importance of using the same lease - database at all times when running dhcpd in production, - these options should be used oooonnnnllllyyyy for testing lease files or - database files in a non-production environment. +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. - 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 mes- - sage, the ----qqqq flag may be specified. + 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. -CCCCOOOONNNNFFFFIIIIGGGGUUUURRRRAAAATTTTIIIIOOOONNNN - The syntax of the dhcpd.conf(5) file is discussed - seperately. This section should be used as an overview of - the configuration process, and the dhcpd.conf(5) documenta- - tion should be consulted for detailed reference information. + 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: -SSSSuuuubbbbnnnneeeettttssss - 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. - 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.107; + default-lease-time 600; + max-lease-time 7200; + | - subnet 239.252.197.0 netmask 255.255.255.0 { - range 239.252.197.10 239.252.197.250; - } + 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 + 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 -SunOS 5.6 Last change: 3 + 4 -Maintenance Procedures dhcpd(8) +dhcpd(8) dhcpd(8) + bootp client declaration might look like this: - Multiple address ranges may be specified like this: + host haagen { + hardware ethernet 08:00:2b:4c:59:23; + fixed-address 239.252.197.9; + filename "/tftpboot/haagen.boot"; + } - 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; - } +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). - 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. + 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: -LLLLeeeeaaaasssseeee LLLLeeeennnnggggtttthhhhssss - 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. + 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"; + } - 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 appliance - before packaging it up for delivery. + 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: - 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: + 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"; + } - 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; - | + A more complete description of the dhcpd.conf file syntax + is provided in dhcpd.conf(5). - 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). +FFIILLEESS + //eettcc//ddhhccppdd..ccoonnff,, //vvaarr//ddbb//ddhhccppdd..lleeaasseess,, //vvaarr//rruunn//ddhhccppdd..ppiidd,, + //vvaarr//ddbb//ddhhccppdd..lleeaasseess~~.. - 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 have widely - disparate values for default and maximum lease times on each - subnet. -BBBBOOOOOOOOTTTTPPPP SSSSuuuuppppppppoooorrrrtttt - 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 -SunOS 5.6 Last change: 4 + 5 +dhcpd(8) dhcpd(8) -Maintenance Procedures dhcpd(8) +SSEEEE AALLSSOO + dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5) +AAUUTTHHOORR + ddhhccppdd((88)) was written by Ted Lemon 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.. - 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"; - } -OOOOppppttttiiiioooonnnnssss - 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 precedence. 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 different - 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"; - } - A more complete description of the dhcpd.conf file syntax is - provided in dhcpd.conf(5). -SunOS 5.6 Last change: 5 -Maintenance Procedures dhcpd(8) -FFFFIIIILLLLEEEESSSS - ////eeeettttcccc////ddddhhhhccccppppdddd....ccccoooonnnnffff,,,, ////eeeettttcccc////ddddhhhhccccppppdddd....lllleeeeaaaasssseeeessss,,,, ////eeeettttcccc////ddddhhhhccccppppdddd....ppppiiiidddd,,,, - ////eeeettttcccc////ddddhhhhccccppppdddd....lllleeeeaaaasssseeeessss~~~~.... -SSSSEEEEEEEE AAAALLLLSSSSOOOO - dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5) -AAAAUUUUTTTTHHHHOOOORRRR - ddddhhhhccccppppdddd((((8888)))) was written by Ted Lemon 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 - hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc.... @@ -372,25 +391,6 @@ AAAAUUUUTTTTHHHHOOOORRRR - - - - - - - - - - - - - - - - - - -SunOS 5.6 Last change: 6 - + 6 diff --git a/server/dhcpd.conf.cat5 b/server/dhcpd.conf.cat5 index cfd018fbb..a9def2541 100644 --- a/server/dhcpd.conf.cat5 +++ b/server/dhcpd.conf.cat5 @@ -1,1040 +1,1370 @@ -Headers, Environments, and Macros dhcpd.conf(5) +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, + there is currently no way to group parameter assignments + other than by network topology. + + When a client is to be booted, its boot parameters are + determined by first consulting that client's _h_o_s_t declara­ + tion (if any), then consulting the _g_r_o_u_p declaration (if + any) which enclosed that _h_o_s_t declaration, then consulting + the _s_u_b_n_e_t declaration for the subnet on which the client + is booting, then consulting the _s_h_a_r_e_d_-_n_e_t_w_o_r_k declaration + (if any) containing that subnet, and finally consulting + the top-level parameters which may be specified outside of + any declaration. + + 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; + } + + 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; + } -NNNNAAAAMMMMEEEE - dhcpd.conf - dhcpd configuration file + 2 -DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN - 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-insensitive. Com- - ments may be placed anywhere within the file (except within - quotes). Comments begin with the # character 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 gateway - 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. +dhcpd.conf(5) dhcpd.conf(5) - 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 declaration. For - clients with statically assigned addresses, or for installa- - tions where only known clients will be served, each such - client must have a _h_o_s_t declaration. If parameters 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 subnet - 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 dynam- - ically allocated on that subnet. + 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; -SunOS 5.6 Last change: 1 + 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 legiti­ + mate 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. -Headers, Environments, and Macros dhcpd.conf(5) + 3 - Some installations have physical networks on which more than - one IP subnet operates. For example, if there is a site- - wide requirement that 8-bit subnet masks be used, but a - department with a single physical ethernet network expands - to the point where it has more than 254 nodes, it may be - necessary to run two 8-bit subnets on the same ethernet - until such time as a new physical network can be added. In - this case, the _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 declaration. - Some sites may have departments which have clients on more - than one subnet, but it may be desirable to offer those - clients a uniform set of parameters which are different than - what would be offered to clients from other departments on - the same subnet. For clients which will be declared expli- - citly with _h_o_s_t declarations, these declarations 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, there is currently - no way to group parameter assignments other than by network - topology. - When a client is to be booted, its boot parameters are - determined by first consulting that client's _h_o_s_t declara- - tion (if any), then consulting the _g_r_o_u_p declaration (if - any) which enclosed that _h_o_s_t declaration, then consulting - the _s_u_b_n_e_t declaration for the subnet on which the client is - booting, then consulting the _s_h_a_r_e_d-_n_e_t_w_o_r_k declaration (if - any) containing that subnet, and finally consulting the - top-level parameters which may be specified outside of any - declaration. - 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 network 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 dif- - ferent subnet or shared network. -EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS - A typical dhcpd.conf file will look something like this: +dhcpd.conf(5) dhcpd.conf(5) - _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; - } + 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; -SunOS 5.6 Last change: 2 + 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; } + } + group { + filename "Xncd19c"; + next-server ncd-booter; -Headers, Environments, and Macros 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; - } + 4 - 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... + + + +dhcpd.conf(5) dhcpd.conf(5) + + + host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } + host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } } - 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... + + 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; } } - 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... + +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; + } } - } - Figure 1 + 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 - 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 + 5 - 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 eth- - ernet 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 necessity, - has its own router. So for the first subnet, for example, - there should be something like: - option routers 204.254.239.1; +dhcpd.conf(5) dhcpd.conf(5) + 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. -SunOS 5.6 Last change: 3 +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 + 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 + 6 -Headers, Environments, and Macros dhcpd.conf(5) - Note that the address here is specified numerically. This - is not required - if you have a different domain name for - each interface on your router, it's perfectly legitimate to - use the domain name for that interface instead of the - numeric address. However, in many cases there may be only - one domain name for all of a router's IP addresses, and it - would not be appropriate to use that name here. - In Figure 1 there is also a _g_r_o_u_p statement, which provides - 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 supplied to - these hosts: +dhcpd.conf(5) dhcpd.conf(5) - 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 mechanism, - we might set the lease timeout somewhat shorter than the - default: + 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. - max-lease-time 120; - default-lease-time 120; + 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. - 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). +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"; + } - 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. + 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" { + } - Imagine that you have a site with a lot of NCD X-Terminals. - 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: + 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 - group { - filename "Xncd19r"; - next-server ncd-booter; + 7 -SunOS 5.6 Last change: 4 +dhcpd.conf(5) dhcpd.conf(5) + 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. -Headers, Environments, and Macros dhcpd.conf(5) + 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 "vendor-classes" { + match option vendor-class-identifier; + } + subclass "vendor-classes" "SUNW.Ultra-5_10" { + option vendor-encapsulated-options + 2: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:73:70:61:72:63; + } - 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; } - } + subclass "vendor-classes" "SUNW.i86pc" { + 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; + } - group { - filename "Xncd19c"; - next-server ncd-booter; + The string following the class name for the subclasses + specifies the string that is expected to match the expres­ + sion in the class declaration for the vendor-classes + class. + + 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; + } - host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } - host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } - } + This will produce a class in which a maximum of four mem­ + bers may hold a lease at one time. - 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; } - } -AAAADDDDDDDDRRRREEEESSSSSSSS PPPPOOOOOOOOLLLLSSSS - The ppppoooooooollll 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 firewall, 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 register their DHCP - clients. To do this, you would set up a pair of pool - declarations: + 8 - 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; + + + +dhcpd.conf(5) dhcpd.conf(5) + + + 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 + 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" { + match if exists agent.circuit-id; + spawn with agent.circuit-id; + lease limit 4; } - # Known clients get this pool. - pool { - option domain-name-servers ns1.example.com, ns2.example.com; - max-lease-time 28800; + 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. +RREEFFEERREENNCCEE:: DDEECCLLAARRAATTIIOONNSS + TThhee _s_h_a_r_e_d_-_n_e_t_w_o_r_k ssttaatteemmeenntt -SunOS 5.6 Last change: 5 + 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 + 9 -Headers, Environments, and Macros dhcpd.conf(5) - range 10.0.0.5 10.0.0.199; - deny unknown clients; - } - } +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 declara- - tions can be on different subnets. -CCCCLLLLIIIIEEEENNNNTTTT CCCCLLLLAAAASSSSSSSSIIIINNNNGGGG - Clients can be seperated into classes, and treated dif- - ferently 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 sub- - classing based on the contents of the client packet. + when booting clients on those subnets unless parameters + provided at the subnet or host level override them. If + 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. - 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 aaaadddddddd state- - ment in the conditional's list of statements: + _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. - if substring (option dhcp-client-identifier, 0, 3) = "RAS" { - add ras-clients; - } + TThhee _s_u_b_n_e_t ssttaatteemmeenntt - An equivalent way to do this is to simply specify the condi- - tional expression as a matching expression in the class - statement: + 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 ] + }} - class ras-clients { - match if substring (option dhcp-client-identifier, 0, 3) = "RAS"; - } + 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. - In addition to classes, it is possible to declare subc- - lasses. A subclass is a class with the same name as a reg- - ular 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. Subclasses work as - follows: + 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. - class vendor-classes { - match option vendor-class-identifier; - } + 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. - subclass vendor-classes "SUNW.Ultra-5_10" { - option vendor-encapsulated-options + 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 -SunOS 5.6 Last change: 6 + 10 -Headers, Environments, and Macros dhcpd.conf(5) +dhcpd.conf(5) dhcpd.conf(5) - 2: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:73:70:61:72:63; - } + specified range may be dynamically assigned to BOOTP + clients as well as DHCP clients. When specifying a sin­ + gle address, _h_i_g_h_-_a_d_d_r_e_s_s can be omitted. - subclass vendor-classes "SUNW.i86pc" { - 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; - } + TThhee _h_o_s_t ssttaatteemmeenntt - The string following the class name for the subclasses - specifies the string that is expected to match the expres- - sion in the class declaration for the vendor-classes class. + 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 ] + }} - 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 specified as fol- - lows: + 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. - class limited-1 { - lease limit 4; - } + 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. - This will produce a class in which a maximum of four members - may hold a lease at one time. + If client-specific boot parameters must change based on + the network to which the client is attached, then multiple + hhoosstt statements should be used. - 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 application 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 addresses - from the network segment to which they are connected. + 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. - 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 typically 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 { - match if exists agent.circuit-id; + _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 ] + }} -SunOS 5.6 Last change: 7 + 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 + 11 -Headers, Environments, and Macros dhcpd.conf(5) +dhcpd.conf(5) dhcpd.conf(5) - spawn with 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 ddddhhhhccccppppdddd....lllleeeeaaaasssseeeessss - 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. + groups. - The use of the subclass spawning mechanism is not restricted - to relay agent options - this particular example is given - only because it is a fairly straightforward one. +RREEFFEERREENNCCEE:: AALLLLOOWW AANNDD DDEENNYY + The _a_l_l_o_w and _d_e_n_y statements can be used to control the + behaviour of dhcpd to various sorts of requests. The + allow and deny keywords actually have different meanings + depending on the context. In a pool context, these key­ + words can be used to set up access lists for address allo­ + cation pools. In other contexts, the keywords simply + control general server behaviour with respect to clients + based on scope. -RRRREEEEFFFFEEEERRRREEEENNNNCCCCEEEE:::: DDDDEEEECCCCLLLLAAAARRRRAAAATTTTIIIIOOOONNNNSSSS - TTTThhhheeee _s_h_a_r_e_d-_n_e_t_w_o_r_k ssssttttaaaatttteeeemmmmeeeennnntttt - sssshhhhaaaarrrreeeedddd----nnnneeeettttwwwwoooorrrrkkkk _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 ] - }}}} +AALLLLOOWW AANNDD DDEENNYY 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. - 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 physical - 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 any subnet in a - shared network has addresses available for dynamic alloca- - tion, 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. + TThhee _u_n_k_n_o_w_n_-_c_l_i_e_n_t_s kkeeyywwoorrdd - _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. + aallllooww uunnkknnoowwnn--cclliieennttss;; + ddeennyy uunnkknnoowwnn--cclliieennttss;; - TTTThhhheeee _s_u_b_n_e_t ssssttttaaaatttteeeemmmmeeeennnntttt + 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. - ssssuuuubbbbnnnneeeetttt _s_u_b_n_e_t-_n_u_m_b_e_r nnnneeeettttmmmmaaaasssskkkk _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 ] + TThhee _b_o_o_t_p kkeeyywwoorrdd + aallllooww bboooottpp;; + ddeennyy bboooottpp;; + The bboooottpp flag is used to tell dhcpd whether or not to + respond to bootp queries. Bootp queries are aalllloowwed by + default. -SunOS 5.6 Last change: 8 + TThhee _b_o_o_t_i_n_g kkeeyywwoorrdd + aallllooww bboooottiinngg;; + ddeennyy 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. +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 -Headers, Environments, and Macros dhcpd.conf(5) + 12 - }}}} - 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-specific - 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. +dhcpd.conf(5) dhcpd.conf(5) - Although a netmask must be given with every subnet declara- - tion, 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. - TTTThhhheeee _r_a_n_g_e ssssttttaaaatttteeeemmmmeeeennnntttt + 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 + send a DHCPACK message. - rrrraaaannnnggggeeee [ ddddyyyynnnnaaaammmmiiiicccc----bbbboooooooottttpppp ] _l_o_w-_a_d_d_r_e_s_s [ + 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. - 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 single address, - _h_i_g_h-_a_d_d_r_e_s_s can be omitted. + 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. - TTTThhhheeee _h_o_s_t ssssttttaaaatttteeeemmmmeeeennnntttt + When declaring permit lists for address allocation pools, + the following syntaxes are recognized following the allow + or deny keyword: - hhhhoooosssstttt _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 ] - }}}} + kknnoowwnn cclliieennttss;; - There must be at least one hhhhoooosssstttt statement for every BOOTP - client that is to be served. hhhhoooosssstttt statements may also be - specified for DHCP clients, although this is not required - unless booting is only enabled for known hosts. + If specified, this statement either allows or prevents + allocation from this pool to any client that has a host + declaration (i.e., is known). - 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 + 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"";; -SunOS 5.6 Last change: 9 + 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;; -Headers, Environments, and Macros dhcpd.conf(5) + 13 - address may be specified in the _f_i_x_e_d-_a_d_d_r_e_s_s parameter, or - more than one hhhhoooosssstttt statement may be specified. - If client-specific boot parameters must change based on the - network to which the client is attached, then multiple hhhhoooosssstttt - 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 hhhhoooosssstttt statement must be specified without a - ffffiiiixxxxeeeedddd----aaaaddddddddrrrreeeessssssss clause. _h_o_s_t_n_a_m_e should be a name identifying - 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. +dhcpd.conf(5) dhcpd.conf(5) - _H_o_s_t declarations are matched to actual DHCP or BOOTP - clients by matching the dhcp-client-identifier option speci- - fied 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 network - 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. - TTTThhhheeee _g_r_o_u_p ssssttttaaaatttteeeemmmmeeeennnntttt + If specified, this statement either allows or prevents + allocation from this pool to any client that has been + authenticated using the DHCP authentication protocol. + This is not yet supported. - ggggrrrroooouuuupppp { - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }}}} + uunnaauutthheennttiiccaatteedd cclliieennttss;; - 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. + 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. -RRRREEEEFFFFEEEERRRREEEENNNNCCCCEEEE:::: AAAALLLLLLLLOOOOWWWW aaaannnndddd DDDDEEEENNNNYYYY - The _a_l_l_o_w and _d_e_n_y statements can be used to control the - behaviour of dhcpd to various sorts of requests. + aallll cclliieennttss;; - TTTThhhheeee _u_n_k_n_o_w_n-_c_l_i_e_n_t_s kkkkeeeeyyyywwwwoooorrrrdddd + 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. - aaaalllllllloooowwww uuuunnnnkkkknnnnoooowwwwnnnn----cccclllliiiieeeennnnttttssss;;;; - ddddeeeennnnyyyy uuuunnnnkkkknnnnoooowwwwnnnn----cccclllliiiieeeennnnttttssss;;;; +RREEFFEERREENNCCEE:: PPAARRAAMMEETTEERRSS + TThhee _d_e_f_a_u_l_t_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt - The uuuunnnnkkkknnnnoooowwwwnnnn----cccclllliiiieeeennnnttttssss flag is used to tell dhcpd whether or - not to dynamically assign addresses to unknown clients. - Dynamic address assignment to unknown clients is aaaalllllllloooowwwwed by - default. + ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;; - TTTThhhheeee _b_o_o_t_p kkkkeeeeyyyywwwwoooorrrrdddd + _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 + 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. -SunOS 5.6 Last change: 10 + 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 -Headers, Environments, and Macros dhcpd.conf(5) + 14 - aaaalllllllloooowwww bbbboooooooottttpppp;;;; - ddddeeeennnnyyyy bbbboooooooottttpppp;;;; - The bbbboooooooottttpppp flag is used to tell dhcpd whether or not to - respond to bootp queries. Bootp queries are aaaalllllllloooowwwwed by - default. - TTTThhhheeee _b_o_o_t_i_n_g kkkkeeeeyyyywwwwoooorrrrdddd - aaaalllllllloooowwww bbbboooooooottttiiiinnnngggg;;;; - ddddeeeennnnyyyy bbbboooooooottttiiiinnnngggg;;;; - The bbbboooooooottttiiiinnnngggg 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 aaaalllllllloooowwwwed, but if it is disabled for a - particular client, then that client will not be able to get - and address from the DHCP server. +dhcpd.conf(5) dhcpd.conf(5) -RRRREEEEFFFFEEEERRRREEEENNNNCCCCEEEE:::: PPPPAAAARRRRAAAAMMMMEEEETTTTEEEERRRRSSSS - TTTThhhheeee _d_e_f_a_u_l_t-_l_e_a_s_e-_t_i_m_e ssssttttaaaatttteeeemmmmeeeennnntttt - ddddeeeeffffaaaauuuulllltttt----lllleeeeaaaasssseeee----ttttiiiimmmmeeee _t_i_m_e;;;; + 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. - _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. + 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. - TTTThhhheeee _m_a_x-_l_e_a_s_e-_t_i_m_e ssssttttaaaatttteeeemmmmeeeennnntttt + TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt - mmmmaaaaxxxx----lllleeeeaaaasssseeee----ttttiiiimmmmeeee _t_i_m_e;;;; + 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;; - _T_i_m_e should be the maximum length in seconds that will be - 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. + 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. - TTTThhhheeee _m_i_n-_l_e_a_s_e-_t_i_m_e ssssttttaaaatttteeeemmmmeeeennnntttt + TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt - mmmmiiiinnnn----lllleeeeaaaasssseeee----ttttiiiimmmmeeee _t_i_m_e;;;; + ffiilleennaammee ""_f_i_l_e_n_a_m_e"";; - _T_i_m_e should be the minimum length in seconds that will be - assigned to a lease. + 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. + 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. - TTTThhhheeee _m_i_n-_s_e_c_s ssssttttaaaatttteeeemmmmeeeennnntttt + TThhee _s_e_r_v_e_r_-_n_a_m_e ssttaatteemmeenntt - mmmmiiiinnnn----sssseeeeccccssss _s_e_c_o_n_d_s;;;; + sseerrvveerr--nnaammee ""_n_a_m_e"";; - _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 + 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;; -SunOS 5.6 Last change: 11 + The _n_e_x_t_-_s_e_r_v_e_r statement is used to specify the host + 15 -Headers, Environments, and Macros dhcpd.conf(5) +dhcpd.conf(5) dhcpd.conf(5) - that the client can report is 255 seconds. Generally, set- - ting this to one will result in the DHCP server not respond- - ing 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 oth- - erwise 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. + 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. - TTTThhhheeee _h_a_r_d_w_a_r_e ssssttttaaaatttteeeemmmmeeeennnntttt + TThhee _f_i_x_e_d_-_a_d_d_r_e_s_s ssttaatteemmeenntt - hhhhaaaarrrrddddwwwwaaaarrrreeee _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;;;; + ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _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 eeeetttthhhh---- - eeeerrrrnnnneeeetttt and ttttooookkkkeeeennnn----rrrriiiinnnngggg types are recognized, although support - for a ffffddddddddiiii hardware type (and others) would also be desir- - able. 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_f_R _s_t_a_t_e_m_e_n_t _m_a_y _a_l_s_o _b_e _u_s_e_d _f_o_r _D_H_C_P _c_l_i_e_n_t_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. - TTTThhhheeee _f_i_l_e_n_a_m_e ssssttttaaaatttteeeemmmmeeeennnntttt + 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 - ffffiiiilllleeeennnnaaaammmmeeee """"_f_i_l_e_n_a_m_e"""";;;; + ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_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. - 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. + 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. - TTTThhhheeee _s_e_r_v_e_r-_n_a_m_e ssssttttaaaatttteeeemmmmeeeennnntttt + _D_a_t_e should be the date on which all assigned BOOTP leases + will end. The date is specified in the form: - sssseeeerrrrvvvveeeerrrr----nnnnaaaammmmeeee """"_n_a_m_e"""";;;; + W YYYY/MM/DD HH:MM:SS - 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. + 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. - TTTThhhheeee _n_e_x_t-_s_e_r_v_e_r ssssttttaaaatttteeeemmmmeeeennnntttt + 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 - nnnneeeexxxxtttt----sssseeeerrrrvvvveeeerrrr _s_e_r_v_e_r-_n_a_m_e;;;; + ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;; - 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 + 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 -SunOS 5.6 Last change: 12 + 16 +dhcpd.conf(5) dhcpd.conf(5) -Headers, Environments, and Macros dhcpd.conf(5) + 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 - (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. + ggeett--lleeaassee--hhoossttnnaammeess _f_l_a_g;; - TTTThhhheeee _f_i_x_e_d-_a_d_d_r_e_s_s ssssttttaaaatttteeeemmmmeeeennnntttt + 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. - ffffiiiixxxxeeeedddd----aaaaddddddddrrrreeeessssssss _a_d_d_r_e_s_s [,,,, _a_d_d_r_e_s_s ... ];;;; + TThhee _u_s_e_-_h_o_s_t_-_d_e_c_l_-_n_a_m_e_s ssttaatteemmeenntt - 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 booting, that client will - not match the _h_o_s_t declaration containing 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. + uussee--hhoosstt--ddeeccll--nnaammeess _f_l_a_g;; - TTTThhhheeee _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_c_u_t_o_f_f ssssttttaaaatttteeeemmmmeeeennnntttt + 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, - ddddyyyynnnnaaaammmmiiiicccc----bbbboooooooottttpppp----lllleeeeaaaasssseeee----ccccuuuuttttooooffffffff _d_a_t_e;;;; + group { + use-host-decl-names on; - 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 cut- - off 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. + host joe { + hardware ethernet 08:00:2b:4c:29:32; + fixed-address joe.fugue.com; + } + } - _D_a_t_e should be the date on which all assigned BOOTP leases - will end. The date is specified in the form: + is equivalent to - W YYYY/MM/DD HH:MM:SS + host joe { + hardware ethernet 08:00:2b:4c:29:32; + fixed-address joe.fugue.com; + option host-name "joe"; + } - 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. + 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. - TTTThhhheeee _d_y_n_a_m_i_c-_b_o_o_t_p-_l_e_a_s_e-_l_e_n_g_t_h ssssttttaaaatttteeeemmmmeeeennnntttt + TThhee _a_u_t_h_o_r_i_t_a_t_i_v_e ssttaatteemmeenntt - ddddyyyynnnnaaaammmmiiiicccc----bbbboooooooottttpppp----lllleeeeaaaasssseeee----lllleeeennnnggggtttthhhh _l_e_n_g_t_h;;;; + 17 -SunOS 5.6 Last change: 13 +dhcpd.conf(5) dhcpd.conf(5) + aauutthhoorriittaattiivvee;; -Headers, Environments, and Macros dhcpd.conf(5) + nnoott aauutthhoorriittaattiivvee;; + The DHCP server will normally assume that the configura­ + tion information about a given network segment is known to + be correct and is authoritative. So if a client requests + an IP address on a given network segment that the server + knows is not valid for that segment, the server will + respond with a DHCPNAK message, causing the client to for­ + get its IP address and try to get a new one. + If a DHCP server is being configured by somebody who is + not the network administrator and who therefore does not + wish to assert this level of authority, then the statement + "not authoritative" should be written in the appropriate + scope in the configuration file. - 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 number 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. + Usually, writing nnoott 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. - TTTThhhheeee _g_e_t-_l_e_a_s_e-_h_o_s_t_n_a_m_e_s ssssttttaaaatttteeeemmmmeeeennnntttt + 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. - ggggeeeetttt----lllleeeeaaaasssseeee----hhhhoooossssttttnnnnaaaammmmeeeessss _f_l_a_g;;;; + TThhee _a_l_w_a_y_s_-_r_e_p_l_y_-_r_f_c_1_0_4_8 ssttaatteemmeenntt - 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. + aallwwaayyss--rreeppllyy--rrffcc11004488 _f_l_a_g;; - TTTThhhheeee _u_s_e-_h_o_s_t-_d_e_c_l-_n_a_m_e_s ssssttttaaaatttteeeemmmmeeeennnntttt + 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. - uuuusssseeee----hhhhoooosssstttt----ddddeeeeccccllll----nnnnaaaammmmeeeessss _f_l_a_g;;;; + 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. - 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 supplied - to the client as its hostname. So, for example, + 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 - group { - use-host-decl-names on; - host joe { - hardware ethernet 08:00:2b:4c:29:32; - fixed-address joe.fugue.com; - } - } - is equivalent to + 18 + + + + + +dhcpd.conf(5) dhcpd.conf(5) + + + uussee--lleeaassee--aaddddrr--ffoorr--ddeeffaauulltt--rroouuttee _f_l_a_g;; + + 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. + +RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS + DHCP option statements are documented in the ddhhccpp-- + ooppttiioonnss((55)) manual page. + +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 hunk of opaque data, or an actual option buffer + just like a standard DHCP option buffer. + + You can send this option to clients in one of two ways - + either define the data directly, using a text string or a + colon-seperated list of hexadecimal values, or define an - 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. + 19 -SunOS 5.6 Last change: 14 +dhcpd.conf(5) dhcpd.conf(5) + + + 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 in some scope. + + To send a simple clump of data, simply provide a value for + the option in the right scope, as in the example shown + earlier in the CCLLIIEENNTT CCLLAASSSSIINNGG section. + + 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 in the ddhhccpp--ooppttiioonnss((55)) manual page. For exam­ + ple: + + 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 some options, + you can set up scopes that define values for those + options, and you can say when to use them. For example, + suppose you want to handle two different classes of + clients, as in the example in the CCLLIIEENNTT CCLLAASSSSIINNGG section. + Using the option space definition we just did, the CCLLIIEENNTT + CCLLAASSSSIINNGG example can be implemented more legibly as fol­ + lows: + 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 indicates that in that scope, the + vveennddoorr--eennccaappssuullaatteedd--ooppttiioonnss option should be constructed + + + + 20 -Headers, Environments, and Macros dhcpd.conf(5) +dhcpd.conf(5) dhcpd.conf(5) - TTTThhhheeee _a_u_t_h_o_r_i_t_a_t_i_v_e ssssttttaaaatttteeeemmmmeeeennnntttt + using the values of all the options in the SUNW option + space. - aaaauuuutttthhhhoooorrrriiiittttaaaattttiiiivvvveeee;;;; +SSEEEE AALLSSOO + dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131. - nnnnooootttt aaaauuuutttthhhhoooorrrriiiittttaaaattttiiiivvvveeee;;;; +AAUUTTHHOORR + ddhhccppdd((88)) was written by Ted Lemon 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.. - The DHCP server will normally assume that the configuration - information about a given network segment is known to be - correct and is authoritative. So if a client requests an - IP address on a given network segment that the server knows - is not valid for that segment, the server will respond with - a DHCPNAK message, causing the client to forget its IP - address and try to get a new one. - If a DHCP server is being configured by somebody who is not - the network administrator and who therefore does not wish to - assert this level of authority, then the statement "not - authoritative" should be written in the appropriate scope in - the configuration file. - Usually, writing nnnnooootttt aaaauuuutttthhhhoooorrrriiiittttaaaattttiiiivvvveeee;;;; 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 authoritative - for some subnets within a shared network, but not authorita- - tive for others, nor is it meaningful to specify that the - server is authoritative for some host declarations and not - others. - TTTThhhheeee _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 ssssttttaaaatttteeeemmmmeeeennnntttt - uuuusssseeee----lllleeeeaaaasssseeee----aaaaddddddddrrrr----ffffoooorrrr----ddddeeeeffffaaaauuuulllltttt----rrrroooouuuutttteeee _f_l_a_g;;;; - 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 specified - in the routers option (or sending no value at all), the IP - address of the lease being assigned is sent to the client. - This supposedly causes Win95 machines to ARP for all IP - addresses, which can be helpful if your router is configured - for proxy ARP. - TTTThhhheeee _s_e_r_v_e_r-_i_d_e_n_t_i_f_i_e_r ssssttttaaaatttteeeemmmmeeeennnntttt -SunOS 5.6 Last change: 15 -Headers, Environments, and Macros dhcpd.conf(5) - sssseeeerrrrvvvveeeerrrr----iiiiddddeeeennnnttttiiiiffffiiiieeeerrrr _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 mmmmuuuusssstttt 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 network inter- - face 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 appropriate - 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 con- - tacting the server. - Supplying a value for the dhcp-server-identifier option is - equivalent to using the server-identifier statement. -RRRREEEEFFFFEEEERRRREEEENNNNCCCCEEEE:::: OOOOPPPPTTTTIIIIOOOONNNN SSSSTTTTAAAATTTTEEEEMMMMEEEENNNNTTTTSSSS - DHCP option statements are documented in the ddddhhhhccccpppp----ooooppppttttiiiioooonnnnssss((((5555)))) - manual page. -SSSSEEEEEEEE AAAALLLLSSSSOOOO - dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131. -AAAAUUUUTTTTHHHHOOOORRRR - ddddhhhhccccppppdddd((((8888)))) was written by Ted Lemon under a - contract with Vixie Labs. Funding for this project was - provided by the Internet Software Consortium. Information - about the Internet Software Consortium can be found at - hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc.... @@ -1050,7 +1380,7 @@ AAAAUUUUTTTTHHHHOOOORRRR -SunOS 5.6 Last change: 16 + 21 diff --git a/server/dhcpd.leases.cat5 b/server/dhcpd.leases.cat5 index 9a3b55ff6..f509e6221 100644 --- a/server/dhcpd.leases.cat5 +++ b/server/dhcpd.leases.cat5 @@ -1,186 +1,189 @@ -Headers, Environments, and Macros dhcpd.leases(5) +dhcpd.leases(5) dhcpd.leases(5) +NNAAMMEE + dhcpd.leases - DHCP client lease database -NNNNAAAAMMMMEEEE - 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. -DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN - The Internet Software Consortium DHCP Server keeps a per- - sistent database of leases that it has assigned. This data- - base 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. - 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 /etc/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. - In order to prevent the lease database from growing without - 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 - /etc/dhcpd.leases~. Finally, the newly written lease data- - base 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. - 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 /etc/dhcpd.leases. In - this case, dhcpd will refuse to start, and will require - manual intervention. DDDDOOOO NNNNOOOOTTTT 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 - /etc/dhcpd.leases~ to /etc/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. -FFFFOOOORRRRMMMMAAAATTTT - Lease descriptions are stored in a format that is parsed by - the same recursive descent parser used to read the - ddddhhhhccccppppdddd....ccccoooonnnnffff((((5555)))) and ddddhhhhcccclllliiiieeeennnntttt....ccccoooonnnnffff((((5555)))) files. Currently, the - only declaration that is used in the dhcpd.leases file is - the lllleeeeaaaasssseeee declaration. + lleeaassee _i_p_-_a_d_d_r_e_s_s {{ _s_t_a_t_e_m_e_n_t_s_._._. }} - lllleeeeaaaasssseeee _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. - 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: - The start and end time of a lease are recorded using the - ``starts'' and ``ends'' statements: -SunOS 5.6 Last change: 1 + 1 +dhcpd.leases(5) dhcpd.leases(5) -Headers, Environments, and Macros dhcpd.leases(5) + ssttaarrttss _d_a_t_e;; + eennddss _d_a_t_e;; + Dates are specified as follows: - ssssttttaaaarrrrttttssss _d_a_t_e;;;; - eeeennnnddddssss _d_a_t_e;;;; + _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 - Dates are specified as follows: + 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. - _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 + 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 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 second also a - number between 0 and 59. + The MAC address of the network interface that was used to + acquire the lease is recorded with the hhaarrddwwaarree statement: - 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 probably - 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 ddddaaaatttteeee - ----uuuu. + 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 of the network interface that was used to - acquire the lease is recorded with the hhhhaaaarrrrddddwwwwaaaarrrreeee statement: + The MAC address is specified as a series of hexadecimal + octets, seperated by colons. - hhhhaaaarrrrddddwwwwaaaarrrreeee _h_a_r_d_w_a_r_e-_t_y_p_e _m_a_c-_a_d_d_r_e_s_s;;;; + If the client used a client identifier to acquire its + address, the client identifier is recorded using the uuiidd + statement: - The MAC address is specified as a series of hexadecimal - octets, seperated by colons. + uuiidd _c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r;; - If the client used a client identifier to acquire its - address, the client identifier is recorded using the uuuuiiiidddd - statement: + 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. - uuuuiiiidddd _c_l_i_e_n_t-_i_d_e_n_t_i_f_i_e_r;;;; + 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. - The client identifier is recorded as a series of hexadecimal - octets, regardless of whether the client specifies an ASCII - string or uses the newer hardware type/MAC address format. + cclliieenntt--hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";; - 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 - cccclllliiiieeeennnntttt----hhhhoooossssttttnnnnaaaammmmeeee statement. + 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 - cccclllliiiieeeennnntttt----hhhhoooossssttttnnnnaaaammmmeeee """"_h_o_s_t_n_a_m_e"""";;;; + 2 -SunOS 5.6 Last change: 2 +dhcpd.leases(5) dhcpd.leases(5) + hhoossttnnaammee statement. + hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";; -Headers, Environments, and Macros dhcpd.leases(5) + 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 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 hhhhoooossssttttnnnnaaaammmmeeee state- - ment. + 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. - hhhhoooossssttttnnnnaaaammmmeeee """"_h_o_s_t_n_a_m_e"""";;;; +FFIILLEESS + //vvaarr//ddbb//ddhhccppdd..lleeaasseess - The DHCP server may determine that a lease has been misused - 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 aaaabbbbaaaannnn---- - ddddoooonnnneeeedddd statement will be used to indicate that the lease - should not be reassigned. +SSEEEE AALLSSOO + dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132, + RFC2131. - aaaabbbbaaaannnnddddoooonnnneeeedddd;;;; +AAUUTTHHOORR + ddhhccppdd((88)) was written by Ted Lemon 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.. - 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 aban- - doned lease. The standard mechanisms for checking for - lease address conflicts are still followed, so if the aban- - doned lease's IP address is still in use, it will be reaban- - doned. - If a client rrrreeeeqqqquuuueeeessssttttssss 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 immediately - assigned to the client. -FFFFIIIILLLLEEEESSSS - ////eeeettttcccc////ddddhhhhccccppppdddd....lllleeeeaaaasssseeeessss -SSSSEEEEEEEE AAAALLLLSSSSOOOO - dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132, RFC2131. -AAAAUUUUTTTTHHHHOOOORRRR - ddddhhhhccccppppdddd((((8888)))) was written by Ted Lemon under a - contract with Vixie Labs. Funding for this project was - provided by the Internet Software Corporation. Information - about the Internet Software Consortium can be found at - hhhhttttttttpppp::::////////wwwwwwwwwwww....iiiisssscccc....oooorrrrgggg////iiiisssscccc.... @@ -190,9 +193,6 @@ AAAAUUUUTTTTHHHHOOOORRRR - - -SunOS 5.6 Last change: 3 - + 3