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-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\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-
+ addresses, and also to discover information about the net
work to which they are attached. BOOTP provides similar
functionality, with certain restrictions.
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-
+ 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.
refresh its memory about what leases have been assigned.
New leases are appended to the end of the dhcpd.leases
- file. In order to prevent the file from becoming arbi-
+ file. In order to prevent the file from becoming arbi
trarily 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
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-
+ 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.
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-
+ network interfaces which are up, elimininating non-broad
+ cast interfaces if possible, and listen for DHCP broad
casts on each interface.
If dhcpd should listen on a port other than the standard
under a debugger, or when running it out of inittab on
System V systems.
- To have dhcpd log to the standard error descriptor, spec-
+ 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-
+ 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.
these options should be used o\bon\bnl\bly\by for testing lease files
or database files in a non-production environment.
+ When starting dhcpd up from a system startup script (e.g.,
+ /etc/rc), it may not be desirable to print out the entire
+ copyright message on startup. To avoid printing this
+ message, the -\b-q\bq flag may be specified.
+
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-
+ 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.
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
+ 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
+ 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.113 239.252.197.250;
}
- If a subnet will only be provided with BOOTP service and
- no dynamic address assignment, the range clause can be
- left out entirely, but the subnet statement must appear.
-
-
-
+ If a subnet will only be provided with BOOTP service and
dhcpd(8) dhcpd(8)
+ no dynamic address assignment, the range clause can be
+ left out entirely, but the subnet statement must appear.
+
+
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
+ DHCP leases can be assigned almost any length from zero
+ seconds to infinity. What lease length makes sense for
any given subnet, or for any given installation, will vary
depending on the kinds of hosts being served.
- For example, in an office environment where systems are
+ 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-
+ lease times of a month of more. In a final test environ
+ ment on a manufacturing floor, it may make more sense to
+ assign a maximum lease length of 30 minutes - enough time
+ to go through a simple test procedure on a network appli
ance before packaging it up for delivery.
- It is possible to specify two lease lengths: the default
- length that will be assigned if a client doesn't ask for
- any particular lease length, and a maximum lease length.
+ It is possible to specify two lease lengths: the default
+ length that will be assigned if a client doesn't ask for
+ any particular lease length, and a maximum lease length.
These are specified as clauses to the subnet command:
subnet 239.252.197.0 netmask 255.255.255.0 {
max-lease-time 7200;
|
- This particular subnet declaration specifies a default
- lease time of 600 seconds (ten minutes), and a maximum
- lease time of 7200 seconds (two hours). Other common
- values would be 86400 (one day), 604800 (one week) and
+ 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
+ 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
+ Each BOOTP client must be explicitly declared in the
+ dhcpd.conf file. A very basic client declaration will
+ specify the client network interface's hardware address
+ and the IP address to assign to that client. If the
+ client needs to be able to load a boot file from the
+ server, that file's name must be specified. A simple
bootp client declaration might look like this:
host haagen {
hardware ethernet 08:00:2b:4c:59:23;
fixed-address 239.252.197.9;
- filename "/tftpboot/haagen.boot";
- }
-
-
dhcpd(8) dhcpd(8)
+ filename "/tftpboot/haagen.boot";
+ }
+
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
+ DHCP (and also BOOTP with Vendor Extensions) provide a
+ mechanism whereby the server can provide the client with
+ information about how to configure its network interface
+ (e.g., subnet mask), and also how the client can access
+ various network services (e.g., DNS, IP routers, and so
on).
These options can be specified on a per-subnet basis, and,
- for BOOTP clients, also on a per-client basis. In the
- event that a BOOTP client declaration specifies options
- that are also specified in its subnet declaration, the
- options specified in the client declaration take prece-
- dence. An reasonably complete DHCP configuration might
+ for BOOTP clients, also on a per-client basis. In the
+ event that a BOOTP client declaration specifies options
+ that are also specified in its subnet declaration, the
+ options specified in the client declaration take prece
+ dence. An reasonably complete DHCP configuration might
look something like this:
subnet 239.252.197.0 netmask 255.255.255.0 {
option domain-name "isc.org";
}
- A bootp host on that subnet that needs to be in a differ-
- ent domain and use a different name server might be
+ A bootp host on that subnet that needs to be in a differ
+ ent domain and use a different name server might be
declared as follows:
host haagen {
option domain-name "vix.com";
}
- A more complete description of the dhcpd.conf file syntax
+ A more complete description of the dhcpd.conf file syntax
is provided in dhcpd.conf(5).
F\bFI\bIL\bLE\bES\bS
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.
+ contract with Vixie Labs. Funding for this project was
5
+
+
+
+dhcpd(8) dhcpd(8)
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 6
+
+
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-
+ 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-
+ (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.
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-
+ 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-
+ 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
be specified before any declarations which depend on those
parameters may be specified.
- Declarations about network topology include the _\bs_\be_\br_\bv_\be_\br_\b-
- _\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br, the _\bs_\bh_\ba_\br_\be_\bd_\b-_\bn_\be_\bt_\bw_\bo_\br_\bk and the _\bs_\bu_\bb_\bn_\be_\bt declara-
- tions. 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 stati-
- cally assigned addresses, or for installations 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.
-
- Each dhcpd.conf file must have one (and only one) _\bs_\be_\br_\bv_\be_\br_\b-
- _\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br declaration, which tells dhcpd the identifier
- to use when issuing leases. 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 dynamically allocated on that
- subnet.
+ 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
dhcpd.conf(5) dhcpd.conf(5)
- 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 eth-
+ 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-
+ 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-
+ 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-
+ 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,
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-
+ 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
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-
+ _\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,
E\bEX\bXA\bAM\bMP\bPL\bLE\bES\bS
A typical dhcpd.conf file will look something like this:
- server-identifier dhcps.isc.org;
_\bg_\bl_\bo_\bb_\ba_\bl _\bp_\ba_\br_\ba_\bm_\be_\bt_\be_\br_\bs_\b._\b._\b.
shared-network ISC-BIGGIE {
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;
}
- 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;
- }
}
subnet 204.254.239.64 netmask 255.255.255.224 {
Figure 1
- Notice that after the server-identifier declaration,
- 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:
+ 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;
option domain-name "accounting.isc.org";
+ All subnet declarations appearing in the shared-network
+ declaration would then have the domain-name option set to
+ "accounting.isc.org" instead of just "isc.org".
+
3
dhcpd.conf(5) dhcpd.conf(5)
- All subnet declarations appearing in the shared-network
- declaration would then have the domain-name option set to
- "accounting.isc.org" instead of just "isc.org".
-
- The most obvious reason for having subnet-specific parame-
- ters as shown in Figure 1 is that each subnet, of neces-
+ 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:
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-
+ 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.
- In Figure 1 there is also a _\bg_\br_\bo_\bu_\bp statement, which pro-
+ 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-
+ 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-
+ machines. If we wanted to test the DHCP leasing mecha
nism, we might set the lease timeout somewhat shorter than
the default:
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
dhcpd.conf(5) dhcpd.conf(5)
- 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 {
}
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_\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 declaration must be used exactly
- once in each dhcpd.conf file to tell dhcpd what IP address
- to use as its server identifier, as required by the DHCP
- protocol. On a machine with a single interface, the
- server identifier should be the primary address of that
- interface. On machines with multiple interfaces, the
- address of one such interface must be chosen. Any
- address may be chosen, as long as it is the address of one
- of the interfaces of that machine.
-
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
s\bsh\bha\bar\bre\bed\bd-\b-n\bne\bet\btw\bwo\bor\brk\bk _\bn_\ba_\bm_\be {\b{
[ _\bd_\be_\bc_\bl_\ba_\br_\ba_\bt_\bi_\bo_\bn_\bs ]
}\b}
-
-
-
- 5
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
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-
+ 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
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,
+
+
+
+ 5
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
enclosed in quotes.
T\bTh\bhe\be _\bs_\bu_\bb_\bn_\be_\bt s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
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-
+ 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.
are sufficient to determine whether any given IP address
is on the specified subnet.
- Although a netmask must be given with every subnet decla-
+ 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
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
+ 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
+ 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.
+ T\bTh\bhe\be _\bh_\bo_\bs_\bt s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+ 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}
- 6
+ 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
+ 6
-dhcpd.conf(5) dhcpd.conf(5)
- dynamically, 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 specified range may be dynamically
- assigned to BOOTP clients as well as DHCP clients. When
- specifying a single address, _\bh_\bi_\bg_\bh_\b-_\ba_\bd_\bd_\br_\be_\bs_\bs can be omitted.
- T\bTh\bhe\be _\bh_\bo_\bs_\bt s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+dhcpd.conf(5) dhcpd.conf(5)
- 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}
- 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
+ specified for DHCP clients, although this is not required
unless booting is only enabled for known hosts.
- If it is desirable to be able to boot a DHCP or BOOTP
- client on more than one subnet with fixed addresses, more
- than one address may be specified in the _\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-
+ 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.
- If client-specific boot parameters must change based on
+ 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.
- 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
+ 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.
- _\bH_\bo_\bs_\bt declarations are matched to actual DHCP or BOOTP
+ _\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
+ 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
+ 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}
+ 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.
+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.
- 7
+ 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
+ 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;
+ 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
-dhcpd.conf(5) dhcpd.conf(5)
+ 7
- }\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.
-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.
- 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
+dhcpd.conf(5) dhcpd.conf(5)
- 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;
- 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
+ not to dynamically assign addresses to unknown clients.
+ Dynamic address assignment to unknown clients is a\bal\bll\blo\bow\bwed
by default.
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
+ 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.
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
+ 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
+ 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.
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 _\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 if the client requesting the lease
+ asks for a specific expiration time.
+ T\bTh\bhe\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
- 8
+ 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;
+ 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 type is recognized, although support for t\bto\bok\bke\ben\bn-\b-
+ r\bri\bin\bng\bg and f\bfd\bdd\bdi\bi hardware types 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
+ 8
-dhcpd.conf(5) dhcpd.conf(5)
- 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 if the client requesting the lease
- asks for a specific expiration time.
- T\bTh\bhe\be _\bh_\ba_\br_\bd_\bw_\ba_\br_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
+dhcpd.conf(5) dhcpd.conf(5)
- 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;
- 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 type is recognized, although support for t\bto\bok\bke\ben\bn-\b-
- r\bri\bin\bng\bg and f\bfd\bdd\bdi\bi hardware types 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_\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_\b.
T\bTh\bhe\be _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be s\bst\bta\bat\bte\bem\bme\ben\bnt\bt
f\bfi\bil\ble\ben\bna\bam\bme\be "\b"_\bf_\bi_\bl_\be_\bn_\ba_\bm_\be"\b";\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 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
+ file transfer protocol the client can be expected to use
to load the file.
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
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;
- The _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br statement is used to specify the host
- 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 address specified in the _\bs_\be_\br_\bv_\be_\br_\b-_\bi_\bd_\be_\bn_\bt_\bi_\bf_\bi_\be_\br
- statement is used.
+ The _\bn_\be_\bx_\bt_\b-_\bs_\be_\br_\bv_\be_\br statement is used to specify the host
+ 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\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
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;
-
-
-
- 9
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
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-
+ 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.
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
+
+
+
+ 9
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
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
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-
+ 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.
-
-
- 10
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
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
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;
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-
+
+
+
+ 10
+
+
+
+
+
+dhcpd.conf(5) dhcpd.conf(5)
+
+
+ the name provided for the host declaration will be sup
plied to the client as its hostname. So, for example,
group {
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.
-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 _\bo_\bp_\bt_\bi_\bo_\bn statements always start with the _\bo_\bp_\bt_\bi_\bo_\bn key-
- word, followed by an option name, followed by option data.
- The option names and data formats are described below.
- It is not necessary to exhaustively specify all DHCP
- options - only those options which are needed by clients
- must be specified.
-
- Option data comes in a variety of formats, as defined
- below:
-
- The i\bip\bp-\b-a\bad\bdd\bdr\bre\bes\bss\bs data type can be entered either as an
- explicit IP address (e.g., 239.254.197.10) or as a domain
-
-
-
- 11
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
- name (e.g., haagen.isc.org). When entering a domain name,
- be sure that that domain name resolves to a single IP
- address.
-
- The i\bin\bnt\bt3\b32\b2 data type specifies a signed 32-bit integer.
- The u\bui\bin\bnt\bt3\b32\b2 data type specifies an unsigned 32-bit integer.
- The i\bin\bnt\bt1\b16\b6 and u\bui\bin\bnt\bt1\b16\b6 data types specify signed and
- unsigned 16-bit integers. The i\bin\bnt\bt8\b8 and u\bui\bin\bnt\bt8\b8 data types
- specify signed and unsigned 8-bit integers. Unsigned
- 8-bit integers are also sometimes referred to as octets.
-
- The s\bst\btr\bri\bin\bng\bg data type specifies an NVT ASCII string, which
- must be enclosed in double quotes - for example, to spec-
- ify a domain-name option, the syntax would be
-
- option domain-name "isc.org";
-
- The f\bfl\bla\bag\bg data type specifies a boolean value. Booleans
- can be either true or false (or on or off, if that makes
- more sense to you).
-
- The 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:
-
- option client-identifier "CLIENT-FOO";
- or
- option client-identifier 43:4c:49:45:54:2d:46:4f:4f;
-
- 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-
- _\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-
- 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 provided any-
- where in scope, as a last resort dhcpd will use the subnet
- mask from the subnet declaration for the network on which
-
-
-
- 12
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
- an address is being assigned. However, _\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 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 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 _\b[_\b, _\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 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 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;
-
- 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 prefer-
- ence.
-
- 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 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
- cookie servers available to the client. Servers should be
- listed in order of preference.
-
- o\bop\bpt\bti\bio\bon\bn l\blp\bpr\br-\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 LPR server option specifies a list of RFC 1179 line
- printer servers available to the client. Servers should
-
-
-
- 13
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
- 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
- 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 Location
- 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 set restric-
- tions.
-
- 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;
-
- This option specifies the length in 512-octet blocks of
- the default boot image for the client.
-
- 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 the
- client crashes. The path is formatted as a character
- string consisting of characters from the NVT ASCII charac-
- ter 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 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 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
- client's root disk. The path is formatted as a character
- string consisting of characters from the NVT ASCII charac-
- ter 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;
-
-
-
-
- 14
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
- This option specifies whether the client should configure
- its IP layer for packet forwarding. A value of 0 means
- disable IP forwarding, and a value of 1 means enable IP
- forwarding.
-
- 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 configure
- its IP layer to allow forwarding of datagrams with non-
- local source routes (see Section 3.3.5 of [4] for a dis-
- cussion of this topic). A value of 0 means disallow for-
- warding 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
- _\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 addresses
- and masks which specify destination/mask pairs with which
- to filter incoming source routes.
-
- Any source routed datagram whose next-hop address does not
- match one of the filters should be discarded by the
- client.
-
- See STD 3 (RFC1122) for further information.
-
- 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 the
- client should be prepared to reassemble. The minimum
- value legal value is 576.
-
- o\bop\bpt\bti\bio\bon\bn d\bde\bef\bfa\bau\bul\blt\bt-\b-i\bip\bp-\b-t\btt\btl\bl _\bu_\bi_\bn_\bt_\b8_\b;
-
- This option specifies the default time-to-live that the
- client should use on outgoing datagrams.
-
- 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 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 minimum 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;
-
-
-
- 15
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
- This option specifies the MTU to use on this interface.
- The minimum legal value for the MTU is 68.
-
- 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 that network
- to which the client is directly connected. A value of 1
- indicates that all subnets share the same MTU. A value of
- 0 means that the client should assume that some subnets of
- the directly connected network may have smaller MTUs.
-
- 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 (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
- perform subnet mask discovery using ICMP. A value of 0
- indicates that the client should not perform mask discov-
- ery. A value of 1 means that the client should perform
- mask discovery.
-
- o\bop\bpt\bti\bio\bon\bn m\bma\bas\bsk\bk-\b-s\bsu\bup\bpp\bpl\bli\bie\ber\br _\bf_\bl_\ba_\bg;\b;
-
- This option specifies whether or not the client should
- respond to subnet mask requests using ICMP. A value of 0
- indicates that the client should not respond. A value of
- 1 means that the client should respond.
-
- 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
- client should not perform router discovery. A value of 1
- means that the client should perform router discovery.
-
- 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
- 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
- _\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 multiple
- routes to the same destination are specified, they are
- listed in descending order of priority.
-
-
-
- 16
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
- The routes consist of a list of IP address pairs. The
- first address is the destination address, and the second
- address is the router for the destination.
-
- The default route (0.0.0.0) is an illegal destination for
- a static route. 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
- negotiate the use of trailers (RFC 893 [14]) when using
- the ARP protocol. A value of 0 indicates that the client
- should not attempt to use trailers. A value of 1 means
- that the client should attempt to use trailers.
-
- 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 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 1042)
- encapsulation if the interface is an Ethernet. A value of
- 0 indicates that the client should use RFC 894 encapsula-
- tion. 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 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 connec-
- tions 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 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;
-
-
-
- 17
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
-
- This option specifies the name of the client's NIS (Sun
- Network Information Services) domain. The domain is for-
- matted as a character string consisting of characters 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;
-
- 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 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. 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 ...
- ];\b;
-
- The NetBIOS name server (NBNS) option specifies a list of
- RFC 1001/1002 NBNS name servers listed in order of prefer-
- ence.
-
- 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 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 a
- single octet which identifies the client type. A value of
- 1 corresponds to a NetBIOS B-node; a value of 2 corre-
- sponds to a P-node; a value of 4 corresponds to an M-node;
- a value of 8 corresponds to an H-node.
-
- 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 charac-
- ter-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 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;
-
-
-
- 18
-
-
-
-
-
-dhcpd.conf(5) dhcpd.conf(5)
-
+ 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
- This option specifies a list of systems that are running
- the X Window System Display Manager and are available to
- the client. Addresses should be listed in order of pref-
- erence.
+ 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;
- 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;
+ The server-identifier statement is now obsolete and is
+ ignored by the DHCP server.
- This option can be used to specify the a DHCP client iden-
- tifier in a host declaration, so that dhcpd can find the
- host record by matching against the client identifier.
+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.
S\bSE\bEE\bE A\bAL\bLS\bSO\bO
- dhcpd.conf(5), dhcpd.leases(5), draft-ietf-dhc-
- options-1533update-04.txt, draft-ietf-dhc-dhcp-07.txt.
+ dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.
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-
+ 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 19
+ 11
projects / thirdparty / dhcp.git / commitdiff
