bootpd(1M)bootpd(1M)NAMEbootpd - Internet Boot Protocol server
SYNOPSIS
debuglevel] ping-timeout] timeout] [configfile [dumpfile]]
DESCRIPTION
The daemon implements three functions: a Dynamic Host Configuration
Protocol (DHCP) server as defined in RFC1541, an Internet Boot Protocol
(BOOTP) server as defined in RFC951 and RFC1395, and a DHCP/BOOTP relay
agent as defined in RFC1542. It also contains some of the useful
fields as defined in RFC2132.
is run through (see inetd(1M)). It is run by when the following line
(or equivalent) is included in the file
Options
starts when a boot request arrives.
If it has not received another boot request after 500 min‐
utes, exits. The option can be used to specify a different
timeout value in minutes (such as With a timeout value of
zero never exits.
The option enables the server to accept valid short packets >
packet size >
The option sets the verbosity level (1−3) of the logging emitted
by the daemon via (see syslog(3C)). For improved perfor‐
mance, this option should not be used. If this option is not
used, no logging is done by except for fatal errors.
By default, the
daemon pings the IP address before assigning the address to a
client to check if the IP Address is already in use. The
option suppresses from pinging this address.
The option can be used to specify the ping timeout period. The
server pings for this duration of time to check if the IP
address is already in use. The ping-timeout period is speci‐
fied in milliseconds and the maximum value is 3000 millisec‐
onds. When the option is used, the option has no effect,
since never pings the IP address.
When receives a DHCP/BOOTP request, it first checks if the hardware
address of the client is listed in the database. If yes, this client
is denied lease. If the client is not listed in the database, it
checks whether the client information is in the database. If the
client information is available, sends back the reply. Otherwise, it
checks whether there is any matched relay information for the client in
the database. If so, goes through a series of checks to see if it
should relay the request. If no matched relay information was found,
checks whether the client information is matched by a pool or device
group in the database. If a match is found, sends back a reply. The
request is dropped if no matched group information is found.
To reply to a DHCP or BOOTP request the server puts together a BOOTRE‐
PLY message and does a number of checks to ensure the message is sent
to the correct destination.
first checks the (client IP address) field of the DHCP/BOOTP packet.
If this field is nonzero, the BOOTREPLY message is sent to the IP
address identified in
If the field is zero, checks the field. If this field is not zero,
sends the BOOTREPLY message to the relay agent specified in field and
the relay agent delivers the BOOTREPLY message to the client. If the
field is zero, sends the BOOTREPLY message to the client. In both
cases, the BOOTREPLY will either be sent to the IP address specified in
the (your IP address) field or as a broadcast message. On HP-UX, there
are two ways to specify that the BOOTREPLY should be sent as a broad‐
cast message.
1. The client sets the broadcast flag bit in the flag field (bit 0)
of the DHCP/BOOTP request packet.
2. Define the tag in the file (see below)
For the case where the has matched a relay entry in it attempts to for‐
ward the request to the configured DHCP/BOOTP server.
first checks whether the relay function is enabled for the requesting
client. The relay capability is configurable. If the relay function
is disabled, then the request packet is dropped.
Before relays the request, it also examines the (gateway IP address)
field. The client sets the field to zero when it sends out the
request. If the relay agent finds this field is zero, it fills this
field with the primary IP address of the interface on which the request
was received; otherwise, the relay agent does not change this field.
Then increments the value of the field, and relays the request to the
DHCP/BOOTP servers that have been configured for this client.
If the relay function is enabled for this client, checks the field of
the DHCP/BOOTP request packet. The client sets the field to 0 when it
sends out the DHCP/BOOTP request. The value is increased every time
the request packet is relayed by a relay agent. The maximum hop number
can be configured. The maximum possible hop number allowed is 16. The
default maximum is set to 4. The request packet is dropped if the hop
value exceeds the configured maximum.
Then compares the value of the (seconds since the client began booting)
field of the DHCP/BOOTP packet to the value. The client sets the field
to zero when it first sends out the request. The client repeats the
request if it does not receive a reply. When the client repeats the
request, it sets the value to the number of seconds since the first
request was sent. does not relay the request if the value of the field
is less than the value. The value can be configured. The default
value is 0.
Configuration
Upon startup, reads its configuration files to build its internal data‐
base, then listens for boot request packets. The default configuration
files are and The file can be specified in the command line. rereads
its configuration file when it receives a hangup signal, or when it
receives a boot request packet and detects that the configuration file
has been updated. If hosts are added, deleted, or modified, their
entries in the internal database are updated accordingly when the con‐
figuration files are reread. The database contains the list of hard‐
ware addresses of the clients that will not be served by this server.
If receives a signal, it dumps its memory-resident database to the file
or the dumpfile specified in the command line.
The configuration file can contain two types of host entries:
1. The client entries, which contains the client information.
2. The relay entries, which contains the configuration to relay
DHCP/BOOTP requests for one or more clients.
The configuration uses two-character, case-sensitive tag symbols to
represent host parameters. These parameter declarations are separated
by colons The general format is:
where hostname is the actual name of a DHCP/BOOTP client in the client
entries, and in the case of a relay entry, it can be the actual name of
a client if it is an individual relay entry, or it can be a name for a
group of clients if it is a group relay entry. tg is a two-character
tag symbol. Most tags must be followed by an equals-sign, and a value
as above. Some can appear in a boolean form with no value (that is,
Blank lines and lines beginning with are ignored in the configuration
file. Host entries are separated from one another by newlines; a sin‐
gle host entry can be extended over multiple lines if the lines end
with a backslash It is also acceptable for lines to be longer than 80
characters. Tags can appear in any order with the following excep‐
tions: The host name must be the very first field in an entry, and the
hardware type tag, must precede the hardware address tag, and the hard‐
ware mask tag,
IP addresses are specified in standard Internet dot notation, and can
use decimal, octal, or hexadecimal numbers (octal numbers begin with
hexadecimal numbers begin with or Certain tags accept a list of one or
more IP addresses (ip_address_list). When more than one IP address is
listed, the addresses must be separated by whitespace.
The types of tags can be grouped into three categories:
1. The tags that can be used for both the client and the relay
entries.
2. The tags that can only be used in the relay entries.
3. The tags that can only be used in the client information entries.
Tag is used to differentiate a client entry from a relay entry. An
entry with tag defined is treated as a client entry. A relay entry can
contain the relay configuration for an individual client, also a hard‐
ware address mask mechanism is provided to configure the relay entry
for a group of clients. The group client relay entries are kept in a
linear sorted table by When a client does not have an individual relay
specification, the linear table is searched to see if there is a match
for the client. If there are multiple matched entries in the sorted
table, only the first one is used. Tag is used to differentiate an
individual client relay entry from a group relay entry. The linear
sorted table is sorted on the value of tag The search and match mecha‐
nism is explained in the discussion of tag
This tag specifies the hardware address of the client.
The hardware address must be specified in hexadecimal;
optional periods and/or a leading can be included for
readability. The tag must be preceded by the tag (either
explicitly or implicitly; see below).
This tag specifies the hardware type code.
hardware-type can be an unsigned decimal, octal, or hexa‐
decimal integer corresponding to one of the ARP Hardware
Type codes specified in RFC1010. It can also be speci‐
fied by the symbolic names or for 10-Mb Ethernet; or for
3-Mb experimental Ethernet; or for IEEE 802 networks; for
Proteon ProNET Token Ring; and for Chaos and ARCNET,
respectively.
This tag indicates a table continuation.
Often, many host entries share common values for certain
tags (such as domain servers, etc.). Rather than repeat‐
edly specifying these tags, a full specification can be
listed for one host entry and shared by others via the
mechanism.
The template-host is a dummy host that does not actually
exist and never sends boot requests. Information explic‐
itly specified for a host always overrides information
implied by a tag symbol. The value of template-host can
be the host name or IP address of any host entry previ‐
ously listed in the configuration file.
Sometimes it is necessary to delete a specific tag after
it has been inferred via This can be done using the con‐
struction tag@ which removes the effect of tag. For
example, to completely undo an RFC1034 domain name server
specification, use at an appropriate place in the config‐
uration entry. After removal with a tag is eligible to
be set again through the mechanism.
This tag specifies the BOOTP servers
that DHCP/BOOTP requests will be relayed to. The value
of bootp-servers can be one or more individual IP
addresses, and/or one or more network broadcast
addresses. A relay entry with this tag configured indi‐
cates that the relay function is on for the clients spec‐
ified in this entry. A relay entry missing this symbol
means that the relay function is off for the clients
specified in this entry.
This tag specifies the
threshold value in seconds for the entry. The default
value is 0.
This tag specifies the maximum
hops value. If the hops value exceeds 16, it is set to
16. The default value is 4.
This tag specifies the mask for the hardware address
hardware-address-mask must be specified in hexadecimal.
An optional leading can be included for readability. The
tag must be preceded by the tag (either explicitly or
implicitly; see above). Each bit in specifies that the
corresponding bit in is a "don't-care" bit, each bit in
specifies that the corresponding bit in the value is
ANDed with the value. If the result is the same and also
the hardware type matches, then a match is found. For
example,
This tag specifies that
should broadcast the boot reply to the client. As a
boolean tag, it causes to send the boot reply on the con‐
figured broadcast address of each network interface. You
can also assign the tag an IP-address value, which speci‐
fies the specific IP or broadcast address for the boot
reply.
This tag specifies the
filename of the bootfile that the client should download.
The client's boot request, and the values of the (see
below) and symbols, determine the contents of the boot‐
file field in the boot reply packet.
If the client specifies an absolute path name (in its
boot request), and that file is accessible on the server
machine (see below), returns that path name in the reply
packet. If the file is not accessible, the request is
discarded; no reply is sent. If the client specifies a
relative path name, constructs a full path name by
appending the relative path name to the value of the tag,
and tests to determine if the full path name is accessi‐
ble. If the full path name is accessible, it is returned
in the boot reply packet; if not, the request is dis‐
carded.
Clients that do not specify boot files in their boot
requests always elicit a reply from the server. The
exact reply depends on the values of the and tags. If
the tag specifies an absolute path name, and the file is
accessible, that path name is returned in the reply
packet. Otherwise, if the and tags together specify an
accessible file, that file name is returned in the reply.
If a complete file name cannot be determined, or the file
is not accessible publicly, the reply contains a zeroed-
out bootfile field.
If the pseudo-user exists, treats all path names (abso‐
lute or relative) as being relative to the home directory
of and checks there first. If the file is not accessible
under the home directory or the pseudo-user does not
exist, checks for the file relative to
For a file to be available, it must exist, and be pub‐
licly readable.
All file names are first tried as and then simply as
filename. However, in the case when the pseudo-user
exists, but and filename are not accessible under the
home directly, only filename is checked relative to
Note that a file considered to be accessible relative to
might not actually be accessible via if the command line
arguments to disallow that path.
This tag specifies the size of the bootfile.
The parameter size can be either a decimal, octal, or
hexadecimal integer specifying the size of the bootfile
in 512-octet blocks, or the keyword which causes the
server to automatically calculate the bootfile size at
each request. Specifying the symbol as a boolean has the
same effect as specifying as its value.
This tag specifies the client identifier of the client.
The parameter client_ID can be either a hexadecimal inte‐
ger, or a string contained in double quotes. The
client_ID is a unique identifier that the DHCP client may
use to identify itself to the server. If present, the
client identifier supersedes the hardware address, so a
client and an entry will only match in one of two situa‐
tions: one, they both have the same client identifier, or
two they both have the same hardware address and neither
has a client identifier. If a request has a client iden‐
tifier, then that is used to match the client up with an
entry in the configuration file. One common client ID
used is to concatenate the hardware type (e.g. 0x01 for
ethernet) with the hardware address.
This tag specifies the IP addresses
of RFC865 Quote of the Day (cookie) servers.
This tag specifies the domain name of the client for Domain Name
Server
resolution (see RFC1034).
This tag specifies the IP addresses of RFC1034 Domain Name
servers.
Specifies the name of an extensions file. The file,
retrievable via TFTP, contains information which can be
interpreted in the same way as the 64-octet vendor-exten‐
sion field within the BOOTP response. The maximum length
of the file is unconstrained. All references to an
extensions filename within the file are ignored.
This tag specifies the IP addresses of gateways for the client's
subnet.
If one of multiple gateways is preferred, it should be
listed first.
This tag specifies a directory name to which the bootfile is
appended (see the
tag above). The default value of the tag is
The presence of this tag indicates that the client's host name
should be sent in the boot reply. The tag is a boolean
tag. attempts to send the entire host name as it is
specified in the configuration file or hosts database.
The configuration file is checked first, if the host name
is not found, the hosts(4) database is then checked. If
the hostname cannot fit into the reply packet, an attempt
is made to shorten the name to just the host field (up to
the first period, if present) and then tried. In no case
is an arbitrarily truncated host name sent. If nothing
reasonable can fit, nothing is sent.
This tag specifies the IP addresses of Impress network image
servers.
This tag specifies the IP address of the DHCP/BOOTP client.
This tag specifies the IP addresses of MIT-LCS UDP log servers.
This tag specifies the IP addresses of Berkeley 4BSD printer
servers.
This tag specifies the name of a file to dump the core of a
client.
This tag specifies the IP address(es) of SMTP servers
available to the client (RFC2132).
This tag specifies the IP address(es) of RFC 1001/1002 NetBIOS
name server(s)
in order of preference.
This tag specifies the IP address(es) of RFC 1001/1002 NetBIOS
datagram
distribution server(s) in order of preference.
Specifies the NetBIOS node type code. Allows NetBIOS over
TCP/IP clients to be configured as described in
RFC1001/1002. The NetBIOS_node_type can be an unsigned
decimal, octal, or hexadecimal integer corresponding to
one of the client types as follows:
or for B-node;
or for P-node;
or for M-node;
or for H-node.
This tag specifies the NetBIOS over TCP/IP scope parameter
for the client as specified in RFC 1001/1002.
This tag specifies the IP addresses of IEN-116 name servers.
This tag specifies the IP addresses of Network Time Protocol
servers.
Servers should be listed in order of preference.
This tag specifies the name of clients NIS+ domain name
(RFC2132).
This tag specifies the IP address(es) of NIS+ servers available
to the client
(RFC2132).
This tag specifies the IP addresses of
RFC887 Resource Location Protocol servers.
This tag specifies a path name to be mounted as a root disk.
This tag specifies the IP address of the TFTP server where the
client's
bootfile resides. When this option is enabled, uses the
IP address specified in this tag for the siaddr field in
a BOOTP/DHCP packet header. Otherwise, the IP address of
the BOOTP/DHCP server is used in the siaddr field. The
tag allows the BOOTP/DHCP server and the TFTP server to
be two different systems, if desired.
This tag specifies the client's subnet mask.
subnet-mask is specified as a single IP address.
This tag specifies a list of static routes that the client
should put
in its routing cache. Each route consists of a pair of
IP addresses. The first address is the destination
address, and the second is the router. Use the option to
specify the default route (0.0.0.0) as it is not a legal
destination address.
This tag specifies the IP address of a swap server.
This is a generic tag where
nnn is an RFC1533 option field tag number. Use this
option to configure RFC1533 options not currently sup‐
ported with tag names. This option allows one to immedi‐
ately take advantage of future extensions to RFC1533.
The generic-data data can be represented as either a
stream of hexadecimal numbers or as a quoted string of
ASCII characters. The length of the generic data is
automatically determined and inserted into the proper
fields of the RFC1541-style boot reply.
This tag specifies the client's time zone offset in seconds from
UTC.
The time offset can be either a signed decimal integer or
the keyword which uses the server's time zone offset.
Specifying the symbol as a boolean has the same effect as
specifying as its value.
This tag specifies the IP addresses of RFC868 Time Protocol
servers.
Specifies the name of the client's NIS domain.
Specifies the IP address(es) of NIS servers available to the
client.
Servers should be listed in order of preference.
This tag specifies the RFC1048 vendor information magic cookie.
magic-cookie can be one of the following keywords: (indi‐
cating that vendor information is determined by the
client's request), (which always forces an RFC1048-style
reply), or (which always forces a CMU-style reply).
This is a generic tag for vendor specific information where
nnn is a vendor defined option field tag number. The
generic-data data can be represented as either a stream
of hexadecimal numbers or as a quoted string of ASCII
characters. The length of the generic data is automati‐
cally determined and inserted into the vendor specific
field of the RFC1541-style boot reply.
This tag specifies the IP addresses of systems that are running
the X
Window System Display Manager and are available to the
client. Addresses should be listed in order of prefer‐
ence.
This tag specifies the IP addresses of X window System font
servers
available to the client. Servers should be listed in
order of preference.
Dhcpdeny Configuration
The configuration file contains the list of hardware addresses, one
address per line, for clients that will not be served by our server.
If we know about some bad clients in the network and we don't want to
serve them, add the hardware address of those clients in this file.
This file, like other configuration files, takes character as the
starting of a comment.
Dhcptab Configuration
The configuration file defines groups of IP addresses that to be leased
out to clients. It also specifies certain general behaviors of the
server, such as whether or not to give addresses from these groups to
clients or only to DHCP clients.
The configuration file has a format similar to the configuration file,
with a keyword followed by one or more tag symbols. These tag symbols
are separated by colons The general format is:
where keyword is one of four allowed (non-case-sensitive) symbols and
tg is a two or more (case-sensitive) character tag symbol. Most tags
must be followed by an equals-sign and a value as above. Some can also
appear in a boolean form with no value (i.e.
Blank lines and lines beginning with are ignored in the configuration
file. Keyword entries are separated from one another by newlines; a
single host entry may be extended over multiple lines if each continued
line ends with a backslash Lines may be longer than 80 characters.
Tags can appear in any order.
IP addresses must be specified in standard Internet ``dot'' notation,
and can use decimal, octal, or hexadecimal numbers (octal numbers begin
with hexadecimal numbers begin with or Certain tags accept a list of
one or more IP addresses (ip_address_list). When more than one IP
address is listed, they must be separated by white space.
The currently recognized keywords are:
This keyword is followed by tags defining a group of IP
addresses to give
out to clients on the same subnet, and the characteristics
of that group. In addition to the tags defined for DHCP
groups, all of the two-letter tags for bootp entries may
also be used (except for the hardware type tag, the hard‐
ware address tag, or the client ID tag. Required tags
are: and
This keyword is used to define a group of IP addresses on a sub‐
net much
like but with one exception: all clients in a device group
must have the same client class (specified with tag This
allows different types of clients to receive different
parameters from the server. Required tags are: and
This keyword is followed by tags to be applied to all groups.
These tag
values can be overridden for a specific group if that tag
is defined for that specific group. This keyword simply
saves one from entering the same tag for every group.
Thus most tags that may be used for and may be used here.
The tag descriptions specify if a tag may not be used
here.
This keyword is followed by tags that specify a few general
behaviors
for the dhcp server as a whole.
The currently supported tags for are:
This boolean tag specifies that
supports the subnet selection option (RFC 3011). However,
a group will support the subnet selection option only when
this tag is specified in that group.
This parameter takes a small integer (like 2 or 5) as input. If
set, the
write to the file will be delayed by the server. This
will increase performance for busy servers. If set to a
value greater than 2, the server will spawn a new process
to do the writing, which will be a considerable perfor‐
mance improvement.
Callbacks are a powerful feature that allow the system adminis‐
trator to
customize the operation of the server. A user-supplied
executable file (typically a shell script) is executed
each time one of the main server actions is performed
(example: granting a lease). An argument list is passed
in with information about the individual client and the
lease. The tag specifies whether the old (and confusing)
argument list should be used with the feature described
below. The new (and recommended) argument list is much
simpler to use, and is identical for all of the functions.
The new style simply inserts a value of "00" for fields
that are not sensible for a particular callback. The new
argument list is:
The old argument list is described for each of the indi‐
vidual callbacks below.
This tag specifies an executable file
filename that will be called when the server receives a
request to which it cannot send a response. Certain argu‐
ments will be passed in; the call executed will be:
where client-id is the client ID in hex if present, or 00
if there is no client ID. htype is the hardware type as
per the ARP section of the "Assigned Numbers" RFC. haddr
is the hardware address in hex. gateway is the IP address
of the relay agent. If the packet was not relayed, then
this field is absent.
The currently supported tags for and are:
This boolean tag specifies that this group supports the subnet
selection option.
However, if this tag is not specified in the then this
option will also be ignored. This tag is inappropriate
for
This tag specifies the fully qualified
filename to be called when an IP address has been assigned
to a new client. Some arguments will be passed in, the
call will be made as follows:
where client-id is the client ID in hex if present, or 00
if there is no client ID. htype is the hardware type as
per the ARP section of the "Assigned Numbers" RFC. haddr
is the hardware address in hex. ipaddr is the IP address
that was assigned to the client. subnet-mask is the sub‐
net mask of the client represented as an IP address.
lease-expiration is the internal representation of when
the lease will expire (based on a C call to time()), a
value of represents an infinite lease. If there is a
hostname associated with this address, then it is the
final argument.
This tag specifies the fully qualified
filename to be called when an IP address has been declined
by a new client. Some arguments will be passed in, the
call will be made as follows:
where client-id is the client ID in hex if present, or 00
if there is no client ID. htype is the hardware type as
per the ARP section of the "Assigned Numbers" RFC. haddr
is the hardware address in hex. ipaddr is the IP address
that was declined by the client. subnet-mask is the sub‐
net mask of the client represented as an IP address.
This tag specifies the fully qualified
filename to be called when an IP address has been dis‐
carded due to a conflict. Some arguments will be passed
in, the call will be made as follows:
where client-id is the client ID in hex if present, or 00
if there is no client ID. htype is the hardware type as
per the ARP section of the "Assigned Numbers" RFC. haddr
is the hardware address in hex. ipaddr is the IP address
that was declined by the client. subnet-mask is the sub‐
net mask of the client represented as an IP address.
This tag specifies the fully qualified
filename to be called when an IP address has been released
by a client. Some arguments will be passed in, the call
will be made as follows:
where client-id is the client ID in hex if present, or 00
if there is no client ID. htype is the hardware type as
per the ARP section of the "Assigned Numbers" RFC. haddr
is the hardware address in hex. ipaddr is the IP address
that was released by the client. lease-expiration is the
internal representation of when the lease would have
expired, a value of represents an infinite lease.
This tag specifies the fully qualified
filename to be called when an IP address lease for a
client has been extended. Some arguments will be passed
in, the call will be made as follows:
where client-id is the client ID in hex if present, or 00
if there is no client ID. htype is the hardware type as
per the ARP section of the "Assigned Numbers" RFC. haddr
is the hardware address in hex. ipaddr is the IP address
that was assigned to the client. subnet-mask is the sub‐
net mask of the client represented as an IP address.
lease-expiration is the internal representation of when
the lease will expire (based on a C call to time()), a
value of represents an infinite lease.
This tag specifies the fully qualified
filename to be called when the server receives a discover.
It should be noted that this callback can only be used
when callback-style is set to new. The format of the
arguments passed to this callback is same as the format
specified for callback-style=new. If a particular parame‐
ter is not known or not required, 00 can be used in it's
place.
This tag specifies the fully qualified
filename to be called when the server sends an offer to a
client. It should be noted that this callback can only be
used when callback-style is set to new. The format of the
arguments passed to this callback is same as the format
specified for callback-style=new. If a particular parame‐
ter is not known or not required, 00 can be used in it's
place.
This tag specifies a name to refer to a device group by. It is
only
applicable to The only use that makes of this field is in
logging errors found in the configuration of the group.
This tag specifies a name to refer to a pool group by. It is
only
applicable to The only use that makes of this field is in
logging errors found in the configuration of the group.
This tag specifies the
client-class that clients must have to be assigned to this
group. This tag is required for and is inappropriate for
any other keyword. Some DHCP clients send out a client-
class that identifies a class that a client belongs to.
For an IP address to be assigned from a device group
address pool, not only must the client be on the right
subnet, it must send a request with a client-class that
matches that defined for the This may be specified in
either hex or in ASCII (an ASCII string must be enclosed
in double quotes).
This is a boolean tag that instructs
not to send the back to the client. This tag is applica‐
ble only for
This is a boolean tag that instructs the
to match the in the client's request with the in any that
contains the tag using any basic regular expression. This
tag is applicable only for
This tag specifies the subnet mask for the addresses in the
group being
defined. It is specified as an IP address. This tag is
required for both and and is inappropriate for
This tag specifies the lowest address in the pool group to be
assigned.
This tag is required for both and and is inappropriate for
This tag specifies the highest address in the pool group to be
assigned.
This address and the define a range of addresses that can
be assigned to clients. For the server, no two group
address ranges may overlap.
This tag is followed by one address that falls in the
range of the group. This address is reserved, and will
not be assigned to any clients by the DHCP server. Alter‐
natively, a range of addresses may be defined by giving 2
addresses, with the range being the addresses from the
first address up to the second address, inclusively. This
tag may be repeated to reserve more addresses in the same
group. It is not appropriate for
This tag specifies the time in seconds that a lease should be
given to
each client. The word "infinite" may be used to specify
leases that never expire. The default is "infinite."
Note that if a client asks for a shorter lease than is
configured for it, it will get that shorter lease time. A
lease time shorter than 120 seconds will be silently
upgraded to 120.
This tag specifies the time after a lease expires during which
that
lease will not be assigned to a new client. percent is
the percentage of the configured lease time that this
grace period lasts. The default is 5%.
This tag specifies the DHCP IP lease renewal time (T1). This is
the time
interval from lease assignment until when the client
attempts to renew the lease. RFC1541 states that T1
defaults to half the lease duration. The minimum value is
40 percent. T1 must always be smaller than T2.
This tag specifies the DHCP IP lease rebind time (T2). This is
the time
interval from lease assignment until when the client
attempts to obtain a new lease from any server. RFC1541
states that T2 defaults to 0.875 times the lease duration.
The minimum value is 50 percent. T2 must always be
greater than T1.
This tag specifies whether or not the assigning of new leases
can be done.
If policy is set to then no new clients can get a lease,
and only clients with existing leases will get a response.
accept-new-clients is the default.
This tag specifies whether or not bootp clients can be members
of the
group being defined. The default is If boolean is then an
IP address may be assigned to a client that doesn't have
an entry in the file and that is on the same subnet as the
group being defined. This address is treated as an infi‐
nite lease, and a boot reply is sent to the client. This
tag is is not appropriate for since bootp clients don't
have a client class (and therefore a bootp client would be
incapable of matching the client class of the device
group). If this tag is used for then it is only applica‐
ble to pool groups.
This tag specifies the IP address of the Domain Name Server
(DNS) to which
dynamic update requests are sent.
This tag specifies that the name sent by client should be given
preference.
As a boolean tag, if set it causes bootpd to accept the
name sent by the client (if any). If name is not sent by
the client, bootpd tries to find one.
As a boolean tag, if set it causes bootpd to not use pre-requi‐
site
section in the update request when an update request is to
be sent to DNS.
DHCP/BOOTP Packet
The DHCP/BOOTP packet has the following format:
DHCP Option Numbers
The DHCP/BootP options discussed above correspond to the option numbers
in RFC1533 as follows:
Number Tag Description
────────────────────────────────────────────────────────────
1 sm Subnet Mask
2 to Time Offset
3 gw Gateways
4 ts Time Servers
5 ns IEN 116 Name Servers
6 ds Domain Name Servers
7 lg Log Servers
8 cs Cookie Servers
9 lp LPR Servers
10 im Impress Servers
11 rl Resource Location Servers
12 hn Send Host Name in reply
13 bs Boot File Size
14 md Merit Dump File
15 dn Domain Name
16 ss Swap Server
17 rp Root Path
18 ef Extensions Path
28 ba Broadcast Address
33 sr Static Routes
40 yd NIS Domain
41 ys NIS Servers
42 nt NTP Servers
43 V### Vendor Specific Information
44 na NetBIOS Name Servers
45 nb NetBIOS Datagram Distribution Servers
46 nc NetBIOS Node Type
47 nd NetBIOS Scope
48 xf X Font Servers
49 xd X Display Manager
51 lease-time IP Address Lease Time
58 tr Lease Renewal Time (T1)
59 tv Lease Rebinding Time (T2)
60 class-id Class Identifier
61 ci Client Identifier
64 pd NIS+ Domain
65 ps NIS+ Servers
69 ms SMTP Servers
EXAMPLES
This is an example of a file:
This is an example of a file:
This is an example of a file:
WARNINGS
Individual host entries must not exceed 1024 characters.
AUTHOR
was developed by Carnegie Mellon University, Stanford University, and
HP.
FILESSEE ALSObootpquery(1M), dhcptools(1M), inetd(1M), tftpd(1M), syslog(3C),
hosts(4).
DARPA Internet Requests For Comments: RFC865, RFC868, RFC887, RFC951,
RFC1010, RFC1034, RFC1048, RFC1084, RFC1395, RFC1533, RFC1534, RFC1541,
RFC1542, RFC2131, RFC2132, RFC3011.
bootpd(1M)
