dhcpd.conf(5) MachTen Programmer’s Manual dhcpd.conf(5)

NAME
dhcpd.conf - dhcpd configuration file

DESCRIPTION
The dhcpd.conf file contains configuration information for
dhcpd, 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 server-
identifier, the shared-network and the subnet declara-
tions. If clients on a subnet are to be assigned
addresses dynamically, a range declaration must appear
within the subnet declaration. For clients with stati-
cally assigned addresses, or for installations where only
known clients will be served, each such client must have a
host declaration. If parameters are to be applied to a
group of declarations which are not related strictly on a
per-subnet basis, the group declaration can be used.

Each dhcpd.conf file must have one (and only one) server-
identifier 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 subnet declaration, which
tells dhcpd how to recognize that an address is on that
subnet. A subnet 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
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 subnet declarations for these
two networks may be enclosed in a shared-network 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 host declarations, these declara-
tions can be enclosed in a group 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 host declara-
tion (if any), then consulting the group declaration (if
any) which enclosed that host declaration, then consulting
the subnet declaration for the subnet on which the client
is booting, then consulting the shared-network 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 host declaration for a client,
it first looks for a host declaration which has a fixed-
address 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 fixed-address 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.

EXAMPLES
A typical dhcpd.conf file will look something like this:

server-identifier dhcps.isc.org;
global parameters...

shared-network ISC-BIGGIE {
shared-network-specific parameters...
subnet 204.254.239.0 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.10 204.254.239.30;
}
subnet 204.254.239.32 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.42 204.254.239.62;
}
}

subnet 204.254.239.64 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.74 204.254.239.94;
}

group {
group-specific parameters...
host zappo.test.isc.org {
host-specific parameters...
}
host beppo.test.isc.org {
host-specific parameters...
}
host harpo.test.isc.org {
host-specific parameters...
}
}

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:

option domain-name "isc.org";
option domain-name-servers ns1.isc.org, ns2.isc.org;

Figure 2

As you can see in Figure 2, it’s legal to specify host
addresses in parameters as domain names rather than as
numeric IP addresses. If a given hostname resolves to
more than one IP address (for example, if that host has
two ethernet interfaces), both addresses are supplied to
the client.

In Figure 1, you can see that both the shared-network
statement and the subnet statements can have parameters.
Let us say that the shared network ISC-BIGGIE supports an
entire department - perhaps the accounting department.
If accounting has its own domain, then a shared-network-
specific parameter might be:

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".

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.

In Figure 1 there is also a group statement, which pro-
vides common parameters for a set of three hosts - zappo,
beppo and harpo. As you can see, these hosts are all in
the test.isc.org domain, so it might make sense for a
group-specific parameter to override the domain name sup-
plied to these hosts:

option domain-name "test.isc.org";

Also, given the domain they’re in, these are probably test
machines. If we wanted to test the DHCP leasing mecha-
nism, we might set the lease timeout somewhat shorter than
the default:

max-lease-time 120;
default-lease-time 120;

You may have noticed that while some parameters start with
the option keyword, some do not. Parameters starting
with the option 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 host-specific parameters.
These could include such things as the hostname option,
the name of a file to upload (the filename parameter) and
the address of the server from which to upload the file
(the next-server 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;

host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
}

group {
filename "XncdHMX";
next-server ncd-booter;

host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }
host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }
host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }
}

REFERENCE: DECLARATIONS
The server-identifier statement

server-identifier hostname;

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.

The shared-network statement

shared-network name {
[ parameters ]
[ declarations ]
}

The shared-network 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 shared-network statement. Parameters
specified in the shared-network 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 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.

Name 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.

The subnet statement

subnet subnet-number netmask netmask {
[ parameters ]
[ declarations ]
}

The subnet 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 range declaration.

