mir/isc-dhcp
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/dhcp synced 2025-08-31 14:25:41 +00:00
Code Issues Releases Wiki Activity

Formatted man pages

Browse Source
This commit is contained in:
Ted Lemon
1996-03-06 10:08:47 +00:00
parent 5f39769efa
commit 05f8b3f6b3
4 changed files with 1238 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

182
dhcpd.cat8 Normal file
View File

@@ -0,0 +1,182 @@
dhcpd(8) NetBSD System Manager's Manual dhcpd(8)
NNAAMMEE
ddhhccppdd - Dynamic Host Configuration Protocol server
SSYYNNOOPPSSIISS
ddhhccppdd [--pp --ppoorrtt]
DDEESSCCRRIIPPTTIIOONN
dhcpd(8) 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 in-
formation about the network to which they are attached. BOOTP provides
similar but much more limited functionality.
OOPPEERRAATTIIOONN
The DHCP protocol allows a host which is unknown to the network adminis-
trator 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 ad-
ministrator allocates address pools in each subnet and enters them into
the dhcpd.conf(5) file.
On startup, dhcpd reads the ddhhccppdd..ccoonnff file and keeps the list of avail-
able addresses on each subnet in memory. When a host requests an address
using the DHCP protocol, dhcpd allocates an address for it. Each such
host is assigned a lease, which expires after an amount of time chosen by
the administrator (by default, one day). As leases expire, the hosts to
which they are assigned are expected to renew the leases if they wish to
continue to use the addresses. Once a lease has expired, the host to
which that lease is assigned is no longer permitted to use the IP address
assigned to it.
In order to keep track of leases across system reboots and server
restarts, ddhhccppdd keeps a list of leases it has assigned in the
dhcpd.leases(5) file. Before dhcpd grants a lease to a host, it records
the lease in this file and makes sure that the contents of the file are
flushed to disk. This ensures that even in the event of a system crash,
ddhhccppdd will not forget about a lease that it has assigned. On startup,
after reading the ddhhccppdd..ccoonnff file, ddhhccppdd reads the ddhhccppdd..lleeaasseess file to
refresh its memory about what leases have been assigned.
New leases are appended to the end of the ddhhccppdd..lleeaasseess file. In order
to prevent the file from becoming arbitrarily large, from time to time
ddhhccppdd creates a new ddhhccppdd..lleeaasseess file from its in-core lease database.
Once this file has been written to disk, the old file is renamed
ddhhccppdd..lleeaasseess~~, and the new file is renamed ddhhccppdd..lleeaasseess. If the system
crashes in the middle of this process, whichever ddhhccppdd..lleeaasseess file re-
mains will contain all the lease information, so there is no need for a
special crash recovery process.
BOOTP support is also provided by this server. Unlike DHCP, the BOOTP
protocol requires that the server know the hardware address of the client
that is to be booted. The network administrator must determine that ad-
dress, allocate an IP address for the client, and enter that information
into the ddhhccppdd..ccoonnff file.
Whenever changes are made to the ddhhccppdd..ccoonnff file, ddhhccppdd must be restart-
ed. To restart ddhhccppdd, send signal 15 to the process ID contained in
//vvaarr//rruunn//ddhhccppdd..ppiidd, and then re-invoke ddhhccppdd.
CCOONNFFIIGGUURRAATTIIOONN
The syntax of the dhcpd.conf(8) file is discussed seperately. This sec-
tion should be used as an overview of the configuration process, and the
dhcpd.conf(8) documentation should be consulted for detailed reference
information.
SSuubbnneettss
dhcpd(8) needs to know the subnet numbers and netmasks of all subnets for
which it will be providing service. In addition, in order to dynamical-
ly allocate addresses, it must be assigned one or more ranges of address-
es on each subnet which it can in turn assign to client hosts as they
boot. Thus, a very simple configuration providing DHCP support might
look like this:
subnet 239.252.197.0 netmask 255.255.255.0
range 239.252.197.10 239.252.197.250;
Multiple address ranges may be specified like this:
subnet 239.252.197.0 netmask 255.255.255.0
range 239.252.197.10 239.252.197.107
range 239.252.197.113 239.252.197.250;
If a subnet will only be provided with BOOTP service and no dynamic ad-
dress assignment, the range clause can be left out entirely, but the sub-
net statement must appear.
LLeeaassee LLeennggtthhss
DHCP leases can be assigned almost any length from zero seconds to infin-
ity. What lease length makes sense for any given subnet, or for any
given installation, will vary depending on the kinds of hosts being
served.
For example, in an office environment where systems are added from time
to time and removed from time to time, but move relatively infrequently,
it might make sense to allow lease times of a month of more. In a final
test environment on a manufacturing floor, it may make more sense to as-
sign a maximum lease length of 30 minutes - enough time to go through a
simple test procedure on a network appliance before packaging it up for
delivery.
It is possible to specify two lease lengths: the default length that will
be assigned if a client doesn't ask for any particular lease length, and
a maximum lease length. These are specified as clauses to the subnet
command:
subnet 239.252.197.0 netmask 255.255.255.0
range 239.252.197.10 239.252.197.107
default-lease-time 600
max-lease-time 7200;
This particular subnet declaration specifies a default lease time of 600
seconds (ten minutes), and a maximum lease time of 7200 seconds (two
hours). Other common values would be 86400 (one day), 604800 (one week)
and 2592000 (30 days).
Each subnet need not have the same lease--in the case of an office envi-
ronment and a manufacturing environment served by the same DHCP server,
it might make sense to have widely disparate values for default and maxi-
mum lease times on each subnet.
BBOOOOTTPP SSuuppppoorrtt
Each BOOTP client must be explicitly declared in the ddhhccppdd..ccoonnff file. A
very basic client declaration will specify the client network interface's
hardware address and the IP address to assign to that client. If the
client needs to be able to load a boot file from the server, that file's
name must be specified. A simple bootp client declaration might look
like this:
host haagen hardware ethernet 08:00:2b:4c:59:23
fixed-address 239.252.197.9
filename "/tftpboot/haagen.boot";
OOppttiioonnss
DHCP (and also BOOTP with Vendor Extensions) provide a mechanism whereby
the server can provide the client with information about how to configure
its network interface (e.g., subnet mask), and also how the client can
access various network services (e.g., DNS, IP routers, and so on).
These options can be specified on a per-subnet basis, and, for BOOTP
clients, also on a per-client basis. In the event that a BOOTP client
declaration specifies options that are also specified in its subnet dec-
laration, the options specified in the client declaration take prece-
dence. An reasonably complete DHCP configuration might look something
like this:
subnet 239.252.197.0 netmask 255.255.255.0
range 239.252.197.10 239.252.197.250
default-lease-time 600 max-lease-time 7200
option subnet-mask 255.255.255.0
option broadcast-address 239.252.197.255
option routers 239.252.197.1
option domain-name-servers 239.252.197.2, 239.252.197.3
option domain-name "isc.org";
A bootp host on that subnet that needs to be in a different domain and
use a different name server might be declared as follows:
host haagen hardware ethernet 08:00:2b:4c:59:23
fixed-address 239.252.197.9
filename "/tftpboot/haagen.boot"
option domain-name-servers 192.5.5.1
option domain-name "vix.com";
A complete list of DHCP Options and their syntaxes is provided in
dhcpd.conf(5).
FFIILLEESS
//eettcc//ddhhccppdd..ccoonnff, //eettcc//ddhhccppdd..lleeaasseess, //vvaarr//rruunn//ddhhccppdd..ppiidd,
//eettcc//ddhhccppdd..lleeaasseess~~.
SSEEEE AALLSSOO
dhcpd.conf(5), dhcpd.leases(5)
AAUUTTHHOORR
dhcpd(8) was written by Ted Lemon <<mmeelllloonn@@vviixx..ccoomm>> under a contract with
Vixie Labs. Funding for this project was provided by the Internet Soft-
ware Corporation. Information about the Internet Software Consortium can
be found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.
March 6, 1996 3

