-Maintenance Procedures dhclient(8)
-
-
-
-N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
- dhclient-script - DHCP client network configuration script
-
-D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- The DHCP client network configuration script is invoked from
- time to time by d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt(\b(\b(\b(8\b8\b8\b8)\b)\b)\b). 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 /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.c\bc\bc\bco\bo\bo\bon\bn\bn\bnf\bf\bf\bf script. If you
- find that you can't make such a customization without cus-
- tomizing dhclient.conf, please submit a bug report.
-
-O\bO\bO\bOP\bP\bP\bPE\bE\bE\bER\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- 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)
+
+
+N\bNA\bAM\bME\bE
+ dhclient-script - DHCP client network configuration script
+
+D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
+ The DHCP client network configuration script is invoked
+ from time to time by d\bdh\bhc\bcl\bli\bie\ben\bnt\bt(\b(8\b8)\b). 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
+ /\b/e\bet\btc\bc/\b/r\bre\bes\bso\bol\blv\bv.\b.c\bco\bon\bnf\bf 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
+ /\b/e\bet\btc\bc/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.c\bco\bon\bnf\bf file. If you find that you can't make
+ such a customization without customizing
+ /\b/e\bet\btc\bc/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.c\bco\bon\bnf\bf or using the enter and exit hooks,
+ please submit a bug report.
-M\bM\bM\bME\bE\bE\bED\bD\bD\bDI\bI\bI\bIU\bU\bU\bUM\bM\bM\bM
- 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.
+H\bHO\bOO\bOK\bKS\bS
+ When it starts, the client script first defines a shell
+ function, m\bma\bak\bke\be_\b_r\bre\bes\bso\bol\blv\bv_\b_c\bco\bon\bnf\bf ,\b, which is later used to create
+ the /\b/e\bet\btc\bc/\b/r\bre\bes\bso\bol\blv\bv.\b.c\bco\bon\bnf\bf file. To override the default
+ behaviour, redefine this function in the enter hook
+ script.
-P\bP\bP\bPR\bR\bR\bRE\bE\bE\bEI\bI\bI\bIN\bN\bN\bNI\bI\bI\bIT\bT\bT\bT
- 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
+ /\b/e\bet\btc\bc/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt-\b-e\ben\bnt\bte\ber\br-\b-h\bho\boo\bok\bks\bs 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
+ /\b/e\bet\btc\bc/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt-\b-s\bsc\bcr\bri\bip\bpt\bt 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, /\b/e\bet\btc\bc/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt-\b-s\bsc\bcr\bri\bip\bpt\bt
+ checks for the presence of an executable /\b/e\bet\btc\bc/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt-\b-
+ e\bex\bxi\bit\bt-\b-h\bho\boo\bok\bks\bs 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.
+
+O\bOP\bPE\bER\bRA\bAT\bTI\bIO\bON\bN
+ 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.
+
+
+M\bME\bED\bDI\bIU\bUM\bM
+ 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.
+
+P\bPR\bRE\bEI\bIN\bNI\bIT\bT
+ 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.
+B\bBO\bOU\bUN\bND\bD
+ 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 d\bdh\bhc\bcp\bp-\b-o\bop\bpt\bti\bio\bon\bns\bs, 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)
-B\bB\bB\bBO\bO\bO\bOU\bU\bU\bUN\bN\bN\bND\bD\bD\bD
- 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 d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bp-\b-\b-\b-
- o\bo\bo\bop\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bns\bs\bs\bs, 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.
-R\bR\bR\bRE\bE\bE\bEN\bN\bN\bNE\bE\bE\bEW\bW\bW\bW
- 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.
-R\bR\bR\bRE\bE\bE\bEB\bB\bB\bBI\bI\bI\bIN\bN\bN\bND\bD\bD\bD
- The DHCP client has rebound to a new DHCP server. This can
- be handled as with RENEW, except that if the IP address has
+R\bRE\bEN\bNE\bEW\bW
+ 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.
+R\bRE\bEB\bBI\bIN\bND\bD
+ 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.
+R\bRE\bEB\bBO\bOO\bOT\bT
+ 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
+E\bEX\bXP\bPI\bIR\bRE\bE
+ 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.
+F\bFA\bAI\bIL\bL
+ 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.
+T\bTI\bIM\bME\bEO\bOU\bUT\bT
+ The DHCP client has been unable to contact any DHCP
+ 3
-Maintenance Procedures dhclient(8)
- changed, the ARP table should be cleared.
-R\bR\bR\bRE\bE\bE\bEB\bB\bB\bBO\bO\bO\bOO\bO\bO\bOT\bT\bT\bT
- 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)
-E\bE\bE\bEX\bX\bX\bXP\bP\bP\bPI\bI\bI\bIR\bR\bR\bRE\bE\bE\bE
- 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.
-F\bF\bF\bFA\bA\bA\bAI\bI\bI\bIL\bL\bL\bL
- 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.
-T\bT\bT\bTI\bI\bI\bIM\bM\bM\bME\bE\bE\bEO\bO\bO\bOU\bU\bU\bUT\bT\bT\bT
- 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.
+F\bFI\bIL\bLE\bES\bS
+ 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.
-F\bF\bF\bFI\bI\bI\bIL\bL\bL\bLE\bE\bE\bES\bS\bS\bS
- 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.
+B\bBU\bUG\bGS\bS
+ 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.
-B\bB\bB\bBU\bU\bU\bUG\bG\bG\bGS\bS\bS\bS
- 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.
+S\bSE\bEE\bE A\bAL\bLS\bSO\bO
+ dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) and
+ dhclient.leases(5).
+A\bAU\bUT\bTH\bHO\bOR\bR
+ d\bdh\bhc\bcl\bli\bie\ben\bnt\bt-\b-s\bsc\bcr\bri\bip\bpt\bt(\b(8\b8)\b) has been written for the Internet Soft
+ ware Consortium by Ted Lemon <mellon@fugue.com> in cooper
+ ation with Vixie Enterprises. To learn more about the
+ Internet Software Consortium, see h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.v\bvi\bix\bx.\b.c\bco\bom\bm/\b/i\bis\bsc\bc.\b.
+ To learn more about Vixie Enterprises, see
+ h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.v\bvi\bix\bx.\b.c\bco\bom\bm.\b.
-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.
-
-S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
- dhclient(8), dhcpd(8), dhcrelay(8), dhclient.conf(5) and
- dhclient.leases(5).
-
-A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt-\b-\b-\b-s\bs\bs\bsc\bc\bc\bcr\br\br\bri\bi\bi\bip\bp\bp\bpt\bt\bt\bt(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) has been written for the Internet
- Software Consortium by Ted Lemon <mellon@fugue.com> in
- cooperation with Vixie Enterprises. To learn more about the
- Internet Software Consortium, see h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.v\bv\bv\bvi\bi\bi\bix\bx\bx\bx.\b.\b.\b.c\bc\bc\bco\bo\bo\bom\bm\bm\bm/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b. To
- learn more about Vixie Enterprises, see h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.v\bv\bv\bvi\bi\bi\bix\bx\bx\bx.\b.\b.\b.c\bc\bc\bco\bo\bo\bom\bm\bm\bm.\b.\b.\b.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-SunOS 5.6 Last change: 4
+ 4
-Maintenance Procedures dhclient(8)
+dhclient(8) dhclient(8)
+
+N\bNA\bAM\bME\bE
+ dhclient - Dynamic Host Configuration Protocol Client
+S\bSY\bYN\bNO\bOP\bPS\bSI\bIS\bS
+ d\bdh\bhc\bcl\bli\bie\ben\bnt\bt [ -\b-p\bp _\bp_\bo_\br_\bt ] [ -\b-d\bd ] [ _\bi_\bf_\b0 [ _\b._\b._\b._\bi_\bf_\bN ] ]
-N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
- dhclient - Dynamic Host Configuration Protocol Client
+D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
+ 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.
-S\bS\bS\bSY\bY\bY\bYN\bN\bN\bNO\bO\bO\bOP\bP\bP\bPS\bS\bS\bSI\bI\bI\bIS\bS\bS\bS
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt [ -\b-\b-\b-p\bp\bp\bp _\bp_\bo_\br_\bt ] [ -\b-\b-\b-d\bd\bd\bd ] [ _\bi_\bf_\b0 [ ..._\bi_\bf_\bN ] ]
+O\bOP\bPE\bER\bRA\bAT\bTI\bIO\bON\bN
+ 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.
-D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- 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 _\bd_\bh_\bc_\bl_\bi_\be_\bn_\bt_\b._\bc_\bo_\bn_\bf 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.
-O\bO\bO\bOP\bP\bP\bPE\bE\bE\bER\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- 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 _\bd_\bh_\bc_\bl_\bi_\be_\bn_\bt._\bc_\bo_\bn_\bf 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
+ _\bd_\bh_\bc_\bp_\bd_\b._\bl_\be_\ba_\bs_\be_\bs_\b~ 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 _\bd_\bh_\bc_\bp_\bd._\bl_\be_\ba_\bs_\be_\bs~ 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.
+C\bCO\bOM\bMM\bMA\bAN\bND\bD L\bLI\bIN\bNE\bE
+ 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 -\b-p\bp 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 -\b-d\bd flag should be specified.
+ This is useful when running dhclient under a debugger, or
+ when running it out of inittab on System V systems.
-C\bC\bC\bCO\bO\bO\bOM\bM\bM\bMM\bM\bM\bMA\bA\bA\bAN\bN\bN\bND\bD\bD\bD L\bL\bL\bLI\bI\bI\bIN\bN\bN\bNE\bE\bE\bE
- 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 -\b-\b-\b-p\bp\bp\bp flag may used. It should be
- followed by the udp port number that dhclient should use.
- This is mostly useful for debugging purposes.
+C\bCO\bON\bNF\bFI\bIG\bGU\bUR\bRA\bAT\bTI\bIO\bON\bN
+ 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 -\b-\b-\b-d\bd\bd\bd flag should be specified. This
- is useful when running dhclient under a debugger, or when
- running it out of inittab on System V systems.
+F\bFI\bIL\bLE\bES\bS
+ /\b/e\bet\btc\bc/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.c\bco\bon\bnf\bf,\b, /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.l\ble\bea\bas\bse\bes\bs,\b,
+ /\b/v\bva\bar\br/\b/r\bru\bun\bn/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.p\bpi\bid\bd,\b, /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.l\ble\bea\bas\bse\bes\bs~\b~.\b.
-C\bC\bC\bCO\bO\bO\bON\bN\bN\bNF\bF\bF\bFI\bI\bI\bIG\bG\bG\bGU\bU\bU\bUR\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- The syntax of the dhclient.conf(8) file is discussed
- seperately.
+S\bSE\bEE\bE A\bAL\bLS\bSO\bO
+ dhcpd(8), dhcrelay(8), dhclient.conf(5),
+ dhclient.leases(5)
-F\bF\bF\bFI\bI\bI\bIL\bL\bL\bLE\bE\bE\bES\bS\bS\bS
- /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.c\bc\bc\bco\bo\bo\bon\bn\bn\bnf\bf\bf\bf,\b,\b,\b, /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs,\b,\b,\b, /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.p\bp\bp\bpi\bi\bi\bid\bd\bd\bd,\b,\b,\b,
- /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs~\b~\b~\b~.\b.\b.\b.
+A\bAU\bUT\bTH\bHO\bOR\bR
+ d\bdh\bhc\bcl\bli\bie\ben\bnt\bt(\b(8\b8)\b) has been written for the Internet Software
+ Consortium by Ted Lemon <mellon@fugue.com> in cooperation
+ with Vixie Enterprises. To learn more about the Internet
+ Software Consortium, see h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.v\bvi\bix\bx.\b.c\bco\bom\bm/\b/i\bis\bsc\bc.\b. To learn
+ more about Vixie Enterprises, see h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.v\bvi\bix\bx.\b.c\bco\bom\bm.\b.
-S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
- dhcpd(8), dhcrelay(8), dhclient.conf(5), dhclient.leases(5)
-A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) has been written for the Internet Software Con-
- sortium by Ted Lemon <mellon@fugue.com> in cooperation with
- Vixie Enterprises. To learn more about the Internet
- Software Consortium, see h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.v\bv\bv\bvi\bi\bi\bix\bx\bx\bx.\b.\b.\b.c\bc\bc\bco\bo\bo\bom\bm\bm\bm/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b. To learn
- more about Vixie Enterprises, see h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.v\bv\bv\bvi\bi\bi\bix\bx\bx\bx.\b.\b.\b.c\bc\bc\bco\bo\bo\bom\bm\bm\bm.\b.\b.\b.
+ 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.
-
-
-
-SunOS 5.6 Last change: 3
+ 3
-Headers, Environments, and Macros dhclient.conf(5)
+dhclient.conf(5) dhclient.conf(5)
+N\bNA\bAM\bME\bE
+ dhclient.conf - DHCP client configuration file
-N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
- dhclient.conf - DHCP client configuration file
+D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
+ The dhclient.conf file contains configuration information
+ for _\bd_\bh_\bc_\bl_\bi_\be_\bn_\bt_\b, the Internet Software Consortium DHCP
+ Client.
-D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- The dhclient.conf file contains configuration information
- for _\bd_\bh_\bc_\bl_\bi_\be_\bn_\bt, 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.
+P\bPR\bRO\bOT\bTO\bOC\bCO\bOL\bL T\bTI\bIM\bMI\bIN\bNG\bG
+ 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.
-P\bP\bP\bPR\bR\bR\bRO\bO\bO\bOT\bT\bT\bTO\bO\bO\bOC\bC\bC\bCO\bO\bO\bOL\bL\bL\bL T\bT\bT\bTI\bI\bI\bIM\bM\bM\bMI\bI\bI\bIN\bN\bN\bNG\bG\bG\bG
- 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:
+ _\bT_\bh_\be t\bti\bim\bme\beo\bou\but\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- _\bT_\bh_\be t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\beo\bo\bo\bou\bu\bu\but\bt\bt\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ t\bti\bim\bme\beo\bou\but\bt _\bt_\bi_\bm_\be ;\b;
- t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\beo\bo\bo\bou\bu\bu\but\bt\bt\bt _\bt_\bi_\bm_\be ;\b;\b;\b;
+ The _\bt_\bi_\bm_\be_\bo_\bu_\bt 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 _\bt_\bi_\bm_\be_\bo_\bu_\bt 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)
+ _\bT_\bh_\be r\bre\bet\btr\bry\by _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ r\bre\bet\btr\bry\by _\bt_\bi_\bm_\be;\b;
+ The _\br_\be_\bt_\br_\by 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.
- _\bT_\bh_\be r\br\br\bre\be\be\bet\bt\bt\btr\br\br\bry\by\by\by _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ _\bT_\bh_\be s\bse\bel\ble\bec\bct\bt-\b-t\bti\bim\bme\beo\bou\but\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- r\br\br\bre\be\be\bet\bt\bt\btr\br\br\bry\by\by\by _\bt_\bi_\bm_\be;\b;\b;\b;
+ s\bse\bel\ble\bec\bct\bt-\b-t\bti\bim\bme\beo\bou\but\bt _\bt_\bi_\bm_\be;\b;
- The _\br_\be_\bt_\br_\by 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).
- _\bT_\bh_\be s\bs\bs\bse\be\be\bel\bl\bl\ble\be\be\bec\bc\bc\bct\bt\bt\bt-\b-\b-\b-t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\beo\bo\bo\bou\bu\bu\but\bt\bt\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ The _\bs_\be_\bl_\be_\bc_\bt_\b-_\bt_\bi_\bm_\be_\bo_\bu_\bt 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 _\bs_\be_\bl_\be_\bc_\bt_\b-_\bt_\bi_\bm_\be_\bo_\bu_\bt has expired, the client will
+ accept the first offer that arrives.
- s\bs\bs\bse\be\be\bel\bl\bl\ble\be\be\bec\bc\bc\bct\bt\bt\bt-\b-\b-\b-t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\beo\bo\bo\bou\bu\bu\but\bt\bt\bt _\bt_\bi_\bm_\be;\b;\b;\b;
+ 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).
+ _\bT_\bh_\be r\bre\beb\bbo\boo\bot\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- The _\bs_\be_\bl_\be_\bc_\bt-_\bt_\bi_\bm_\be_\bo_\bu_\bt 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 _\bs_\be_\bl_\be_\bc_\bt-_\bt_\bi_\bm_\be_\bo_\bu_\bt has expired, the client will accept
- the first offer that arrives.
+ r\bre\beb\bbo\boo\bot\bt _\bt_\bi_\bm_\be;\b;
- 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 _\br_\be_\bb_\bo_\bo_\bt 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.
- _\bT_\bh_\be r\br\br\bre\be\be\beb\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ _\bT_\bh_\be b\bba\bac\bck\bko\bof\bff\bf-\b-c\bcu\but\bto\bof\bff\bf _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- r\br\br\bre\be\be\beb\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\bt _\bt_\bi_\bm_\be;\b;\b;\b;
+ b\bba\bac\bck\bko\bof\bff\bf-\b-c\bcu\but\bto\bof\bff\bf _\bt_\bi_\bm_\be;\b;
- 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 _\br_\be_\bb_\bo_\bo_\bt 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 _\bb_\ba_\bc_\bk_\bo_\bf_\bf_\b-_\bc_\bu_\bt_\bo_\bf_\bf statement determines the
+ maximum amount of time that the client is allowed to back
+ off. It defaults to two minutes.
- _\bT_\bh_\be b\bb\bb\bba\ba\ba\bac\bc\bc\bck\bk\bk\bko\bo\bo\bof\bf\bf\bff\bf\bf\bf-\b-\b-\b-c\bc\bc\bcu\bu\bu\but\bt\bt\bto\bo\bo\bof\bf\bf\bff\bf\bf\bf _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- b\bb\bb\bba\ba\ba\bac\bc\bc\bck\bk\bk\bko\bo\bo\bof\bf\bf\bff\bf\bf\bf-\b-\b-\b-c\bc\bc\bcu\bu\bu\but\bt\bt\bto\bo\bo\bof\bf\bf\bff\bf\bf\bf _\bt_\bi_\bm_\be;\b;\b;\b;
- 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 _\bb_\ba_\bc_\bk_\bo_\bf_\bf-_\bc_\bu_\bt_\bo_\bf_\bf statement determines the
+ 2
-SunOS 5.6 Last change: 2
+dhclient.conf(5) dhclient.conf(5)
+ _\bT_\bh_\be i\bin\bni\bit\bti\bia\bal\bl-\b-i\bin\bnt\bte\ber\brv\bva\bal\bl _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ i\bin\bni\bit\bti\bia\bal\bl-\b-i\bin\bnt\bte\ber\brv\bva\bal\bl _\bt_\bi_\bm_\be;\b;
-Headers, Environments, and Macros dhclient.conf(5)
+ The _\bi_\bn_\bi_\bt_\bi_\ba_\bl_\b-_\bi_\bn_\bt_\be_\br_\bv_\ba_\bl 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.
+L\bLE\bEA\bAS\bSE\bE R\bRE\bEQ\bQU\bUI\bIR\bRE\bEM\bME\bEN\bNT\bTS\bS A\bAN\bND\bD R\bRE\bEQ\bQU\bUE\bES\bST\bTS\bS
+ 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 _\bD_\bH_\bC_\bP _\bO_\bp_\bt_\bi_\bo_\bn_\bs.
+ DHCP Options are defined in
+ d\bdh\bhc\bcp\bp-\b-o\bop\bpt\bti\bio\bon\bns\bs(\b(5\b5)\b).
- maximum amount of time that the client is allowed to back
- off. It defaults to two minutes.
+ _\bT_\bh_\be r\bre\beq\bqu\bue\bes\bst\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- _\bT_\bh_\be i\bi\bi\bin\bn\bn\bni\bi\bi\bit\bt\bt\bti\bi\bi\bia\ba\ba\bal\bl\bl\bl-\b-\b-\b-i\bi\bi\bin\bn\bn\bnt\bt\bt\bte\be\be\ber\br\br\brv\bv\bv\bva\ba\ba\bal\bl\bl\bl _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ r\bre\beq\bqu\bue\bes\bst\bt [\b[ _\bo_\bp_\bt_\bi_\bo_\bn ] [,\b, _\b._\b._\b. _\bo_\bp_\bt_\bi_\bo_\bn ];\b;
- i\bi\bi\bin\bn\bn\bni\bi\bi\bit\bt\bt\bti\bi\bi\bia\ba\ba\bal\bl\bl\bl-\b-\b-\b-i\bi\bi\bin\bn\bn\bnt\bt\bt\bte\be\be\ber\br\br\brv\bv\bv\bva\ba\ba\bal\bl\bl\bl _\bt_\bi_\bm_\be;\b;\b;\b;
+ 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 _\bi_\bn_\bi_\bt_\bi_\ba_\bl-_\bi_\bn_\bt_\be_\br_\bv_\ba_\bl 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.
+ _\bT_\bh_\be r\bre\beq\bqu\bui\bir\bre\be _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
-L\bL\bL\bLE\bE\bE\bEA\bA\bA\bAS\bS\bS\bSE\bE\bE\bE R\bR\bR\bRE\bE\bE\bEQ\bQ\bQ\bQU\bU\bU\bUI\bI\bI\bIR\bR\bR\bRE\bE\bE\bEM\bM\bM\bME\bE\bE\bEN\bN\bN\bNT\bT\bT\bTS\bS\bS\bS A\bA\bA\bAN\bN\bN\bND\bD\bD\bD R\bR\bR\bRE\bE\bE\bEQ\bQ\bQ\bQU\bU\bU\bUE\bE\bE\bES\bS\bS\bST\bT\bT\bTS\bS\bS\bS
- 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.
+ r\bre\beq\bqu\bui\bir\bre\be [\b[ _\bo_\bp_\bt_\bi_\bo_\bn ] [,\b, _\b._\b._\b. _\bo_\bp_\bt_\bi_\bo_\bn _\b];\b;
- 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 _\bD_\bH_\bC_\bP _\bO_\bp_\bt_\bi_\bo_\bn_\bs. DHCP
- Options are defined in
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bp-\b-\b-\b-o\bo\bo\bop\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bns\bs\bs\bs(\b(\b(\b(5\b5\b5\b5)\b)\b)\b).
+ 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.
- _\bT_\bh_\be r\br\br\bre\be\be\beq\bq\bq\bqu\bu\bu\bue\be\be\bes\bs\bs\bst\bt\bt\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ _\bT_\bh_\be s\bse\ben\bnd\bd _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- r\br\br\bre\be\be\beq\bq\bq\bqu\bu\bu\bue\be\be\bes\bs\bs\bst\bt\bt\bt [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn ] [,\b,\b,\b, ... _\bo_\bp_\bt_\bi_\bo_\bn ];\b;\b;\b;
+ s\bse\ben\bnd\bd {\b{ [\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] [,\b, _\b._\b._\b. _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn
+ ]}\b}
- 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 d\bdh\bhc\bcp\bp-\b-
+ o\bop\bpt\bti\bio\bon\bns\bs(\b(5\b5)\b). Options that are always sent in the DHCP
- _\bT_\bh_\be r\br\br\bre\be\be\beq\bq\bq\bqu\bu\bu\bui\bi\bi\bir\br\br\bre\be\be\be _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- r\br\br\bre\be\be\beq\bq\bq\bqu\bu\bu\bui\bi\bi\bir\br\br\bre\be\be\be [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn ] [,\b,\b,\b, ... _\bo_\bp_\bt_\bi_\bo_\bn ];\b;\b;\b;
- 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
- _\bT_\bh_\be s\bs\bs\bse\be\be\ben\bn\bn\bnd\bd\bd\bd _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- s\bs\bs\bse\be\be\ben\bn\bn\bnd\bd\bd\bd {\b{\b{\b{ [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] [,\b,\b,\b, ... _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ]}\b}\b}\b}
- 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 r\bre\beq\bqu\bue\bes\bst\bte\bed\bd-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be 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.
+O\bOP\bPT\bTI\bIO\bON\bN M\bMO\bOD\bDI\bIF\bFI\bIE\bER\bRS\bS
+ 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.
+ _\bT_\bh_\be d\bde\bef\bfa\bau\bul\blt\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ d\bde\bef\bfa\bau\bul\blt\bt [\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;
+ 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 d\bde\bef\bfa\bau\bul\blt\bt statement.
-Headers, Environments, and Macros dhclient.conf(5)
+ _\bT_\bh_\be s\bsu\bup\bpe\ber\brs\bse\bed\bde\be _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ s\bsu\bup\bpe\ber\brs\bse\bed\bde\be [\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;
+ 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
+ s\bsu\bup\bpe\ber\brs\bse\bed\bde\be statement.
- full option declarations as described in d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bp-\b-\b-\b-o\bo\bo\bop\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bns\bs\bs\bs(\b(\b(\b(5\b5\b5\b5)\b)\b)\b).
- Options that are always sent in the DHCP protocol should not
- be specified here, except that the client can specify a
- r\br\br\bre\be\be\beq\bq\bq\bqu\bu\bu\bue\be\be\bes\bs\bs\bst\bt\bt\bte\be\be\bed\bd\bd\bd-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\be 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.
+ _\bT_\bh_\be p\bpr\bre\bep\bpe\ben\bnd\bd _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
-O\bO\bO\bOP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN M\bM\bM\bMO\bO\bO\bOD\bD\bD\bDI\bI\bI\bIF\bF\bF\bFI\bI\bI\bIE\bE\bE\bER\bR\bR\bRS\bS\bS\bS
- 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.
+ p\bpr\bre\bep\bpe\ben\bnd\bd [\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;
- _\bT_\bh_\be d\bd\bd\bde\be\be\bef\bf\bf\bfa\ba\ba\bau\bu\bu\bul\bl\bl\blt\bt\bt\bt _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ 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 p\bpr\bre\bep\bpe\ben\bnd\bd
+ statement. The p\bpr\bre\bep\bpe\ben\bnd\bd 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.
- d\bd\bd\bde\be\be\bef\bf\bf\bfa\ba\ba\bau\bu\bu\bul\bl\bl\blt\bt\bt\bt [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;\b;\b;
+ _\bT_\bh_\be a\bap\bpp\bpe\ben\bnd\bd _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- 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 d\bd\bd\bde\be\be\bef\bf\bf\bfa\ba\ba\bau\bu\bu\bul\bl\bl\blt\bt\bt\bt statement.
+ a\bap\bpp\bpe\ben\bnd\bd [\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;
- _\bT_\bh_\be s\bs\bs\bsu\bu\bu\bup\bp\bp\bpe\be\be\ber\br\br\brs\bs\bs\bse\be\be\bed\bd\bd\bde\be\be\be _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ 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 a\bap\bpp\bpe\ben\bnd\bd
+ statement. The a\bap\bpp\bpe\ben\bnd\bd statement can only be used for
- s\bs\bs\bsu\bu\bu\bup\bp\bp\bpe\be\be\ber\br\br\brs\bs\bs\bse\be\be\bed\bd\bd\bde\be\be\be [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;\b;\b;
- 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 s\bs\bs\bsu\bu\bu\bup\bp\bp\bpe\be\be\ber\br\br\brs\bs\bs\bse\be\be\bed\bd\bd\bde\be\be\be
- statement.
- _\bT_\bh_\be p\bp\bp\bpr\br\br\bre\be\be\bep\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
+ 4
- p\bp\bp\bpr\br\br\bre\be\be\bep\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;\b;\b;
- 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 p\bp\bp\bpr\br\br\bre\be\be\bep\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd statement. The
- p\bp\bp\bpr\br\br\bre\be\be\bep\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd statement can only be used for options which allow
- more than one value to be given.
- _\bT_\bh_\be a\ba\ba\bap\bp\bp\bpp\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt
- a\ba\ba\bap\bp\bp\bpp\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd [\b[\b[\b[ _\bo_\bp_\bt_\bi_\bo_\bn _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] ;\b;\b;\b;
- 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
+L\bLE\bEA\bAS\bSE\bE D\bDE\bEC\bCL\bLA\bAR\bRA\bAT\bTI\bIO\bON\bNS\bS
+ _\bT_\bh_\be l\ble\bea\bas\bse\be _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn
+ l\ble\bea\bas\bse\be {\b{ _\bl_\be_\ba_\bs_\be_\b-_\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn [ ... _\bl_\be_\ba_\bs_\be_\b-_\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn _\b] }\b}
+ The DHCP client may decide after some period of time (see
+ P\bPR\bRO\bOT\bTO\bOC\bCO\bOL\bL T\bTI\bIM\bMI\bIN\bNG\bG) 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 _\bf_\bi_\bx_\be_\bd 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 l\ble\bea\bas\bse\be 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:
+ b\bbo\boo\bot\btp\bp;\b;
-Headers, Environments, and Macros dhclient.conf(5)
+ The b\bbo\boo\bot\btp\bp 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.
+ i\bin\bnt\bte\ber\brf\bfa\bac\bce\be "\b"_\bs_\bt_\br_\bi_\bn_\bg"\b";\b;
+ The i\bin\bnt\bte\ber\brf\bfa\bac\bce\be 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 a\ba\ba\bap\bp\bp\bpp\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd statement.
- The a\ba\ba\bap\bp\bp\bpp\bp\bp\bpe\be\be\ben\bn\bn\bnd\bd\bd\bd statement can only be used for options which
- allow more than one value to be given.
+ f\bfi\bix\bxe\bed\bd-\b-a\bad\bdd\bdr\bre\bes\bss\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
-L\bL\bL\bLE\bE\bE\bEA\bA\bA\bAS\bS\bS\bSE\bE\bE\bE D\bD\bD\bDE\bE\bE\bEC\bC\bC\bCL\bL\bL\bLA\bA\bA\bAR\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bNS\bS\bS\bS
- _\bT_\bh_\be l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn
+ The f\bfi\bix\bxe\bed\bd-\b-a\bad\bdd\bdr\bre\bes\bss\bs statement is used to set the ip address
- l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be {\b{\b{\b{ _\bl_\be_\ba_\bs_\be-_\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn [ ... _\bl_\be_\ba_\bs_\be-_\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn ] }\b}\b}\b}
- The DHCP client may decide after some period of time (see
- P\bP\bP\bPR\bR\bR\bRO\bO\bO\bOT\bT\bT\bTO\bO\bO\bOC\bC\bC\bCO\bO\bO\bOL\bL\bL\bL T\bT\bT\bTI\bI\bI\bIM\bM\bM\bMI\bI\bI\bIN\bN\bN\bNG\bG\bG\bG) 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 _\bf_\bi_\bx_\be_\bd 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 l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be 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:
- b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp;\b;\b;\b;
- The b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp 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.
- i\bi\bi\bin\bn\bn\bnt\bt\bt\bte\be\be\ber\br\br\brf\bf\bf\bfa\ba\ba\bac\bc\bc\bce\be\be\be "\b"\b"\b"_\bs_\bt_\br_\bi_\bn_\bg"\b"\b"\b";\b;\b;\b;
- The i\bi\bi\bin\bn\bn\bnt\bt\bt\bte\be\be\ber\br\br\brf\bf\bf\bfa\ba\ba\bac\bc\bc\bce\be\be\be 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).
+ f\bfi\bil\ble\ben\bna\bam\bme\be "\b"_\bs_\bt_\br_\bi_\bn_\bg"\b";\b;
+ The f\bfi\bil\ble\ben\bna\bam\bme\be 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
+ s\bse\ber\brv\bve\ber\br-\b-n\bna\bam\bme\be "\b"_\bs_\bt_\br_\bi_\bn_\bg"\b";\b;
+ The s\bse\ber\brv\bve\ber\br-\b-n\bna\bam\bme\be statement specifies the name of the boot
+ server name to use. This is also not used by the stan
+ dard client configuration script.
+ o\bop\bpt\bti\bio\bon\bn _\bo_\bp_\bt_\bi_\bo_\bn_\b-_\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn;\b;
+ The o\bop\bpt\bti\bio\bon\bn 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.
+ s\bsc\bcr\bri\bip\bpt\bt "\b"_\bs_\bc_\br_\bi_\bp_\bt_\b-_\bn_\ba_\bm_\be"\b";\b;
+ The s\bsc\bcr\bri\bip\bpt\bt 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
+ d\bdh\bhc\bcl\bli\bie\ben\bnt\bt-\b-l\ble\bea\bas\bse\be(\b(8\b8)\b).\b.
-Headers, Environments, and Macros dhclient.conf(5)
+ m\bme\bed\bdi\biu\bum\bm "\b"_\bm_\be_\bd_\bi_\ba _\bs_\be_\bt_\bu_\bp"\b";\b;
+ The m\bme\bed\bdi\biu\bum\bm 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 m\bme\bed\bdi\bia\ba 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.
- f\bf\bf\bfi\bi\bi\bix\bx\bx\bxe\be\be\bed\bd\bd\bd-\b-\b-\b-a\ba\ba\bad\bd\bd\bdd\bd\bd\bdr\br\br\bre\be\be\bes\bs\bs\bss\bs\bs\bs _\bi_\bp-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;\b;\b;
- The f\bf\bf\bfi\bi\bi\bix\bx\bx\bxe\be\be\bed\bd\bd\bd-\b-\b-\b-a\ba\ba\bad\bd\bd\bdd\bd\bd\bdr\br\br\bre\be\be\bes\bs\bs\bss\bs\bs\bs 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).
- f\bf\bf\bfi\bi\bi\bil\bl\bl\ble\be\be\ben\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be "\b"\b"\b"_\bs_\bt_\br_\bi_\bn_\bg"\b"\b"\b";\b;\b;\b;
- The f\bf\bf\bfi\bi\bi\bil\bl\bl\ble\be\be\ben\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be 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
- s\bs\bs\bse\be\be\ber\br\br\brv\bv\bv\bve\be\be\ber\br\br\br-\b-\b-\b-n\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be "\b"\b"\b"_\bs_\bt_\br_\bi_\bn_\bg"\b"\b"\b";\b;\b;\b;
- The s\bs\bs\bse\be\be\ber\br\br\brv\bv\bv\bve\be\be\ber\br\br\br-\b-\b-\b-n\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be statement specifies the name of the boot
- server name to use. This is also not used by the standard
- client configuration script.
- o\bo\bo\bop\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bn _\bo_\bp_\bt_\bi_\bo_\bn-_\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn;\b;\b;\b;
- The o\bo\bo\bop\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bn 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.
- s\bs\bs\bsc\bc\bc\bcr\br\br\bri\bi\bi\bip\bp\bp\bpt\bt\bt\bt "\b"\b"\b"_\bs_\bc_\br_\bi_\bp_\bt-_\bn_\ba_\bm_\be"\b"\b"\b";\b;\b;\b;
+dhclient.conf(5) dhclient.conf(5)
- The s\bs\bs\bsc\bc\bc\bcr\br\br\bri\bi\bi\bip\bp\bp\bpt\bt\bt\bt 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 d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be(\b(\b(\b(8\b8\b8\b8)\b)\b)\b).\b.\b.\b.
- m\bm\bm\bme\be\be\bed\bd\bd\bdi\bi\bi\biu\bu\bu\bum\bm\bm\bm "\b"\b"\b"_\bm_\be_\bd_\bi_\ba _\bs_\be_\bt_\bu_\bp"\b"\b"\b";\b;\b;\b;
+ r\bre\ben\bne\bew\bw _\bd_\ba_\bt_\be;\b;
- The m\bm\bm\bme\be\be\bed\bd\bd\bdi\bi\bi\biu\bu\bu\bum\bm\bm\bm 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.
+ r\bre\beb\bbi\bin\bnd\bd _\bd_\ba_\bt_\be;\b;
- The dhcp client automatically declares this parameter if it
- used a media type (see the m\bm\bm\bme\be\be\bed\bd\bd\bdi\bi\bi\bia\ba\ba\ba statement) when configuring
- the interface in order to obtain a lease. This statement
+ e\bex\bxp\bpi\bir\bre\be _\bd_\ba_\bt_\be;\b;
+ The r\bre\ben\bne\bew\bw 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 r\bre\beb\bbi\bin\bnd\bd statement defines
+ the time at which the dhcp client should begin to try to
+ contact _\ba_\bn_\by dhcp server in order to renew its lease. The
+ e\bex\bxp\bpi\bir\bre\be 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:
+ _\b<_\bw_\be_\be_\bk_\bd_\ba_\by_\b> _\b<_\by_\be_\ba_\br_\b>/\b/_\b<_\bm_\bo_\bn_\bt_\bh_\b>/\b/_\b<_\bd_\ba_\by_\b> _\b<_\bh_\bo_\bu_\br_\b>:\b:_\b<_\bm_\bi_\bn_\bu_\bt_\be_\b>:\b:_\b<_\bs_\be_\bc_\bo_\bn_\bd_\b>
+ 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.
+A\bAL\bLI\bIA\bAS\bS D\bDE\bEC\bCL\bLA\bAR\bRA\bAT\bTI\bIO\bON\bNS\bS
+ a\bal\bli\bia\bas\bs {\b{ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs _\b._\b._\b. }\b}
+ 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 a\bal\bli\bia\bas\bs 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.
- r\br\br\bre\be\be\ben\bn\bn\bne\be\be\bew\bw\bw\bw _\bd_\ba_\bt_\be;\b;\b;\b;
- r\br\br\bre\be\be\beb\bb\bb\bbi\bi\bi\bin\bn\bn\bnd\bd\bd\bd _\bd_\ba_\bt_\be;\b;\b;\b;
- e\be\be\bex\bx\bx\bxp\bp\bp\bpi\bi\bi\bir\br\br\bre\be\be\be _\bd_\ba_\bt_\be;\b;\b;\b;
- The r\br\br\bre\be\be\ben\bn\bn\bne\be\be\bew\bw\bw\bw 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 r\br\br\bre\be\be\beb\bb\bb\bbi\bi\bi\bin\bn\bn\bnd\bd\bd\bd statement defines the
- time at which the dhcp client should begin to try to contact
- _\ba_\bn_\by dhcp server in order to renew its lease. The e\be\be\bex\bx\bx\bxp\bp\bp\bpi\bi\bi\bir\br\br\bre\be\be\be
- 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.
- <_\bw_\be_\be_\bk_\bd_\ba_\by> <_\by_\be_\ba_\br>/\b/\b/\b/<_\bm_\bo_\bn_\bt_\bh>/\b/\b/\b/<_\bd_\ba_\by> <_\bh_\bo_\bu_\br>:\b:\b:\b:<_\bm_\bi_\bn_\bu_\bt_\be>:\b:\b:\b:<_\bs_\be_\bc_\bo_\bn_\bd>
+O\bOT\bTH\bHE\bER\bR D\bDE\bEC\bCL\bLA\bAR\bRA\bAT\bTI\bIO\bON\bNS\bS
+ r\bre\bej\bje\bec\bct\bt _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
- 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.
-A\bA\bA\bAL\bL\bL\bLI\bI\bI\bIA\bA\bA\bAS\bS\bS\bS D\bD\bD\bDE\bE\bE\bEC\bC\bC\bCL\bL\bL\bLA\bA\bA\bAR\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bNS\bS\bS\bS
- a\ba\ba\bal\bl\bl\bli\bi\bi\bia\ba\ba\bas\bs\bs\bs {\b{\b{\b{ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ... }\b}\b}\b}
+ i\bin\bnt\bte\ber\brf\bfa\bac\bce\be "\b"_\bn_\ba_\bm_\be"\b" {\b{ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs _\b._\b._\b. }\b}
- 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 a\ba\ba\bal\bl\bl\bli\bi\bi\bia\ba\ba\bas\bs\bs\bs 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.
+ m\bme\bed\bdi\bia\ba "\b"_\bm_\be_\bd_\bi_\ba _\bs_\be_\bt_\bu_\bp"\b" _\b[ ,\b, "\b"_\bm_\be_\bd_\bi_\ba _\bs_\be_\bt_\bu_\bp"\b",\b, _\b._\b._\b. _\b];\b;
+ The m\bme\bed\bdi\bia\ba 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.
+S\bSA\bAM\bMP\bPL\bLE\bE
+ 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.
-O\bO\bO\bOT\bT\bT\bTH\bH\bH\bHE\bE\bE\bER\bR\bR\bR D\bD\bD\bDE\bE\bE\bEC\bC\bC\bCL\bL\bL\bLA\bA\bA\bAR\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bNS\bS\bS\bS
- r\br\br\bre\be\be\bej\bj\bj\bje\be\be\bec\bc\bc\bct\bt\bt\bt _\bi_\bp-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;\b;\b;
- 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;
- i\bi\bi\bin\bn\bn\bnt\bt\bt\bte\be\be\ber\br\br\brf\bf\bf\bfa\ba\ba\bac\bc\bc\bce\be\be\be "\b"\b"\b"_\bn_\ba_\bm_\be"\b"\b"\b" {\b{\b{\b{ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ... }\b}\b}\b}
+ 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.
- m\bm\bm\bme\be\be\bed\bd\bd\bdi\bi\bi\bia\ba\ba\ba "\b"\b"\b"_\bm_\be_\bd_\bi_\ba _\bs_\be_\bt_\bu_\bp"\b"\b"\b" [ ,\b,\b,\b, "\b"\b"\b"_\bm_\be_\bd_\bi_\ba _\bs_\be_\bt_\bu_\bp"\b"\b"\b",\b,\b,\b, ... ];\b;\b;\b;
+S\bSE\bEE\bE A\bAL\bLS\bSO\bO
+ dhcp-options(5), dhclient.leases(5), dhcpd(8),
+ dhcpd.conf(5), RFC2132, RFC2131.
- The m\bm\bm\bme\be\be\bed\bd\bd\bdi\bi\bi\bia\ba\ba\ba 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).
+A\bAU\bUT\bTH\bHO\bOR\bR
+ d\bdh\bhc\bcl\bli\bie\ben\bnt\bt(\b(8\b8)\b) was written by Ted Lemon <mellon@vix.com>
+ under a contract with Vixie Labs. Funding for this pro
+ ject was provided by the Internet Software Consortium.
+ Information about the Internet Software Consortium can be
+ found at h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
- 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)
-
-S\bS\bS\bSA\bA\bA\bAM\bM\bM\bMP\bP\bP\bPL\bL\bL\bLE\bE\bE\bE
- 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.
-
-S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
- dhcp-options(5), dhclient.leases(5), dhcpd(8),
- dhcpd.conf(5), RFC2132, RFC2131.
-
-A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) was written by Ted Lemon <mellon@vix.com> under
- a contract with Vixie Labs. Funding for this project was
- provided by the Internet Software Consortium. Information
- about the Internet Software Consortium can be found at
- h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.o\bo\bo\bor\br\br\brg\bg\bg\bg/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.
-
-
-
-
-
-SunOS 5.6 Last change: 9
-
+ 9
-Headers, Environments, and Macros dhclient.leases(5)
+dhclient.leases(5) dhclient.leases(5)
+N\bNA\bAM\bME\bE
+ dhclient.leases - DHCP client lease database
-N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
- dhclient.leases - DHCP client lease database
+D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
+ 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.
-D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- 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
+ d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.c\bco\bon\bnf\bf(\b(5\b5)\b).\b.
- The format of the lease declarations is described in
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.c\bc\bc\bco\bo\bo\bon\bn\bn\bnf\bf\bf\bf(\b(\b(\b(5\b5\b5\b5)\b)\b)\b).\b.\b.\b.
+F\bFI\bIL\bLE\bES\bS
+ /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.l\ble\bea\bas\bse\bes\bs
-F\bF\bF\bFI\bI\bI\bIL\bL\bL\bLE\bE\bE\bES\bS\bS\bS
- /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs
+S\bSE\bEE\bE A\bAL\bLS\bSO\bO
+ dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8),
+ dhcpd.conf(5), RFC2132, RFC2131.
-S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
- dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8),
- dhcpd.conf(5), RFC2132, RFC2131.
+A\bAU\bUT\bTH\bHO\bOR\bR
+ d\bdh\bhc\bcl\bli\bie\ben\bnt\bt(\b(8\b8)\b) was written by Ted Lemon <mellon@vix.com>
+ under a contract with Vixie Labs. Funding for this pro
+ ject was provided by the Internet Software Consortium.
+ Information about the Internet Software Consortium can be
+ found at h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
-A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) was written by Ted Lemon <mellon@vix.com> under
- a contract with Vixie Labs. Funding for this project was
- provided by the Internet Software Consortium. Information
- about the Internet Software Consortium can be found at
- h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.o\bo\bo\bor\br\br\brg\bg\bg\bg/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.
-SunOS 5.6 Last change: 1
+ 1
can be either true or false (or on or off, if that makes
more sense to you).
- The d\bda\bat\bta\ba-\b-s\bst\btr\bri\bin\bng\bg 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 s\bst\btr\bri\bin\bng\bg 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;
+
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-_\bn_\bn_\bn, where _\bn_\bn_\bn _\bi_\bs _\bt_\bh_\be _\bd_\be_\bc_\bi_\bm_\ba_\bl
+ 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-_\bn_\bn_\bn, where _\bn_\bn_\bn _\bi_\bs _\bt_\bh_\be _\bd_\be_\bc_\bi_\bm_\ba_\bl
_\bn_\bu_\bm_\bb_\be_\br _\bo_\bf _\bt_\bh_\be _\bo_\bp_\bt_\bi_\bo_\bn _\bc_\bo_\bd_\be_\b. _\bT_\bh_\be_\bs_\be _\bo_\bp_\bt_\bi_\bo_\bn_\bs _\bm_\ba_\by _\bb_\be _\bf_\bo_\bl_\bl_\bo_\bw_\be_\bd
- _\be_\bi_\bt_\bh_\be_\br _\bb_\by _\ba _\bs_\bt_\br_\bi_\bn_\bg_\b, _\be_\bn_\bc_\bl_\bo_\bs_\be_\bd _\bi_\bn _\bq_\bu_\bo_\bt_\be_\bs_\b, _\bo_\br _\bb_\by _\ba _\bs_\be_\br_\bi_\be_\bs _\bo_\bf
- _\bo_\bc_\bt_\be_\bt_\bs_\b, _\be_\bx_\bp_\br_\be_\bs_\bs_\be_\bd _\ba_\bs _\bt_\bw_\bo_\b-_\bd_\bi_\bg_\bi_\bt _\bh_\be_\bx_\ba_\bd_\be_\bc_\bi_\bm_\ba_\bl _\bn_\bu_\bm_\bb_\be_\br_\bs _\bs_\be_\bp_\be_\br_\b
+ _\be_\bi_\bt_\bh_\be_\br _\bb_\by _\ba _\bs_\bt_\br_\bi_\bn_\bg_\b, _\be_\bn_\bc_\bl_\bo_\bs_\be_\bd _\bi_\bn _\bq_\bu_\bo_\bt_\be_\bs_\b, _\bo_\br _\bb_\by _\ba _\bs_\be_\br_\bi_\be_\bs _\bo_\bf
+ _\bo_\bc_\bt_\be_\bt_\bs_\b, _\be_\bx_\bp_\br_\be_\bs_\bs_\be_\bd _\ba_\bs _\bt_\bw_\bo_\b-_\bd_\bi_\bg_\bi_\bt _\bh_\be_\bx_\ba_\bd_\be_\bc_\bi_\bm_\ba_\bl _\bn_\bu_\bm_\bb_\be_\br_\bs _\bs_\be_\bp_\be_\br_\b
_\ba_\bt_\be_\bd _\bb_\by _\bc_\bo_\bl_\bo_\bn_\bs_\b. _\bF_\bo_\br _\be_\bx_\ba_\bm_\bp_\bl_\be_\b:
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:
o\bop\bpt\bti\bio\bon\bn s\bsu\bub\bbn\bne\bet\bt-\b-m\bma\bas\bsk\bk _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
- 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, _\ba_\bn_\by 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, _\ba_\bn_\by subnet-mask option declaration that is in
+ scope for the address being assigned will override the
subnet mask specified in the subnet declaration.
o\bop\bpt\bti\bio\bon\bn t\bti\bim\bme\be-\b-o\bof\bff\bfs\bse\bet\bt _\bi_\bn_\bt_\b3_\b2;\b;
- 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).
o\bop\bpt\bti\bio\bon\bn r\bro\bou\but\bte\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
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.
o\bop\bpt\bti\bio\bon\bn t\bti\bim\bme\be-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
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.
o\bop\bpt\bti\bio\bon\bn i\bie\ben\bn1\b11\b16\b6-\b-n\bna\bam\bme\be-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];
- 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.
o\bop\bpt\bti\bio\bon\bn d\bdo\bom\bma\bai\bin\bn-\b-n\bna\bam\bme\be-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
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.
o\bop\bpt\bti\bio\bon\bn l\blo\bog\bg-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
- 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.
o\bop\bpt\bti\bio\bon\bn c\bco\boo\bok\bki\bie\be-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
- 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.
o\bop\bpt\bti\bio\bon\bn i\bim\bmp\bpr\bre\bes\bss\bs-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
- 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.
o\bop\bpt\bti\bio\bon\bn r\bre\bes\bso\bou\bur\brc\bce\be-\b-l\blo\boc\bca\bat\bti\bio\bon\bn-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-
_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
- 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.
o\bop\bpt\bti\bio\bon\bn h\bho\bos\bst\bt-\b-n\bna\bam\bme\be _\bs_\bt_\br_\bi_\bn_\bg;\b;
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.
o\bop\bpt\bti\bio\bon\bn b\bbo\boo\bot\bt-\b-s\bsi\biz\bze\be _\bu_\bi_\bn_\bt_\b1_\b6;\b;
o\bop\bpt\bti\bio\bon\bn m\bme\ber\bri\bit\bt-\b-d\bdu\bum\bmp\bp _\bs_\bt_\br_\bi_\bn_\bg;\b;
- 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
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.
o\bop\bpt\bti\bio\bon\bn d\bdo\bom\bma\bai\bin\bn-\b-n\bna\bam\bme\be _\bs_\bt_\br_\bi_\bn_\bg;\b;
- 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.
o\bop\bpt\bti\bio\bon\bn s\bsw\bwa\bap\bp-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
- This specifies the IP address of the client's swap
+ This specifies the IP address of the client's swap
server.
o\bop\bpt\bti\bio\bon\bn r\bro\boo\bot\bt-\b-p\bpa\bat\bth\bh _\bs_\bt_\br_\bi_\bn_\bg;\b;
- 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.
o\bop\bpt\bti\bio\bon\bn i\bip\bp-\b-f\bfo\bor\brw\bwa\bar\brd\bdi\bin\bng\bg _\bf_\bl_\ba_\bg;\b;
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.
o\bop\bpt\bti\bio\bon\bn n\bno\bon\bn-\b-l\blo\boc\bca\bal\bl-\b-s\bso\bou\bur\brc\bce\be-\b-r\bro\bou\but\bti\bin\bng\bg _\bf_\bl_\ba_\bg;\b;
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.
- o\bop\bpt\bti\bio\bon\bn p\bpo\bol\bli\bic\bcy\by-\b-f\bfi\bil\blt\bte\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
+ o\bop\bpt\bti\bio\bon\bn p\bpo\bol\bli\bic\bcy\by-\b-f\bfi\bil\blt\bte\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
_\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
- 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.
o\bop\bpt\bti\bio\bon\bn m\bma\bax\bx-\b-d\bdg\bgr\bra\bam\bm-\b-r\bre\bea\bas\bss\bse\bem\bmb\bbl\bly\by _\bu_\bi_\bn_\bt_\b1_\b6;\b;
- This option specifies the maximum size datagram that
+ This option specifies the maximum size datagram that
o\bop\bpt\bti\bio\bon\bn p\bpa\bat\bth\bh-\b-m\bmt\btu\bu-\b-a\bag\bgi\bin\bng\bg-\b-t\bti\bim\bme\beo\bou\but\bt _\bu_\bi_\bn_\bt_\b3_\b2;\b;
- 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.
o\bop\bpt\bti\bio\bon\bn p\bpa\bat\bth\bh-\b-m\bmt\btu\bu-\b-p\bpl\bla\bat\bte\bea\bau\bu-\b-t\bta\bab\bbl\ble\be _\bu_\bi_\bn_\bt_\b1_\b6 [,\b, _\bu_\bi_\bn_\bt_\b1_\b6... ];\b;
- 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.
o\bop\bpt\bti\bio\bon\bn i\bin\bnt\bte\ber\brf\bfa\bac\bce\be-\b-m\bmt\btu\bu _\bu_\bi_\bn_\bt_\b1_\b6;\b;
o\bop\bpt\bti\bio\bon\bn a\bal\bll\bl-\b-s\bsu\bub\bbn\bne\bet\bts\bs-\b-l\blo\boc\bca\bal\bl _\bf_\bl_\ba_\bg;\b;
- 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.
o\bop\bpt\bti\bio\bon\bn b\bbr\bro\boa\bad\bdc\bca\bas\bst\bt-\b-a\bad\bdd\bdr\bre\bes\bss\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
- 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).
o\bop\bpt\bti\bio\bon\bn p\bpe\ber\brf\bfo\bor\brm\bm-\b-m\bma\bas\bsk\bk-\b-d\bdi\bis\bsc\bco\bov\bve\ber\bry\by _\bf_\bl_\ba_\bg;\b;
- 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.
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.
o\bop\bpt\bti\bio\bon\bn r\bro\bou\but\bte\ber\br-\b-d\bdi\bis\bsc\bco\bov\bve\ber\bry\by _\bf_\bl_\ba_\bg;\b;
- 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.
o\bop\bpt\bti\bio\bon\bn r\bro\bou\but\bte\ber\br-\b-s\bso\bol\bli\bic\bci\bit\bta\bat\bti\bio\bon\bn-\b-a\bad\bdd\bdr\bre\bes\bss\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
- This option specifies the address to which the client
+ This option specifies the address to which the client
should transmit router solicitation requests.
- o\bop\bpt\bti\bio\bon\bn s\bst\bta\bat\bti\bic\bc-\b-r\bro\bou\but\bte\bes\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
+ o\bop\bpt\bti\bio\bon\bn s\bst\bta\bat\bti\bic\bc-\b-r\bro\bou\but\bte\bes\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
_\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
- 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 r\bro\bou\but\bte\ber\brs\bs option.
o\bop\bpt\bti\bio\bon\bn t\btr\bra\bai\bil\ble\ber\br-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bti\bio\bon\bn _\bf_\bl_\ba_\bg;\b;
- 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.
o\bop\bpt\bti\bio\bon\bn a\bar\brp\bp-\b-c\bca\bac\bch\bhe\be-\b-t\bti\bim\bme\beo\bou\but\bt _\bu_\bi_\bn_\bt_\b3_\b2;\b;
- This option specifies the timeout in seconds for ARP
+ This option specifies the timeout in seconds for ARP
cache entries.
o\bop\bpt\bti\bio\bon\bn i\bie\bee\bee\be8\b80\b02\b2-\b-3\b3-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bti\bio\bon\bn _\bf_\bl_\ba_\bg;\b;
- 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
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.
o\bop\bpt\bti\bio\bon\bn d\bde\bef\bfa\bau\bul\blt\bt-\b-t\btc\bcp\bp-\b-t\btt\btl\bl _\bu_\bi_\bn_\bt_\b8;\b;
- 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.
o\bop\bpt\bti\bio\bon\bn t\btc\bcp\bp-\b-k\bke\bee\bep\bpa\bal\bli\biv\bve\be-\b-i\bin\bnt\bte\ber\brv\bva\bal\bl _\bu_\bi_\bn_\bt_\b3_\b2;\b;
- 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.
o\bop\bpt\bti\bio\bon\bn t\btc\bcp\bp-\b-k\bke\bee\bep\bpa\bal\bli\biv\bve\be-\b-g\bga\bar\brb\bba\bag\bge\be _\bf_\bl_\ba_\bg;\b;
- 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.
o\bop\bpt\bti\bio\bon\bn n\bni\bis\bs-\b-d\bdo\bom\bma\bai\bin\bn _\bs_\bt_\br_\bi_\bn_\bg;\b;
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.
o\bop\bpt\bti\bio\bon\bn n\bni\bis\bs-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
o\bop\bpt\bti\bio\bon\bn n\bnt\btp\bp-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
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.
- o\bop\bpt\bti\bio\bon\bn n\bne\bet\btb\bbi\bio\bos\bs-\b-n\bna\bam\bme\be-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs...
+ o\bop\bpt\bti\bio\bon\bn n\bne\bet\btb\bbi\bio\bos\bs-\b-n\bna\bam\bme\be-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs...
];\b;
- 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
o\bop\bpt\bti\bio\bon\bn n\bne\bet\btb\bbi\bio\bos\bs-\b-d\bdd\bd-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
- 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.
o\bop\bpt\bti\bio\bon\bn n\bne\bet\btb\bbi\bio\bos\bs-\b-n\bno\bod\bde\be-\b-t\bty\byp\bpe\be _\bu_\bi_\bn_\bt_\b8;\b;
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:
o\bop\bpt\bti\bio\bon\bn n\bne\bet\btb\bbi\bio\bos\bs-\b-s\bsc\bco\bop\bpe\be _\bs_\bt_\br_\bi_\bn_\bg;\b;
- 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.
o\bop\bpt\bti\bio\bon\bn f\bfo\bon\bnt\bt-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
- 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.
o\bop\bpt\bti\bio\bon\bn x\bx-\b-d\bdi\bis\bsp\bpl\bla\bay\by-\b-m\bma\ban\bna\bag\bge\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
- 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.
- o\bop\bpt\bti\bio\bon\bn d\bdh\bhc\bcp\bp-\b-c\bcl\bli\bie\ben\bnt\bt-\b-i\bid\bde\ben\bnt\bti\bif\bfi\bie\ber\br _\bd_\ba_\bt_\ba_\b-_\bs_\bt_\br_\bi_\bn_\bg;\b;
+ o\bop\bpt\bti\bio\bon\bn d\bdh\bhc\bcp\bp-\b-c\bcl\bli\bie\ben\bnt\bt-\b-i\bid\bde\ben\bnt\bti\bif\bfi\bie\ber\br _\bs_\bt_\br_\bi_\bn_\bg;\b;
- 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.
-
+ o\bop\bpt\bti\bio\bon\bn n\bni\bis\bsp\bpl\blu\bus\bs-\b-d\bdo\bom\bma\bai\bin\bn _\bs_\bt_\br_\bi_\bn_\bg;\b;
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.
+ o\bop\bpt\bti\bio\bon\bn n\bni\bis\bsp\bpl\blu\bus\bs-\b-s\bse\ber\brv\bve\ber\brs\bs _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
+
+ This option specifies a list of IP addresses indicating
+ NIS+ servers available to the client. Servers should
+ be listed in order of preference.
+
+ o\bop\bpt\bti\bio\bon\bn t\btf\bft\btp\bp-\b-s\bse\ber\brv\bve\ber\br-\b-n\bna\bam\bme\be _\bs_\bt_\br_\bi_\bn_\bg;\b;
+
+ This option is used to identify a TFTP server and, if
+ supported by the client, should have the same effect as
+ the s\bse\ber\brv\bve\ber\br-\b-n\bna\bam\bme\be declaration. BOOTP clients are
+ unlikely to support this option. Some DHCP clients
+ will support it, and others actually require it.
+
+ o\bop\bpt\bti\bio\bon\bn b\bbo\boo\bot\btf\bfi\bil\ble\be-\b-n\bna\bam\bme\be _\bs_\bt_\br_\bi_\bn_\bg;\b;
+
+ This option is used to identify a bootstrap file. If
+ supported by the client, it should have the same effect
+ as the f\bfi\bil\ble\ben\bna\bam\bme\be declaration. BOOTP clients are
+ unlikely to support this option. Some DHCP clients
+ will support it, and others actually require it.
+
+ o\bop\bpt\bti\bio\bon\bn m\bmo\bob\bbi\bil\ble\be-\b-i\bip\bp-\b-h\bho\bom\bme\be-\b-a\bag\bge\ben\bnt\bt _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
+
+ 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.
+
+ o\bop\bpt\bti\bio\bon\bn s\bsm\bmt\btp\bp-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
+
+ The SMTP server option specifies a list of SMTP servers
+ available to the client. Servers should be listed in
+ order of preference.
+
+ o\bop\bpt\bti\bio\bon\bn p\bpo\bop\bp-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
+
+ The POP3 server option specifies a list of POP3 avail
+ able to the client. Servers should be listed in order
+ of preference.
+
+ o\bop\bpt\bti\bio\bon\bn n\bnn\bnt\btp\bp-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
+
+ The NNTP server option specifies a list of NNTP avail
+ able to the client. Servers should be listed in order
+ of preference.
+
+ o\bop\bpt\bti\bio\bon\bn w\bww\bww\bw-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
+
+ 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.
+
+ o\bop\bpt\bti\bio\bon\bn f\bfi\bin\bng\bge\ber\br-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
+
+ The Finger server option specifies a list of Finger
+ available to the client. Servers should be listed in
+ order of preference.
+
+ o\bop\bpt\bti\bio\bon\bn i\bir\brc\bc-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
+
+ The IRC server option specifies a list of IRC available
+ to the client. Servers should be listed in order of
+ preference.
+
+ o\bop\bpt\bti\bio\bon\bn s\bst\btr\bre\bee\bet\btt\bta\bal\blk\bk-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
+
+ The StreetTalk server option specifies a list of
+ StreetTalk servers available to the client. Servers
+ should be listed in order of preference.
+
+ o\bop\bpt\bti\bio\bon\bn s\bst\btr\bre\bee\bet\bta\bal\blk\bk-\b-d\bdi\bir\bre\bec\bct\bto\bor\bry\by-\b-a\bas\bss\bsi\bis\bst\bta\ban\bnc\bce\be-\b-s\bse\ber\brv\bve\ber\br _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [,\b,
+ _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs... ];\b;
+
+ 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.
+
R\bRE\bEL\bLA\bAY\bY A\bAG\bGE\bEN\bNT\bT I\bIN\bNF\bFO\bOR\bRM\bMA\bAT\bTI\bIO\bON\bN O\bOP\bPT\bTI\bIO\bON\bN
An IETF draft, draft-ietf-dhc-agent-options-03.txt,
defines a series of encapsulated options that a relay
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. o\bop\bpt\bti\bio\bon\bn a\bag\bge\ben\bnt\bt.\b.c\bci\bir\brc\bcu\bui\bit\bt-\b-i\bid\bd _\bd_\ba_\bt_\ba_\b-_\bs_\bt_\br_\bi_\bn_\bg;\b;
+ client.
+
+ o\bop\bpt\bti\bio\bon\bn a\bag\bge\ben\bnt\bt.\b.c\bci\bir\brc\bcu\bui\bit\bt-\b-i\bid\bd _\bs_\bt_\br_\bi_\bn_\bg;\b;
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.
- o\bop\bpt\bti\bio\bon\bn a\bag\bge\ben\bnt\bt.\b.c\bci\bir\brc\bcu\bui\bit\bt-\b-i\bid\bd _\bd_\ba_\bt_\ba_\b-_\bs_\bt_\br_\bi_\bn_\bg;\b;
+ o\bop\bpt\bti\bio\bon\bn a\bag\bge\ben\bnt\bt.\b.r\bre\bem\bmo\bot\bte\be-\b-i\bid\bd _\bs_\bt_\br_\bi_\bn_\bg;\b;
The remote-id suboption encodes information about the
remote host end of a circuit. Examples of what it
be an opaque object that is administratively guaranteed
to be unique to a particular remote end of a circuit.
+D\bDE\bEF\bFI\bIN\bNI\bIN\bNG\bG N\bNE\bEW\bW O\bOP\bPT\bTI\bIO\bON\bNS\bS
+ 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)
+
+
+ o\bop\bpt\bti\bio\bon\bn _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be c\bco\bod\bde\be _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be =\b= _\bd_\be_\bf_\bi_\bn_\bi_\bt_\bi_\bo_\bn ;\b;
+
+ The values of _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be and _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be should be the name you
+ have chosen for the new option and the code you have cho
+ sen. The _\bd_\be_\bf_\bi_\bn_\bi_\bt_\bi_\bo_\bn should be the definition of the
+ structure of the option.
+
+ The following simple option type definitions are sup
+ ported:
+
+ B\bBO\bOO\bOL\bLE\bEA\bAN\bN
+
+ o\bop\bpt\bti\bio\bon\bn _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be c\bco\bod\bde\be _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be =\b= b\bbo\boo\bol\ble\bea\ban\bn ;\b;
+
+ 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;
+
+ I\bIN\bNT\bTE\bEG\bGE\bER\bR
+
+ o\bop\bpt\bti\bio\bon\bn _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be c\bco\bod\bde\be _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be =\b= _\bs_\bi_\bg_\bn i\bin\bnt\bte\beg\bge\ber\br _\bw_\bi_\bd_\bt_\bh ;\b;
+
+ The _\bs_\bi_\bg_\bn token should either be blank, _\bu_\bn_\bs_\bi_\bg_\bn_\be_\bd or _\bs_\bi_\bg_\bn_\be_\bd.
+ 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;
+
+ I\bIP\bP-\b-A\bAD\bDD\bDR\bRE\bES\bSS\bS
+
+ o\bop\bpt\bti\bio\bon\bn _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be c\bco\bod\bde\be _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be =\b= i\bip\bp-\b-a\bad\bdd\bdr\bre\bes\bss\bs ;\b;
+
+ 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;
+
+
+ T\bTE\bEX\bXT\bT
+
+ o\bop\bpt\bti\bio\bon\bn _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be c\bco\bod\bde\be _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be =\b= t\bte\bex\bxt\bt ;\b;
+
+ 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";
+
+
+ D\bDA\bAT\bTA\bA S\bST\bTR\bRI\bIN\bNG\bG
+
+ o\bop\bpt\bti\bio\bon\bn _\bn_\be_\bw_\b-_\bn_\ba_\bm_\be c\bco\bod\bde\be _\bn_\be_\bw_\b-_\bc_\bo_\bd_\be =\b= s\bst\btr\bri\bin\bng\bg ;\b;
+
+ 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;
+
+
+ A\bAR\bRR\bRA\bAY\bYS\bS
+
+ 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;
+
+ R\bRE\bEC\bCO\bOR\bRD\bDS\bS
+
+ 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;
+
+
S\bSE\bEE\bE A\bAL\bLS\bSO\bO
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.
A\bAU\bUT\bTH\bHO\bOR\bR
- The Internet Software Consortium DHCP Distribution was
- written by Ted Lemon <mellon@isc.org> under a contract
- with Vixie Labs. Funding for this project was provided
- through the Internet Software Consortium. Information
- about the Internet Software Consortium can be found at
+ The Internet Software Consortium DHCP Distribution was
+
+
+
+ 13
+
+
+
+
+
+dhcpd-options(5) dhcpd-options(5)
+
+
+ written by Ted Lemon <mellon@isc.org> under a contract
+ with Vixie Labs. Funding for this project was provided
+ through the Internet Software Consortium. Information
+ about the Internet Software Consortium can be found at
h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
- 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 14
-Maintenance Procedures dhcrelay(8)
+dhcrelay(8) dhcrelay(8)
+N\bNA\bAM\bME\bE
+ dhcrelay - Dynamic Host Configuration Protocol Relay Agent
+
+S\bSY\bYN\bNO\bOP\bPS\bSI\bIS\bS
+ d\bdh\bhc\bcr\bre\bel\bla\bay\by [ -\b-p\bp _\bp_\bo_\br_\bt ] [ -\b-d\bd ] [ -\b-q\bq ] [ -\b-i\bi _\bi_\bf_\b0 [ .\b..\b..\b. -\b-i\bi _\bi_\bf_\bN
+ ] ] [ -\b-a\ba ] [ -\b-A\bA _\bl_\be_\bn_\bg_\bt_\bh ] [ -\b-D\bD ] [ -\b-m\bm _\ba_\bp_\bp_\be_\bn_\bd | _\br_\be_\bp_\bl_\ba_\bc_\be |
+ _\bf_\bo_\br_\bw_\ba_\br_\bd | _\bd_\bi_\bs_\bc_\ba_\br_\bd ] _\bs_\be_\br_\bv_\be_\br_\b0 [ _\b._\b._\b._\bs_\be_\br_\bv_\be_\br_\bN ]
+
+D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
+ 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.
+
+O\bOP\bPE\bER\bRA\bAT\bTI\bIO\bON\bN
+ 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.
-N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
- dhcrelay - Dynamic Host Configuration Protocol Relay Agent
+C\bCO\bOM\bMM\bMA\bAN\bND\bD L\bLI\bIN\bNE\bE
+ The names of the network interfaces that dhcrelay should
+ attempt to configure may be specified on the command line
+ using the -\b-i\bi 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.
-S\bS\bS\bSY\bY\bY\bYN\bN\bN\bNO\bO\bO\bOP\bP\bP\bPS\bS\bS\bSI\bI\bI\bIS\bS\bS\bS
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcr\br\br\bre\be\be\bel\bl\bl\bla\ba\ba\bay\by\by\by [ -\b-\b-\b-p\bp\bp\bp _\bp_\bo_\br_\bt ] [ -\b-\b-\b-d\bd\bd\bd ] [ -\b-\b-\b-q\bq\bq\bq ] [ -\b-\b-\b-i\bi\bi\bi _\bi_\bf_\b0 [ .\b.\b.\b..\b.\b.\b..\b.\b.\b. -\b-\b-\b-i\bi\bi\bi _\bi_\bf_\bN ] ]
- [ -\b-\b-\b-a\ba\ba\ba ] [ -\b-\b-\b-A\bA\bA\bA _\bl_\be_\bn_\bg_\bt_\bh ] [ -\b-\b-\b-D\bD\bD\bD ] [ -\b-\b-\b-m\bm\bm\bm _\ba_\bp_\bp_\be_\bn_\bd | _\br_\be_\bp_\bl_\ba_\bc_\be | _\bf_\bo_\br_\bw_\ba_\br_\bd
- | _\bd_\bi_\bs_\bc_\ba_\br_\bd ] _\bs_\be_\br_\bv_\be_\br_\b0 [ ..._\bs_\be_\br_\bv_\be_\br_\bN ]
+ 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 _\ba_\br_\be 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 -\b-i\bi flag.
-D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- 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 _\bi_\bs 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.
-O\bO\bO\bOP\bP\bP\bPE\bE\bE\bER\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- 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 -\b-p\bp flag may used. It
+ should be followed by the udp port number that dhcrelay
+ should use. This is mostly useful for debugging purposes.
-C\bC\bC\bCO\bO\bO\bOM\bM\bM\bMM\bM\bM\bMA\bA\bA\bAN\bN\bN\bND\bD\bD\bD L\bL\bL\bLI\bI\bI\bIN\bN\bN\bNE\bE\bE\bE
- The names of the network interfaces that dhcrelay should
- attempt to configure may be specified on the command line
- using the -\b-\b-\b-i\bi\bi\bi 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 _\ba_\br_\be 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 -\b-\b-\b-i\bi\bi\bi flag.
- Note that in some cases it _\bi_\bs 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 -\b-\b-\b-p\bp\bp\bp 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 -\b-d\bd 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 -\b-q\bq flag.
+R\bRE\bEL\bLA\bAY\bY A\bAG\bGE\bEN\bNT\bT I\bIN\bNF\bFO\bOR\bRM\bMA\bAT\bTI\bIO\bON\bN O\bOP\bPT\bTI\bIO\bON\bNS\bS
+ If the -\b-a\ba 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)
+ _\bN_\bo_\bt_\be_\b: 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 -\b-A\bA 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 -\b-\b-\b-d\bd\bd\bd 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 -\b-\b-\b-q\bq\bq\bq flag.
-R\bR\bR\bRE\bE\bE\bEL\bL\bL\bLA\bA\bA\bAY\bY\bY\bY A\bA\bA\bAG\bG\bG\bGE\bE\bE\bEN\bN\bN\bNT\bT\bT\bT I\bI\bI\bIN\bN\bN\bNF\bF\bF\bFO\bO\bO\bOR\bR\bR\bRM\bM\bM\bMA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN O\bO\bO\bOP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bNS\bS\bS\bS
- If the -\b-\b-\b-a\ba\ba\ba 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.
- _\bN_\bo_\bt_\be: 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 -\b-\b-\b-A\bA\bA\bA
- 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 _\ba_\bp_\bp_\be_\bn_\bd its own set of relay
+ options to the packet, leaving the supplied option field
+ intact. It may _\br_\be_\bp_\bl_\ba_\bc_\be the existing agent option field.
+ It may _\bf_\bo_\br_\bw_\ba_\br_\bd the packet unchanged. Or, it may _\bd_\bi_\bs_\bc_\ba_\br_\bd
+ it.
+ Which of these behaviours is followed by the Internet
+ Software Consortium DHCP Relay Agent may be configured
+ with the -\b-m\bm flag, followed by one of the four keywords
+ specified in _\bi_\bt_\ba_\bl_\bi_\bc_\bs 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 -\b-D\bD option is specified, all packets that
+ don't contain a match will be dropped.
+S\bSP\bPE\bEC\bCI\bIF\bFY\bYI\bIN\bNG\bG D\bDH\bHC\bCP\bP S\bSE\bER\bRV\bVE\bER\bRS\bS
+ 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)
+S\bSE\bEE\bE A\bAL\bLS\bSO\bO
+ dhclient(8), dhcpd(8), RFC2132, RFC2131, draft-ietf-dhc-
+ agent-options-03.txt.
+B\bBU\bUG\bGS\bS
+ 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.
+A\bAU\bUT\bTH\bHO\bOR\bR
+ d\bdh\bhc\bcr\bre\bel\bla\bay\by(\b(8\b8)\b) has been written for the Internet Software
+ Consortium by Ted Lemon <mellon@fugue.com> in cooperation
+ with Vixie Enterprises. To learn more about the Internet
+ Software Consortium, see h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.v\bvi\bix\bx.\b.c\bco\bom\bm/\b/i\bis\bsc\bc.\b. 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 _\ba_\bp_\bp_\be_\bn_\bd its own set of relay options to
- the packet, leaving the supplied option field intact. It
- may _\br_\be_\bp_\bl_\ba_\bc_\be the existing agent option field. It may _\bf_\bo_\br_\bw_\ba_\br_\bd
- the packet unchanged. Or, it may _\bd_\bi_\bs_\bc_\ba_\br_\bd it.
- Which of these behaviours is followed by the Internet
- Software Consortium DHCP Relay Agent may be configured with
- the -\b-\b-\b-m\bm\bm\bm flag, followed by one of the four keywords specified
- in _\bi_\bt_\ba_\bl_\bi_\bc_\bs 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 -\b-\b-\b-D\bD\bD\bD
- option is specified, all packets that don't contain a match
- will be dropped.
-S\bS\bS\bSP\bP\bP\bPE\bE\bE\bEC\bC\bC\bCI\bI\bI\bIF\bF\bF\bFY\bY\bY\bYI\bI\bI\bIN\bN\bN\bNG\bG\bG\bG D\bD\bD\bDH\bH\bH\bHC\bC\bC\bCP\bP\bP\bP S\bS\bS\bSE\bE\bE\bER\bR\bR\bRV\bV\bV\bVE\bE\bE\bER\bR\bR\bRS\bS\bS\bS
- 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.
-S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
- dhclient(8), dhcpd(8), RFC2132, RFC2131, draft-ietf-dhc-
- agent-options-03.txt.
-B\bB\bB\bBU\bU\bU\bUG\bG\bG\bGS\bS\bS\bS
- 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 h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.v\bvi\bix\bx.\b.c\bco\bom\bm.\b.
-SunOS 5.6 Last change: 3
-Maintenance Procedures dhcrelay(8)
-A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcr\br\br\bre\be\be\bel\bl\bl\bla\ba\ba\bay\by\by\by(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) has been written for the Internet Software Con-
- sortium by Ted Lemon <mellon@fugue.com> in cooperation with
- Vixie Enterprises. To learn more about the Internet
- Software Consortium, see h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.v\bv\bv\bvi\bi\bi\bix\bx\bx\bx.\b.\b.\b.c\bc\bc\bco\bo\bo\bom\bm\bm\bm/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b. To learn
- more about Vixie Enterprises, see h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.v\bv\bv\bvi\bi\bi\bix\bx\bx\bx.\b.\b.\b.c\bc\bc\bco\bo\bo\bom\bm\bm\bm.\b.\b.\b.
-
-
-
-SunOS 5.6 Last change: 4
-
+ 4
-Maintenance Procedures dhcpd(8)
+dhcpd(8) dhcpd(8)
+
+
+N\bNA\bAM\bME\bE
+ dhcpd - Dynamic Host Configuration Protocol Server
+
+S\bSY\bYN\bNO\bOP\bPS\bSI\bIS\bS
+ d\bdh\bhc\bcp\bpd\bd [ -\b-p\bp _\bp_\bo_\br_\bt ] [ -\b-f\bf ] [ -\b-d\bd ] [ -\b-q\bq ] [ -\b-c\bcf\bf _\bc_\bo_\bn_\bf_\bi_\bg_\b-_\bf_\bi_\bl_\be ]
+ [ -\b-l\blf\bf _\bl_\be_\ba_\bs_\be_\b-_\bf_\bi_\bl_\be ] [ _\bi_\bf_\b0 [ _\b._\b._\b._\bi_\bf_\bN ] ]
+
+D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
+ 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.
+
+C\bCO\bON\bNT\bTR\bRI\bIB\bBU\bUT\bTI\bIO\bON\bNS\bS
+ Development of this software is funded through contribu
+ tions and support contracts. Please see d\bdh\bhc\bcp\bp-\b-c\bco\bon\bnt\btr\bri\bib\bb(\b(5\b5)\b)
+ for information on how you can contribute.
+
+O\bOP\bPE\bER\bRA\bAT\bTI\bIO\bON\bN
+ 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 _\bd_\bh_\bc_\bp_\bd_\b._\bc_\bo_\bn_\bf 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.
-N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
- 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 _\bd_\bh_\bc_\bp_\bd_\b._\bl_\be_\ba_\bs_\be_\bs_\b~, 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.
-S\bS\bS\bSY\bY\bY\bYN\bN\bN\bNO\bO\bO\bOP\bP\bP\bPS\bS\bS\bSI\bI\bI\bIS\bS\bS\bS
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd [ -\b-\b-\b-p\bp\bp\bp _\bp_\bo_\br_\bt ] [ -\b-\b-\b-f\bf\bf\bf ] [ -\b-\b-\b-d\bd\bd\bd ] [ -\b-\b-\b-q\bq\bq\bq ] [ -\b-\b-\b-c\bc\bc\bcf\bf\bf\bf _\bc_\bo_\bn_\bf_\bi_\bg-_\bf_\bi_\bl_\be ] [
- -\b-\b-\b-l\bl\bl\blf\bf\bf\bf _\bl_\be_\ba_\bs_\be-_\bf_\bi_\bl_\be ] [ _\bi_\bf_\b0 [ ..._\bi_\bf_\bN ] ]
-
-D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- 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.
-
-C\bC\bC\bCO\bO\bO\bON\bN\bN\bNT\bT\bT\bTR\bR\bR\bRI\bI\bI\bIB\bB\bB\bBU\bU\bU\bUT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bNS\bS\bS\bS
- Development of this software is funded through contributions
- and support contracts. Please see d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bp-\b-\b-\b-c\bc\bc\bco\bo\bo\bon\bn\bn\bnt\bt\bt\btr\br\br\bri\bi\bi\bib\bb\bb\bb(\b(\b(\b(5\b5\b5\b5)\b)\b)\b) for
- information on how you can contribute.
-
-O\bO\bO\bOP\bP\bP\bPE\bE\bE\bER\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- 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
+ _\b/_\bv_\ba_\br_\b/_\br_\bu_\bn_\b/_\bd_\bh_\bc_\bp_\bd_\b._\bp_\bi_\bd, 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 _\bd_\bh_\bc_\bp_\bd._\bc_\bo_\bn_\bf 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.
+C\bCO\bOM\bMM\bMA\bAN\bND\bD L\bLI\bIN\bNE\bE
+ 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 -\b-p\bp 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 -\b-f\bf 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 _\bd_\bh_\bc_\bp_\bd._\bl_\be_\ba_\bs_\be_\bs~,
- 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 -\b-d\bd 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 -\b-c\bcf\bf flag, or an alternate lease file with the -\b-l\blf\bf
+ flag. Because of the importance of using the same lease
+ database at all times when running dhcpd in production,
+ these options should be used o\bon\bnl\bly\by 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 -\b-q\bq 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 /_\be_\bt_\bc/_\bd_\bh_\bc_\bp_\bd._\bp_\bi_\bd, 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.
+C\bCO\bON\bNF\bFI\bIG\bGU\bUR\bRA\bAT\bTI\bIO\bON\bN
+ 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.
-C\bC\bC\bCO\bO\bO\bOM\bM\bM\bMM\bM\bM\bMA\bA\bA\bAN\bN\bN\bND\bD\bD\bD L\bL\bL\bLI\bI\bI\bIN\bN\bN\bNE\bE\bE\bE
- 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
+S\bSu\bub\bbn\bne\bet\bts\bs
+ 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 -\b-\b-\b-p\bp\bp\bp 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 -\b-\b-\b-f\bf\bf\bf 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 -\b-\b-\b-d\bd\bd\bd 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 -\b-\b-\b-c\bc\bc\bcf\bf\bf\bf flag, or an alternate lease file with the -\b-\b-\b-l\bl\bl\blf\bf\bf\bf
- flag. Because of the importance of using the same lease
- database at all times when running dhcpd in production,
- these options should be used o\bo\bo\bon\bn\bn\bnl\bl\bl\bly\by\by\by for testing lease files or
- database files in a non-production environment.
+L\bLe\bea\bas\bse\be L\bLe\ben\bng\bgt\bth\bhs\bs
+ 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 -\b-\b-\b-q\bq\bq\bq 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.
-C\bC\bC\bCO\bO\bO\bON\bN\bN\bNF\bF\bF\bFI\bI\bI\bIG\bG\bG\bGU\bU\bU\bUR\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- 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:
-S\bS\bS\bSu\bu\bu\bub\bb\bb\bbn\bn\bn\bne\be\be\bet\bt\bt\bts\bs\bs\bs
- 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.
+B\bBO\bOO\bOT\bTP\bP S\bSu\bup\bpp\bpo\bor\brt\bt
+ 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;
- }
+O\bOp\bpt\bti\bio\bon\bns\bs
+ 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:
-L\bL\bL\bLe\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be L\bL\bL\bLe\be\be\ben\bn\bn\bng\bg\bg\bgt\bt\bt\bth\bh\bh\bhs\bs\bs\bs
- 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).
+F\bFI\bIL\bLE\bES\bS
+ /\b/e\bet\btc\bc/\b/d\bdh\bhc\bcp\bpd\bd.\b.c\bco\bon\bnf\bf,\b, /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcp\bpd\bd.\b.l\ble\bea\bas\bse\bes\bs,\b, /\b/v\bva\bar\br/\b/r\bru\bun\bn/\b/d\bdh\bhc\bcp\bpd\bd.\b.p\bpi\bid\bd,\b,
+ /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcp\bpd\bd.\b.l\ble\bea\bas\bse\bes\bs~\b~.\b.
- 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.
-B\bB\bB\bBO\bO\bO\bOO\bO\bO\bOT\bT\bT\bTP\bP\bP\bP S\bS\bS\bSu\bu\bu\bup\bp\bp\bpp\bp\bp\bpo\bo\bo\bor\br\br\brt\bt\bt\bt
- 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)
+S\bSE\bEE\bE A\bAL\bLS\bSO\bO
+ dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5)
+A\bAU\bUT\bTH\bHO\bOR\bR
+ d\bdh\bhc\bcp\bpd\bd(\b(8\b8)\b) was written by Ted Lemon <mellon@vix.com> under a
+ contract with Vixie Labs. Funding for this project was
+ provided by the Internet Software Consortium. Information
+ about the Internet Software Consortium can be found at
+ h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
- 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";
- }
-O\bO\bO\bOp\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bns\bs\bs\bs
- 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)
-F\bF\bF\bFI\bI\bI\bIL\bL\bL\bLE\bE\bE\bES\bS\bS\bS
- /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.c\bc\bc\bco\bo\bo\bon\bn\bn\bnf\bf\bf\bf,\b,\b,\b, /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs,\b,\b,\b, /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.p\bp\bp\bpi\bi\bi\bid\bd\bd\bd,\b,\b,\b,
- /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs~\b~\b~\b~.\b.\b.\b.
-S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
- dhclient(8), dhcrelay(8), dhcpd.conf(5), dhcpd.leases(5)
-A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) was written by Ted Lemon <mellon@vix.com> under a
- contract with Vixie Labs. Funding for this project was
- provided by the Internet Software Consortium. Information
- about the Internet Software Consortium can be found at
- h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.o\bo\bo\bor\br\br\brg\bg\bg\bg/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-SunOS 5.6 Last change: 6
-
+ 6
-Headers, Environments, and Macros dhcpd.conf(5)
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+N\bNA\bAM\bME\bE
+ dhcpd.conf - dhcpd configuration file
+
+D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
+ The dhcpd.conf file contains configuration information for
+ _\bd_\bh_\bc_\bp_\bd_\b, 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
+ _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk and the _\bs_\bu_\bb_\bn_\be_\bt declarations. If clients
+ on a subnet are to be assigned addresses dynamically, a
+ _\br_\ba_\bn_\bg_\be declaration must appear within the _\bs_\bu_\bb_\bn_\be_\bt declara
+ tion. For clients with statically assigned addresses, or
+ for installations where only known clients will be served,
+ each such client must have a _\bh_\bo_\bs_\bt declaration. If param
+ eters are to be applied to a group of declarations which
+ are not related strictly on a per-subnet basis, the _\bg_\br_\bo_\bu_\bp
+ 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 _\bs_\bu_\bb_\bn_\be_\bt declaration, which tells dhcpd how to recognize
+ that an address is on that subnet. A _\bs_\bu_\bb_\bn_\be_\bt 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 _\bs_\bu_\bb_\bn_\be_\bt declarations for these
+ two networks may be enclosed in a _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk 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 _\bh_\bo_\bs_\bt declarations, these declara
+ tions can be enclosed in a _\bg_\br_\bo_\bu_\bp 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 _\bh_\bo_\bs_\bt declara
+ tion (if any), then consulting the _\bg_\br_\bo_\bu_\bp declaration (if
+ any) which enclosed that _\bh_\bo_\bs_\bt declaration, then consulting
+ the _\bs_\bu_\bb_\bn_\be_\bt declaration for the subnet on which the client
+ is booting, then consulting the _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk 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 _\bh_\bo_\bs_\bt declaration for a client,
+ it first looks for a _\bh_\bo_\bs_\bt declaration which has a _\bf_\bi_\bx_\be_\bd_\b-
+ _\ba_\bd_\bd_\br_\be_\bs_\bs 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 _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs 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.
+
+E\bEX\bXA\bAM\bMP\bPL\bLE\bES\bS
+ A typical dhcpd.conf file will look something like this:
+
+ _\bg_\bl_\bo_\bb_\ba_\bl _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
+
+ subnet 204.254.239.0 netmask 255.255.255.224 {
+ _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
+ range 204.254.239.10 204.254.239.30;
+ }
+
+ subnet 204.254.239.32 netmask 255.255.255.224 {
+ _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
+ range 204.254.239.42 204.254.239.62;
+ }
-N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
- dhcpd.conf - dhcpd configuration file
+ 2
-D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- The dhcpd.conf file contains configuration information for
- _\bd_\bh_\bc_\bp_\bd, 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
- _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk and the _\bs_\bu_\bb_\bn_\be_\bt declarations. If clients on
- a subnet are to be assigned addresses dynamically, a _\br_\ba_\bn_\bg_\be
- declaration must appear within the _\bs_\bu_\bb_\bn_\be_\bt declaration. For
- clients with statically assigned addresses, or for installa-
- tions where only known clients will be served, each such
- client must have a _\bh_\bo_\bs_\bt declaration. If parameters are to
- be applied to a group of declarations which are not related
- strictly on a per-subnet basis, the _\bg_\br_\bo_\bu_\bp 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
- _\bs_\bu_\bb_\bn_\be_\bt declaration, which tells dhcpd how to recognize that
- an address is on that subnet. A _\bs_\bu_\bb_\bn_\be_\bt 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 {
+ _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
+ range 204.254.239.74 204.254.239.94;
+ }
+
+ group {
+ _\bg_\br_\bo_\bu_\bp_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
+ host zappo.test.isc.org {
+ _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
+ }
+ host beppo.test.isc.org {
+ _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
+ }
+ host harpo.test.isc.org {
+ _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
+ }
+ }
+ 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 _\bs_\bu_\bb_\bn_\be_\bt declarations for these two networks
- may be enclosed in a _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk 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 _\bh_\bo_\bs_\bt declarations, these declarations can be
- enclosed in a _\bg_\br_\bo_\bu_\bp 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 _\bh_\bo_\bs_\bt declara-
- tion (if any), then consulting the _\bg_\br_\bo_\bu_\bp declaration (if
- any) which enclosed that _\bh_\bo_\bs_\bt declaration, then consulting
- the _\bs_\bu_\bb_\bn_\be_\bt declaration for the subnet on which the client is
- booting, then consulting the _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk 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 _\bh_\bo_\bs_\bt declaration for a client, it
- first looks for a _\bh_\bo_\bs_\bt declaration which has a _\bf_\bi_\bx_\be_\bd-_\ba_\bd_\bd_\br_\be_\bs_\bs
- 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 _\bf_\bi_\bx_\be_\bd-
- _\ba_\bd_\bd_\br_\be_\bs_\bs 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.
-E\bE\bE\bEX\bX\bX\bXA\bA\bA\bAM\bM\bM\bMP\bP\bP\bPL\bL\bL\bLE\bE\bE\bES\bS\bS\bS
- A typical dhcpd.conf file will look something like this:
+dhcpd.conf(5) dhcpd.conf(5)
- _\bg_\bl_\bo_\bb_\ba_\bl _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
- subnet 204.254.239.0 netmask 255.255.255.224 {
- _\bs_\bu_\bb_\bn_\be_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
- range 204.254.239.10 204.254.239.30;
- }
+ In Figure 1 there is also a _\bg_\br_\bo_\bu_\bp 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 _\bo_\bp_\bt_\bi_\bo_\bn keyword, some do not. Parameters starting
+ with the _\bo_\bp_\bt_\bi_\bo_\bn 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 _\bh_\bo_\bs_\bt_\b-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs.
+ These could include such things as the _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option,
+ the name of a file to upload (the _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\b) _\ba_\bn_\bd
+ _\bt_\bh_\be _\ba_\bd_\bd_\br_\be_\bs_\bs _\bo_\bf _\bt_\bh_\be _\bs_\be_\br_\bv_\be_\br _\bf_\br_\bo_\bm _\bw_\bh_\bi_\bc_\bh _\bt_\bo _\bu_\bp_\bl_\bo_\ba_\bd _\bt_\bh_\be _\bf_\bi_\bl_\be
+ _\b(_\bt_\bh_\be _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br 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 {
- _\bs_\bu_\bb_\bn_\be_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
- range 204.254.239.42 204.254.239.62;
- }
+ 4
- subnet 204.254.239.64 netmask 255.255.255.224 {
- _\bs_\bu_\bb_\bn_\be_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
- range 204.254.239.74 204.254.239.94;
- }
- group {
- _\bg_\br_\bo_\bu_\bp-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
- host zappo.test.isc.org {
- _\bh_\bo_\bs_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
+
+
+
+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 {
- _\bh_\bo_\bs_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
+
+ 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 {
- _\bh_\bo_\bs_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs...
+
+A\bAD\bDD\bDR\bRE\bES\bSS\bS P\bPO\bOO\bOL\bLS\bS
+ The p\bpo\boo\bol\bl 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 _\ba_\bl_\bl_\bo_\bw or _\bd_\be_\bn_\by 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
+A\bAD\bDD\bDR\bRE\bES\bSS\bS A\bAL\bLL\bLO\bOC\bCA\bAT\bTI\bIO\bON\bN
+ 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 _\br_\ba_\bn_\bg_\be 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 _\bg_\br_\bo_\bu_\bp 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 _\bo_\bp_\bt_\bi_\bo_\bn keyword, some do not. Parameters starting with
- the _\bo_\bp_\bt_\bi_\bo_\bn 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).
+C\bCL\bLI\bIE\bEN\bNT\bT C\bCL\bLA\bAS\bSS\bSI\bIN\bNG\bG
+ 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 a\bad\bdd\bd
+ 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 _\bh_\bo_\bs_\bt-_\bs_\bp_\be_\bc_\bi_\bf_\bi_\bc _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs. These
- could include such things as the _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option, the name
- of a file to upload (the _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br) _\ba_\bn_\bd _\bt_\bh_\be _\ba_\bd_\bd_\br_\be_\bs_\bs
- _\bo_\bf _\bt_\bh_\be _\bs_\be_\br_\bv_\be_\br _\bf_\br_\bo_\bm _\bw_\bh_\bi_\bc_\bh _\bt_\bo _\bu_\bp_\bl_\bo_\ba_\bd _\bt_\bh_\be _\bf_\bi_\bl_\be (_\bt_\bh_\be _\bn_\be_\bx_\bt-_\bs_\be_\br_\bv_\be_\br
- 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 a\bad\bdd\bd 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; }
- }
-A\bA\bA\bAD\bD\bD\bDD\bD\bD\bDR\bR\bR\bRE\bE\bE\bES\bS\bS\bSS\bS\bS\bS P\bP\bP\bPO\bO\bO\bOO\bO\bO\bOL\bL\bL\bLS\bS\bS\bS
- The p\bp\bp\bpo\bo\bo\boo\bo\bo\bol\bl\bl\bl 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 _\bs_\bp_\ba_\bw_\bn_\bi_\bn_\bg _\bc_\bl_\ba_\bs_\bs. 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 d\bdh\bhc\bcp\bpd\bd.\b.l\ble\bea\bas\bse\bes\bs 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.
+R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: D\bDE\bEC\bCL\bLA\bAR\bRA\bAT\bTI\bIO\bON\bNS\bS
+ T\bTh\bhe\be _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
-SunOS 5.6 Last change: 5
+ s\bsh\bha\bar\bre\bed\bd-\b-n\bne\bet\btw\bwo\bor\brk\bk _\bn_\ba_\bm_\be {\b{
+ [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
+ [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
+ }\b}
+ The _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk 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 _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk statement. Parameters
+ specified in the _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk 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.
-C\bC\bC\bCL\bL\bL\bLI\bI\bI\bIE\bE\bE\bEN\bN\bN\bNT\bT\bT\bT C\bC\bC\bCL\bL\bL\bLA\bA\bA\bAS\bS\bS\bSS\bS\bS\bSI\bI\bI\bIN\bN\bN\bNG\bG\bG\bG
- 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 a\ba\ba\bad\bd\bd\bdd\bd\bd\bd state-
- ment in the conditional's list of statements:
+ _\bN_\ba_\bm_\be 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;
- }
+ T\bTh\bhe\be _\bs_\bu_\bb_\bn_\be_\bt s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- An equivalent way to do this is to simply specify the condi-
- tional expression as a matching expression in the class
- statement:
+ s\bsu\bub\bbn\bne\bet\bt _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bn_\bu_\bm_\bb_\be_\br n\bne\bet\btm\bma\bas\bsk\bk _\bn_\be_\bt_\bm_\ba_\bs_\bk {\b{
+ [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
+ [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
+ }\b}
- class ras-clients {
- match if substring (option dhcp-client-identifier, 0, 3) = "RAS";
- }
+ The _\bs_\bu_\bb_\bn_\be_\bt 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 _\br_\ba_\bn_\bg_\be 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 _\bs_\bu_\bb_\bn_\be_\bt_\b-_\bn_\bu_\bm_\bb_\be_\br should be an IP address or domain name
+ which resolves to the subnet number of the subnet being
+ described. The _\bn_\be_\bt_\bm_\ba_\bs_\bk 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
+ T\bTh\bhe\be _\br_\ba_\bn_\bg_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+ r\bra\ban\bng\bge\be [ d\bdy\byn\bna\bam\bmi\bic\bc-\b-b\bbo\boo\bot\btp\bp ] _\bl_\bo_\bw_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs [ _\bh_\bi_\bg_\bh_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs];\b;
+ For any subnet on which addresses will be assigned dynami
+ cally, there must be at least one _\br_\ba_\bn_\bg_\be 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 _\br_\ba_\bn_\bg_\be statement is declared. The
+ _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp 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, _\bh_\bi_\bg_\bh_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs 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;
- }
+ T\bTh\bhe\be _\bh_\bo_\bs_\bt s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- 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.
+ h\bho\bos\bst\bt _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be {
+ [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
+ [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
+ }\b}
- 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 h\bho\bos\bst\bt statement for every BOOTP
+ client that is to be served. h\bho\bos\bst\bt 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 _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
+ parameter, or more than one h\bho\bos\bst\bt 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
+ h\bho\bos\bst\bt statements should be used.
- It is possible to declare a _\bs_\bp_\ba_\bw_\bn_\bi_\bn_\bg _\bc_\bl_\ba_\bs_\bs. 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 h\bho\bos\bst\bt statement must be specified without a
+ f\bfi\bix\bxe\bed\bd-\b-a\bad\bdd\bdr\bre\bes\bss\bs clause. _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be should be a name identify
+ ing the host. If a _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option is not specified for
+ the host, _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be 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;
+ _\bH_\bo_\bs_\bt declarations are matched to actual DHCP or BOOTP
+ clients by matching the dhcp-client-identifier option
+ specified in the _\bh_\bo_\bs_\bt declaration to the one supplied by
+ the client, or, if the _\bh_\bo_\bs_\bt declaration or the client does
+ not provide a dhcp-client-identifier option, by matching
+ the _\bh_\ba_\br_\bd_\bw_\ba_\br_\be parameter in the _\bh_\bo_\bs_\bt declaration to the net
+ work hardware address supplied by the client. BOOTP
+ clients do not normally provide a _\bd_\bh_\bc_\bp_\b-_\bc_\bl_\bi_\be_\bn_\bt_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br,
+ so the hardware address must be used for all clients that
+ may boot using the BOOTP protocol.
+ T\bTh\bhe\be _\bg_\br_\bo_\bu_\bp s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+ g\bgr\bro\bou\bup\bp {
+ [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
+ [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
+ }\b}
-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 d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs
- 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.
+R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: A\bAL\bLL\bLO\bOW\bW A\bAN\bND\bD D\bDE\bEN\bNY\bY
+ The _\ba_\bl_\bl_\bo_\bw and _\bd_\be_\bn_\by 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.
-R\bR\bR\bRE\bE\bE\bEF\bF\bF\bFE\bE\bE\bER\bR\bR\bRE\bE\bE\bEN\bN\bN\bNC\bC\bC\bCE\bE\bE\bE:\b:\b:\b: D\bD\bD\bDE\bE\bE\bEC\bC\bC\bCL\bL\bL\bLA\bA\bA\bAR\bR\bR\bRA\bA\bA\bAT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bNS\bS\bS\bS
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
- s\bs\bs\bsh\bh\bh\bha\ba\ba\bar\br\br\bre\be\be\bed\bd\bd\bd-\b-\b-\b-n\bn\bn\bne\be\be\bet\bt\bt\btw\bw\bw\bwo\bo\bo\bor\br\br\brk\bk\bk\bk _\bn_\ba_\bm_\be {\b{\b{\b{
- [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
- [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
- }\b}\b}\b}
+A\bAL\bLL\bLO\bOW\bW A\bAN\bND\bD D\bDE\bEN\bNY\bY I\bIN\bN S\bSC\bCO\bOP\bPE\bE
+ 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 _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk 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 _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk statement. Parameters specified in
- the _\bs_\bh_\ba_\br_\be_\bd-_\bn_\be_\bt_\bw_\bo_\br_\bk 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.
+ T\bTh\bhe\be _\bu_\bn_\bk_\bn_\bo_\bw_\bn_\b-_\bc_\bl_\bi_\be_\bn_\bt_\bs k\bke\bey\byw\bwo\bor\brd\bd
- _\bN_\ba_\bm_\be 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.
+ a\bal\bll\blo\bow\bw u\bun\bnk\bkn\bno\bow\bwn\bn-\b-c\bcl\bli\bie\ben\bnt\bts\bs;\b;
+ d\bde\ben\bny\by u\bun\bnk\bkn\bno\bow\bwn\bn-\b-c\bcl\bli\bie\ben\bnt\bts\bs;\b;
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bs_\bu_\bb_\bn_\be_\bt s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ The u\bun\bnk\bkn\bno\bow\bwn\bn-\b-c\bcl\bli\bie\ben\bnt\bts\bs flag is used to tell dhcpd whether or
+ not to dynamically assign addresses to unknown clients.
+ Dynamic address assignment to unknown clients is a\bal\bll\blo\bow\bwed
+ by default.
- s\bs\bs\bsu\bu\bu\bub\bb\bb\bbn\bn\bn\bne\be\be\bet\bt\bt\bt _\bs_\bu_\bb_\bn_\be_\bt-_\bn_\bu_\bm_\bb_\be_\br n\bn\bn\bne\be\be\bet\bt\bt\btm\bm\bm\bma\ba\ba\bas\bs\bs\bsk\bk\bk\bk _\bn_\be_\bt_\bm_\ba_\bs_\bk {\b{\b{\b{
- [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
- [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
+ T\bTh\bhe\be _\bb_\bo_\bo_\bt_\bp k\bke\bey\byw\bwo\bor\brd\bd
+ a\bal\bll\blo\bow\bw b\bbo\boo\bot\btp\bp;\b;
+ d\bde\ben\bny\by b\bbo\boo\bot\btp\bp;\b;
+ The b\bbo\boo\bot\btp\bp flag is used to tell dhcpd whether or not to
+ respond to bootp queries. Bootp queries are a\bal\bll\blo\bow\bwed by
+ default.
-SunOS 5.6 Last change: 8
+ T\bTh\bhe\be _\bb_\bo_\bo_\bt_\bi_\bn_\bg k\bke\bey\byw\bwo\bor\brd\bd
+ a\bal\bll\blo\bow\bw b\bbo\boo\bot\bti\bin\bng\bg;\b;
+ d\bde\ben\bny\by b\bbo\boo\bot\bti\bin\bng\bg;\b;
+ The b\bbo\boo\bot\bti\bin\bng\bg 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 a\bal\bll\blo\bow\bwed, but if it is disabled for
+ a particular client, then that client will not be able to
+ get and address from the DHCP server.
+A\bAL\bLL\bLO\bOW\bW A\bAN\bND\bD D\bDE\bEN\bNY\bY W\bWI\bIT\bTH\bHI\bIN\bN P\bPO\bOO\bOL\bL D\bDE\bEC\bCL\bLA\bAR\bRA\bAT\bTI\bIO\bON\bNS\bS
+ 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
- }\b}\b}\b}
- The _\bs_\bu_\bb_\bn_\be_\bt 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 _\br_\ba_\bn_\bg_\be declaration.
- The _\bs_\bu_\bb_\bn_\be_\bt-_\bn_\bu_\bm_\bb_\be_\br should be an IP address or domain name
- which resolves to the subnet number of the subnet being
- described. The _\bn_\be_\bt_\bm_\ba_\bs_\bk 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.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\br_\ba_\bn_\bg_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ 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.
- r\br\br\bra\ba\ba\ban\bn\bn\bng\bg\bg\bge\be\be\be [ d\bd\bd\bdy\by\by\byn\bn\bn\bna\ba\ba\bam\bm\bm\bmi\bi\bi\bic\bc\bc\bc-\b-\b-\b-b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp ] _\bl_\bo_\bw-_\ba_\bd_\bd_\br_\be_\bs_\bs [
+ 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 _\br_\ba_\bn_\bg_\be 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 _\br_\ba_\bn_\bg_\be statement is declared. The
- _\bd_\by_\bn_\ba_\bm_\bi_\bc-_\bb_\bo_\bo_\bt_\bp 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,
- _\bh_\bi_\bg_\bh-_\ba_\bd_\bd_\br_\be_\bs_\bs 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.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bh_\bo_\bs_\bt s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ When declaring permit lists for address allocation pools,
+ the following syntaxes are recognized following the allow
+ or deny keyword:
- h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be {
- [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
- [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
- }\b}\b}\b}
+ k\bkn\bno\bow\bwn\bn c\bcl\bli\bie\ben\bnt\bts\bs;\b;
- There must be at least one h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt statement for every BOOTP
- client that is to be served. h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt 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
+ u\bun\bnk\bkn\bno\bow\bwn\bn c\bcl\bli\bie\ben\bnt\bts\bs;\b;
+ 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).
+ m\bme\bem\bmb\bbe\ber\brs\bs o\bof\bf "\b"class"\b";\b;
-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.
+ d\bdy\byn\bna\bam\bmi\bic\bc b\bbo\boo\bot\btp\bp c\bcl\bli\bie\ben\bnt\bts\bs;\b;
+ If specified, this statement either allows or prevents
+ allocation from this pool to any bootp client.
+ a\bau\but\bth\bhe\ben\bnt\bti\bic\bca\bat\bte\bed\bd c\bcl\bli\bie\ben\bnt\bts\bs;\b;
-Headers, Environments, and Macros dhcpd.conf(5)
+ 13
- address may be specified in the _\bf_\bi_\bx_\be_\bd-_\ba_\bd_\bd_\br_\be_\bs_\bs parameter, or
- more than one h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt statement may be specified.
- If client-specific boot parameters must change based on the
- network to which the client is attached, then multiple h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt
- 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 h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt statement must be specified without a
- f\bf\bf\bfi\bi\bi\bix\bx\bx\bxe\be\be\bed\bd\bd\bd-\b-\b-\b-a\ba\ba\bad\bd\bd\bdd\bd\bd\bdr\br\br\bre\be\be\bes\bs\bs\bss\bs\bs\bs clause. _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be should be a name identifying
- the host. If a _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option is not specified for the
- host, _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be is used.
+dhcpd.conf(5) dhcpd.conf(5)
- _\bH_\bo_\bs_\bt declarations are matched to actual DHCP or BOOTP
- clients by matching the dhcp-client-identifier option speci-
- fied in the _\bh_\bo_\bs_\bt declaration to the one supplied by the
- client, or, if the _\bh_\bo_\bs_\bt declaration or the client does not
- provide a dhcp-client-identifier option, by matching the
- _\bh_\ba_\br_\bd_\bw_\ba_\br_\be parameter in the _\bh_\bo_\bs_\bt declaration to the network
- hardware address supplied by the client. BOOTP clients do
- not normally provide a _\bd_\bh_\bc_\bp-_\bc_\bl_\bi_\be_\bn_\bt-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br, so the
- hardware address must be used for all clients that may boot
- using the BOOTP protocol.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bg_\br_\bo_\bu_\bp s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ 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.
- g\bg\bg\bgr\br\br\bro\bo\bo\bou\bu\bu\bup\bp\bp\bp {
- [ _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs ]
- [ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
- }\b}\b}\b}
+ u\bun\bna\bau\but\bth\bhe\ben\bnt\bti\bic\bca\bat\bte\bed\bd c\bcl\bli\bie\ben\bnt\bts\bs;\b;
- 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.
-R\bR\bR\bRE\bE\bE\bEF\bF\bF\bFE\bE\bE\bER\bR\bR\bRE\bE\bE\bEN\bN\bN\bNC\bC\bC\bCE\bE\bE\bE:\b:\b:\b: A\bA\bA\bAL\bL\bL\bLL\bL\bL\bLO\bO\bO\bOW\bW\bW\bW a\ba\ba\ban\bn\bn\bnd\bd\bd\bd D\bD\bD\bDE\bE\bE\bEN\bN\bN\bNY\bY\bY\bY
- The _\ba_\bl_\bl_\bo_\bw and _\bd_\be_\bn_\by statements can be used to control the
- behaviour of dhcpd to various sorts of requests.
+ a\bal\bll\bl c\bcl\bli\bie\ben\bnt\bts\bs;\b;
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bu_\bn_\bk_\bn_\bo_\bw_\bn-_\bc_\bl_\bi_\be_\bn_\bt_\bs k\bk\bk\bke\be\be\bey\by\by\byw\bw\bw\bwo\bo\bo\bor\br\br\brd\bd\bd\bd
+ 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.
- a\ba\ba\bal\bl\bl\bll\bl\bl\blo\bo\bo\bow\bw\bw\bw u\bu\bu\bun\bn\bn\bnk\bk\bk\bkn\bn\bn\bno\bo\bo\bow\bw\bw\bwn\bn\bn\bn-\b-\b-\b-c\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bts\bs\bs\bs;\b;\b;\b;
- d\bd\bd\bde\be\be\ben\bn\bn\bny\by\by\by u\bu\bu\bun\bn\bn\bnk\bk\bk\bkn\bn\bn\bno\bo\bo\bow\bw\bw\bwn\bn\bn\bn-\b-\b-\b-c\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bts\bs\bs\bs;\b;\b;\b;
+R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: P\bPA\bAR\bRA\bAM\bME\bET\bTE\bER\bRS\bS
+ T\bTh\bhe\be _\bd_\be_\bf_\ba_\bu_\bl_\bt_\b-_\bl_\be_\ba_\bs_\be_\b-_\bt_\bi_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- The u\bu\bu\bun\bn\bn\bnk\bk\bk\bkn\bn\bn\bno\bo\bo\bow\bw\bw\bwn\bn\bn\bn-\b-\b-\b-c\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bts\bs\bs\bs flag is used to tell dhcpd whether or
- not to dynamically assign addresses to unknown clients.
- Dynamic address assignment to unknown clients is a\ba\ba\bal\bl\bl\bll\bl\bl\blo\bo\bo\bow\bw\bw\bwed by
- default.
+ d\bde\bef\bfa\bau\bul\blt\bt-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be _\bt_\bi_\bm_\be;\b;
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bb_\bo_\bo_\bt_\bp k\bk\bk\bke\be\be\bey\by\by\byw\bw\bw\bwo\bo\bo\bor\br\br\brd\bd\bd\bd
+ _\bT_\bi_\bm_\be 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.
+ T\bTh\bhe\be _\bm_\ba_\bx_\b-_\bl_\be_\ba_\bs_\be_\b-_\bt_\bi_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+ m\bma\bax\bx-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be _\bt_\bi_\bm_\be;\b;
+ _\bT_\bi_\bm_\be 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
+ T\bTh\bhe\be _\bm_\bi_\bn_\b-_\bl_\be_\ba_\bs_\be_\b-_\bt_\bi_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+ m\bmi\bin\bn-\b-l\ble\bea\bas\bse\be-\b-t\bti\bim\bme\be _\bt_\bi_\bm_\be;\b;
+ _\bT_\bi_\bm_\be should be the minimum length in seconds that will be
+ assigned to a lease.
+ T\bTh\bhe\be _\bm_\bi_\bn_\b-_\bs_\be_\bc_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+ m\bmi\bin\bn-\b-s\bse\bec\bcs\bs _\bs_\be_\bc_\bo_\bn_\bd_\bs;\b;
+ _\bS_\be_\bc_\bo_\bn_\bd_\bs 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
- a\ba\ba\bal\bl\bl\bll\bl\bl\blo\bo\bo\bow\bw\bw\bw b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp;\b;\b;\b;
- d\bd\bd\bde\be\be\ben\bn\bn\bny\by\by\by b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp;\b;\b;\b;
- The b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp flag is used to tell dhcpd whether or not to
- respond to bootp queries. Bootp queries are a\ba\ba\bal\bl\bl\bll\bl\bl\blo\bo\bo\bow\bw\bw\bwed by
- default.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bb_\bo_\bo_\bt_\bi_\bn_\bg k\bk\bk\bke\be\be\bey\by\by\byw\bw\bw\bwo\bo\bo\bor\br\br\brd\bd\bd\bd
- a\ba\ba\bal\bl\bl\bll\bl\bl\blo\bo\bo\bow\bw\bw\bw b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\bti\bi\bi\bin\bn\bn\bng\bg\bg\bg;\b;\b;\b;
- d\bd\bd\bde\be\be\ben\bn\bn\bny\by\by\by b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\bti\bi\bi\bin\bn\bn\bng\bg\bg\bg;\b;\b;\b;
- The b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\bti\bi\bi\bin\bn\bn\bng\bg\bg\bg 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 a\ba\ba\bal\bl\bl\bll\bl\bl\blo\bo\bo\bow\bw\bw\bwed, 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)
-R\bR\bR\bRE\bE\bE\bEF\bF\bF\bFE\bE\bE\bER\bR\bR\bRE\bE\bE\bEN\bN\bN\bNC\bC\bC\bCE\bE\bE\bE:\b:\b:\b: P\bP\bP\bPA\bA\bA\bAR\bR\bR\bRA\bA\bA\bAM\bM\bM\bME\bE\bE\bET\bT\bT\bTE\bE\bE\bER\bR\bR\bRS\bS\bS\bS
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bd_\be_\bf_\ba_\bu_\bl_\bt-_\bl_\be_\ba_\bs_\be-_\bt_\bi_\bm_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
- d\bd\bd\bde\be\be\bef\bf\bf\bfa\ba\ba\bau\bu\bu\bul\bl\bl\blt\bt\bt\bt-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\be _\bt_\bi_\bm_\be;\b;\b;\b;
+ 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.
- _\bT_\bi_\bm_\be 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.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bm_\ba_\bx-_\bl_\be_\ba_\bs_\be-_\bt_\bi_\bm_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ T\bTh\bhe\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- m\bm\bm\bma\ba\ba\bax\bx\bx\bx-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\be _\bt_\bi_\bm_\be;\b;\b;\b;
+ h\bha\bar\brd\bdw\bwa\bar\bre\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\bt_\by_\bp_\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
- _\bT_\bi_\bm_\be 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 _\bh_\ba_\br_\bd_\bw_\ba_\br_\be clause
+ in the _\bh_\bo_\bs_\bt statement. _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\bt_\by_\bp_\be must be the name of
+ a physical hardware interface type. Currently, only the
+ e\bet\bth\bhe\ber\brn\bne\bet\bt and t\bto\bok\bke\ben\bn-\b-r\bri\bin\bng\bg types are recognized, although
+ support for a f\bfd\bdd\bdi\bi hardware type (and others) would also
+ be desirable. The _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs should be a set of
+ hexadecimal octets (numbers from 0 through ff) seperated
+ by colons. The _\bh_\ba_\br_\bd_\bw_\ba_\br_\be statement may also be used for
+ DHCP clients.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bm_\bi_\bn-_\bl_\be_\ba_\bs_\be-_\bt_\bi_\bm_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ T\bTh\bhe\be _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- m\bm\bm\bmi\bi\bi\bin\bn\bn\bn-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-t\bt\bt\bti\bi\bi\bim\bm\bm\bme\be\be\be _\bt_\bi_\bm_\be;\b;\b;\b;
+ f\bfi\bil\ble\ben\bna\bam\bme\be "\b"_\bf_\bi_\bl_\be_\bn_\ba_\bm_\be"\b";\b;
- _\bT_\bi_\bm_\be should be the minimum length in seconds that will be
- assigned to a lease.
+ The _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be statement can be used to specify the name of
+ the initial boot file which is to be loaded by a client.
+ The _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be should be a filename recognizable to whatever
+ file transfer protocol the client can be expected to use
+ to load the file.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bm_\bi_\bn-_\bs_\be_\bc_\bs s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ T\bTh\bhe\be _\bs_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- m\bm\bm\bmi\bi\bi\bin\bn\bn\bn-\b-\b-\b-s\bs\bs\bse\be\be\bec\bc\bc\bcs\bs\bs\bs _\bs_\be_\bc_\bo_\bn_\bd_\bs;\b;\b;\b;
+ s\bse\ber\brv\bve\ber\br-\b-n\bna\bam\bme\be "\b"_\bn_\ba_\bm_\be"\b";\b;
- _\bS_\be_\bc_\bo_\bn_\bd_\bs 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 _\bs_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be statement can be used to inform the client
+ of the name of the server from which it is booting. _\bN_\ba_\bm_\be
+ should be the name that will be provided to the client.
+ T\bTh\bhe\be _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+ n\bne\bex\bxt\bt-\b-s\bse\ber\brv\bve\ber\br _\bs_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be;\b;
-SunOS 5.6 Last change: 11
+ The _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br 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 _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be statement) is to be loaded.
+ _\bS_\be_\br_\bv_\be_\br_\b-_\bn_\ba_\bm_\be should be a numeric IP address or a domain
+ name. If no _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br parameter applies to a given
+ client, the DHCP server's IP address is used.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ T\bTh\bhe\be _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- h\bh\bh\bha\ba\ba\bar\br\br\brd\bd\bd\bdw\bw\bw\bwa\ba\ba\bar\br\br\bre\be\be\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be-_\bt_\by_\bp_\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;\b;\b;
+ f\bfi\bix\bxe\bed\bd-\b-a\bad\bdd\bdr\bre\bes\bss\bs _\ba_\bd_\bd_\br_\be_\bs_\bs [,\b, _\ba_\bd_\bd_\br_\be_\bs_\bs ... ];\b;
- In order for a BOOTP client to be recognized, its network
- hardware address must be declared using a _\bh_\ba_\br_\bd_\bw_\ba_\br_\be clause in
- the _\bh_\bo_\bs_\bt statement. _\bh_\ba_\br_\bd_\bw_\ba_\br_\be-_\bt_\by_\bp_\be must be the name of a
- physical hardware interface type. Currently, only the e\be\be\bet\bt\bt\bth\bh\bh\bh-\b-\b-\b-
- e\be\be\ber\br\br\brn\bn\bn\bne\be\be\bet\bt\bt\bt and t\bt\bt\bto\bo\bo\bok\bk\bk\bke\be\be\ben\bn\bn\bn-\b-\b-\b-r\br\br\bri\bi\bi\bin\bn\bn\bng\bg\bg\bg types are recognized, although support
- for a f\bf\bf\bfd\bd\bd\bdd\bd\bd\bdi\bi\bi\bi hardware type (and others) would also be desir-
- able. The _\bh_\ba_\br_\bd_\bw_\ba_\br_\be-_\ba_\bd_\bd_\br_\be_\bs_\bs should be a set of hexadecimal
- octets (numbers from 0 through ff) seperated by colons.
- The _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\bf_\bR _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt _\bm_\ba_\by _\ba_\bl_\bs_\bo _\bb_\be _\bu_\bs_\be_\bd _\bf_\bo_\br _\bD_\bH_\bC_\bP _\bc_\bl_\bi_\be_\bn_\bt_\bs.
+ The _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs statement is used to assign one or more
+ fixed IP addresses to a client. It should only appear in
+ a _\bh_\bo_\bs_\bt 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 _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs
+ statement are on the network on which the client is boot
+ ing, that client will not match the _\bh_\bo_\bs_\bt declaration con
+ taining that _\bf_\bi_\bx_\be_\bd_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs statement. Each _\ba_\bd_\bd_\br_\be_\bs_\bs should
+ be either an IP address or a domain name which resolves to
+ one or more IP addresses.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ T\bTh\bhe\be _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bc_\bu_\bt_\bo_\bf_\bf s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- f\bf\bf\bfi\bi\bi\bil\bl\bl\ble\be\be\ben\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be "\b"\b"\b"_\bf_\bi_\bl_\be_\bn_\ba_\bm_\be"\b"\b"\b";\b;\b;\b;
+ d\bdy\byn\bna\bam\bmi\bic\bc-\b-b\bbo\boo\bot\btp\bp-\b-l\ble\bea\bas\bse\be-\b-c\bcu\but\bto\bof\bff\bf _\bd_\ba_\bt_\be;\b;
- The _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be statement can be used to specify the name of
- the initial boot file which is to be loaded by a client.
- The _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be should be a filename recognizable to whatever
- file transfer protocol the client can be expected to use to
- load the file.
+ The _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bc_\bu_\bt_\bo_\bf_\bf 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.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bs_\be_\br_\bv_\be_\br-_\bn_\ba_\bm_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ _\bD_\ba_\bt_\be should be the date on which all assigned BOOTP leases
+ will end. The date is specified in the form:
- s\bs\bs\bse\be\be\ber\br\br\brv\bv\bv\bve\be\be\ber\br\br\br-\b-\b-\b-n\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be "\b"\b"\b"_\bn_\ba_\bm_\be"\b"\b"\b";\b;\b;\b;
+ W YYYY/MM/DD HH:MM:SS
- The _\bs_\be_\br_\bv_\be_\br-_\bn_\ba_\bm_\be statement can be used to inform the client
- of the name of the server from which it is booting. _\bN_\ba_\bm_\be
- 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.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bn_\be_\bx_\bt-_\bs_\be_\br_\bv_\be_\br s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ T\bTh\bhe\be _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bl_\be_\bn_\bg_\bt_\bh s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- n\bn\bn\bne\be\be\bex\bx\bx\bxt\bt\bt\bt-\b-\b-\b-s\bs\bs\bse\be\be\ber\br\br\brv\bv\bv\bve\be\be\ber\br\br\br _\bs_\be_\br_\bv_\be_\br-_\bn_\ba_\bm_\be;\b;\b;\b;
+ d\bdy\byn\bna\bam\bmi\bic\bc-\b-b\bbo\boo\bot\btp\bp-\b-l\ble\bea\bas\bse\be-\b-l\ble\ben\bng\bgt\bth\bh _\bl_\be_\bn_\bg_\bt_\bh;\b;
- The _\bn_\be_\bx_\bt-_\bs_\be_\br_\bv_\be_\br statement is used to specify the host
- address of the server from which the initial boot file
+ The _\bd_\by_\bn_\ba_\bm_\bi_\bc_\b-_\bb_\bo_\bo_\bt_\bp_\b-_\bl_\be_\ba_\bs_\be_\b-_\bl_\be_\bn_\bg_\bt_\bh 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 _\bl_\be_\bn_\bg_\bt_\bh as a num
+ ber of seconds. If a client reboots using BOOTP during
+ the timeout period, the lease duration is reset to _\bl_\be_\bn_\bg_\bt_\bh,
+ so a BOOTP client that boots frequently enough will never
+ lose its lease. Needless to say, this parameter should be
+ adjusted with extreme caution.
+ T\bTh\bhe\be _\bg_\be_\bt_\b-_\bl_\be_\ba_\bs_\be_\b-_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- (specified in the _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be statement) is to be loaded.
- _\bS_\be_\br_\bv_\be_\br-_\bn_\ba_\bm_\be should be a numeric IP address or a domain name.
- If no _\bn_\be_\bx_\bt-_\bs_\be_\br_\bv_\be_\br parameter applies to a given client, the
- DHCP server's IP address is used.
+ g\bge\bet\bt-\b-l\ble\bea\bas\bse\be-\b-h\bho\bos\bst\btn\bna\bam\bme\bes\bs _\bf_\bl_\ba_\bg;\b;
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bf_\bi_\bx_\be_\bd-_\ba_\bd_\bd_\br_\be_\bs_\bs s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ The _\bg_\be_\bt_\b-_\bl_\be_\ba_\bs_\be_\b-_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be_\bs 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 _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option. If _\bf_\bl_\ba_\bg is
+ true, then this lookup is done for all addresses in the
+ current scope. By default, or if _\bf_\bl_\ba_\bg is false, no
+ lookups are done.
- f\bf\bf\bfi\bi\bi\bix\bx\bx\bxe\be\be\bed\bd\bd\bd-\b-\b-\b-a\ba\ba\bad\bd\bd\bdd\bd\bd\bdr\br\br\bre\be\be\bes\bs\bs\bss\bs\bs\bs _\ba_\bd_\bd_\br_\be_\bs_\bs [,\b,\b,\b, _\ba_\bd_\bd_\br_\be_\bs_\bs ... ];\b;\b;\b;
+ T\bTh\bhe\be _\bu_\bs_\be_\b-_\bh_\bo_\bs_\bt_\b-_\bd_\be_\bc_\bl_\b-_\bn_\ba_\bm_\be_\bs s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- The _\bf_\bi_\bx_\be_\bd-_\ba_\bd_\bd_\br_\be_\bs_\bs statement is used to assign one or more
- fixed IP addresses to a client. It should only appear in a
- _\bh_\bo_\bs_\bt 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 _\bf_\bi_\bx_\be_\bd-_\ba_\bd_\bd_\br_\be_\bs_\bs statement are on
- the network on which the client is booting, that client will
- not match the _\bh_\bo_\bs_\bt declaration containing that _\bf_\bi_\bx_\be_\bd-_\ba_\bd_\bd_\br_\be_\bs_\bs
- statement. Each _\ba_\bd_\bd_\br_\be_\bs_\bs should be either an IP address or a
- domain name which resolves to one or more IP addresses.
+ u\bus\bse\be-\b-h\bho\bos\bst\bt-\b-d\bde\bec\bcl\bl-\b-n\bna\bam\bme\bes\bs _\bf_\bl_\ba_\bg;\b;
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bd_\by_\bn_\ba_\bm_\bi_\bc-_\bb_\bo_\bo_\bt_\bp-_\bl_\be_\ba_\bs_\be-_\bc_\bu_\bt_\bo_\bf_\bf s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ If the _\bu_\bs_\be_\b-_\bh_\bo_\bs_\bt_\b-_\bd_\be_\bc_\bl_\b-_\bn_\ba_\bm_\be_\bs 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,
- d\bd\bd\bdy\by\by\byn\bn\bn\bna\ba\ba\bam\bm\bm\bmi\bi\bi\bic\bc\bc\bc-\b-\b-\b-b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-c\bc\bc\bcu\bu\bu\but\bt\bt\bto\bo\bo\bof\bf\bf\bff\bf\bf\bf _\bd_\ba_\bt_\be;\b;\b;\b;
+ group {
+ use-host-decl-names on;
- The _\bd_\by_\bn_\ba_\bm_\bi_\bc-_\bb_\bo_\bo_\bt_\bp-_\bl_\be_\ba_\bs_\be-_\bc_\bu_\bt_\bo_\bf_\bf 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;
+ }
+ }
- _\bD_\ba_\bt_\be 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 _\bo_\bp_\bt_\bi_\bo_\bn _\bh_\bo_\bs_\bt_\b-_\bn_\ba_\bm_\be statement within a host declaration
+ will override the use of the name in the host declaration.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bd_\by_\bn_\ba_\bm_\bi_\bc-_\bb_\bo_\bo_\bt_\bp-_\bl_\be_\ba_\bs_\be-_\bl_\be_\bn_\bg_\bt_\bh s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ T\bTh\bhe\be _\ba_\bu_\bt_\bh_\bo_\br_\bi_\bt_\ba_\bt_\bi_\bv_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- d\bd\bd\bdy\by\by\byn\bn\bn\bna\ba\ba\bam\bm\bm\bmi\bi\bi\bic\bc\bc\bc-\b-\b-\b-b\bb\bb\bbo\bo\bo\boo\bo\bo\bot\bt\bt\btp\bp\bp\bp-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-l\bl\bl\ble\be\be\ben\bn\bn\bng\bg\bg\bgt\bt\bt\bth\bh\bh\bh _\bl_\be_\bn_\bg_\bt_\bh;\b;\b;\b;
+ 17
-SunOS 5.6 Last change: 13
+dhcpd.conf(5) dhcpd.conf(5)
+ a\bau\but\bth\bho\bor\bri\bit\bta\bat\bti\biv\bve\be;\b;
-Headers, Environments, and Macros dhcpd.conf(5)
+ n\bno\bot\bt a\bau\but\bth\bho\bor\bri\bit\bta\bat\bti\biv\bve\be;\b;
+ 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 _\bd_\by_\bn_\ba_\bm_\bi_\bc-_\bb_\bo_\bo_\bt_\bp-_\bl_\be_\ba_\bs_\be-_\bl_\be_\bn_\bg_\bt_\bh 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 _\bl_\be_\bn_\bg_\bt_\bh as a number of seconds. If a client
- reboots using BOOTP during the timeout period, the lease
- duration is reset to _\bl_\be_\bn_\bg_\bt_\bh, 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 n\bno\bot\bt a\bau\but\bth\bho\bor\bri\bit\bta\bat\bti\biv\bve\be;\b; 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.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bg_\be_\bt-_\bl_\be_\ba_\bs_\be-_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be_\bs s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ 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.
- g\bg\bg\bge\be\be\bet\bt\bt\bt-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\btn\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\bes\bs\bs\bs _\bf_\bl_\ba_\bg;\b;\b;\b;
+ T\bTh\bhe\be _\ba_\bl_\bw_\ba_\by_\bs_\b-_\br_\be_\bp_\bl_\by_\b-_\br_\bf_\bc_\b1_\b0_\b4_\b8 s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- The _\bg_\be_\bt-_\bl_\be_\ba_\bs_\be-_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be_\bs 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 _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be option. If _\bf_\bl_\ba_\bg is true,
- then this lookup is done for all addresses in the current
- scope. By default, or if _\bf_\bl_\ba_\bg is false, no lookups are
- done.
+ a\bal\blw\bwa\bay\bys\bs-\b-r\bre\bep\bpl\bly\by-\b-r\brf\bfc\bc1\b10\b04\b48\b8 _\bf_\bl_\ba_\bg;\b;
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bu_\bs_\be-_\bh_\bo_\bs_\bt-_\bd_\be_\bc_\bl-_\bn_\ba_\bm_\be_\bs s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ 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.
- u\bu\bu\bus\bs\bs\bse\be\be\be-\b-\b-\b-h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\bt-\b-\b-\b-d\bd\bd\bde\be\be\bec\bc\bc\bcl\bl\bl\bl-\b-\b-\b-n\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\bes\bs\bs\bs _\bf_\bl_\ba_\bg;\b;\b;\b;
+ If you want to send rfc1048 options to such a client, you
+ can set the a\bal\blw\bwa\bay\bys\bs-\b-r\bre\bep\bpl\bly\by-\b-r\brf\bfc\bc1\b10\b04\b48\b8 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 _\bu_\bs_\be-_\bh_\bo_\bs_\bt-_\bd_\be_\bc_\bl-_\bn_\ba_\bm_\be_\bs 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,
+ T\bTh\bhe\be _\bu_\bs_\be_\b-_\bl_\be_\ba_\bs_\be_\b-_\ba_\bd_\bd_\br_\b-_\bf_\bo_\br_\b-_\bd_\be_\bf_\ba_\bu_\bl_\bt_\b-_\br_\bo_\bu_\bt_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- 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)
+
+
+ u\bus\bse\be-\b-l\ble\bea\bas\bse\be-\b-a\bad\bdd\bdr\br-\b-f\bfo\bor\br-\b-d\bde\bef\bfa\bau\bul\blt\bt-\b-r\bro\bou\but\bte\be _\bf_\bl_\ba_\bg;\b;
+
+ If the _\bu_\bs_\be_\b-_\bl_\be_\ba_\bs_\be_\b-_\ba_\bd_\bd_\br_\b-_\bf_\bo_\br_\b-_\bd_\be_\bf_\ba_\bu_\bl_\bt_\b-_\br_\bo_\bu_\bt_\be 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.
+
+ T\bTh\bhe\be _\bs_\be_\br_\bv_\be_\br_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+
+ s\bse\ber\brv\bve\ber\br-\b-i\bid\bde\ben\bnt\bti\bif\bfi\bie\ber\br _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be;\b;
+
+ 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 m\bmu\bus\bst\bt 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 _\bs_\be_\br_\bv_\be_\br_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br 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.
+
+R\bRE\bEF\bFE\bER\bRE\bEN\bNC\bCE\bE:\b: O\bOP\bPT\bTI\bIO\bON\bN S\bST\bTA\bAT\bTE\bEM\bME\bEN\bNT\bTS\bS
+ DHCP option statements are documented in the d\bdh\bhc\bcp\bp-\b-
+ o\bop\bpt\bti\bio\bon\bns\bs(\b(5\b5)\b) manual page.
+
+V\bVE\bEN\bND\bDO\bOR\bR E\bEN\bNC\bCA\bAP\bPS\bSU\bUL\bLA\bAT\bTE\bED\bD O\bOP\bPT\bTI\bIO\bON\bNS\bS
+ The DHCP protocol defines the v\bve\ben\bnd\bdo\bor\br-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bte\bed\bd-\b-o\bop\bpt\bti\bio\bon\bns\bs
+ option, which allows vendors to define their own options
+ that will be sent encapsulated in a standard DHCP option.
+ The format of the v\bve\ben\bnd\bdo\bor\br-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bte\bed\bd-\b-o\bop\bpt\bti\bio\bon\bns\bs 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 _\bo_\bp_\bt_\bi_\bo_\bn _\bh_\bo_\bs_\bt-_\bn_\ba_\bm_\be 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 v\bve\ben\bnd\bdo\bor\br-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bte\bed\bd-\b-
+ o\bop\bpt\bti\bio\bon\bns\bs 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 C\bCL\bLI\bIE\bEN\bNT\bT C\bCL\bLA\bAS\bSS\bSI\bIN\bNG\bG section.
+
+ To define a new option space in which vendor options can
+ be stored, use the option space statement:
+
+ o\bop\bpt\bti\bio\bon\bn s\bsp\bpa\bac\bce\be _\bn_\ba_\bm_\be ;\b;
+
+ The name can then be used in option definitions, as
+ described in the d\bdh\bhc\bcp\bp-\b-o\bop\bpt\bti\bio\bon\bns\bs(\b(5\b5)\b) 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 C\bCL\bLI\bIE\bEN\bNT\bT C\bCL\bLA\bAS\bSS\bSI\bIN\bNG\bG section.
+ Using the option space definition we just did, the C\bCL\bLI\bIE\bEN\bNT\bT
+ C\bCL\bLA\bAS\bSS\bSI\bIN\bNG\bG 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 v\bve\ben\bnd\bdo\bor\br-\b-
+ o\bop\bpt\bti\bio\bon\bn-\b-s\bsp\bpa\bac\bce\be declaration indicates that in that scope, the
+ v\bve\ben\bnd\bdo\bor\br-\b-e\ben\bnc\bca\bap\bps\bsu\bul\bla\bat\bte\bed\bd-\b-o\bop\bpt\bti\bio\bon\bns\bs option should be constructed
+
+
+
+ 20
-Headers, Environments, and Macros dhcpd.conf(5)
+dhcpd.conf(5) dhcpd.conf(5)
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\ba_\bu_\bt_\bh_\bo_\br_\bi_\bt_\ba_\bt_\bi_\bv_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
+ using the values of all the options in the SUNW option
+ space.
- a\ba\ba\bau\bu\bu\but\bt\bt\bth\bh\bh\bho\bo\bo\bor\br\br\bri\bi\bi\bit\bt\bt\bta\ba\ba\bat\bt\bt\bti\bi\bi\biv\bv\bv\bve\be\be\be;\b;\b;\b;
+S\bSE\bEE\bE A\bAL\bLS\bSO\bO
+ dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.
- n\bn\bn\bno\bo\bo\bot\bt\bt\bt a\ba\ba\bau\bu\bu\but\bt\bt\bth\bh\bh\bho\bo\bo\bor\br\br\bri\bi\bi\bit\bt\bt\bta\ba\ba\bat\bt\bt\bti\bi\bi\biv\bv\bv\bve\be\be\be;\b;\b;\b;
+A\bAU\bUT\bTH\bHO\bOR\bR
+ d\bdh\bhc\bcp\bpd\bd(\b(8\b8)\b) was written by Ted Lemon <mellon@vix.com> under a
+ contract with Vixie Labs. Funding for this project was
+ provided by the Internet Software Consortium. Information
+ about the Internet Software Consortium can be found at
+ h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
- 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 n\bn\bn\bno\bo\bo\bot\bt\bt\bt a\ba\ba\bau\bu\bu\but\bt\bt\bth\bh\bh\bho\bo\bo\bor\br\br\bri\bi\bi\bit\bt\bt\bta\ba\ba\bat\bt\bt\bti\bi\bi\biv\bv\bv\bve\be\be\be;\b;\b;\b; 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.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bu_\bs_\be-_\bl_\be_\ba_\bs_\be-_\ba_\bd_\bd_\br-_\bf_\bo_\br-_\bd_\be_\bf_\ba_\bu_\bl_\bt-_\br_\bo_\bu_\bt_\be s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
- u\bu\bu\bus\bs\bs\bse\be\be\be-\b-\b-\b-l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be-\b-\b-\b-a\ba\ba\bad\bd\bd\bdd\bd\bd\bdr\br\br\br-\b-\b-\b-f\bf\bf\bfo\bo\bo\bor\br\br\br-\b-\b-\b-d\bd\bd\bde\be\be\bef\bf\bf\bfa\ba\ba\bau\bu\bu\bul\bl\bl\blt\bt\bt\bt-\b-\b-\b-r\br\br\bro\bo\bo\bou\bu\bu\but\bt\bt\bte\be\be\be _\bf_\bl_\ba_\bg;\b;\b;\b;
- If the _\bu_\bs_\be-_\bl_\be_\ba_\bs_\be-_\ba_\bd_\bd_\br-_\bf_\bo_\br-_\bd_\be_\bf_\ba_\bu_\bl_\bt-_\br_\bo_\bu_\bt_\be 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.
- T\bT\bT\bTh\bh\bh\bhe\be\be\be _\bs_\be_\br_\bv_\be_\br-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br s\bs\bs\bst\bt\bt\bta\ba\ba\bat\bt\bt\bte\be\be\bem\bm\bm\bme\be\be\ben\bn\bn\bnt\bt\bt\bt
-SunOS 5.6 Last change: 15
-Headers, Environments, and Macros dhcpd.conf(5)
- s\bs\bs\bse\be\be\ber\br\br\brv\bv\bv\bve\be\be\ber\br\br\br-\b-\b-\b-i\bi\bi\bid\bd\bd\bde\be\be\ben\bn\bn\bnt\bt\bt\bti\bi\bi\bif\bf\bf\bfi\bi\bi\bie\be\be\ber\br\br\br _\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be;\b;\b;\b;
- 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 m\bm\bm\bmu\bu\bu\bus\bs\bs\bst\bt\bt\bt 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 _\bs_\be_\br_\bv_\be_\br-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br 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.
-R\bR\bR\bRE\bE\bE\bEF\bF\bF\bFE\bE\bE\bER\bR\bR\bRE\bE\bE\bEN\bN\bN\bNC\bC\bC\bCE\bE\bE\bE:\b:\b:\b: O\bO\bO\bOP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN S\bS\bS\bST\bT\bT\bTA\bA\bA\bAT\bT\bT\bTE\bE\bE\bEM\bM\bM\bME\bE\bE\bEN\bN\bN\bNT\bT\bT\bTS\bS\bS\bS
- DHCP option statements are documented in the d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bp-\b-\b-\b-o\bo\bo\bop\bp\bp\bpt\bt\bt\bti\bi\bi\bio\bo\bo\bon\bn\bn\bns\bs\bs\bs(\b(\b(\b(5\b5\b5\b5)\b)\b)\b)
- manual page.
-S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
- dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.
-A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) was written by Ted Lemon <mellon@vix.com> under a
- contract with Vixie Labs. Funding for this project was
- provided by the Internet Software Consortium. Information
- about the Internet Software Consortium can be found at
- h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.o\bo\bo\bor\br\br\brg\bg\bg\bg/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.
-SunOS 5.6 Last change: 16
+ 21
-Headers, Environments, and Macros dhcpd.leases(5)
+dhcpd.leases(5) dhcpd.leases(5)
+N\bNA\bAM\bME\bE
+ dhcpd.leases - DHCP client lease database
-N\bN\bN\bNA\bA\bA\bAM\bM\bM\bME\bE\bE\bE
- dhcpd.leases - DHCP client lease database
+D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
+ 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.
-D\bD\bD\bDE\bE\bE\bES\bS\bS\bSC\bC\bC\bCR\bR\bR\bRI\bI\bI\bIP\bP\bP\bPT\bT\bT\bTI\bI\bI\bIO\bO\bO\bON\bN\bN\bN
- 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. D\bDO\bO N\bNO\bOT\bT 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. D\bD\bD\bDO\bO\bO\bO N\bN\bN\bNO\bO\bO\bOT\bT\bT\bT 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.
+F\bFO\bOR\bRM\bMA\bAT\bT
+ Lease descriptions are stored in a format that is parsed
+ by the same recursive descent parser used to read the
+ d\bdh\bhc\bcp\bpd\bd.\b.c\bco\bon\bnf\bf(\b(5\b5)\b) and d\bdh\bhc\bcl\bli\bie\ben\bnt\bt.\b.c\bco\bon\bnf\bf(\b(5\b5)\b) files. Currently, the
+ only declaration that is used in the dhcpd.leases file is
+ the l\ble\bea\bas\bse\be declaration.
-F\bF\bF\bFO\bO\bO\bOR\bR\bR\bRM\bM\bM\bMA\bA\bA\bAT\bT\bT\bT
- Lease descriptions are stored in a format that is parsed by
- the same recursive descent parser used to read the
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.c\bc\bc\bco\bo\bo\bon\bn\bn\bnf\bf\bf\bf(\b(\b(\b(5\b5\b5\b5)\b)\b)\b) and d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt.\b.\b.\b.c\bc\bc\bco\bo\bo\bon\bn\bn\bnf\bf\bf\bf(\b(\b(\b(5\b5\b5\b5)\b)\b)\b) files. Currently, the
- only declaration that is used in the dhcpd.leases file is
- the l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be declaration.
+ l\ble\bea\bas\bse\be _\bi_\bp_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs {\b{ _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt_\bs_\b._\b._\b. }\b}
- l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\be _\bi_\bp-_\ba_\bd_\bd_\br_\be_\bs_\bs {\b{\b{\b{ _\bs_\bt_\ba_\bt_\be_\bm_\be_\bn_\bt_\bs... }\b}\b}\b}
+ 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)
+ s\bst\bta\bar\brt\bts\bs _\bd_\ba_\bt_\be;\b;
+ e\ben\bnd\bds\bs _\bd_\ba_\bt_\be;\b;
+ Dates are specified as follows:
- s\bs\bs\bst\bt\bt\bta\ba\ba\bar\br\br\brt\bt\bt\bts\bs\bs\bs _\bd_\ba_\bt_\be;\b;\b;\b;
- e\be\be\ben\bn\bn\bnd\bd\bd\bds\bs\bs\bs _\bd_\ba_\bt_\be;\b;\b;\b;
+ _\bw_\be_\be_\bk_\bd_\ba_\by _\by_\be_\ba_\br/\b/_\bm_\bo_\bn_\bt_\bh/\b/_\bd_\ba_\by _\bh_\bo_\bu_\br:\b:_\bm_\bi_\bn_\bu_\bt_\be:\b:_\bs_\be_\bc_\bo_\bn_\bd
- 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.
- _\bw_\be_\be_\bk_\bd_\ba_\by _\by_\be_\ba_\br/\b/\b/\b/_\bm_\bo_\bn_\bt_\bh/\b/\b/\b/_\bd_\ba_\by _\bh_\bo_\bu_\br:\b:\b:\b:_\bm_\bi_\bn_\bu_\bt_\be:\b:\b:\b:_\bs_\be_\bc_\bo_\bn_\bd
+ 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 d\bda\bat\bte\be -\b-u\bu.
- 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 h\bha\bar\brd\bdw\bwa\bar\bre\be 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 d\bd\bd\bda\ba\ba\bat\bt\bt\bte\be\be\be
- -\b-\b-\b-u\bu\bu\bu.
+ h\bha\bar\brd\bdw\bwa\bar\bre\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be_\b-_\bt_\by_\bp_\be _\bm_\ba_\bc_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;
- The MAC address of the network interface that was used to
- acquire the lease is recorded with the h\bh\bh\bha\ba\ba\bar\br\br\brd\bd\bd\bdw\bw\bw\bwa\ba\ba\bar\br\br\bre\be\be\be statement:
+ The MAC address is specified as a series of hexadecimal
+ octets, seperated by colons.
- h\bh\bh\bha\ba\ba\bar\br\br\brd\bd\bd\bdw\bw\bw\bwa\ba\ba\bar\br\br\bre\be\be\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be-_\bt_\by_\bp_\be _\bm_\ba_\bc-_\ba_\bd_\bd_\br_\be_\bs_\bs;\b;\b;\b;
+ If the client used a client identifier to acquire its
+ address, the client identifier is recorded using the u\bui\bid\bd
+ statement:
- The MAC address is specified as a series of hexadecimal
- octets, seperated by colons.
+ u\bui\bid\bd _\bc_\bl_\bi_\be_\bn_\bt_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br;\b;
- If the client used a client identifier to acquire its
- address, the client identifier is recorded using the u\bu\bu\bui\bi\bi\bid\bd\bd\bd
- 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.
- u\bu\bu\bui\bi\bi\bid\bd\bd\bd _\bc_\bl_\bi_\be_\bn_\bt-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br;\b;\b;\b;
+ If the client sends a hostname using the _\bC_\bl_\bi_\be_\bn_\bt _\bH_\bo_\bs_\bt_\bn_\ba_\bm_\be
+ option, as specified in some versions of the DHCP-DNS
+ Interaction draft, that hostname is recorded using the
+ c\bcl\bli\bie\ben\bnt\bt-\b-h\bho\bos\bst\btn\bna\bam\bme\be 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.
+ c\bcl\bli\bie\ben\bnt\bt-\b-h\bho\bos\bst\btn\bna\bam\bme\be "\b"_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be"\b";\b;
- If the client sends a hostname using the _\bC_\bl_\bi_\be_\bn_\bt _\bH_\bo_\bs_\bt_\bn_\ba_\bm_\be
- option, as specified in some versions of the DHCP-DNS
- Interaction draft, that hostname is recorded using the
- c\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt-\b-\b-\b-h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\btn\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be statement.
+ If the client sends its hostname using the _\bH_\bo_\bs_\bt_\bn_\ba_\bm_\be
+ option, as Windows 95 does, it is recorded using the
- c\bc\bc\bcl\bl\bl\bli\bi\bi\bie\be\be\ben\bn\bn\bnt\bt\bt\bt-\b-\b-\b-h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\btn\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be "\b"\b"\b"_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be"\b"\b"\b";\b;\b;\b;
+ 2
-SunOS 5.6 Last change: 2
+dhcpd.leases(5) dhcpd.leases(5)
+ h\bho\bos\bst\btn\bna\bam\bme\be statement.
+ h\bho\bos\bst\btn\bna\bam\bme\be "\b"_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be"\b";\b;
-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 a\bab\bba\ban\bnd\bdo\bon\bne\bed\bd statement will be used to indi
+ cate that the lease should not be reassigned.
+ a\bab\bba\ban\bnd\bdo\bon\bne\bed\bd;\b;
+ 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 _\bH_\bo_\bs_\bt_\bn_\ba_\bm_\be option,
- as Windows 95 does, it is recorded using the h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\btn\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be state-
- ment.
+ If a client r\bre\beq\bqu\bue\bes\bst\bts\bs 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.
- h\bh\bh\bho\bo\bo\bos\bs\bs\bst\bt\bt\btn\bn\bn\bna\ba\ba\bam\bm\bm\bme\be\be\be "\b"\b"\b"_\bh_\bo_\bs_\bt_\bn_\ba_\bm_\be"\b"\b"\b";\b;\b;\b;
+F\bFI\bIL\bLE\bES\bS
+ /\b/v\bva\bar\br/\b/d\bdb\bb/\b/d\bdh\bhc\bcp\bpd\bd.\b.l\ble\bea\bas\bse\bes\bs
- 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 a\ba\ba\bab\bb\bb\bba\ba\ba\ban\bn\bn\bn-\b-\b-\b-
- d\bd\bd\bdo\bo\bo\bon\bn\bn\bne\be\be\bed\bd\bd\bd statement will be used to indicate that the lease
- should not be reassigned.
+S\bSE\bEE\bE A\bAL\bLS\bSO\bO
+ dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132,
+ RFC2131.
- a\ba\ba\bab\bb\bb\bba\ba\ba\ban\bn\bn\bnd\bd\bd\bdo\bo\bo\bon\bn\bn\bne\be\be\bed\bd\bd\bd;\b;\b;\b;
+A\bAU\bUT\bTH\bHO\bOR\bR
+ d\bdh\bhc\bcp\bpd\bd(\b(8\b8)\b) was written by Ted Lemon <mellon@vix.com> under a
+ contract with Vixie Labs. Funding for this project was
+ provided by the Internet Software Corporation. Informa
+ tion about the Internet Software Consortium can be found
+ at h\bht\btt\btp\bp:\b:/\b//\b/w\bww\bww\bw.\b.i\bis\bsc\bc.\b.o\bor\brg\bg/\b/i\bis\bsc\bc.\b.
- 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 r\br\br\bre\be\be\beq\bq\bq\bqu\bu\bu\bue\be\be\bes\bs\bs\bst\bt\bt\bts\bs\bs\bs 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.
-F\bF\bF\bFI\bI\bI\bIL\bL\bL\bLE\bE\bE\bES\bS\bS\bS
- /\b/\b/\b/e\be\be\bet\bt\bt\btc\bc\bc\bc/\b/\b/\b/d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd.\b.\b.\b.l\bl\bl\ble\be\be\bea\ba\ba\bas\bs\bs\bse\be\be\bes\bs\bs\bs
-S\bS\bS\bSE\bE\bE\bEE\bE\bE\bE A\bA\bA\bAL\bL\bL\bLS\bS\bS\bSO\bO\bO\bO
- dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132, RFC2131.
-A\bA\bA\bAU\bU\bU\bUT\bT\bT\bTH\bH\bH\bHO\bO\bO\bOR\bR\bR\bR
- d\bd\bd\bdh\bh\bh\bhc\bc\bc\bcp\bp\bp\bpd\bd\bd\bd(\b(\b(\b(8\b8\b8\b8)\b)\b)\b) was written by Ted Lemon <mellon@vix.com> under a
- contract with Vixie Labs. Funding for this project was
- provided by the Internet Software Corporation. Information
- about the Internet Software Consortium can be found at
- h\bh\bh\bht\bt\bt\btt\bt\bt\btp\bp\bp\bp:\b:\b:\b:/\b/\b/\b//\b/\b/\b/w\bw\bw\bww\bw\bw\bww\bw\bw\bw.\b.\b.\b.i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.o\bo\bo\bor\br\br\brg\bg\bg\bg/\b/\b/\b/i\bi\bi\bis\bs\bs\bsc\bc\bc\bc.\b.\b.\b.
-
-
-SunOS 5.6 Last change: 3
-
+ 3
projects / thirdparty / dhcp.git / commitdiff