The subnet-number should be an IP address or domain name
which resolves to the subnet number of the subnet being
described. The netmask should be an IP address or domain
name which resolves to the subnet mask of the subnet being
described. The subnet number, together with the netmask,
are sufficient to determine whether any given IP address
is on the specified subnet.

Although a netmask must be given with every subnet decla-
ration, it is recommended that if there is any variance in
subnet masks at a site, a subnet-mask option statement be
used in each subnet declaration to set the desired subnet
mask, since any subnet-mask option statement will override
the subnet mask declared in the subnet statement.

The range statement

range [ dynamic-bootp ] low-address [ high-address];

For any subnet on which addresses will be assigned dynami-
cally, there must be at least one range 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 range statement is declared. The
dynamic-bootp 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, high-address can be omitted.

The host statement

host hostname {
[ parameters ]
[ declarations ]
}

There must be at least one host statement for every BOOTP
client that is to be served. host statements may also be
specified for DHCP clients, although this is not required
unless booting is only enabled for known hosts.

If it is desirable to be able to boot a DHCP or BOOTP
client on more than one subnet with fixed addresses, more
than one address may be specified in the fixed-address
parameter, or more than one host statement may be speci-
fied.

If client-specific boot parameters must change based on
the network to which the client is attached, then multiple
host 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 host statement must be specified without a
fixed-address clause. hostname should be a name identify-
ing the host. If a hostname option is not specified for
the host, hostname is used.

Host declarations are matched to actual DHCP or BOOTP
clients by matching the dhcp-client-identifier option
specified in the host declaration to the one supplied by
the client, or, if the host declaration or the client does
not provide a dhcp-client-identifier option, by matching
the hardware parameter in the host declaration to the net-
work hardware address supplied by the client. BOOTP
clients do not normally provide a dhcp-client-identifier,
so the hardware address must be used for all clients that
may boot using the BOOTP protocol.

The group statement

group {
[ parameters ]
[ declarations ]
}

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.

REFERENCE: PARAMETERS
The default-lease-time statement

default-lease-time time;

Time 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.

The max-lease-time statement

max-lease-time time;

Time 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.

The hardware statement

hardware hardware-type hardware-address;

In order for a BOOTP client to be recognized, its network
hardware address must be declared using a hardware clause
in the host statement. hardware-type must be the name of
a physical hardware interface type. Currently, only the
ethernet type is recognized, although support for token-
ring and fddi hardware types would also be desirable. The
hardware-address should be a set of hexadecimal octets
(numbers from 0 through ff) seperated by colons. The
hardware statement may also be used for DHCP clients.

The filename statement

filename "filename";

The filename statement can be used to specify the name of
the initial boot file which is to be loaded by a client.
The filename should be a filename recognizable to whatever
file transfer protocol the client can be expected to use
to load the file.

The server-name statement

server-name "name";

The server-name statement can be used to inform the client
of the name of the server from which it is booting. Name
should be the name that will be provided to the client.

The next-server statement

next-server server-name;

The next-server statement is used to specify the host
address of the server from which the initial boot file
(specified in the filename statement) is to be loaded.
Server-name should be a numeric IP address or a domain
name. If no next-server parameter applies to a given
client, the address specified in the server-identifier
statement is used.

The fixed-address statement

fixed-address address [, address ... ];

The fixed-address statement is used to assign one or more
fixed IP addresses to a client. It should only appear in
a host 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 fixed-address
statement are on the network on which the client is boot-
ing, that client will not match the host declaration con-
taining that fixed-address statement. Each address should
be either an IP address or a domain name which resolves to
one or more IP addresses.

The dynamic-bootp-lease-cutoff statement

dynamic-bootp-lease-cutoff date;

The dynamic-bootp-lease-cutoff 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.

Date should be the date on which all assigned BOOTP leases
will end. The date is specified in the form:

W YYYY/MM/DD HH:MM:SS