437
dhcpd.conf.cat5 Normal file
View File

@@ -0,0 +1,437 @@
dhcpd.conf(5) NetBSD Programmer's Manual dhcpd.conf(5)
NNAAMMEE
ddhhccppdd..ccoonnff - dhcpd configuration file
DDEESSCCRRIIPPTTIIOONN
The dhcpd.conf(5) file contains configuration information for dhcpd(8),
the Dynamic Host Configuration Protocol daemon. A primer on configuring
ddhhccppdd is included in dhcpd(8). This document describes the format of the
file in detail, and is probably a better reference than a primer.
The ddhhccppdd..ccoonnff file is a free-form ASCII text file. It is parsed by a
recursive-descent parser. Statements in the file may contain extra tabs
and newlines for formatting purposes. Each statement in the file is
terminated by a semicolon. Keywords in the file are case-insensitive.
There are currently two statements that can meaningfully appear in the
file--the ssuubbnneett statement, and the hhoosstt statement.
TThhee SSUUBBNNEETT ssttaatteemmeenntt
ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k [_c_l_a_u_s_e_s];
_s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or DNS name which resolves to the
subnet number of the subnet being described. _n_e_t_m_a_s_k should be an IP ad-
dress or DNS name which resolves to the subnet mask of the subnet being
described. These are the only required fields in a subnet declaration,
although it may be desirable to add one or more of the following clauses.
Subnets for which addresses will be dynamically allocated must have one
or more addresses reserved for future allocation by ddhhccppdd. These address-
es are allocated using the rraannggee clause.
rraannggee _l_o_w_e_s_t_-_a_d_d_r_e_s_s _h_i_g_h_e_s_t_-_a_d_d_r_e_s_s
_L_o_w_e_s_t_-_a_d_d_r_e_s_s should be the lowest address in the range that may be as-
signed by ddhhccppdd to a DHCP client. _H_i_g_h_e_s_t_-_a_d_d_r_e_s_s should be the highest
address in the range that may be assigned by ddhhccppdd. If there is only one
address in a range, it must be specified as both the lowest and highest
addresses. As many rraannggee clauses as are needed may be specified in any
given ssuubbnneett statement.
ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e
_T_i_m_e should be the expiration time in seconds that will be assigned to a
lease if the client requesting the lease does not ask for a specific ex-
piration time. This clause may only appear once in each ssuubbnneett state-
ment.
mmaaxx--lleeaassee--ttiimmee _t_i_m_e
_T_i_m_e should be the maximum expiration time in seconds that will be as-
signed to a lease if the client requesting the lease asks for a specific
expiration time. This clause may only appear once in each ssuubbnneett state-
ment.
ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n
Any number of ddhhccppdd..ccoonnff option clauses may appear in a subnet statement.
The syntax of option declarations is described later in this document.
TThhee HHOOSSTT ssttaatteemmeenntt
hhoosstt _h_o_s_t_n_a_m_e [_c_l_a_u_s_e_s];
There must be at least one hhoosstt statement for every BOOTP client that is
to be served. _h_o_s_t_n_a_m_e should be a name identifying the host. It is
for labelling purposes only, and is not used in the BOOTP protocol.
hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s
In order for a BOOTP client to be recognized, its network hardware ad-
dress must be declared using a hhaarrddwwaarree clause in the hhoosstt statement.
Only one such clause can appear in any host statement. _h_a_r_d_w_a_r_e_-_t_y_p_e
must be the name of a physical hardware interface type. Currently, only
the eetthheerrnneett type is recognized, although support for ttookkeenn--rriinngg and ffddddii
hardware types will be added soon. The _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s should be a set
of hexadecimal octets (numbers from 0 through ff) seperated by colons.
ffiilleennaammee _f_i_l_e_n_a_m_e
If the BOOTP client needs to load a boot file (for example, a kernel or
configuration file), the name of this file may be provided to the client
using the ffiilleennaammee clause. The _f_i_l_e_n_a_m_e should be a filename recogniz-
able to whatever file transfer protocol the client can be expected to use
to load the file.
ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s
BOOTP clients must be assigned fixed IP addresses. The ffiixxeedd--aaddddrreessss
clause is used to associate a fixed IP address with a BOOTP client.
_A_d_d_r_e_s_s should be either an IP address or a DNS name which resolves to a
single IP address.
ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n
Any number of ddhhccppdd..ccoonnff option clauses may appear in a host statement.
The syntax of option declarations is described later in this document.
If an option clause in a hhoosstt statement conflicts with an option clause
in the ssuubbnneett statement for the subnet containing that host, the option
clause in the hhoosstt statement is used.
OOppttiioonn DDeeccllaarraattiioonnss
Option declarations always start with the ooppttiioonn keyword, followed by an
option name, followed by option data. The option names and data formats
are described below. Many of the options described below which set IP
or TCP parameters have default values which will generally work perfectly
well, so only those options whose values must be set explicitly should be
included in ssuubbnneett or hhoosstt statements.
Option data comes in a variety of formats. In order to avoid having to
explain the formats along with each option definition below, a number of
data types have been defined.
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 sin-
gle 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 en-
closed in double quotes - for example, to specify a domain-name option,
the syntax would be
option domain-name "isc.org"
The flag data type specifies a one-bit (boolean) number.
The documentation for the various options mentioned below is taken from
the latest IETF draft document on DHCP options.
ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s
The subnet mask option specifies the client's subnet mask as per RFC 950.
ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2
The time-offset option specifies the offset of the client's subnet in
seconds from Coordinated Universal Time (UTC).
ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The routers option specifies a list of IP addresses for routers on the
client's subnet. Routers should be listed in order of preference.
ooppttiioonn ttiimmee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The time-server option specifies a list of RFC 868 time servers available
to the client. Servers should be listed in order of preference.
ooppttiioonn nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The name-servers option specifies a list of IEN 116 name servers avail-
able to the client. Servers should be listed in order of preference.
ooppttiioonn ddoommaaiinn--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The domain-name-servers option specifies a list of Domain Name System
(STD 13, RFC 1035) name servers available to the client. Servers should
be listed in order of preference.
ooppttiioonn lloogg--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The log-server option specifies a list of MIT-LCS UDP log servers avail-
able to the client. Servers should be listed in order of preference.
ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The cookie server option specifies a list of RFC 865 cookie servers
available to the client. Servers should be listed in order of prefer-
ence.
ooppttiioonn llpprr--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The LPR server option specifies a list of RFC 1179 line printer servers
available to the client. Servers should be listed in order of prefer-
ence.
ooppttiioonn iimmpprreessss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The impress-server option specifies a list of Imagen Impress servers
available to the client. Servers should be listed in order of prefer-
ence.
ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies a list of RFC 887 Resource Location servers avail-
able to the client. Servers should be listed in order of preference.
ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g
This option specifies the name of the client. The name may or may not be
qualified with the local domain name (it is preferable to use the domain-
name option to specify the domain name). See RFC 1035 for character set
restrictions.
ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6
This option specifies the length in 512-octet blocks of the default boot
image for the client.
ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g
This option specifies the path-name of a file to which the client's core
image should be dumped in the event the client crashes. The path is for-
matted as a character string consisting of characters from the NVT ASCII
character set.
ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g
This option specifies the domain name that client should use when resolv-
ing hostnames via the Domain Name System.
ooppttiioonn sswwaapp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s
This specifies the IP address of the client's swap server.
ooppttiioonn rroooott--ppaatthh _s_t_r_i_n_g
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 character set.
ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g
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.
ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g
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 discussion of this topic). A value of 0 means disal-
low forwarding of such datagrams, and a value of 1 means allow forward-
ing.
ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies policy filters for non-local source routing. The
filters consist of a list of IP addresses and masks which specify desti-
nation/mask pairs with which to filter incoming source routes.
Any source routed datagram whose next-hop address does not match one of
the filters should be discarded by the client.
See STD 3 (RFC1122) for further information.
ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6
This option specifies the maximum size datagram that the client should be
prepared to reassemble. The minimum value legal value is 576.
ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8
This option specifies the default time-to-live that the client should use
on outgoing datagrams.
ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2
This option specifies the timeout (in seconds) to use when aging Path MTU
values discovered by the mechanism defined in RFC 1191.
ooppttiioonn ppaatthh--mmttuu--ppllaatteeaauu--ttaabbllee _u_i_n_t_1_6 [ , _u_i_n_t_1_6 _._._.]
This option specifies a table of MTU sizes to use when performing Path
MTU Discovery as defined in RFC 1191. The table is formatted as a list
of 16-bit unsigned integers, ordered from smallest to largest. The mini-
mum MTU value cannot be smaller than 68.
ooppttiioonn iinntteerrffaaccee--mmttuu _u_i_n_t_1_6
This option specifies the MTU to use on this interface. The minimum le-
gal value for the MTU is 68.
ooppttiioonn aallll--ssuubbnneettss--llooccaall _f_l_a_g This option specifies whether or not the
client may assume that all subnets of the IP network to which the client
is connected use the same MTU as the subnet of that network to which the
client is directly connected. A value of 1 indicates that all subnets
share the same MTU. A value of 0 means that the client should assume
that some subnets of the directly connected network may have smaller
MTUs.
ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p_-_a_d_d_r_e_s_s
This option specifies the broadcast address in use on the client's sub-
net. Legal values for broadcast addresses are specified in section
3.2.1.3 of STD 3 (RFC1122).
ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g
This option specifies whether or not the client should perform subnet
mask discovery using ICMP. A value of 0 indicates that the client should
not perform mask discovery. A value of 1 means that the client should
perform mask discovery.
ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g
This option specifies whether or not the client should respond to subnet
mask requests using ICMP. A value of 0 indicates that the client should
not respond. A value of 1 means that the client should respond.
ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g
This option specifies whether or not the client should solicit routers
using the Router Discovery mechanism defined in RFC 1256. A value of 0
indicates that the client should not perform router discovery. A value
of 1 means that the client should perform router discovery.
ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p_-_a_d_d_r_e_s_s
This option specifies the address to which the client should transmit
router solicitation requests.
ooppttiioonn ssttaattiicc--rroouutteess _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies a list of static routes that the client should in-
stall 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 rroouutteerrss option.
ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g
This option specifies whether or not the client should negotiate the use
of trailers (RFC 893 [14]) when using the ARP protocol. A value of 0 in-
dicates that the client should not attempt to use trailers. A value of 1
means that the client should attempt to use trailers.
ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2
This option specifies the timeout in seconds for ARP cache entries.
ooppttiioonn iieeeeee880022..33--eennccaappssuullaattiioonn _f_l_a_g
This option specifies whether or not the client should use Ethernet Ver-
sion 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 encapsulation. A value of 1 means that the client should use RFC
1042 encapsulation.
ooppttiioonn ddeeffaauulltt--ttccpp--ttttll _u_i_n_t_8
This option specifies the default TTL that the client should use when
sending TCP segments. The minimum value is 1.
ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2
This option specifies the interval (in seconds) that the client TCP
should wait before sending a keepalive message on a TCP connection. The
time is specified as a 32-bit unsigned integer. A value of zero indi-
cates that the client should not generate keepalive messages on connec-
tions unless specifically requested by an application.
ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g
This option specifies the whether or not the client should send TCP
keepalive messages with a octet of garbage for compatibility with older
implementations. A value of 0 indicates that a garbage octet should not
be sent. A value of 1 indicates that a garbage octet should be sent.
ooppttiioonn nniiss--ddoommaaiinn _s_t_r_i_n_g
This option specifies the name of the client's NIS (Sun Network Informa-
tion Services) domain. The domain is formatted as a character string
consisting of characters from the NVT ASCII character set.
ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies a list of IP addresses indicating NIS servers
available to the client. Servers should be listed in order of prefer-
ence.
ooppttiioonn nnttpp--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies a list of IP addresses indicating NTP (RFC 1035)
servers available to the client. Servers should be listed in order of
preference.
ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The NetBIOS name server (NBNS) option specifies a list of RFC 1001/1002
NBNS name servers listed in order of preference.
ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The NetBIOS datagram distribution server (NBDD) option specifies a list
of RFC 1001/1002 NBDD servers listed in order of preference.
ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8
The NetBIOS node type option allows NetBIOS over TCP/IP clients which are
configurable to be configured as described in RFC 1001/1002. The value
is specified as a single octet which identifies the client type. A value
of 1 corresponds to a NetBIOS B-node; a value of 2 corresponds to a P-
node; a value of 4 corresponds to an M-node; a value of 8 corresponds to
an H-node.
ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g
The NetBIOS scope option specifies the NetBIOS over TCP/IP scope parame-
ter for the client as specified in RFC 1001/1002. See RFC1001, RFC1002,
and RFC1035 for character-set restrictions.
ooppttiioonn ffoonntt--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies a list of X Window System Font servers available to
the client. Servers should be listed in order of preference.
ooppttiioonn xx--ddiissppllaayy--mmaannaaggeerr _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies a list of systems that are running the X Window
System Display Manager and are available to the client. Addresses should
be listed in order of preference.
SSEEEE AALLSSOO
dhcpd.conf(5), dhcpd.leases(5)
AAUUTTHHOORR
dhcpd(8) was written by Ted Lemon <<mmeelllloonn@@vviixx..ccoomm>> under a contract with
Vixie Labs. Funding for this project was provided by the Internet Soft-
ware Corporation. Information about the Internet Software Consortium can
be found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.
March 6, 1996 7

