bootpd(1M) bootpd(1M)
NAME
bootpd - 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
starts when a boot request arrives. If it has not received another boot request after 500 minutes, exits. The option can be used to spec-
ify a different timeout value in minutes (such as With a timeout value of zero never exits.
The option sets the verbosity level (1-3) of the logging emitted by the daemon via (see syslog(3C)). For improved performance, 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 period is specified in milliseconds and the maximum value is 3000 milliseconds. 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 dhcpdeny 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 BOOTREPLY 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 broadcast 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 forward 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 database, then listens for boot request packets. The default configura-
tion 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 configuration files are reread. The database contains the list of
hardware 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-char-
acter 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
single 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 exceptions: 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 hardware 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 hardware 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 mechanism 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 hexadecimal integer corresponding to one of the ARP Hardware Type codes
specified in RFC1010. It can also be specified by the symbolic names or for 10-Mb Ethernet; or for 3-Mb experimental Ether-
net; 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 repeatedly speci-
fying 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 explicitly speci-
fied 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 previously 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 construction
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 configuration 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 indicates that the relay function is on for
the clients specified 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 configured broad-
cast address of each network interface. You can also assign the tag an IP-address value, which specifies 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 bootfile 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 accessible. If the full path name is accessible, it is
returned in the boot reply packet; if not, the request is discarded.
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 (absolute 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 publicly 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 integer, 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 super-
sedes the hardware address, so a client and an entry will only match in one of two situations: 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 identifier, 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-extension 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 supported with tag
names. This option allows one to immediately 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: (indicating 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 automatically 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 preference.
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 sym-
bols 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 hardware address tag, or
the client ID tag. Required tags are: and
This keyword is used to define a group of IP addresses on a subnet 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 performance improvement.
Callbacks are a powerful feature that allow the system administrator 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 fea-
ture described below. The new (and recommended) argument list is much simpler to use, and is identical for all of the func-
tions. 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 individual 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 arguments 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 subnet 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 subnet 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 discarded 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 subnet 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 subnet 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 call-
back-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 parameter 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 call-
back-style=new. If a particular parameter 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 applicable 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. Alternatively, 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 infinite 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 applicable 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-requisite
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.
FILES
SEE ALSO
bootpquery(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)