W is the day of the week expressed as a number from zero
(Sunday) to six (Saturday). YYYY is the year, including
the century. MM is the month expressed as a number from 1
to 12. DD is the day of the month, counting from 1. HH
is the hour, from zero to 23. MM is the minute and SS is
the second. The time is always in Greenwich Mean Time
(GMT), not local time.

The dynamic-bootp-lease-length statement

dynamic-bootp-lease-length length;

The dynamic-bootp-lease-length 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 length as a num-
ber of seconds. If a client reboots using BOOTP during
the timeout period, the lease duration is reset to length,
so a BOOTP client that boots frequently enough will never
lose its lease. Needless to say, this parameter should be
adjusted with extreme caution.

The boot-unknown-clients statement

boot-unknown-clients flag;

The boot-unknown-clients statement is used to tell dhcpd
whether or not to dynamically assign addresses to unknown
clients. If flag is true (the default), then addresses
are dynamically assigned to unknown clients when avail-
able. If flag is false, then addresses are provided only
to clients which match at least one host declaration.

The get-lease-hostnames statement

get-lease-hostnames flag;

The get-lease-hostnames 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 hostname option. If flag is
true, then this lookup is done for all addresses in the
current scope. By default, or if flag is false, no
lookups are done.

The use-host-decl-names statement

use-host-decl-names flag;

If the use-host-decl-names parameter is true in a given
scope, then for every host declaration within that scope,
the name provided for the host declaration will be sup-
plied to the client as its hostname. So, for example,

group {
use-host-decl-names on;

host joe {
hardware ethernet 08:00:2b:4c:29:32;
fixed-address joe.fugue.com;
}
}

is equivalent to

host joe {
hardware ethernet 08:00:2b:4c:29:32;
fixed-address joe.fugue.com;
option host-name "joe";
}

An option host-name statement within a host declaration
will override the use of the name in the host declaration.

REFERENCE: OPTION STATEMENTS
DHCP option statements always start with the option 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 ip-address data type can be entered either as an
explicit IP address (e.g., 239.254.197.10) or as a domain
name (e.g., haagen.isc.org). When entering a domain name,
be sure that that domain name resolves to a single IP
address.

The int32 data type specifies a signed 32-bit integer.
The uint32 data type specifies an unsigned 32-bit integer.
The int16 and uint16 data types specify signed and
unsigned 16-bit integers. The int8 and uint8 data types
specify signed and unsigned 8-bit integers. Unsigned
8-bit integers are also sometimes referred to as octets.

The string 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 flag 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 data-string 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-nnn, where nnn is the decimal
number of the option code. These options may be followed
either by a string, enclosed in quotes, or by a series of
octets, expressed as two-digit hexadecimal numbers seper-
ated by colons. For example:

option option-133 "my-option-133-text";
option option-129 1:54:c9:2b:47;

Because dhcpd does not know the format of these undefined
option codes, no checking is done to ensure the correct-
ness of the entered data.

The standard options are:

option subnet-mask ip-address;

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
an address is being assigned. However, any subnet-mask
option declaration that is in scope for the address being
assigned will override the subnet mask specified in the
subnet declaration.

option time-offset int32;

The time-offset option specifies the offset of the
client’s subnet in seconds from Coordinated Universal Time
(UTC).

option routers ip-address [, ip-address ... ];

The routers option specifies a list of IP addresses for
routers on the client’s subnet. Routers should be listed
in order of preference.

option time-servers ip-address [, ip-address ... ];

The time-server option specifies a list of RFC 868 time
servers available to the client. Servers should be listed
in order of preference.

option ien116-name-servers ip-address [, ip-address ...
];

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.

option domain-name-servers ip-address [, ip-address ...
];

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.

option log-servers ip-address [, ip-address ... ];

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.

option cookie-servers ip-address [, ip-address ... ];

The cookie server option specifies a list of RFC 865
cookie servers available to the client. Servers should be
listed in order of preference.

option lpr-servers ip-address [, ip-address ... ];