182
server/dhcpd.cat8 Normal file
View File

@@ -0,0 +1,182 @@
dhcpd(8) NetBSD System Manager's Manual dhcpd(8)
NNAAMMEE
ddhhccppdd - Dynamic Host Configuration Protocol server
SSYYNNOOPPSSIISS
ddhhccppdd [--pp --ppoorrtt]
DDEESSCCRRIIPPTTIIOONN
dhcpd(8) 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 in-
formation about the network to which they are attached. BOOTP provides
similar but much more limited functionality.
OOPPEERRAATTIIOONN
The DHCP protocol allows a host which is unknown to the network adminis-
trator 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 ad-
ministrator allocates address pools in each subnet and enters them into
the dhcpd.conf(5) file.
On startup, dhcpd reads the ddhhccppdd..ccoonnff file and keeps the list of avail-
able addresses on each subnet in memory. When a host requests an address
using the DHCP protocol, dhcpd allocates an address for it. Each such
host is assigned a lease, which expires after an amount of time chosen by
the administrator (by default, one day). As leases expire, the hosts to
which they are assigned are expected to renew the leases if they wish to
continue to use the addresses. Once a lease has expired, the host to
which that lease is assigned is no longer permitted to use the IP address
assigned to it.
In order to keep track of leases across system reboots and server
restarts, ddhhccppdd keeps a list of leases it has assigned in the
dhcpd.leases(5) file. Before dhcpd grants a lease to a host, it records
the lease in this file and makes sure that the contents of the file are
flushed to disk. This ensures that even in the event of a system crash,
ddhhccppdd will not forget about a lease that it has assigned. On startup,
after reading the ddhhccppdd..ccoonnff file, ddhhccppdd reads the ddhhccppdd..lleeaasseess file to
refresh its memory about what leases have been assigned.
New leases are appended to the end of the ddhhccppdd..lleeaasseess file. In order
to prevent the file from becoming arbitrarily large, from time to time
ddhhccppdd creates a new ddhhccppdd..lleeaasseess file from its in-core lease database.
Once this file has been written to disk, the old file is renamed
ddhhccppdd..lleeaasseess~~, and the new file is renamed ddhhccppdd..lleeaasseess. If the system
crashes in the middle of this process, whichever ddhhccppdd..lleeaasseess file re-
mains will contain all the lease information, so there is no need for a
special crash recovery process.
BOOTP support is also provided by this server. Unlike DHCP, the BOOTP
protocol requires that the server know the hardware address of the client
that is to be booted. The network administrator must determine that ad-
dress, allocate an IP address for the client, and enter that information
into the ddhhccppdd..ccoonnff file.
Whenever changes are made to the ddhhccppdd..ccoonnff file, ddhhccppdd must be restart-
ed. To restart ddhhccppdd, send signal 15 to the process ID contained in
//vvaarr//rruunn//ddhhccppdd..ppiidd, and then re-invoke ddhhccppdd.
CCOONNFFIIGGUURRAATTIIOONN
The syntax of the dhcpd.conf(8) file is discussed seperately. This sec-
tion should be used as an overview of the configuration process, and the
dhcpd.conf(8) documentation should be consulted for detailed reference
information.
SSuubbnneettss
dhcpd(8) needs to know the subnet numbers and netmasks of all subnets for
which it will be providing service. In addition, in order to dynamical-
ly allocate addresses, it must be assigned one or more ranges of address-
es on each subnet which it can in turn assign to client hosts as they
boot. Thus, a very simple configuration providing DHCP support might
look like this:
subnet 239.252.197.0 netmask 255.255.255.0
range 239.252.197.10 239.252.197.250;
Multiple address ranges may be specified like this:
subnet 239.252.197.0 netmask 255.255.255.0
range 239.252.197.10 239.252.197.107
range 239.252.197.113 239.252.197.250;
If a subnet will only be provided with BOOTP service and no dynamic ad-
dress assignment, the range clause can be left out entirely, but the sub-
net statement must appear.
LLeeaassee LLeennggtthhss
DHCP leases can be assigned almost any length from zero seconds to infin-
ity. What lease length makes sense for any given subnet, or for any
given installation, will vary depending on the kinds of hosts being
served.
For example, in an office environment where systems are added from time
to time and removed from time to time, but move relatively infrequently,
it might make sense to allow lease times of a month of more. In a final
test environment on a manufacturing floor, it may make more sense to as-
sign a maximum lease length of 30 minutes - enough time to go through a
simple test procedure on a network appliance before packaging it up for
delivery.
It is possible to specify two lease lengths: the default length that will
be assigned if a client doesn't ask for any particular lease length, and
a maximum lease length. These are specified as clauses to the subnet
command:
subnet 239.252.197.0 netmask 255.255.255.0
range 239.252.197.10 239.252.197.107
default-lease-time 600
max-lease-time 7200;
This particular subnet declaration specifies a default lease time of 600
seconds (ten minutes), and a maximum lease time of 7200 seconds (two
hours). Other common values would be 86400 (one day), 604800 (one week)
and 2592000 (30 days).
Each subnet need not have the same lease--in the case of an office envi-
ronment and a manufacturing environment served by the same DHCP server,
it might make sense to have widely disparate values for default and maxi-
mum lease times on each subnet.
BBOOOOTTPP SSuuppppoorrtt
Each BOOTP client must be explicitly declared in the ddhhccppdd..ccoonnff file. A
very basic client declaration will specify the client network interface's
hardware address and the IP address to assign to that client. If the
client needs to be able to load a boot file from the server, that file's
name must be specified. A simple bootp client declaration might look
like this:
host haagen hardware ethernet 08:00:2b:4c:59:23
fixed-address 239.252.197.9
filename "/tftpboot/haagen.boot";
OOppttiioonnss
DHCP (and also BOOTP with Vendor Extensions) provide a mechanism whereby
the server can provide the client with information about how to configure
its network interface (e.g., subnet mask), and also how the client can
access various network services (e.g., DNS, IP routers, and so on).
These options can be specified on a per-subnet basis, and, for BOOTP
clients, also on a per-client basis. In the event that a BOOTP client
declaration specifies options that are also specified in its subnet dec-
laration, the options specified in the client declaration take prece-
dence. An reasonably complete DHCP configuration might look something
like this:
subnet 239.252.197.0 netmask 255.255.255.0
range 239.252.197.10 239.252.197.250
default-lease-time 600 max-lease-time 7200
option subnet-mask 255.255.255.0
option broadcast-address 239.252.197.255
option routers 239.252.197.1
option domain-name-servers 239.252.197.2, 239.252.197.3
option domain-name "isc.org";
A bootp host on that subnet that needs to be in a different domain and
use a different name server might be declared as follows:
host haagen hardware ethernet 08:00:2b:4c:59:23
fixed-address 239.252.197.9
filename "/tftpboot/haagen.boot"
option domain-name-servers 192.5.5.1
option domain-name "vix.com";
A complete list of DHCP Options and their syntaxes is provided in
dhcpd.conf(5).
FFIILLEESS
//eettcc//ddhhccppdd..ccoonnff, //eettcc//ddhhccppdd..lleeaasseess, //vvaarr//rruunn//ddhhccppdd..ppiidd,
//eettcc//ddhhccppdd..lleeaasseess~~.
SSEEEE AALLSSOO
dhcpd.conf(5), dhcpd.leases(5)
AAUUTTHHOORR
dhcpd(8) was written by Ted Lemon <<mmeelllloonn@@vviixx..ccoomm>> under a contract with
Vixie Labs. Funding for this project was provided by the Internet Soft-
ware Corporation. Information about the Internet Software Consortium can
be found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.
March 6, 1996 3

