Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Not needed in NetBSD

Browse Source
This commit is contained in:
mellon 1999-02-19 22:01:10 +00:00
parent 4c4fb0b6fd
commit db803634cc
6 changed files with 0 additions and 2442 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

594
usr.sbin/dhcp/client/dhclient.conf.cat5
View File

@ -1,594 +0,0 @@
dhclient.conf(5) dhclient.conf(5)
NNAAMMEE
dhclient.conf - DHCP client configuration file
DDEESSCCRRIIPPTTIIOONN
The dhclient.conf file contains configuration information
for _d_h_c_l_i_e_n_t_, the Internet Software Consortium DHCP
Client.
The dhclient.conf file is a free-form ASCII text file.
It is parsed by the recursive-descent parser built into
dhclient. The file may contain extra tabs and newlines
for formatting purposes. Keywords in the file are case-
insensitive. Comments may be placed anywhere within the
file (except within quotes). Comments begin with the #
character and end at the end of the line.
The dhclient.conf file can be used to configure the
behaviour of the client in a wide variety of ways: proto­
col timing, information requested from the server, infor­
mation required of the server, defaults to use if the
server does not provide certain information, values with
which to override information provided by the server, or
values to prepend or append to information provided by the
server. The configuration file can also be preinitialized
with addresses to use on networks that don't have DHCP
servers.
PPRROOTTOOCCOOLL TTIIMMIINNGG
The timing behaviour of the client need not be configured
by the user. If no timing configuration is provided by
the user, a fairly reasonable timing behaviour will be
used by default - one which results in fairly timely
updates without placing an inordinate load on the server.
The following statements can be used to adjust the timing
behaviour of the DHCP client if required, however:
_T_h_e ttiimmeeoouutt _s_t_a_t_e_m_e_n_t
ttiimmeeoouutt _t_i_m_e ;;
The _t_i_m_e_o_u_t statement determines the amount of time that
must pass between the time that the client begins to try
to determine its address and the time that it decides that
it's not going to be able to contact a server. By
default, this timeout is sixty seconds. After the time­
out has passed, if there are any static leases defined in
the configuration file, or any leases remaining in the
lease database that have not yet expired, the client will
loop through these leases attempting to validate them, and
if it finds one that appears to be valid, it will use that
lease's address. If there are no valid static leases or
unexpired leases in the lease database, the client will
restart the protocol after the defined retry interval.
1
dhclient.conf(5) dhclient.conf(5)
_T_h_e rreettrryy _s_t_a_t_e_m_e_n_t
rreettrryy _t_i_m_e;;
The _r_e_t_r_y statement determines the time that must pass
after the client has determined that there is no DHCP
server present before it tries again to contact a DHCP
server. By default, this is five minutes.
_T_h_e sseelleecctt--ttiimmeeoouutt _s_t_a_t_e_m_e_n_t
sseelleecctt--ttiimmeeoouutt _t_i_m_e;;
It is possible (some might say desirable) for there to be
more than one DHCP server serving any given network. In
this case, it is possible that a client may be sent more
than one offer in response to its initial lease discovery
message. It may be that one of these offers is prefer­
able to the other (e.g., one offer may have the address
the client previously used, and the other may not).
The _s_e_l_e_c_t_-_t_i_m_e_o_u_t is the time after the client sends its
first lease discovery request at which it stops waiting
for offers from servers, assuming that it has received at
least one such offer. If no offers have been received by
the time the _s_e_l_e_c_t_-_t_i_m_e_o_u_t has expired, the client will
accept the first offer that arrives.
By default, the select-timeout is zero seconds - that is,
the client will take the first offer it sees.
_T_h_e rreebboooott _s_t_a_t_e_m_e_n_t
rreebboooott _t_i_m_e;;
When the client is restarted, it first tries to reacquire
the last address it had. This is called the INIT-REBOOT
state. If it is still attached to the same network it
was attached to when it last ran, this is the quickest way
to get started. The _r_e_b_o_o_t statement sets the time that
must elapse after the client first tries to reacquire its
old address before it gives up and tries to discover a new
address. By default, the reboot timeout is ten seconds.
_T_h_e bbaacckkooffff--ccuuttooffff _s_t_a_t_e_m_e_n_t
bbaacckkooffff--ccuuttooffff _t_i_m_e;;
The client uses an exponential backoff algorithm with some
randomness, so that if many clients try to configure them­
selves at the same time, they will not make their requests
in lockstep. The _b_a_c_k_o_f_f_-_c_u_t_o_f_f statement determines the
maximum amount of time that the client is allowed to back
off. It defaults to two minutes.
2
dhclient.conf(5) dhclient.conf(5)
_T_h_e iinniittiiaall--iinntteerrvvaall _s_t_a_t_e_m_e_n_t
iinniittiiaall--iinntteerrvvaall _t_i_m_e;;
The _i_n_i_t_i_a_l_-_i_n_t_e_r_v_a_l statement sets the amount of time
between the first attempt to reach a server and the second
attempt to reach a server. Each time a message is sent,
the interval between messages is incremented by twice the
current interval multiplied by a random number between
zero and one. If it is greater than the backoff-cutoff
amount, it is set to that amount. It defaults to ten sec­
onds.
LLEEAASSEE RREEQQUUIIRREEMMEENNTTSS AANNDD RREEQQUUEESSTTSS
The DHCP protocol allows the client to request that the
server send it specific information, and not send it other
information that it is not prepared to accept. The pro­
tocol also allows the client to reject offers from servers
if they don't contain information the client needs, or if
the information provided is not satisfactory.
There is a variety of data contained in offers that DHCP
servers send to DHCP clients. The data that can be
specifically requested is what are called _D_H_C_P _O_p_t_i_o_n_s.
DHCP Options are defined in
ddhhccpp--ooppttiioonnss((55)).
_T_h_e rreeqquueesstt _s_t_a_t_e_m_e_n_t
rreeqquueesstt [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n ];;
The request statement causes the client to request that
any server responding to the client send the client its
values for the specified options. Only the option names
should be specified in the request statement - not option
parameters.
_T_h_e rreeqquuiirree _s_t_a_t_e_m_e_n_t
rreeqquuiirree [[ _o_p_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _];;
The require statement lists options that must be sent in
order for an offer to be accepted. Offers that do not
contain all the listed options will be ignored.
_T_h_e sseenndd _s_t_a_t_e_m_e_n_t
sseenndd {{ [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n
]}}
The send statement causes the client to send the specified
options to the server with the specified values. These
are full option declarations as described in ddhhccpp--
ooppttiioonnss((55)). Options that are always sent in the DHCP
3
dhclient.conf(5) dhclient.conf(5)
protocol should not be specified here, except that the
client can specify a rreeqquueesstteedd--lleeaassee--ttiimmee option other
than the default requested lease time, which is two hours.
The other obvious use for this statement is to send infor­
mation to the server that will allow it to differentiate
between this client and other clients or kinds of clients.
OOPPTTIIOONN MMOODDIIFFIIEERRSS
In some cases, a client may receive option data from the
server which is not really appropriate for that client, or
may not receive information that it needs, and for which a
useful default value exists. It may also receive infor­
mation which is useful, but which needs to be supplemented
with local information. To handle these needs, several
option modifiers are available.
_T_h_e ddeeffaauulltt _s_t_a_t_e_m_e_n_t
ddeeffaauulltt {{ [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _d_e_c_l_a_r_a_­
_t_i_o_n ]}}
If for some set of options the client should use the value
supplied by the server, but needs to use some default
value if no value was supplied by the server, these values
can be defined in the ddeeffaauulltt statement.
_T_h_e ssuuppeerrsseeddee _s_t_a_t_e_m_e_n_t
ssuuppeerrsseeddee {{ [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _d_e_c_l_a_r_a_­
_t_i_o_n ]}}
If for some set of options the client should always use
its own value rather than any value supplied by the
server, these values can be defined in the ssuuppeerrsseeddee
statement.
_T_h_e pprreeppeenndd _s_t_a_t_e_m_e_n_t
pprreeppeenndd {{ [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _d_e_c_l_a_r_a_­
_t_i_o_n ]}}
If for some set of options the client should first a value
it supplies, and then use the values supplied by the
server, if any, these values can be defined in the pprreeppeenndd
statement. The pprreeppeenndd statement can only be used for
options which allow more than one value to be given.
_T_h_e aappppeenndd _s_t_a_t_e_m_e_n_t
aappppeenndd {{ [[ _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n ] [,, _._._. _o_p_t_i_o_n _d_e_c_l_a_r_a_t_i_o_n
]}}
If for some set of options the client should first a value
it supplies, and then use the values supplied by the
4
dhclient.conf(5) dhclient.conf(5)
server, if any, these values can be defined in the aappppeenndd
statement. The aappppeenndd statement can only be used for
options which allow more than one value to be given.
LLEEAASSEE DDEECCLLAARRAATTIIOONNSS
_T_h_e lleeaassee _d_e_c_l_a_r_a_t_i_o_n
lleeaassee {{ _l_e_a_s_e_-_d_e_c_l_a_r_a_t_i_o_n [ ... _l_e_a_s_e_-_d_e_c_l_a_r_a_t_i_o_n _] }}
The DHCP client may decide after some period of time (see
PPRROOTTOOCCOOLL TTIIMMIINNGG) decide that it is not going to succeed in
contacting a server. At that time, it consults its own
database of old leases and tests each one that has not yet
timed out by pinging the listed router for that lease to
see if that lease could work. It is possible to define
one or more _f_i_x_e_d leases in the client configuration file
for networks where there is no DHCP or BOOTP service, so
that the client can still automatically configure its
address. This is done with the lleeaassee statement.
NOTE: the lease statement is also used in the
dhclient.leases file in order to record leases that have
been received from DHCP servers. Some of the syntax for
leases as described below is only needed in the
dhclient.leases file. Such syntax is documented here for
completeness.
A lease statement consists of the lease keyword, followed
by a left curly brace, followed by one or more lease dec­
laration statements, followed by a right curly brace.
The following lease declarations are possible:
bboooottpp;;
The bboooottpp statement is used to indicate that the lease was
acquired using the BOOTP protocol rather than the DHCP
protocol. It is never necessary to specify this in the
client configuration file. The client uses this syntax
in its lease database file.
iinntteerrffaaccee ""_s_t_r_i_n_g"";;
The iinntteerrffaaccee lease statement is used to indicate the
interface on which the lease is valid. If set, this
lease will only be tried on a particular interface. When
the client receives a lease from a server, it always
records the interface number on which it received that
lease. If predefined leases are specified in the
dhclient.conf file, the interface should also be speci­
fied, although this is not required.
ffiixxeedd--aaddddrreessss _i_p_-_a_d_d_r_e_s_s;;
The ffiixxeedd--aaddddrreessss statement is used to set the ip address
5
dhclient.conf(5) dhclient.conf(5)
of a particular lease. This is required for all lease
statements. The IP address must be specified as a dotted
quad (e.g., 12.34.56.78).
ffiilleennaammee ""_s_t_r_i_n_g"";;
The ffiilleennaammee statement specifies the name of the boot
filename to use. This is not used by the standard client
configuration script, but is included for completeness.
sseerrvveerr--nnaammee ""_s_t_r_i_n_g"";;
The sseerrvveerr--nnaammee statement specifies the name of the boot
server name to use. This is also not used by the stan­
dard client configuration script.
ooppttiioonn _o_p_t_i_o_n_-_d_e_c_l_a_r_a_t_i_o_n;;
The ooppttiioonn statement is used to specify the value of an
option supplied by the server, or, in the case of prede­
fined leases declared in dhclient.conf, the value that the
user wishes the client configuration script to use if the
predefined lease is used.
ssccrriipptt ""_s_c_r_i_p_t_-_n_a_m_e"";;
The ssccrriipptt statement is used to specify the pathname of
the dhcp client configuration script. This script is used
by the dhcp client to set each interface's initial config­
uration prior to requesting an address, to test the
address once it has been offered, and to set the inter­
face's final configuration once a lease has been acquired.
If no lease is acquired, the script is used to test prede­
fined leases, if any, and also called once if no valid
lease can be identified. For more information, see
ddhhcclliieenntt--lleeaassee((88))..
mmeeddiiuumm ""_m_e_d_i_a _s_e_t_u_p"";;
The mmeeddiiuumm statement can be used on systems where network
interfaces cannot automatically determine the type of net­
work to which they are connected. The media setup string
is a system-dependent parameter which is passed to the
dhcp client configuration script when initializing the
interface. On Unix and Unix-like systems, the argument is
passed on the ifconfig command line when configuring te
interface.
The dhcp client automatically declares this parameter if
it used a media type (see the mmeeddiiaa statement) when con­
figuring the interface in order to obtain a lease. This
statement should be used in predefined leases only if the
network interface requires media type configuration.
6
dhclient.conf(5) dhclient.conf(5)
rreenneeww _d_a_t_e;;
rreebbiinndd _d_a_t_e;;
eexxppiirree _d_a_t_e;;
The rreenneeww statement defines the time at which the dhcp
client should begin trying to contact its server to renew
a lease that it is using. The rreebbiinndd statement defines
the time at which the dhcp client should begin to try to
contact _a_n_y dhcp server in order to renew its lease. The
eexxppiirree statement defines the time at which the dhcp client
must stop using a lease if it has not been able to contact
a server in order to renew it.
These declarations are automatically set in leases
acquired by the DHCP client, but must also be configured
in predefined leases - a predefined lease whose expiry
time has passed will not be used by the DHCP client.
Dates are specified as follows:
_<_w_e_e_k_d_a_y_> _<_y_e_a_r_>//_<_m_o_n_t_h_>//_<_d_a_y_> _<_h_o_u_r_>::_<_m_i_n_u_t_e_>::_<_s_e_c_o_n_d_>
The weekday is present to make it easy for a human to tell
when a lease expires - it's specified as a number from
zero to six, with zero being Sunday. When declaring a
predefined lease, it can always be specified as zero. The
year is specified with the century, so it should generally
be four digits except for really long leases. The month
is specified as a number starting with 1 for January. The
day of the month is likewise specified starting with 1.
The hour is a number between 0 and 23, the minute a number
between 0 and 69, and the second also a number between 0
and 69.
AALLIIAASS DDEECCLLAARRAATTIIOONNSS
aalliiaass {{ _d_e_c_l_a_r_a_t_i_o_n_s _._._. }}
Some DHCP clients running TCP/IP roaming protocols may
require that in addition to the lease they may acquire via
DHCP, their interface also be configured with a predefined
IP alias so that they can have a permanent IP address even
while roaming. The Internet Software Consortium DHCP
client doesn't support roaming with fixed addresses
directly, but in order to facilitate such experimentation,
the dhcp client can be set up to configure an IP alias
using the aalliiaass declaration.
The alias declaration resembles a lease declaration,
except that options other than the subnet-mask option are
ignored by the standard client configuration script, and
expiry times are ignored. A typical alias declaration
includes an interface declaration, a fixed-address
7
dhclient.conf(5) dhclient.conf(5)
declaration for the IP alias address, and a subnet-mask
option declaration. A medium statement should never be
included in an alias declaration.
OOTTHHEERR DDEECCLLAARRAATTIIOONNSS
rreejjeecctt _i_p_-_a_d_d_r_e_s_s;;
The reject statement causes the DHCP client to reject
offers from servers who use the specified address as a
server identifier. This can be used to avoid being con­
figured by rogue or misconfigured dhcp servers, although
it should be a last resort - better to track down the bad
DHCP server and fix it.
iinntteerrffaaccee ""_n_a_m_e"" {{ _d_e_c_l_a_r_a_t_i_o_n_s _._._. }}
A client with more than one network interface may require
different behaviour depending on which interface is being
configured. All timing parameters and declarations other
than lease and alias declarations can be enclosed in an
interface declaration, and those parameters will then be
used only for the interface that matches the specified
name. Interfaces for which there is no interface decla­
ration will use the parameters declared outside of any
interface declaration, or the default settings.
mmeeddiiaa ""_m_e_d_i_a _s_e_t_u_p"" _[ ,, ""_m_e_d_i_a _s_e_t_u_p"",, _._._. _];;
The mmeeddiiaa statement defines one or more media configura­
tion parameters which may be tried while attempting to
acquire an IP address. The dhcp client will cycle
through each media setup string on the list, configuring
the interface using that setup and attempting to boot, and
then trying the next one. This can be used for network
interfaces which aren't capable of sensing the media type
unaided - whichever media type succeeds in getting a
request to the server and hearing the reply is probably
right (no guarantees).
The media setup is only used for the initial phase of
address acquisition (the DHCPDISCOVER and DHCPOFFER pack­
tes). Once an address has been acquired, the dhcp client
will record it in its lease database and will record the
media type used to acquire the address. Whenever the
client tries to renew the lease, it will use that same
media type. The lease must expire before the client will
go back to cycling through media types.
SSAAMMPPLLEE
The following configuration file is used on a laptop run­
ning NetBSD 1.3. The laptop has an IP alias of
192.5.5.213, and has one interface, ep0 (a 3com 3C589C).
Booting intervals have been shortened somewhat from the
default, because the client is known to spend most of its
8
dhclient.conf(5) dhclient.conf(5)
time on networks with little DHCP activity. The laptop
does roam to multiple networks.
timeout 60;
retry 60;
reboot 10;
select-timeout 5;
initial-interval 2;
reject 192.33.137.209;
interface "ep0" {
send host-name "andare.fugue.com";
send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
send dhcp-lease-time 3600;
supersede domain-name "fugue.com rc.vix.com home.vix.com";
prepend domain-name-servers 127.0.0.1;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name;
require subnet-mask, domain-name-servers;
script "/etc/dhclient-script";
media "media 10baseT/UTP", "media 10base2/BNC";
}
alias {
interface "ep0";
fixed-address 192.5.5.213;
option subnet-mask 255.255.255.255;
}
This is a very complicated dhclient.conf file - in gen­
eral, yours should be much simpler. In many cases, it's
sufficient to just create an empty dhclient.conf file -
the defaults are usually fine.
SSEEEE AALLSSOO
dhcp-options(5), dhclient.leases(5), dhcpd(8),
dhcpd.conf(5), RFC2132, RFC2131.
AAUUTTHHOORR
ddhhcclliieenntt((88)) was written by Ted Lemon <mellon@vix.com>
under a contract with Vixie Labs. Funding for this pro­
ject was provided by the Internet Software Corporation.
Information about the Internet Software Consortium can be
found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
9

66
usr.sbin/dhcp/client/dhclient.leases.cat5
View File

@ -1,66 +0,0 @@
dhclient.leases(5) dhclient.leases(5)
NNAAMMEE
dhclient.leases - DHCP client lease database
DDEESSCCRRIIPPTTIIOONN
The Internet Software Consortium DHCP client keeps a per­
sistent database of leases that it has acquired that are
still valid. The database is a free-form ASCII file con­
taining one valid declaration per lease. If more than
one declaration appears for a given lease, the last one in
the file is used. The file is written as a log, so this
is not an unusual occurrance.
The format of the lease declarations is described in
ddhhcclliieenntt..ccoonnff((55))..
FFIILLEESS
//vvaarr//ddbb//ddhhcclliieenntt..lleeaasseess
SSEEEE AALLSSOO
dhclient(8), dhcp-options(5), dhclient.conf(5), dhcpd(8),
dhcpd.conf(5), RFC2132, RFC2131.
AAUUTTHHOORR
ddhhcclliieenntt((88)) was written by Ted Lemon <mellon@vix.com>
under a contract with Vixie Labs. Funding for this pro­
ject was provided by the Internet Software Corporation.
Information about the Internet Software Consortium can be
found at hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
1

594
usr.sbin/dhcp/common/dhcp-options.cat5
View File

@ -1,594 +0,0 @@
dhcpd-options(5) dhcpd-options(5)
NNAAMMEE
dhcp-options - Dynamic Host Configuration Protocol options
DDEESSCCRRIIPPTTIIOONN
The Dynamic Host Configuration protocol allows the client
to receive ooppttiioonnss from the DHCP server describing the
network configuration and various services that are avail­
able on the network. When configuring ddhhccppdd((88)) or
ddhhcclliieenntt((88)) ,, options must often be declared. The syntax
for declaring options, and the names and formats of the
options that can be declared, are documented here.
RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS
DHCP _o_p_t_i_o_n statements always start with the _o_p_t_i_o_n 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 iipp--aaddddrreessss 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 iinntt3322 data type specifies a signed 32-bit integer.
The uuiinntt3322 data type specifies an unsigned 32-bit integer.
The iinntt1166 and uuiinntt1166 data types specify signed and
unsigned 16-bit integers. The iinntt88 and uuiinntt88 data types
specify signed and unsigned 8-bit integers. Unsigned
8-bit integers are also sometimes referred to as octets.
The ssttrriinngg 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 ffllaagg 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 ddaattaa--ssttrriinngg data type specifies either an NVT ASCII
string enclosed in double quotes, or a series of octets
specified in hexadecimal, seperated by colons. For exam­
ple:
option client-identifier "CLIENT-FOO";
or
option client-identifier 43:4c:49:45:54:2d:46:4f:4f;
1
dhcpd-options(5) dhcpd-options(5)
The documentation for the various options mentioned below
is taken from the latest IETF draft document on DHCP
options. Options which are not listed by name may be
defined by the name option-_n_n_n, where _n_n_n _i_s _t_h_e _d_e_c_i_m_a_l
_n_u_m_b_e_r _o_f _t_h_e _o_p_t_i_o_n _c_o_d_e_. _T_h_e_s_e _o_p_t_i_o_n_s _m_a_y _b_e _f_o_l_l_o_w_e_d
_e_i_t_h_e_r _b_y _a _s_t_r_i_n_g_, _e_n_c_l_o_s_e_d _i_n _q_u_o_t_e_s_, _o_r _b_y _a _s_e_r_i_e_s _o_f
_o_c_t_e_t_s_, _e_x_p_r_e_s_s_e_d _a_s _t_w_o_-_d_i_g_i_t _h_e_x_a_d_e_c_i_m_a_l _n_u_m_b_e_r_s _s_e_p_e_r_­
_a_t_e_d _b_y _c_o_l_o_n_s_. _F_o_r _e_x_a_m_p_l_e_:
option option-133 "my-option-133-text";
option option-129 1:54:c9:2b:47;
Because dhcpd does not know the format of these undefined
option codes, no checking is done to ensure the correct­
ness of the entered data.
The standard options are:
ooppttiioonn ssuubbnneett--mmaasskk _i_p_-_a_d_d_r_e_s_s;;
The subnet mask option specifies the client's subnet
mask as per RFC 950. If no subnet mask option is pro­
vided anywhere in scope, as a last resort dhcpd will
use the subnet mask from the subnet declaration for the
network on which an address is being assigned. How­
ever, _a_n_y subnet-mask option declaration that is in
scope for the address being assigned will override the
subnet mask specified in the subnet declaration.
ooppttiioonn ttiimmee--ooffffsseett _i_n_t_3_2;;
The time-offset option specifies the offset of the
client's subnet in seconds from Coordinated Universal
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 iieenn111166--nnaammee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];
The ien116-name-servers option specifies a list of IEN
116 name servers available to the client. Servers
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... ];;
2
dhcpd-options(5) dhcpd-options(5)
The domain-name-servers option specifies a list of
Domain Name System (STD 13, RFC 1035) name servers
available to the client. Servers should be listed in
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 available to the client. Servers should be
listed in order of preference.
ooppttiioonn ccooookkiiee--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];;
The cookie server option specifies a list of RFC 865
cookie servers available to the client. Servers should
be listed in order of preference.
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 preference.
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 preference.
ooppttiioonn rreessoouurrccee--llooccaattiioonn--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-
_a_d_d_r_e_s_s... ];;
This option specifies a list of RFC 887 Resource Loca­
tion servers available to the client. Servers should
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 formatted as a
3
dhcpd-options(5) dhcpd-options(5)
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 resolving hostnames via the Domain Name
System.
ooppttiioonn sswwaapp--sseerrvveerr _i_p_-_a_d_d_r_e_s_s;;
This specifies the IP address of the client's swap
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 charac­
ter string consisting of characters from the NVT ASCII
character set.
ooppttiioonn iipp--ffoorrwwaarrddiinngg _f_l_a_g;;
This option specifies whether the client should config­
ure its IP layer for packet forwarding. A value of 0
means disable IP forwarding, and a value of 1 means
enable IP forwarding.
ooppttiioonn nnoonn--llooccaall--ssoouurrccee--rroouuttiinngg _f_l_a_g;;
This option specifies whether the client should config­
ure its IP layer to allow forwarding of datagrams with
non-local source routes (see Section 3.3.5 of [4] for a
discussion of this topic). A value of 0 means disallow
forwarding of such datagrams, and a value of 1 means
allow forwarding.
ooppttiioonn ppoolliiccyy--ffiilltteerr _i_p_-_a_d_d_r_e_s_s _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s
_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 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.
ooppttiioonn mmaaxx--ddggrraamm--rreeaasssseemmbbllyy _u_i_n_t_1_6;;
This option specifies the maximum size datagram that
4
dhcpd-options(5) dhcpd-options(5)
the client should be prepared to reassemble. The mini­
mum 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 legal 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 subnet. Legal values for broadcast
addresses are specified in section 3.2.1.3 of STD 3
(RFC1122).
ooppttiioonn ppeerrffoorrmm--mmaasskk--ddiissccoovveerryy _f_l_a_g;;
This option specifies whether or not the client should
perform subnet mask discovery using ICMP. A value of 0
indicates that the client should not perform mask dis­
covery. A value of 1 means that the client should per­
form mask discovery.
ooppttiioonn mmaasskk--ssuupppplliieerr _f_l_a_g;;
5
dhcpd-options(5) dhcpd-options(5)
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 discov­
ery.
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 install in its routing cache. If multi­
ple routes to the same destination are specified, they
are listed in descending order of priority.
The routes consist of a list of IP address pairs. The
first address is the destination address, and the sec­
ond address is the router for the destination.
The default route (0.0.0.0) is an illegal destination
for a static route. To specify the default route, use
the 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 indicates that the
client should not attempt to use trailers. A value of
1 means that the client should attempt to use trailers.
ooppttiioonn aarrpp--ccaacchhee--ttiimmeeoouutt _u_i_n_t_3_2;;
This option specifies the timeout in seconds for ARP
cache entries.
ooppttiioonn iieeeeee880022--33--eennccaappssuullaattiioonn _f_l_a_g;;
This option specifies whether or not the client should
use Ethernet Version 2 (RFC 894) or IEEE 802.3 (RFC
1042) encapsulation if the interface is an Ethernet. A
value of 0 indicates that the client should use RFC 894
6
dhcpd-options(5) dhcpd-options(5)
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 indicates
that the client should not generate keepalive messages
on connections unless specifically requested by an
application.
ooppttiioonn ttccpp--kkeeeeppaalliivvee--ggaarrbbaaggee _f_l_a_g;;
This option specifies the whether or not the client
should send TCP keepalive messages with a octet of
garbage for compatibility with older implementations.
A value of 0 indicates that a garbage octet should not
be sent. A value of 1 indicates that a garbage octet
should be sent.
ooppttiioonn nniiss--ddoommaaiinn _s_t_r_i_n_g;;
This option specifies the name of the client's NIS (Sun
Network Information Services) domain. The domain is
formatted as a character string consisting of charac­
ters from the NVT ASCII character set.
ooppttiioonn nniiss--sseerrvveerrss _i_p_-_a_d_d_r_e_s_s [,, _i_p_-_a_d_d_r_e_s_s... ];;
This option specifies a list of IP addresses indicating
NIS servers available to the client. Servers should be
listed in order of preference.
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. NetBIOS Name Service is currently more
commonly referred to as WINS. WINS servers can be
7
dhcpd-options(5) dhcpd-options(5)
specified using the netbios-name-servers option.
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.
Possible node types are:
_1 B-node: Broadcast - no WINS
_2 P-node: Peer - WINS only.
_4 M-node: Mixed - broadcast, then WINS
_8 H-node: Hybrid - WINS, then broadcast
ooppttiioonn nneettbbiiooss--ssccooppee _s_t_r_i_n_g;;
The NetBIOS scope option specifies the NetBIOS over
TCP/IP scope parameter for the client as specified in
RFC 1001/1002. See RFC1001, RFC1002, and RFC1035 for
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 run­
ning the X Window System Display Manager and are avail­
able to the client. Addresses should be listed in
order of preference.
ooppttiioonn ddhhccpp--cclliieenntt--iiddeennttiiffiieerr _d_a_t_a_-_s_t_r_i_n_g;;
This option can be used to specify the a DHCP client
identifier in a host declaration, so that dhcpd can
find the host record by matching against the client
identifier.
8
dhcpd-options(5) dhcpd-options(5)
SSEEEE AALLSSOO
dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5),
dhcpd(8), dhclient(8), RFC2132, RFC2131.
AAUUTTHHOORR
ddhhccppdd((88)) 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 hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
9