The LPR server option specifies a list of RFC 1179 line
printer servers available to the client. Servers should
be listed in order of preference.

option impress-servers ip-address [, ip-address ... ];

The impress-server option specifies a list of Imagen
Impress servers available to the client. Servers should
be listed in order of preference.

option resource-location-servers ip-address [, ip-address
... ];

This option specifies a list of RFC 887 Resource Location
servers available to the client. Servers should be listed
in order of preference.

option host-name string;

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.

option boot-size uint16;

This option specifies the length in 512-octet blocks of
the default boot image for the client.

option merit-dump string;

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.

option domain-name string;

This option specifies the domain name that client should
use when resolving hostnames via the Domain Name System.

option swap-server ip-address;

This specifies the IP address of the client’s swap server.

option root-path string;

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.

option ip-forwarding flag;

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.

option non-local-source-routing flag;

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.

option policy-filter ip-address ip-address [, ip-address
ip-address ... ];

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.

option max-dgram-reassembly uint16;

This option specifies the maximum size datagram that the
client should be prepared to reassemble. The minimum
value legal value is 576.

option default-ip-ttl uint8;

This option specifies the default time-to-live that the
client should use on outgoing datagrams.

option path-mtu-aging-timeout uint32;

This option specifies the timeout (in seconds) to use when
aging Path MTU values discovered by the mechanism defined
in RFC 1191.

option path-mtu-plateau-table uint16 [, uint16 ... ];

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.

option interface-mtu uint16;

This option specifies the MTU to use on this interface.
The minimum legal value for the MTU is 68.

option all-subnets-local flag;

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.

option broadcast-address ip-address;

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).

option perform-mask-discovery flag;

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.

option mask-supplier flag;

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.

option router-discovery flag;

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.

option router-solicitation-address ip-address;

This option specifies the address to which the client
should transmit router solicitation requests.

option static-routes ip-address ip-address [, ip-address
ip-address ... ];

This option specifies a list of static routes that the
client should install in its routing cache. If multiple
routes to the same destination are specified, they are
listed in descending order of priority.

The routes consist of a list of IP address pairs. The
first address is the destination address, and the second
address is the router for the destination.

The default route (0.0.0.0) is an illegal destination for
a static route. To specify the default route, use the
routers option.

option trailer-encapsulation flag;

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.

option arp-cache-timeout uint32;

This option specifies the timeout in seconds for ARP cache
entries.

option ieee802-3-encapsulation flag;

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.

option default-tcp-ttl uint8;

This option specifies the default TTL that the client
should use when sending TCP segments. The minimum value
is 1.

option tcp-keepalive-interval uint32;

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.

option tcp-keepalive-garbage flag;

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.

option nis-domain string;

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.

option nis-servers ip-address [, ip-address ... ];

This option specifies a list of IP addresses indicating
NIS servers available to the client. Servers should be
listed in order of preference.

option ntp-servers ip-address [, ip-address ... ];

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.

option netbios-name-servers ip-address [, ip-address ...
];

The NetBIOS name server (NBNS) option specifies a list of
RFC 1001/1002 NBNS name servers listed in order of prefer-
ence.

option netbios-dd-server ip-address [, ip-address ... ];

The NetBIOS datagram distribution server (NBDD) option
specifies a list of RFC 1001/1002 NBDD servers listed in
order of preference.

option netbios-node-type uint8;

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.

option netbios-scope string;

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.

option font-servers ip-address [, ip-address ... ];

This option specifies a list of X Window System Font
servers available to the client. Servers should be listed
in order of preference.

option x-display-manager ip-address [, ip-address ... ];

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.

option dhcp-client-identifier data-string;

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.

SEE ALSO
dhcpd.conf(5), dhcpd.leases(5), draft-ietf-dhc-
options-1533update-04.txt, draft-ietf-dhc-dhcp-07.txt.

AUTHOR
dhcpd(8) 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 http://www.isc.org/isc.

MachTen 15