437
server/dhcpd.conf.cat5 Normal file
View File

@@ -0,0 +1,437 @@
dhcpd.conf(5) NetBSD Programmer's Manual dhcpd.conf(5)
NNAAMMEE
ddhhccppdd..ccoonnff - dhcpd configuration file
DDEESSCCRRIIPPTTIIOONN
The dhcpd.conf(5) file contains configuration information for dhcpd(8),
the Dynamic Host Configuration Protocol daemon. A primer on configuring
ddhhccppdd is included in dhcpd(8). This document describes the format of the
file in detail, and is probably a better reference than a primer.
The ddhhccppdd..ccoonnff file is a free-form ASCII text file. It is parsed by a
recursive-descent parser. Statements in the file may contain extra tabs
and newlines for formatting purposes. Each statement in the file is
terminated by a semicolon. Keywords in the file are case-insensitive.
There are currently two statements that can meaningfully appear in the
file--the ssuubbnneett statement, and the hhoosstt statement.
TThhee SSUUBBNNEETT ssttaatteemmeenntt
ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k [_c_l_a_u_s_e_s];
_s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or DNS name which resolves to the
subnet number of the subnet being described. _n_e_t_m_a_s_k should be an IP ad-
dress or DNS name which resolves to the subnet mask of the subnet being
described. These are the only required fields in a subnet declaration,
although it may be desirable to add one or more of the following clauses.
Subnets for which addresses will be dynamically allocated must have one
or more addresses reserved for future allocation by ddhhccppdd. These address-
es are allocated using the rraannggee clause.
rraannggee _l_o_w_e_s_t_-_a_d_d_r_e_s_s _h_i_g_h_e_s_t_-_a_d_d_r_e_s_s
_L_o_w_e_s_t_-_a_d_d_r_e_s_s should be the lowest address in the range that may be as-
signed by ddhhccppdd to a DHCP client. _H_i_g_h_e_s_t_-_a_d_d_r_e_s_s should be the highest
address in the range that may be assigned by ddhhccppdd. If there is only one
address in a range, it must be specified as both the lowest and highest
addresses. As many rraannggee clauses as are needed may be specified in any
given ssuubbnneett statement.
ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e
_T_i_m_e should be the expiration time in seconds that will be assigned to a
lease if the client requesting the lease does not ask for a specific ex-
piration time. This clause may only appear once in each ssuubbnneett state-
ment.
mmaaxx--lleeaassee--ttiimmee _t_i_m_e
_T_i_m_e should be the maximum expiration time in seconds that will be as-
signed to a lease if the client requesting the lease asks for a specific
expiration time. This clause may only appear once in each ssuubbnneett state-
ment.
ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n
Any number of ddhhccppdd..ccoonnff option clauses may appear in a subnet statement.
The syntax of option declarations is described later in this document.
TThhee HHOOSSTT ssttaatteemmeenntt
hhoosstt _h_o_s_t_n_a_m_e [_c_l_a_u_s_e_s];
There must be at least one hhoosstt statement for every BOOTP client that is
to be served. _h_o_s_t_n_a_m_e should be a name identifying the host. It is
for labelling purposes only, and is not used in the BOOTP protocol.
hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s
In order for a BOOTP client to be recognized, its network hardware ad-
dress must be declared using a hhaarrddwwaarree clause in the hhoosstt statement.
Only one such clause can appear in any host statement. _h_a_r_d_w_a_r_e_-_t_y_p_e
must be the name of a physical hardware interface type. Currently, only
the eetthheerrnneett type is recognized, although support for ttookkeenn--rriinngg and ffddddii
hardware types will be added soon. The _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s should be a set
of hexadecimal octets (numbers from 0 through ff) seperated by colons.
ffiilleennaammee _f_i_l_e_n_a_m_e
If the BOOTP client needs to load a boot file (for example, a kernel or
configuration file), the name of this file may be provided to the client
using the ffiilleennaammee clause. The _f_i_l_e_n_a_m_e should be a filename recogniz-
able to whatever file transfer protocol the client can be expected to use
to load the file.
ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s
BOOTP clients must be assigned fixed IP addresses. The ffiixxeedd--aaddddrreessss
clause is used to associate a fixed IP address with a BOOTP client.
_A_d_d_r_e_s_s should be either an IP address or a DNS name which resolves to a
single IP address.
ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n
Any number of ddhhccppdd..ccoonnff option clauses may appear in a host statement.
The syntax of option declarations is described later in this document.
If an option clause in a hhoosstt statement conflicts with an option clause
in the ssuubbnneett statement for the subnet containing that host, the option
clause in the hhoosstt statement is used.
OOppttiioonn DDeeccllaarraattiioonnss
Option declarations always start with the ooppttiioonn keyword, followed by an
option name, followed by option data. The option names and data formats
are described below. Many of the options described below which set IP
or TCP parameters have default values which will generally work perfectly
well, so only those options whose values must be set explicitly should be
included in ssuubbnneett or hhoosstt statements.
Option data comes in a variety of formats. In order to avoid having to
explain the formats along with each option definition below, a number of
data types have been defined.
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 sin-
gle 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 en-
closed in double quotes - for example, to specify a domain-name option,
the syntax would be
option domain-name "isc.org"
The flag data type specifies a one-bit (boolean) number.
The documentation for the various options mentioned below is taken from
the latest IETF draft document on DHCP options.
ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s
The subnet mask option specifies the client's subnet mask as per RFC 950.
ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2
The time-offset option specifies the offset of the client's subnet in
seconds from Coordinated Universal Time (UTC).
ooppttiioonn rroouutteerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The routers option specifies a list of IP addresses for routers on the
client's subnet. Routers should be listed in order of preference.
ooppttiioonn ttiimmee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The time-server option specifies a list of RFC 868 time servers available
to the client. Servers should be listed in order of preference.
ooppttiioonn nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The name-servers option specifies a list of IEN 116 name servers avail-
able to the client. Servers should be listed in order of preference.
ooppttiioonn ddoommaaiinn--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The domain-name-servers option specifies a list of Domain Name System
(STD 13, RFC 1035) name servers available to the client. Servers should
be listed in order of preference.
ooppttiioonn lloogg--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The log-server option specifies a list of MIT-LCS UDP log servers avail-
able to the client. Servers should be listed in order of preference.
ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The cookie server option specifies a list of RFC 865 cookie servers
available to the client. Servers should be listed in order of prefer-
ence.
ooppttiioonn llpprr--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The LPR server option specifies a list of RFC 1179 line printer servers
available to the client. Servers should be listed in order of prefer-
ence.
ooppttiioonn iimmpprreessss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The impress-server option specifies a list of Imagen Impress servers
available to the client. Servers should be listed in order of prefer-
ence.
ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies a list of RFC 887 Resource Location servers avail-
able to the client. Servers should be listed in order of preference.
ooppttiioonn hhoosstt--nnaammee _s_t_r_i_n_g
This option specifies the name of the client. The name may or may not be
qualified with the local domain name (it is preferable to use the domain-
name option to specify the domain name). See RFC 1035 for character set
restrictions.
ooppttiioonn bboooott--ssiizzee _u_i_n_t_1_6
This option specifies the length in 512-octet blocks of the default boot
image for the client.
ooppttiioonn mmeerriitt--dduummpp _s_t_r_i_n_g
This option specifies the path-name of a file to which the client's core
image should be dumped in the event the client crashes. The path is for-
matted as a character string consisting of characters from the NVT ASCII
character set.
ooppttiioonn ddoommaaiinn--nnaammee _s_t_r_i_n_g
This option specifies the domain name that client should use when resolv-
ing hostnames via the Domain Name System.
ooppttiioonn sswwaapp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s
This specifies the IP address of the client's swap server.
ooppttiioonn rroooott--ppaatthh _s_t_r_i_n_g
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 character set.
ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g
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.
ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g
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 discussion of this topic). A value of 0 means disal-
low forwarding of such datagrams, and a value of 1 means allow forward-
ing.
ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies policy filters for non-local source routing. The
filters consist of a list of IP addresses and masks which specify desti-
nation/mask pairs with which to filter incoming source routes.
Any source routed datagram whose next-hop address does not match one of
the filters should be discarded by the client.
See STD 3 (RFC1122) for further information.
ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6
This option specifies the maximum size datagram that the client should be
prepared to reassemble. The minimum value legal value is 576.
ooppttiioonn ddeeffaauulltt--iipp--ttttll _u_i_n_t_8
This option specifies the default time-to-live that the client should use
on outgoing datagrams.
ooppttiioonn ppaatthh--mmttuu--aaggiinngg--ttiimmeeoouutt _u_i_n_t_3_2
This option specifies the timeout (in seconds) to use when aging Path MTU
values discovered by the mechanism defined in RFC 1191.
ooppttiioonn ppaatthh--mmttuu--ppllaatteeaauu--ttaabbllee _u_i_n_t_1_6 [ , _u_i_n_t_1_6 _._._.]
This option specifies a table of MTU sizes to use when performing Path
MTU Discovery as defined in RFC 1191. The table is formatted as a list
of 16-bit unsigned integers, ordered from smallest to largest. The mini-
mum MTU value cannot be smaller than 68.
ooppttiioonn iinntteerrffaaccee--mmttuu _u_i_n_t_1_6
This option specifies the MTU to use on this interface. The minimum le-
gal value for the MTU is 68.
ooppttiioonn aallll--ssuubbnneettss--llooccaall _f_l_a_g This option specifies whether or not the
client may assume that all subnets of the IP network to which the client
is connected use the same MTU as the subnet of that network to which the
client is directly connected. A value of 1 indicates that all subnets
share the same MTU. A value of 0 means that the client should assume
that some subnets of the directly connected network may have smaller
MTUs.
ooppttiioonn bbrrooaaddccaasstt--aaddddrreessss _i_p_-_a_d_d_r_e_s_s
This option specifies the broadcast address in use on the client's sub-
net. Legal values for broadcast addresses are specified in section
3.2.1.3 of STD 3 (RFC1122).
ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g
This option specifies whether or not the client should perform subnet
mask discovery using ICMP. A value of 0 indicates that the client should
not perform mask discovery. A value of 1 means that the client should
perform mask discovery.
ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g
This option specifies whether or not the client should respond to subnet
mask requests using ICMP. A value of 0 indicates that the client should
not respond. A value of 1 means that the client should respond.
ooppttiioonn rroouutteerr--ddiissccoovveerryy _f_l_a_g
This option specifies whether or not the client should solicit routers
using the Router Discovery mechanism defined in RFC 1256. A value of 0
indicates that the client should not perform router discovery. A value
of 1 means that the client should perform router discovery.
ooppttiioonn rroouutteerr--ssoolliicciittaattiioonn--aaddddrreessss _i_p_-_a_d_d_r_e_s_s
This option specifies the address to which the client should transmit
router solicitation requests.
ooppttiioonn ssttaattiicc--rroouutteess _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies a list of static routes that the client should in-
stall 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 rroouutteerrss option.
ooppttiioonn ttrraaiilleerr--eennccaappssuullaattiioonn _f_l_a_g
This option specifies whether or not the client should negotiate the use
of trailers (RFC 893 [14]) when using the ARP protocol. A value of 0 in-
dicates that the client should not attempt to use trailers. A value of 1
means that the client should attempt to use trailers.
ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2
This option specifies the timeout in seconds for ARP cache entries.
ooppttiioonn iieeeeee880022..33--eennccaappssuullaattiioonn _f_l_a_g
This option specifies whether or not the client should use Ethernet Ver-
sion 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 encapsulation. A value of 1 means that the client should use RFC
1042 encapsulation.
ooppttiioonn ddeeffaauulltt--ttccpp--ttttll _u_i_n_t_8
This option specifies the default TTL that the client should use when
sending TCP segments. The minimum value is 1.
ooppttiioonn ttccpp--kkeeeeppaalliivvee--iinntteerrvvaall _u_i_n_t_3_2
This option specifies the interval (in seconds) that the client TCP
should wait before sending a keepalive message on a TCP connection. The
time is specified as a 32-bit unsigned integer. A value of zero indi-
cates that the client should not generate keepalive messages on connec-
tions unless specifically requested by an application.
ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g
This option specifies the whether or not the client should send TCP
keepalive messages with a octet of garbage for compatibility with older
implementations. A value of 0 indicates that a garbage octet should not
be sent. A value of 1 indicates that a garbage octet should be sent.
ooppttiioonn nniiss--ddoommaaiinn _s_t_r_i_n_g
This option specifies the name of the client's NIS (Sun Network Informa-
tion Services) domain. The domain is formatted as a character string
consisting of characters from the NVT ASCII character set.
ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies a list of IP addresses indicating NIS servers
available to the client. Servers should be listed in order of prefer-
ence.
ooppttiioonn nnttpp--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies a list of IP addresses indicating NTP (RFC 1035)
servers available to the client. Servers should be listed in order of
preference.
ooppttiioonn nneettbbiiooss--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The NetBIOS name server (NBNS) option specifies a list of RFC 1001/1002
NBNS name servers listed in order of preference.
ooppttiioonn nneettbbiiooss--dddd--sseerrvveerr _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
The NetBIOS datagram distribution server (NBDD) option specifies a list
of RFC 1001/1002 NBDD servers listed in order of preference.
ooppttiioonn nneettbbiiooss--nnooddee--ttyyppee _u_i_n_t_8
The NetBIOS node type option allows NetBIOS over TCP/IP clients which are
configurable to be configured as described in RFC 1001/1002. The value
is specified as a single octet which identifies the client type. A value
of 1 corresponds to a NetBIOS B-node; a value of 2 corresponds to a P-
node; a value of 4 corresponds to an M-node; a value of 8 corresponds to
an H-node.
ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g
The NetBIOS scope option specifies the NetBIOS over TCP/IP scope parame-
ter for the client as specified in RFC 1001/1002. See RFC1001, RFC1002,
and RFC1035 for character-set restrictions.
ooppttiioonn ffoonntt--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies a list of X Window System Font servers available to
the client. Servers should be listed in order of preference.
ooppttiioonn xx--ddiissppllaayy--mmaannaaggeerr _i_p_-_a_d_d_r_e_s_s [ , _i_p_-_a_d_d_r_e_s_s _._._.]
This option specifies a list of systems that are running the X Window
System Display Manager and are available to the client. Addresses should
be listed in order of preference.
SSEEEE AALLSSOO
dhcpd.conf(5), dhcpd.leases(5)
AAUUTTHHOORR
dhcpd(8) was written by Ted Lemon <<mmeelllloonn@@vviixx..ccoomm>> under a contract with
Vixie Labs. Funding for this project was provided by the Internet Soft-
ware Corporation. Information about the Internet Software Consortium can
be found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.
March 6, 1996 7