132
usr.sbin/dhcp/relay/dhcrelay.cat8
View File

@ -1,132 +0,0 @@
dhcrelay(8) dhcrelay(8)
NNAAMMEE
dhcrelay - Dynamic Host Configuration Protocol Relay Agent
SSYYNNOOPPSSIISS
ddhhccrreellaayy [ --pp _p_o_r_t ] [ --dd ] [ --qq ] [ --ii _i_f_0 [ ...... --ii _i_f_N
] ] _s_e_r_v_e_r_0 [ _._._._s_e_r_v_e_r_N ]
DDEESSCCRRIIPPTTIIOONN
The Internet Software Consortium DHCP Relay Agent, dhcre­
lay, provides a means for relaying DHCP and BOOTP requests
from a subnet to which no DHCP server is directly to one
or more DHCP servers on other subnets.
OOPPEERRAATTIIOONN
The DHCP Relay Agent listens for DHCP requests on all
interfaces attached to a host, unless one or more inter­
faces are specified on the command line with the _-_i flag.
When a query is received, dhcrelay forwards it to the list
of DHCP servers specified on the command line. When a
reply is received, it is broadcast or unicast on the net­
work from whence the original request came.
It is possible to specify a set of interfaces on which
dhcrelay will listen, so that if dhcrelay is connected
through one interface to a network on which there is no
DHCP server, but is connected on another interface to a
network on which there is a DHCP server, it will not relay
DHCP and BOOTP requests from the network on which the
server exists to that server. This is an imperfect solu­
tion.
CCOOMMMMAANNDD LLIINNEE
The names of the network interfaces that dhcrelay should
attempt to configure may be specified on the command line
using the _-_i option. If no interface names are specified
on the command line dhcrelay will identify all network
interfaces, elimininating non-broadcast interfaces if pos­
sible, and attempt to configure each interface.
If dhcrelay should listen and transmit on a port other
than the standard (port 67), the --pp flag may used. It
should be followed by the udp port number that dhcrelay
should use. This is mostly useful for debugging purposes.
Dhcrelay will normally run in the foreground until it has
configured an interface, and then will revert to running
in the background. To run force dhcrelay to always run as
a foreground process, the --dd flag should be specified.
This is useful when running dhcrelay under a debugger, or
when running it out of inittab on System V systems.
Dhcrelay will normally print its network configuration on
startup. This can be annoying in a system startup script
1
dhcrelay(8) dhcrelay(8)
- to disable this behaviour, specify the _-_q flag.
The name of at least one DHCP server to which DHCP and
BOOTP requests should be relayed must be specified on the
command line.
SSEEEE AALLSSOO
dhclient(8), dhcpd(8), RFC2132, RFC2131.
AAUUTTHHOORR
ddhhccrreellaayy((88)) has been written for the Internet Software
Consortium by Ted Lemon <mellon@fugue.com> in cooperation
with Vixie Enterprises. To learn more about the Internet
Software Consortium, see hhttttpp::////wwwwww..vviixx..ccoomm//iisscc.. To learn
more about Vixie Enterprises, see hhttttpp::////wwwwww..vviixx..ccoomm..
2

