DHCP Option List
DHCP Option List
DHCP Option List
DHCP options have the same format as the BOOTP 'vendor extensions'. Options may be fixed
length or variable length. All options begin with a tag byte, which uniquely identifies the
option. Fixed length options without data consist of only a tag byte. The value of the length
byte does not include the tag and length fields.
Options containing NVT ASCII data SHOULD NOT include a trailing NULL; however, the
receiver of such options MUST be prepared to delete trailing NULLs if they exist. The receiver
MUST NOT require that a trailing NULL be included in the data. In the case of some variable
length options, the length field is a constant but must still be specified.
dhcpd-options(5) dhcpd-options(5)
NAME
dhcp-options - Dynamic Host Configuration Protocol options
DESCRIPTION
The Dynamic Host Configuration protocol allows the client to receive
options from the DHCP server describing the network configuration and
various services that are available on the network. When configuring
dhcpd(8) or dhclient(8) , 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.
The int32 data type specifies a signed 32-bit integer. The uint32
data type specifies an unsigned 32-bit integer. The int16 and uint16
data types specify signed and unsigned 16-bit integers. The int8 and
uint8 data types specify signed and unsigned 8-bit integers. Unsigned
8-bit integers are also sometimes referred to as octets.
The text data type specifies an NVT ASCII string, which must be
enclosed in double quotes - for example, to specify a root-path option,
the syntax would be
The domain-name data type specifies a domain name, which must not
enclosed in double quotes. This data type is not used for any exist-
ing DHCP options. The domain name is stored just as if it were a text
option.
The flag data type specifies a boolean value. Booleans can be either
true or false (or on or off, if that makes more sense to you).
The string data type specifies either an NVT ASCII string enclosed in
double quotes, or a series of octets specified in hexadecimal, sepa-
For example:
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 true indicates that all subnets share
the same MTU. A value of false means that the client should assume
that some subnets of the directly connected network may have smaller
MTUs.
This option specifies the timeout in seconds for ARP cache entries.
The cookie server option specifies a list of RFC 865 cookie servers
available to the client. Servers should be listed in order of pref-
erence.
This option specifies the default time-to-live that the client should
use on outgoing datagrams.
This option specifies the default TTL that the client should use when
sending TCP segments. The minimum value is 1.
Please be aware that some DHCP clients, when configured with client
identifiers that are ASCII text, will prepend a zero to the ASCII
text. So you may need to write:
rather than:
This option, when sent by the client, specifies the maximum size of
any response that the server sends to the client. When specified on
the server, if the client did not send a dhcp-max-message-size
option, the size specified on the server is used. This works for
BOOTP as well as DHCP responses.
This option, sent by both client and server, specifies the type of
DHCP message contained in the DHCP packet. Possible values (taken
directly from RFC2132) are:
1 DHCPDISCOVER
2 DHCPOFFER
3 DHCPREQUEST
4 DHCPDECLINE
5 DHCPACK
6 DHCPNAK
7 DHCPRELEASE
8 DHCPINFORM
This option, when sent by the client, specifies which options the
client wishes the server to return. Normally, in the ISC DHCP
client, this is done using the request statement. If this option is
not specified by the client, the DHCP server will normally return
every option that is valid in scope and that fits into the reply.
When this option is specified on the server, the server returns the
specified options. This can be used to force a client to take
options that it hasn't requested, and it can also be used to tailor
the response of the DHCP server for clients that may need a more lim-
ited set of options than those the server would normally return.
This option specifies the number of seconds from the time a client
gets an address until the client transitions to the REBINDING state.
This option specifies the number of seconds from the time a client
gets an address until the client transitions to the RENEWING state.
This option specifies the domain name that client should use when
resolving hostnames via the Domain Name System.
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. This option is only honored by dhclient-
script(8) if the hostname for the client machine is not set.
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 false indicates that the client
should use RFC 894 encapsulation. A value of true means that the
client should use RFC 1042 encapsulation.
This option specifies the MTU to use on this interface. The minimum
legal value for the MTU is 68.
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.
This option specifies the maximum size datagram that the client
should be prepared to reassemble. The minimum legal value is 576.
The nds-tree-name option specifies NDS tree name that the NDS client
should use.
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.
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.
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 characters from the NVT ASCII character set.
This option specifies the name of the client's NIS+ domain. The
domain is formatted as a character string consisting of characters
from the NVT ASCII character set.
This option specifies the timeout (in seconds) to use when aging Path
MTU values discovered by the mechanism defined in RFC 1191.
This option specifies whether or not the client should perform subnet
mask discovery using ICMP. A value of false indicates that the
client should not perform mask discovery. A value of true means that
the client should perform mask discovery.
Any source routed datagram whose next-hop address does not match one
of the filters should be discarded by the client.
This option specifies the path-name that contains the client's root
disk. The path is formatted as a character string consisting of
characters from the NVT ASCII character set.
This option specifies the address to which the client should transmit
router solicitation requests.
Please note that in this option and the slp-service-scope option, the
term "SLP Agent" is being used to refer to a Service Location Proto-
col agent running on a machine that is being configured using the
DHCP protocol.
Also, please be aware that some companies may refer to SLP as NDS.
If you have an NDS directory agent whose address you need to config-
ure, the slp-directory-agent option should work.
This option specifies a list of static routes that the client should
install in its routing cache. If multiple routes to the same desti-
nation are specified, they are listed in descending order of prior-
ity.
The subnet mask option specifies the client's subnet mask as per RFC
950. If no subnet mask option is provided anywhere in scope, as a
last resort dhcpd will use the subnet mask from the subnet declara-
tion for the network on which an address is being assigned. However,
any subnet-mask option declaration that is in scope for the address
being assigned will override the subnet mask specified in the subnet
declaration.
This option specifies whether or not the client should send TCP
keepalive messages with an octet of garbage for compatibility with
older implementations. A value of false indicates that a garbage
octet should not be sent. A value of true indicates that a garbage
octet should be sent.
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.
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 false indicates that the client should not attempt to use trail-
ers. A value of true means that the client should attempt to use
trailers.
This option is used by some DHCP clients as a way for users to spec-
ify identifying information to the client. This can be used in a
similar way to the vendor-class-identifier option, but the value of
the option is specified by the user, not the vendor. Most recent
DHCP clients have a way in the user interface to specify the value
for this identifier, usually as a text string.
This will result in all entries in the DHCP server lease database
file for clients that sent vendor-class-identifier options having
a set statement that looks something like this:
The remote-id suboption encodes information about the remote host end
of a circuit. Examples of what it might contain include caller ID
information, username information, remote ATM address, cable modem
ID, and similar things. In principal, the meaning is not well-spec-
ified, and it should generally be assumed to be an opaque object that
is administratively guaranteed to be unique to a particular remote
end of a circuit.
When the client sends this, if it is true, it means the client will
not attempt to update its A record. When sent by the server to the
client, it means that the client should not update its own A record.
When the client sends this to the server, it is requesting that the
server update its A record. When sent by the server, it means that
the server has updated (or is about to update) the client's A record.
If true, this indicates that the domain name included in the option
is encoded in DNS wire format, rather than as plain ASCII text. The
client normally sets this to false if it doesn't support DNS wire
format in the FQDN option. The server should always send back the
same value that the client sent. When this value is set on the con-
figuration side, it controls the format in which the fqdn.fqdn subop-
tion is encoded.
These options specify the result of the updates of the A and PTR
records, respectively, and are only sent by the DHCP server to the
DHCP client. The values of these fields are those defined in the DNS
protocol specification.
Specifies the domain name that the client wishes to use. This can
be a fully-qualified domain name, or a single label. If there is no
trailing generally update that name in some locally-defined domain.
This option should never be set, but it can be read back using the
option and config-option operators in an expression, in which case it
returns the first label in the fqdn.fqdn suboption - for example, if
the value of fqdn.fqdn is "foo.example.com.", then fqdn.hostname will
be "foo".
This option should never be set, but it can be read back using the
option and config-option operators in an expression, in which case it
returns all labels after the first label in the fqdn.fqdn suboption -
for example, if the value of fqdn.fqdn is "foo.example.com.", then
fqdn.hostname will be "example.com.". If this suboption value is
not set, it means that an unqualified name was sent in the fqdn
option, or that no fqdn option was sent at all.
If true, the client should use the NetWare Nearest Server Query to
locate a NetWare/IP server. The behaviour of the Novell client if
this suboption is false, or is not present, is not specified.
To define a new option, you need to choose a name for it that is not in
use for some other option - for example, you can't use "host-name"
because the DHCP protocol already defines a host-name option, which is
documented earlier in this manual page. If an option name doesn't
appear in this manual page, you can use it, but it's probably a good
idea to put some kind of unique string at the beginning so you can be
sure that future options don't take your name. For example, you might
define an option, "local-host-name", feeling some confidence that no
Once you have chosen a name, you must choose a code. For site-local
options, all codes between 128 and 254 are reserved for DHCP options,
so you can pick any one of these. In practice, some vendors have
interpreted the protocol rather loosely and have used option code val-
ues greater than 128 themselves. There's no real way to avoid this
problem, but it's not likely to cause too much trouble in practice.
The values of new-name and new-code should be the name you have chosen
for the new option and the code you have chosen. The definition
should be the definition of the structure of the option.
BOOLEAN
INTEGER
The sign token should either be blank, unsigned or signed. The width
can be either 8, 16 or 32, and refers to the number of bits in the
integer. So for example, the following two lines show a definition of
the sql-connection-max option and its use:
IP-ADDRESS
TEXT
An option whose type is text will encode an ASCII text string. For
example:
DATA STRING
ENCAPSULATION
ARRAYS
Options can contain arrays of any of the above types except for the
text and data string types, which aren't currently supported in arrays.
An example of an array definition is as follows:
RECORDS
It's also possible to have options that are arrays of records, for
example:
The value of this option can be set in one of two ways. The first way
is to simply specify the data directly, using a text string or a colon-
separated list of hexadecimal values. For example:
option vendor-encapsulated-options
2:4:AC:11:41:1:
3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;
The second way of setting the value of this option is to have the DHCP
server generate a vendor-specific option buffer. To do this, you must
do four things: define an option space, define some options in that
option space, provide values for them, and specify that that option
space should be used to generate the vendor-encapsulated-options
option.
To define a new option space in which vendor options can be stored, use
the option space statement:
Once you have defined an option space and the format of some options,
you can set up scopes that define values for those options, and you can
say when to use them. For example, suppose you want to handle two
different classes of clients. Using the option space definition shown
in the previous example, you can send different option values to dif-
ferent clients based on the vendor-class-identifier option that the
clients send, as follows:
class "vendor-classes" {
match option vendor-class-identifier;
}
As you can see in the preceding example, regular scoping rules apply,
so you can define values that are global in the global scope, and only
define values that are specific to a particular class in the local
scope. The vendor-option-space declaration tells the DHCP server to
use options in the SUNW option space to construct the vendor-encapsu-
lated-options option.
SEE ALSO
dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-eval(5),
dhcpd(8), dhclient(8), RFC2132, RFC2131, draft-ietf-dhc-agent-
options-??.txt.
AUTHOR
The Internet Systems Consortium DHCP Distribution was written by Ted
Lemon under a contract with Vixie Labs. Funding for this project was
provided through Internet Systems Consortium. Information about Inter-
net Systems Consortium can be found at http://www.isc.org.
dhcpd-options(5)