858
usr.sbin/dhcp/server/dhcpd.conf.cat5
View File

@ -1,858 +0,0 @@
dhcpd.conf(5) dhcpd.conf(5)
NNAAMMEE
dhcpd.conf - dhcpd configuration file
DDEESSCCRRIIPPTTIIOONN
The dhcpd.conf file contains configuration information for
_d_h_c_p_d_, the Internet Software Consortium DHCP Server.
The dhcpd.conf file is a free-form ASCII text file. It
is parsed by the recursive-descent parser built into
dhcpd. The file may contain extra tabs and newlines for
formatting purposes. Keywords in the file are case-insen­
sitive. Comments may be placed anywhere within the file
(except within quotes). Comments begin with the # char­
acter and end at the end of the line.
The file essentially consists of a list of statements.
Statements fall into two broad categories - parameters and
declarations.
Parameter statements either say how to do something (e.g.,
how long a lease to offer), whether to do something (e.g.,
should dhcpd provide addresses to unknown clients), or
what parameters to provide to the client (e.g., use gate­
way 220.177.244.7).
Declarations are used to describe the topology of the net­
work, to describe clients on the network, to provide
addresses that can be assigned to clients, or to apply a
group of parameters to a group of declarations. In any
group of parameters and declarations, all parameters must
be specified before any declarations which depend on those
parameters may be specified.
Declarations about network topology include the
_s_h_a_r_e_d_-_n_e_t_w_o_r_k and the _s_u_b_n_e_t declarations. If clients
on a subnet are to be assigned addresses dynamically, a
_r_a_n_g_e declaration must appear within the _s_u_b_n_e_t declara­
tion. For clients with statically assigned addresses, or
for installations where only known clients will be served,
each such client must have a _h_o_s_t declaration. If param­
eters are to be applied to a group of declarations which
are not related strictly on a per-subnet basis, the _g_r_o_u_p
declaration can be used.
For every subnet which will be served, and for every sub­
net to which the dhcp server is connected, there must be
one _s_u_b_n_e_t declaration, which tells dhcpd how to recognize
that an address is on that subnet. A _s_u_b_n_e_t declaration
is required for each subnet even if no addresses will be
dynamically allocated on that subnet.
Some installations have physical networks on which more
than one IP subnet operates. For example, if there is a
site-wide requirement that 8-bit subnet masks be used, but
1
dhcpd.conf(5) dhcpd.conf(5)
a department with a single physical ethernet network
expands to the point where it has more than 254 nodes, it
may be necessary to run two 8-bit subnets on the same eth­
ernet until such time as a new physical network can be
added. In this case, the _s_u_b_n_e_t declarations for these
two networks may be enclosed in a _s_h_a_r_e_d_-_n_e_t_w_o_r_k declara­
tion.
Some sites may have departments which have clients on more
than one subnet, but it may be desirable to offer those
clients a uniform set of parameters which are different
than what would be offered to clients from other depart­
ments on the same subnet. For clients which will be
declared explicitly with _h_o_s_t declarations, these declara­
tions can be enclosed in a _g_r_o_u_p declaration along with
the parameters which are common to that department. For
clients whose addresses will be dynamically assigned,
there is currently no way to group parameter assignments
other than by network topology.
When a client is to be booted, its boot parameters are
determined by first consulting that client's _h_o_s_t declara­
tion (if any), then consulting the _g_r_o_u_p declaration (if
any) which enclosed that _h_o_s_t declaration, then consulting
the _s_u_b_n_e_t declaration for the subnet on which the client
is booting, then consulting the _s_h_a_r_e_d_-_n_e_t_w_o_r_k declaration
(if any) containing that subnet, and finally consulting
the top-level parameters which may be specified outside of
any declaration.
When dhcpd tries to find a _h_o_s_t declaration for a client,
it first looks for a _h_o_s_t declaration which has a _f_i_x_e_d_-
_a_d_d_r_e_s_s parameter which matches the subnet or shared net­
work on which the client is booting. If it doesn't find
any such entry, it then tries to find an entry which has
no _f_i_x_e_d_-_a_d_d_r_e_s_s parameter. If no such entry is found,
then dhcpd acts as if there is no entry in the dhcpd.conf
file for that client, even if there is an entry for that
client on a different subnet or shared network.
EEXXAAMMPPLLEESS
A typical dhcpd.conf file will look something like this:
_g_l_o_b_a_l _p_a_r_a_m_e_t_e_r_s_._._.
shared-network ISC-BIGGIE {
_s_h_a_r_e_d_-_n_e_t_w_o_r_k_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
subnet 204.254.239.0 netmask 255.255.255.224 {
_s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
range 204.254.239.10 204.254.239.30;
}
subnet 204.254.239.32 netmask 255.255.255.224 {
_s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
range 204.254.239.42 204.254.239.62;
2
dhcpd.conf(5) dhcpd.conf(5)
}
}
subnet 204.254.239.64 netmask 255.255.255.224 {
_s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
range 204.254.239.74 204.254.239.94;
}
group {
_g_r_o_u_p_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
host zappo.test.isc.org {
_h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
}
host beppo.test.isc.org {
_h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
}
host harpo.test.isc.org {
_h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._.
}
}
Figure 1
Notice that at the beginning of the file, there's a place
for global parameters. These might be things like the
organization's domain name, the addresses of the name
servers (if they are common to the entire organization),
and so on. So, for example:
option domain-name "isc.org";
option domain-name-servers ns1.isc.org, ns2.isc.org;
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 _I_S_C_-_B_I_G_G_I_E 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".
3
dhcpd.conf(5) dhcpd.conf(5)
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 _g_r_o_u_p statement, which pro­
vides common parameters for a set of three hosts - zappo,
beppo and harpo. As you can see, these hosts are all in
the test.isc.org domain, so it might make sense for a
group-specific parameter to override the domain name sup­
plied to these hosts:
option domain-name "test.isc.org";
Also, given the domain they're in, these are probably test
machines. If we wanted to test the DHCP leasing mecha­
nism, we might set the lease timeout somewhat shorter than
the default:
max-lease-time 120;
default-lease-time 120;
You may have noticed that while some parameters start with
the _o_p_t_i_o_n keyword, some do not. Parameters starting
with the _o_p_t_i_o_n keyword correspond to actual DHCP options,
while parameters that do not start with the option keyword
either control the behaviour of the DHCP server (e.g., how
long a lease dhcpd will give out), or specify client
parameters that are not optional in the DHCP protocol (for
example, server-name and filename).
In Figure 1, each host had _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s.
These could include such things as the _h_o_s_t_n_a_m_e option,
the name of a file to upload (the _f_i_l_e_n_a_m_e _p_a_r_a_m_e_t_e_r_) _a_n_d
_t_h_e _a_d_d_r_e_s_s _o_f _t_h_e _s_e_r_v_e_r _f_r_o_m _w_h_i_c_h _t_o _u_p_l_o_a_d _t_h_e _f_i_l_e
_(_t_h_e _n_e_x_t_-_s_e_r_v_e_r parameter). In general, any parameter
can appear anywhere that parameters are allowed, and will
be applied according to the scope in which the parameter
appears.
Imagine that you have a site with a lot of NCD X-Termi­
nals. These terminals come in a variety of models, and
you want to specify the boot files for each models. One
way to do this would be to have host declarations for each
4
dhcpd.conf(5) dhcpd.conf(5)
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; }
}
RREEFFEERREENNCCEE:: DDEECCLLAARRAATTIIOONNSS
TThhee _s_h_a_r_e_d_-_n_e_t_w_o_r_k ssttaatteemmeenntt
sshhaarreedd--nneettwwoorrkk _n_a_m_e {{
[ _p_a_r_a_m_e_t_e_r_s ]
[ _d_e_c_l_a_r_a_t_i_o_n_s ]
}}
The _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement is used to inform the DHCP
server that some IP subnets actually share the same physi­
cal network. Any subnets in a shared network should be
declared within a _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement. Parameters
specified in the _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement will be used
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.
_N_a_m_e should be the name of the shared network. This name
is used when printing debugging messages, so it should be
descriptive for the shared network. The name may have
the syntax of a valid domain name (although it will never
be used as such), or it may be any arbitrary name,
5
dhcpd.conf(5) dhcpd.conf(5)
enclosed in quotes.
TThhee _s_u_b_n_e_t ssttaatteemmeenntt
ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k {{
[ _p_a_r_a_m_e_t_e_r_s ]
[ _d_e_c_l_a_r_a_t_i_o_n_s ]
}}
The _s_u_b_n_e_t statement is used to provide dhcpd with enough
information to tell whether or not an IP address is on
that subnet. It may also be used to provide subnet-spe­
cific parameters and to specify what addresses may be
dynamically allocated to clients booting on that subnet.
Such addresses are specified using the _r_a_n_g_e declaration.
The _s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or domain name
which resolves to the subnet number of the subnet being
described. The _n_e_t_m_a_s_k should be an IP address or domain
name which resolves to the subnet mask of the subnet being
described. The subnet number, together with the netmask,
are sufficient to determine whether any given IP address
is on the specified subnet.
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.
TThhee _r_a_n_g_e ssttaatteemmeenntt
rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w_-_a_d_d_r_e_s_s [ _h_i_g_h_-_a_d_d_r_e_s_s];;
For any subnet on which addresses will be assigned dynami­
cally, there must be at least one _r_a_n_g_e statement. The
range statement gives the lowest and highest IP addresses
in a range. All IP addresses in the range should be in
the subnet in which the _r_a_n_g_e statement is declared. The
_d_y_n_a_m_i_c_-_b_o_o_t_p flag may be specified if addresses in the
specified range may be dynamically assigned to BOOTP
clients as well as DHCP clients. When specifying a sin­
gle address, _h_i_g_h_-_a_d_d_r_e_s_s can be omitted.
TThhee _h_o_s_t ssttaatteemmeenntt
hhoosstt _h_o_s_t_n_a_m_e {
[ _p_a_r_a_m_e_t_e_r_s ]
[ _d_e_c_l_a_r_a_t_i_o_n_s ]
}}
There must be at least one hhoosstt statement for every BOOTP
client that is to be served. hhoosstt statements may also be
6
dhcpd.conf(5) dhcpd.conf(5)
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 _f_i_x_e_d_-_a_d_d_r_e_s_s
parameter, or more than one hhoosstt statement may be speci­
fied.
If client-specific boot parameters must change based on
the network to which the client is attached, then multiple
hhoosstt 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 hhoosstt statement must be specified without a
ffiixxeedd--aaddddrreessss clause. _h_o_s_t_n_a_m_e should be a name identify­
ing the host. If a _h_o_s_t_n_a_m_e option is not specified for
the host, _h_o_s_t_n_a_m_e is used.
_H_o_s_t declarations are matched to actual DHCP or BOOTP
clients by matching the dhcp-client-identifier option
specified in the _h_o_s_t declaration to the one supplied by
the client, or, if the _h_o_s_t declaration or the client does
not provide a dhcp-client-identifier option, by matching
the _h_a_r_d_w_a_r_e parameter in the _h_o_s_t declaration to the net­
work hardware address supplied by the client. BOOTP
clients do not normally provide a _d_h_c_p_-_c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r,
so the hardware address must be used for all clients that
may boot using the BOOTP protocol.
TThhee _g_r_o_u_p ssttaatteemmeenntt
ggrroouupp {
[ _p_a_r_a_m_e_t_e_r_s ]
[ _d_e_c_l_a_r_a_t_i_o_n_s ]
}}
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.
RREEFFEERREENNCCEE:: AALLLLOOWW aanndd DDEENNYY
The _a_l_l_o_w and _d_e_n_y statements can be used to control the
behaviour of dhcpd to various sorts of requests.
TThhee _u_n_k_n_o_w_n_-_c_l_i_e_n_t_s kkeeyywwoorrdd
aallllooww uunnkknnoowwnn--cclliieennttss;;
ddeennyy uunnkknnoowwnn--cclliieennttss;;
The uunnkknnoowwnn--cclliieennttss flag is used to tell dhcpd whether or
7
dhcpd.conf(5) dhcpd.conf(5)
not to dynamically assign addresses to unknown clients.
Dynamic address assignment to unknown clients is aalllloowwed
by default.
TThhee _b_o_o_t_p kkeeyywwoorrdd
aallllooww bboooottpp;;
ddeennyy bboooottpp;;
The bboooottpp flag is used to tell dhcpd whether or not to
respond to bootp queries. Bootp queries are aalllloowwed by
default.
TThhee _b_o_o_t_i_n_g kkeeyywwoorrdd
aallllooww bboooottiinngg;;
ddeennyy bboooottiinngg;;
The bboooottiinngg flag is used to tell dhcpd whether or not to
respond to queries from a particular client. This keyword
only has meaning when it appears in a host declaration.
By default, booting is aalllloowwed, but if it is disabled for
a particular client, then that client will not be able to
get and address from the DHCP server.
RREEFFEERREENNCCEE:: PPAARRAAMMEETTEERRSS
TThhee _d_e_f_a_u_l_t_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt
ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;;
_T_i_m_e should be the length in seconds that will be assigned
to a lease if the client requesting the lease does not ask
for a specific expiration time.
TThhee _m_a_x_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt
mmaaxx--lleeaassee--ttiimmee _t_i_m_e;;
_T_i_m_e should be the maximum length in seconds that will be
assigned to a lease if the client requesting the lease
asks for a specific expiration time.
TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt
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 address must be declared using a _h_a_r_d_w_a_r_e clause
in the _h_o_s_t statement. _h_a_r_d_w_a_r_e_-_t_y_p_e must be the name of
a physical hardware interface type. Currently, only the
eetthheerrnneett and ttookkeenn--rriinngg types are recognized, although
support for a ffddddii hardware type (and others) would also
be desirable. The _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s should be a set of
hexadecimal octets (numbers from 0 through ff) seperated
8
dhcpd.conf(5) dhcpd.conf(5)
by colons. The _h_a_r_d_w_a_r_e_f_R _s_t_a_t_e_m_e_n_t _m_a_y _a_l_s_o _b_e _u_s_e_d _f_o_r
_D_H_C_P _c_l_i_e_n_t_s_.
TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt
ffiilleennaammee ""_f_i_l_e_n_a_m_e"";;
The _f_i_l_e_n_a_m_e statement can be used to specify the name of
the initial boot file which is to be loaded by a client.
The _f_i_l_e_n_a_m_e should be a filename recognizable to whatever
file transfer protocol the client can be expected to use
to load the file.
TThhee _s_e_r_v_e_r_-_n_a_m_e ssttaatteemmeenntt
sseerrvveerr--nnaammee ""_n_a_m_e"";;
The _s_e_r_v_e_r_-_n_a_m_e statement can be used to inform the client
of the name of the server from which it is booting. _N_a_m_e
should be the name that will be provided to the client.
TThhee _n_e_x_t_-_s_e_r_v_e_r ssttaatteemmeenntt
nneexxtt--sseerrvveerr _s_e_r_v_e_r_-_n_a_m_e;;
The _n_e_x_t_-_s_e_r_v_e_r statement is used to specify the host
address of the server from which the initial boot file
(specified in the _f_i_l_e_n_a_m_e statement) is to be loaded.
_S_e_r_v_e_r_-_n_a_m_e should be a numeric IP address or a domain
name. If no _n_e_x_t_-_s_e_r_v_e_r parameter applies to a given
client, the DHCP server's IP address is used.
TThhee _f_i_x_e_d_-_a_d_d_r_e_s_s ssttaatteemmeenntt
ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];;
The _f_i_x_e_d_-_a_d_d_r_e_s_s statement is used to assign one or more
fixed IP addresses to a client. It should only appear in
a _h_o_s_t declaration. If more than one address is supplied,
then when the client boots, it will be assigned the
address which corresponds to the network on which it is
booting. If none of the addresses in the _f_i_x_e_d_-_a_d_d_r_e_s_s
statement are on the network on which the client is boot­
ing, that client will not match the _h_o_s_t declaration con­
taining that _f_i_x_e_d_-_a_d_d_r_e_s_s statement. Each _a_d_d_r_e_s_s should
be either an IP address or a domain name which resolves to
one or more IP addresses.
TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f ssttaatteemmeenntt
ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_e;;
The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f statement sets the ending
time for all leases assigned dynamically to BOOTP clients.
9
dhcpd.conf(5) dhcpd.conf(5)
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.
_D_a_t_e 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.
TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h ssttaatteemmeenntt
ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;;
The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h statement is used to set
the length of leases dynamically assigned to BOOTP
clients. At some sites, it may be possible to assume
that a lease is no longer in use if its holder has not
used BOOTP or DHCP to get its address within a certain
time period. The period is specified in _l_e_n_g_t_h as a num­
ber of seconds. If a client reboots using BOOTP during
the timeout period, the lease duration is reset to _l_e_n_g_t_h,
so a BOOTP client that boots frequently enough will never
lose its lease. Needless to say, this parameter should be
adjusted with extreme caution.
TThhee _g_e_t_-_l_e_a_s_e_-_h_o_s_t_n_a_m_e_s ssttaatteemmeenntt
ggeett--lleeaassee--hhoossttnnaammeess _f_l_a_g;;
The _g_e_t_-_l_e_a_s_e_-_h_o_s_t_n_a_m_e_s statement is used to tell dhcpd
whether or not to look up the domain name corresponding to
the IP address of each address in the lease pool and use
that address for the DHCP _h_o_s_t_n_a_m_e option. If _f_l_a_g is
true, then this lookup is done for all addresses in the
current scope. By default, or if _f_l_a_g is false, no
lookups are done.
TThhee _u_s_e_-_h_o_s_t_-_d_e_c_l_-_n_a_m_e_s ssttaatteemmeenntt
uussee--hhoosstt--ddeeccll--nnaammeess _f_l_a_g;;
If the _u_s_e_-_h_o_s_t_-_d_e_c_l_-_n_a_m_e_s parameter is true in a given
10
dhcpd.conf(5) dhcpd.conf(5)
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 _o_p_t_i_o_n _h_o_s_t_-_n_a_m_e statement within a host declaration
will override the use of the name in the host declaration.
TThhee _a_u_t_h_o_r_i_t_a_t_i_v_e ssttaatteemmeenntt
aauutthhoorriittaattiivvee;;
nnoott aauutthhoorriittaattiivvee;;
The DHCP server will normally assume that the configura­
tion information about a given network segment is known to
be correct and is authoritative. So if a client requests
an IP address on a given network segment that the server
knows is not valid for that segment, the server will
respond with a DHCPNAK message, causing the client to for­
get its IP address and try to get a new one.
If a DHCP server is being configured by somebody who is
not the network administrator and who therefore does not
wish to assert this level of authority, then the statement
"not authoritative" should be written in the appropriate
scope in the configuration file.
Usually, writing nnoott aauutthhoorriittaattiivvee;; at the top level of
the file should be sufficient. However, if a DHCP server
is to be set up so that it is aware of some networks for
which it is authoritative and some networks for which it
is not, it may be more appropriate to declare authority on
a per-network-segment basis.
Note that the most specific scope for which the concept of
authority makes any sense is the physical network segment
- either a shared-network statement or a subnet statement
11
dhcpd.conf(5) dhcpd.conf(5)
that is not contained within a shared-network statement.
It is not meaningful to specify that the server is author­
itative for some subnets within a shared network, but not
authoritative for others, nor is it meaningful to specify
that the server is authoritative for some host declara­
tions and not others.
TThhee _u_s_e_-_l_e_a_s_e_-_a_d_d_r_-_f_o_r_-_d_e_f_a_u_l_t_-_r_o_u_t_e ssttaatteemmeenntt
uussee--lleeaassee--aaddddrr--ffoorr--ddeeffaauulltt--rroouuttee _f_l_a_g;;
If the _u_s_e_-_l_e_a_s_e_-_a_d_d_r_-_f_o_r_-_d_e_f_a_u_l_t_-_r_o_u_t_e parameter is true
in a given scope, then instead of sending the value speci­
fied in the routers option (or sending no value at all),
the IP address of the lease being assigned is sent to the
client. This supposedly causes Win95 machines to ARP for
all IP addresses, which can be helpful if your router is
configured for proxy ARP.
If use-lease-addr-for-default-route is enabled and an
option routers statement are both in scope, the routers
option will be preferred. The rationale for this is that
in situations where you want to use this feature, you
probably want it enabled for a whole bunch of Windows 95
machines, and you want to override it for a few other
machines. Unfortunately, if the opposite happens to be
true for you site, you are probably better off not trying
to use this flag.
TThhee _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r ssttaatteemmeenntt
sseerrvveerr--iiddeennttiiffiieerr _h_o_s_t_n_a_m_e;;
The server-identifier statement can be used to define the
value that is sent in the DHCP Server Identifier option
for a given scope. The value specified mmuusstt be an IP
address for the DHCP server, and must be reachable by all
clients served by a particular scope.
The use of the server-identifier statement is not recom­
mended - the only reason to use it is to force a value
other than the default value to be sent on occasions where
the default value would be incorrect. The default value
is the first IP address associated with the physical net­
work interface on which the request arrived. The usual
case where the _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r statement needs to be
sent is when a physical interface has more than one IP
address, and the one being sent by default isn't appropri­
ate for some or all clients served by that interface.
RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS
DHCP option statements are documented in the ddhhccpp--
ooppttiioonnss((55)) manual page.
12
dhcpd.conf(5) dhcpd.conf(5)
SSEEEE AALLSSOO
dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.
AAUUTTHHOORR
ddhhccppdd((88)) 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 hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
13

198
usr.sbin/dhcp/server/dhcpd.leases.cat5
View File

@ -1,198 +0,0 @@
dhcpd.leases(5) dhcpd.leases(5)
NNAAMMEE
dhcpd.leases - DHCP client lease database
DDEESSCCRRIIPPTTIIOONN
The Internet Software Consortium DHCP Server keeps a per­
sistent database of leases that it has assigned. This
database is a free-form ASCII file containing a series of
lease declarations. Every time a lease is acquired,
renewed or released, its new value is recorded at the end
of the lease file. So if more than one declaration
appears for a given lease, the last one in the file is the
current one.
When dhcpd is first installed, there is no lease database.
However, dhcpd requires that a lease database be present
before it will start. To make the initial lease database,
just create an empty file called /var/db/dhcpd.leases.
In order to prevent the lease database from growing with­
out bound, the file is rewritten from time to time.
First, a temporary lease database is created and all known
leases are dumped to it. Then, the old lease database is
renamed /var/db/dhcpd.leases~. Finally, the newly writ­
ten lease database is moved into place.
There is a window of vulnerability where if the dhcpd pro­
cess is killed or the system crashes after the old lease
database has been renamed but before the new one has been
moved into place, there will be no /var/db/dhcpd.leases.
In this case, dhcpd will refuse to start, and will require
manual intervention. DDOO NNOOTT simply create a new lease
file when this happens - if you do, you will lose all your
old bindings, and chaos will ensue. Instead, rename
/var/db/dhcpd.leases~ to /var/db/dhcpd.leases, restoring
the old, valid lease file, and then start dhcpd. This
guarantees that a valid lease file will be restored.
FFOORRMMAATT
Lease descriptions are stored in a format that is parsed
by the same recursive descent parser used to read the
ddhhccppdd..ccoonnff((55)) and ddhhcclliieenntt..ccoonnff((55)) files. Currently, the
only declaration that is used in the dhcpd.leases file is
the lleeaassee declaration.
lleeaassee _i_p_-_a_d_d_r_e_s_s {{ _s_t_a_t_e_m_e_n_t_s_._._. }}
Each lease declaration include the single IP address that
has been leased to the client. The statements within the
braces define the duration of the lease and to whom it is
assigned.
The start and end time of a lease are recorded using the
``starts'' and ``ends'' statements:
1
dhcpd.leases(5) dhcpd.leases(5)
ssttaarrttss _d_a_t_e;;
eennddss _d_a_t_e;;
Dates are specified as follows:
_w_e_e_k_d_a_y _y_e_a_r//_m_o_n_t_h//_d_a_y _h_o_u_r::_m_i_n_u_t_e::_s_e_c_o_n_d
The weekday is present to make it easy for a human to tell
when a lease expires - it's specified as a number from
zero to six, with zero being Sunday. The day of week is
ignored on input. The year is specified with the century,
so it should generally be four digits except for really
long leases. The month is specified as a number starting
with 1 for January. The day of the month is likewise
specified starting with 1. The hour is a number between 0
and 23, the minute a number between 0 and 59, and the sec­
ond also a number between 0 and 59.
Lease times are specified in Greenwich Mean Time (GMT),
not in the local time zone. Since Greenwich is actually
on Daylight Savings Time part of the year, there is proba­
bly nowhere in the world where the times recorded on a
lease are always the same as wall clock times. On a unix
machine, one can often figure out the current time in GMT
by typing ddaattee --uu.
The MAC address of the network interface that was used to
acquire the lease is recorded with the hhaarrddwwaarree statement:
hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _m_a_c_-_a_d_d_r_e_s_s;;
The MAC address is specified as a series of hexadecimal
octets, seperated by colons.
If the client used a client identifier to acquire its
address, the client identifier is recorded using the uuiidd
statement:
uuiidd _c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r;;
The client identifier is recorded as a series of hexadeci­
mal octets, regardless of whether the client specifies an
ASCII string or uses the newer hardware type/MAC address
format.
If the client sends a hostname using the _C_l_i_e_n_t _H_o_s_t_n_a_m_e
option, as specified in some versions of the DHCP-DNS
Interaction draft, that hostname is recorded using the
cclliieenntt--hhoossttnnaammee statement.
cclliieenntt--hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";;
If the client sends its hostname using the _H_o_s_t_n_a_m_e
option, as Windows 95 does, it is recorded using the
2
dhcpd.leases(5) dhcpd.leases(5)
hhoossttnnaammee statement.
hhoossttnnaammee ""_h_o_s_t_n_a_m_e"";;
The DHCP server may determine that a lease has been mis­
used in some way, either because a client that has been
assigned a lease NAKs it, or because the server's own
attempt to see if an address is in use prior to reusing it
reveals that the address is in fact already in use. In
that case, the aabbaannddoonneedd statement will be used to indi­
cate that the lease should not be reassigned.
aabbaannddoonneedd;;
Abandoned leases are reclaimed automatically. When a
client asks for a new address, and the server finds that
there are no new addresses, it checks to see if there are
any abandoned leases, and allocates the least recently
abandoned lease. The standard mechanisms for checking
for lease address conflicts are still followed, so if the
abandoned lease's IP address is still in use, it will be
reabandoned.
If a client rreeqquueessttss an abandoned address, the server
assumes that the reason the address was abandoned was that
the lease file was corrupted, and that the client is the
machine that responded when the lease was probed, causing
it to be abandoned. In that case, the address is immedi­
ately assigned to the client.
FFIILLEESS
//vvaarr//ddbb//ddhhccppdd..lleeaasseess
SSEEEE AALLSSOO
dhcpd(8), dhcp-options(5), dhcpd.conf(5), RFC2132,
RFC2131.
AAUUTTHHOORR
ddhhccppdd((88)) 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 hhttttpp::////wwwwww..iisscc..oorrgg//iisscc..
3