{ "mode": "man", "parameter": "dhcp-options", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/dhcp-options/5/json", "generated": "2026-06-16T06:21:36Z", "sections": { "NAME": { "content": "dhcp-options - Dynamic Host Configuration Protocol options\n", "subsections": [] }, "DESCRIPTION": { "content": "The Dynamic Host Configuration protocol allows the client to receive options from the DHCP\nserver describing the network configuration and various services that are available on the\nnetwork. When configuring dhcpd(8) or dhclient(8) , options must often be declared. The\nsyntax for declaring options, and the names and formats of the options that can be declared,\nare documented here.\n", "subsections": [ { "name": "REFERENCE: OPTION STATEMENTS", "content": "DHCP option statements always start with the option keyword, followed by an option name, fol‐\nlowed by option data. The option names and data formats are described below. It is not nec‐\nessary to exhaustively specify all DHCP options - only those options which are needed by\nclients must be specified.\n\nOption data comes in a variety of formats, as defined below:\n\nThe ip-address data type can be entered either as an explicit IP address (e.g.,\n239.254.197.10) or as a domain name (e.g., haagen.isc.org). When entering a domain name, be\nsure that that domain name resolves to a single IP address.\n\nThe ip6-address data specifies an IPv6 address, like ::1 or 3ffe:bbbb:aaaa:aaaa::1.\n\nThe int32 data type specifies a signed 32-bit integer. The uint32 data type specifies an un‐\nsigned 32-bit integer. The int16 and uint16 data types specify signed and unsigned 16-bit\nintegers. The int8 and uint8 data types specify signed and unsigned 8-bit integers. Un‐\nsigned 8-bit integers are also sometimes referred to as octets.\n\nThe text data type specifies an NVT ASCII string, which must be enclosed in double quotes -\nfor example, to specify a root-path option, the syntax would be\n\noption root-path \"10.0.1.4:/var/tmp/rootfs\";\n\nThe domain-name data type specifies a domain name, which must not be enclosed in double\nquotes. The domain name is stored just as if it were a text option.\n\nThe domain-list data type specifies a list of domain names, enclosed in double quotes and\nseparated by commas (\"example.com\", \"foo.example.com\").\n\nThe flag data type specifies a boolean value. Booleans can be either true or false (or on or\noff, if that makes more sense to you).\n\nThe string data type specifies either an NVT ASCII string enclosed in double quotes, or a se‐\nries of octets specified in hexadecimal, separated by colons. For example:\n\noption dhcp-client-identifier \"CLIENT-FOO\";\nor\noption dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f;\n" } ] }, "SETTING OPTION VALUES USING EXPRESSIONS": { "content": "Sometimes it's helpful to be able to set the value of a DHCP option based on some value that\nthe client has sent. To do this, you can use expression evaluation. The dhcp-eval(5) manual\npage describes how to write expressions. To assign the result of an evaluation to an option,\ndefine the option as follows:\n\noption my-option = expression ;\n\nFor example:\n\noption hostname = binary-to-ascii (16, 8, \"-\",\nsubstring (hardware, 1, 6));\n", "subsections": [] }, "INCLUDING OPTION DEFINITIONS": { "content": "Starting with 4.3.0 when ISC adds new option definitions those definitions will be included\nin the code based on the definition of an argument for the RFC that defines the option in in‐\ncludes/site.h. This provides you with a method for over-riding the ISC definitions if neces‐\nsary - for example if you have previously defined the option with a different format using\nthe mechanism from DEFINING NEW OPTIONS below.\n\nBy default all of the options are enabled. In order to disable an option you would edit the\nincludes/site.h file and comment out the definition for the proper RFC.\n", "subsections": [] }, "STANDARD DHCPV4 OPTIONS": { "content": "The documentation for the various options mentioned below is taken from the latest IETF draft\ndocument on DHCP options. Options not listed below may not yet be implemented, but it is\npossible to use such options by defining them in the configuration file. Please see the\nDEFINING NEW OPTIONS heading later in this document for more information.\n\nSome of the options documented here are automatically generated by the DHCP server or by\nclients, and cannot be configured by the user. The value of such an option can be used in\nthe configuration file of the receiving DHCP protocol agent (server or client), for example\nin conditional expressions. However, the value of the option cannot be used in the configura‐\ntion file of the sending agent, because the value is determined only after the configuration\nfile has been processed. In the following documentation, such options will be shown as \"not\nuser configurable\"\n\nThe standard options are:\n\noption all-subnets-local flag;\n\nThis option specifies whether or not the client may assume that all subnets of the IP net‐\nwork to which the client is connected use the same MTU as the subnet of that network to\nwhich the client is directly connected. A value of true indicates that all subnets share\nthe same MTU. A value of false means that the client should assume that some subnets of\nthe directly connected network may have smaller MTUs.\n\noption arp-cache-timeout uint32;\n\nThis option specifies the timeout in seconds for ARP cache entries.\n\noption associated-ip ip-address [, ip-address... ];\n\nThis option is part of lease query. It is used to return all of the IP addresses associ‐\nated with a given DHCP client.\n\nThis option is not user configurable.\n\noption bcms-controller-address ip-address [, ip-address... ];\n\nThis option configures a list of IPv4 addresses for use as Broadcast and Multicast Con‐\ntroller Servers (\"BCMS\").\n\noption bcms-controller-names domain-list;\n\nThis option contains the domain names of local Broadcast and Multicast Controller Servers\n(\"BCMS\") controllers which the client may use.\n\noption bootfile-name text;\n\nThis option is used to identify a bootstrap file. If supported by the client, it should\nhave the same effect as the filename declaration. BOOTP clients are unlikely to support\nthis option. Some DHCP clients will support it, and others actually require it.\n\noption boot-size uint16;\n\nThis option specifies the length in 512-octet blocks of the default boot image for the\nclient.\n\noption broadcast-address ip-address;\n\nThis option specifies the broadcast address in use on the client's subnet. Legal values\nfor broadcast addresses are specified in section 3.2.1.3 of STD 3 (RFC1122).\n\noption capwap-ac-v4 ip-address [, ip-address ... ] ;\n\nA list of IPv4 addresses of CAPWAP ACs that the WTP may use. The addresses are listed in\npreference order.\n\nThis option is included based on RFC 5417.\n\noption client-last-transaction-time uint32;\n\nThis option is part of lease query. It allows the receiver to determine the time of the\nmost recent access by the client. The value is a duration in seconds from when the client\nlast communicated with the DHCP server.\n\nThis option is not user configurable.\n\noption cookie-servers ip-address [, ip-address... ];\n\nThe cookie server option specifies a list of RFC 865 cookie servers available to the\nclient. Servers should be listed in order of preference.\n\noption default-ip-ttl uint8;\n\nThis option specifies the default time-to-live that the client should use on outgoing data‐\ngrams.\n\noption default-tcp-ttl uint8;\n\nThis option specifies the default TTL that the client should use when sending TCP segments.\nThe minimum value is 1.\n\noption default-url string;\n\nThe format and meaning of this option is not described in any standards document, but is\nclaimed to be in use by Apple Computer. It is not known what clients may reasonably do if\nsupplied with this option. Use at your own risk.\n\noption dhcp-client-identifier string;\n\nThis option can be used to specify a DHCP client identifier in a host declaration, so that\ndhcpd can find the host record by matching against the client identifier.\n\nPlease be aware that some DHCP clients, when configured with client identifiers that are\nASCII text, will prepend a zero to the ASCII text. So you may need to write:\n\noption dhcp-client-identifier \"\\0foo\";\n\nrather than:\n\noption dhcp-client-identifier \"foo\";\n\noption dhcp-lease-time uint32;\n\nThis option is used in a client request (DHCPDISCOVER or DHCPREQUEST) to allow the client\nto request a lease time for the IP address. In a server reply (DHCPOFFER), a DHCP server\nuses this option to specify the lease time it is willing to offer.\n\nThis option is not directly user configurable in the server; refer to the max-lease-time\nand default-lease-time server options in dhcpd.conf(5).\n\noption dhcp-max-message-size uint16;\n\nThis option, when sent by the client, specifies the maximum size of any response that the\nserver sends to the client. When specified on the server, if the client did not send a\ndhcp-max-message-size option, the size specified on the server is used. This works for\nBOOTP as well as DHCP responses.\n\noption dhcp-message text;\n\nThis option is used by a DHCP server to provide an error message to a DHCP client in a\nDHCPNAK message in the event of a failure. A client may use this option in a DHCPDECLINE\nmessage to indicate why the client declined the offered parameters.\n\nThis option is not user configurable.\n\noption dhcp-message-type uint8;\n\nThis option, sent by both client and server, specifies the type of DHCP message contained\nin the DHCP packet. Possible values (taken directly from RFC2132) are:\n\n1 DHCPDISCOVER\n2 DHCPOFFER\n3 DHCPREQUEST\n4 DHCPDECLINE\n5 DHCPACK\n6 DHCPNAK\n7 DHCPRELEASE\n8 DHCPINFORM\n\nThis option is not user configurable.\n\noption dhcp-option-overload uint8;\n\nThis option is used to indicate that the DHCP ´sname´ or ´file´ fields are being overloaded\nby using them to carry DHCP options. A DHCP server inserts this option if the returned pa‐\nrameters will exceed the usual space allotted for options.\n\nIf this option is present, the client interprets the specified additional fields after it\nconcludes interpretation of the standard option fields.\n\nLegal values for this option are:\n\n1 the ´file´ field is used to hold options\n2 the ´sname´ field is used to hold options\n3 both fields are used to hold options\n\nThis option is not user configurable.\n\noption dhcp-parameter-request-list uint8 [, uint8... ];\n\nThis option, when sent by the client, specifies which options the client wishes the server\nto return. Normally, in the ISC DHCP client, this is done using the request statement. If\nthis option is not specified by the client, the DHCP server will normally return every op‐\ntion that is valid in scope and that fits into the reply. When this option is specified on\nthe server, the server returns the specified options. This can be used to force a client\nto take options that it hasn't requested, and it can also be used to tailor the response of\nthe DHCP server for clients that may need a more limited set of options than those the\nserver would normally return.\n\noption dhcp-rebinding-time uint32;\n\nThis option specifies the number of seconds from the time a client gets an address until\nthe client transitions to the REBINDING state.\n\nThis option is user configurable, but it will be ignored if the value is greater than or\nequal to the lease time.\n\nTo make DHCPv4+DHCPv6 migration easier in the future, any value configured in this option\nis also used as a DHCPv6 \"T1\" (renew) time.\n\noption dhcp-renewal-time uint32;\n\nThis option specifies the number of seconds from the time a client gets an address until\nthe client transitions to the RENEWING state.\n\nThis option is user configurable, but it will be ignored if the value is greater than or\nequal to the rebinding time, or lease time.\n\nTo make DHCPv4+DHCPv6 migration easier in the future, any value configured in this option\nis also used as a DHCPv6 \"T2\" (rebind) time.\n\noption dhcp-requested-address ip-address;\n\nThis option is used by the client in a DHCPDISCOVER to request that a particular IP address\nbe assigned.\n\nThis option is not user configurable.\n\noption dhcp-server-identifier ip-address;\n\nThis option is used in DHCPOFFER and DHCPREQUEST messages, and may optionally be included\nin the DHCPACK and DHCPNAK messages. DHCP servers include this option in the DHCPOFFER in\norder to allow the client to distinguish between lease offers. DHCP clients use the con‐\ntents of the ´server identifier´ field as the destination address for any DHCP messages\nunicast to the DHCP server. DHCP clients also indicate which of several lease offers is\nbeing accepted by including this option in a DHCPREQUEST message.\n\nThe value of this option is the IP address of the server.\n\nThis option is not directly user configurable. See the server-identifier server option in\ndhcpd.conf(5).\n\noption domain-name text;\n\nThis option specifies the domain name that client should use when resolving hostnames via\nthe Domain Name System.\n\noption domain-name-servers ip-address [, ip-address... ];\n\nThe domain-name-servers option specifies a list of Domain Name System (STD 13, RFC 1035)\nname servers available to the client. Servers should be listed in order of preference.\n\noption domain-search domain-list;\n\nThe domain-search option specifies a ´search list´ of Domain Names to be used by the client\nto locate not-fully-qualified domain names. The difference between this option and his‐\ntoric use of the domain-name option for the same ends is that this option is encoded in\nRFC1035 compressed labels on the wire. For example:\n\noption domain-search \"example.com\", \"sales.example.com\",\n\"eng.example.com\";\n\noption extensions-path text;\n\nThis option specifies the name of a file containing additional options to be interpreted\naccording to the DHCP option format as specified in RFC2132.\n\noption finger-server ip-address [, ip-address... ];\n\nThe Finger server option specifies a list of Finger servers available to the client.\nServers should be listed in order of preference.\n\noption font-servers ip-address [, ip-address... ];\n\nThis option specifies a list of X Window System Font servers available to the client.\nServers should be listed in order of preference.\n\noption geoconf-civic string;\n\nA string to hold the geoconf civic structure.\n\nThis option is included based on RFC 4776.\n\noption host-name string;\n\nThis option specifies the name of the client. The name may or may not be qualified with\nthe local domain name (it is preferable to use the domain-name option to specify the domain\nname). See RFC 1035 for character set restrictions. This option is only honored by\ndhclient-script(8) if the hostname for the client machine is not set.\n\noption ieee802-3-encapsulation flag;\n\nThis option specifies whether or not the client should use Ethernet Version 2 (RFC 894) or\nIEEE 802.3 (RFC 1042) encapsulation if the interface is an Ethernet. A value of false in‐\ndicates that the client should use RFC 894 encapsulation. A value of true means that the\nclient should use RFC 1042 encapsulation.\n\noption ien116-name-servers ip-address [, ip-address... ];\n\nThe ien116-name-servers option specifies a list of IEN 116 name servers available to the\nclient. Servers should be listed in order of preference.\n\noption impress-servers ip-address [, ip-address... ];\n\nThe impress-server option specifies a list of Imagen Impress servers available to the\nclient. Servers should be listed in order of preference.\n\noption interface-mtu uint16;\n\nThis option specifies the MTU to use on this interface. The minimum legal value for the\nMTU is 68.\n\noption ip-forwarding flag;\n\nThis option specifies whether the client should configure its IP layer for packet forward‐\ning. A value of false means disable IP forwarding, and a value of true means enable IP\nforwarding.\n\noption irc-server ip-address [, ip-address... ];\n\nThe IRC server option specifies a list of IRC servers available to the client. Servers\nshould be listed in order of preference.\n\n\noption loader-configfile text\n\nThis option is used to specify a boot loading configuration file a PXE client should use.\n\nThis option is included based on RFC 5071.\n\noption loader-pathprefix text\n\nThis option is used to specify a path prefix a PXE client should use in conjunction with\nthe boot load configuration file.\n\nThis option is included based on RFC 5071.\n\noption loader-reboottime uint32\n\nThis option is used to dictate the maximum amount of time a PXE client should allow itself\nto achieve configured network resources before rebooting.\n\nThis option is included based on RFC 5071.\n\noption log-servers ip-address [, ip-address... ];\n\nThe log-server option specifies a list of MIT-LCS UDP log servers available to the client.\nServers should be listed in order of preference.\n\noption lpr-servers ip-address [, ip-address... ];\n\nThe LPR server option specifies a list of RFC 1179 line printer servers available to the\nclient. Servers should be listed in order of preference.\n\noption mask-supplier flag;\n\nThis option specifies whether or not the client should respond to subnet mask requests us‐\ning ICMP. A value of false indicates that the client should not respond. A value of true\nmeans that the client should respond.\n\noption max-dgram-reassembly uint16;\n\nThis option specifies the maximum size datagram that the client should be prepared to re‐\nassemble. The minimum legal value is 576.\n\noption merit-dump text;\n\nThis option specifies the path-name of a file to which the client's core image should be\ndumped in the event the client crashes. The path is formatted as a character string con‐\nsisting of characters from the NVT ASCII character set.\n\noption mobile-ip-home-agent ip-address [, ip-address... ];\n\nThis option specifies a list of IP addresses indicating mobile IP home agents available to\nthe client. Agents should be listed in order of preference, although normally there will\nbe only one such agent.\n\noption name-service-search uint16 [, uint6... ];\n\nThis option specifies a list of name services in the order the client should attempt to use\nthem.\n\nThis option is included based on RFC 2937.\n\noption nds-context string;\n\nThe nds-context option specifies the name of the initial Netware Directory Service for an\nNDS client.\n\noption nds-servers ip-address [, ip-address... ];\n\nThe nds-servers option specifies a list of IP addresses of NDS servers.\n\noption nds-tree-name string;\n\nThe nds-tree-name option specifies NDS tree name that the NDS client should use.\n\noption netbios-dd-server ip-address [, ip-address... ];\n\nThe NetBIOS datagram distribution server (NBDD) option specifies a list of RFC 1001/1002\nNBDD servers listed in order of preference.\n\noption netbios-name-servers ip-address [, ip-address...];\n\nThe NetBIOS name server (NBNS) option specifies a list of RFC 1001/1002 NBNS name servers\nlisted in order of preference. NetBIOS Name Service is currently more commonly referred to\nas WINS. WINS servers can be specified using the netbios-name-servers option.\n\noption netbios-node-type uint8;\n\nThe NetBIOS node type option allows NetBIOS over TCP/IP clients which are configurable to\nbe configured as described in RFC 1001/1002. The value is specified as a single octet\nwhich identifies the client type.\n\nPossible node types are:\n\n1 B-node: Broadcast - no WINS\n\n2 P-node: Peer - WINS only\n\n4 M-node: Mixed - broadcast, then WINS\n\n8 H-node: Hybrid - WINS, then broadcast\n\noption netbios-scope string;\n\nThe NetBIOS scope option specifies the NetBIOS over TCP/IP scope parameter for the client\nas specified in RFC 1001/1002. See RFC1001, RFC1002, and RFC1035 for character-set restric‐\ntions.\n\noption netinfo-server-address ip-address [, ip-address... ];\n\nThe netinfo-server-address option has not been described in any RFC, but has been allocated\n(and is claimed to be in use) by Apple Computers. It's hard to say if the above is the\ncorrect format, or what clients might be expected to do if values were configured. Use at\nyour own risk.\n\noption netinfo-server-tag text;\n\nThe netinfo-server-tag option has not been described in any RFC, but has been allocated\n(and is claimed to be in use) by Apple Computers. It's hard to say if the above is the\ncorrect format, or what clients might be expected to do if values were configured. Use at\nyour own risk.\n\noption nis-domain text;\n\nThis option specifies the name of the client's NIS (Sun Network Information Services) do‐\nmain. The domain is formatted as a character string consisting of characters from the NVT\nASCII character set.\n\noption nis-servers ip-address [, ip-address... ];\n\nThis option specifies a list of IP addresses indicating NIS servers available to the\nclient. Servers should be listed in order of preference.\n\noption nisplus-domain text;\n\nThis option specifies the name of the client's NIS+ domain. The domain is formatted as a\ncharacter string consisting of characters from the NVT ASCII character set.\n\noption nisplus-servers ip-address [, ip-address... ];\n\nThis option specifies a list of IP addresses indicating NIS+ servers available to the\nclient. Servers should be listed in order of preference.\n\noption nntp-server ip-address [, ip-address... ];\n\nThe NNTP server option specifies a list of NNTP servers available to the client. Servers\nshould be listed in order of preference.\n\noption non-local-source-routing flag;\n\nThis option specifies whether the client should configure its IP layer to allow forwarding\nof datagrams with non-local source routes (see Section 3.3.5 of [4] for a discussion of\nthis topic). A value of false means disallow forwarding of such datagrams, and a value of\ntrue means allow forwarding.\n\noption ntp-servers ip-address [, ip-address... ];\n\nThis option specifies a list of IP addresses indicating NTP (RFC 5905) servers available to\nthe client. Servers should be listed in order of preference.\n\noption nwip-domain string;\n\nThe name of the NetWare/IP domain that a NetWare/IP client should use.\n\noption nwip-suboptions string;\n\nA sequence of suboptions for NetWare/IP clients - see RFC2242 for details. Normally this\noption is set by specifying specific NetWare/IP suboptions - see the NETWARE/IP SUBOPTIONS\nsection for more information.\n\noption pxe-system-type uint16 [, uint16 ... ];\n\nA list of one ore more 16-bit integers which allows a client to specify its pre-boot archi‐\ntecture type(s).\n\nThis option is included based on RFC 4578.\n\noption pxe-interface-id uint8 uint8 uint8\n\nA three octet value which allows a client to specify its network interface type.\n\nThis option is included based on RFC 4578.\n\noption pxe-client-id uint8 string\n\nA single octet indicating type, followed by a string that allows a client to specify its\nPXE client identity.\n\nThis option is included based on RFC 4578.\n\noption option-6rd uint8 uint8 ip6-address ip-address [, ip-address ...];\n\nThis option contains information about the rapid deployment option. It is 8 bits of ipv4\nmask length, 8 bits of 6rd prefix length, an ipv6 prefix as an ipv6 address and a list of\none or more ipv4 addresses.\n\nThis option is included based on RFC 5969.\n\noption pana-agent ip-address [, ip-address ... ] ;\n\nA set of IPv4 addresses of a PAA for the client to use. The addresses are listed in pre‐\nferred order.\n\nThis option is included based on RFC 5192.\n\noption path-mtu-aging-timeout uint32;\n\nThis option specifies the timeout (in seconds) to use when aging Path MTU values discovered\nby the mechanism defined in RFC 1191.\n\noption path-mtu-plateau-table uint16 [, uint16... ];\n\nThis option specifies a table of MTU sizes to use when performing Path MTU Discovery as de‐\nfined in RFC 1191. The table is formatted as a list of 16-bit unsigned integers, ordered\nfrom smallest to largest. The minimum MTU value cannot be smaller than 68.\n\noption pcode text;\n\nThis option specifies a string suitable for the TZ variable.\n\nThis option is included based on RFC 4833.\n\noption perform-mask-discovery flag;\n\nThis option specifies whether or not the client should perform subnet mask discovery using\nICMP. A value of false indicates that the client should not perform mask discovery. A\nvalue of true means that the client should perform mask discovery.\n\noption policy-filter ip-address ip-address\n[, ip-address ip-address...];\n\nThis option specifies policy filters for non-local source routing. The filters consist of\na list of IP addresses and masks which specify destination/mask pairs with which to filter\nincoming source routes.\n\nAny source routed datagram whose next-hop address does not match one of the filters should\nbe discarded by the client.\n\nSee STD 3 (RFC1122) for further information.\n\noption pop-server ip-address [, ip-address... ];\n\nThe POP3 server option specifies a list of POP3 servers available to the client. Servers\nshould be listed in order of preference.\n\noption rdnss-selection uint8 ip-address ip-address domain-name;\n\nThe rdnss-selection option specifies an 8 bit flags field, a primary and secondary ip ad‐\ndress for the name server and a domainlist of domains for which the RDNSS has special\nknowledge.\n\nThis option is included based on RFC 6731.\n\noption resource-location-servers ip-address\n[, ip-address...];\n\nThis option specifies a list of RFC 887 Resource Location servers available to the client.\nServers should be listed in order of preference.\n\noption root-path text;\n\nThis option specifies the path-name that contains the client's root disk. The path is for‐\nmatted as a character string consisting of characters from the NVT ASCII character set.\n\noption router-discovery flag;\n\nThis option specifies whether or not the client should solicit routers using the Router\nDiscovery mechanism defined in RFC 1256. A value of false indicates that the client should\nnot perform router discovery. A value of true means that the client should perform router\ndiscovery.\n\noption router-solicitation-address ip-address;\n\nThis option specifies the address to which the client should transmit router solicitation\nrequests.\n\noption routers ip-address [, ip-address... ];\n\nThe routers option specifies a list of IP addresses for routers on the client's subnet.\nRouters should be listed in order of preference.\n\noption slp-directory-agent boolean ip-address [, ip-address... ];\n\nThis option specifies two things: the IP addresses of one or more Service Location Protocol\nDirectory Agents, and whether the use of these addresses is mandatory. If the initial\nboolean value is true, the SLP agent should just use the IP addresses given. If the value\nis false, the SLP agent may additionally do active or passive multicast discovery of SLP\nagents (see RFC2165 for details).\n\nPlease note that in this option and the slp-service-scope option, the term \"SLP Agent\" is\nbeing used to refer to a Service Location Protocol agent running on a machine that is being\nconfigured using the DHCP protocol.\n\nAlso, please be aware that some companies may refer to SLP as NDS. If you have an NDS di‐\nrectory agent whose address you need to configure, the slp-directory-agent option should\nwork.\n\noption slp-service-scope boolean text;\n\nThe Service Location Protocol Service Scope Option specifies two things: a list of service\nscopes for SLP, and whether the use of this list is mandatory. If the initial boolean\nvalue is true, the SLP agent should only use the list of scopes provided in this option;\notherwise, it may use its own static configuration in preference to the list provided in\nthis option.\n\nThe text string should be a comma-separated list of scopes that the SLP agent should use.\nIt may be omitted, in which case the SLP Agent will use the aggregated list of scopes of\nall directory agents known to the SLP agent.\n\noption smtp-server ip-address [, ip-address... ];\n\nThe SMTP server option specifies a list of SMTP servers available to the client. Servers\nshould be listed in order of preference.\n\noption static-routes ip-address ip-address\n[, ip-address ip-address...];\n\nThis option specifies a list of static routes that the client should install in its routing\ncache. If multiple routes to the same destination are specified, they are listed in de‐\nscending order of priority.\n\nThe routes consist of a list of IP address pairs. The first address is the destination ad‐\ndress, and the second address is the router for the destination.\n\nThe default route (0.0.0.0) is an illegal destination for a static route. To specify the\ndefault route, use the routers option. Also, please note that this option is not intended\nfor classless IP routing - it does not include a subnet mask. Since classless IP routing\nis now the most widely deployed routing standard, this option is virtually useless, and is\nnot implemented by any of the popular DHCP clients, for example the Microsoft DHCP client.\n\noption streettalk-directory-assistance-server ip-address\n[, ip-address...];\n\nThe StreetTalk Directory Assistance (STDA) server option specifies a list of STDA servers\navailable to the client. Servers should be listed in order of preference.\n\noption streettalk-server ip-address [, ip-address... ];\n\nThe StreetTalk server option specifies a list of StreetTalk servers available to the\nclient. Servers should be listed in order of preference.\n\noption subnet-mask ip-address;\n\nThe subnet mask option specifies the client's subnet mask as per RFC 950. If no subnet\nmask option is provided anywhere in scope, as a last resort dhcpd will use the subnet mask\nfrom the subnet declaration for the network on which an address is being assigned. How‐\never, any subnet-mask option declaration that is in scope for the address being assigned\nwill override the subnet mask specified in the subnet declaration.\n\noption subnet-selection ip-address;\n\nSent by the client if an address is required in a subnet other than the one that would nor‐\nmally be selected (based on the relaying address of the connected subnet the request is ob‐\ntained from). See RFC3011. Note that the option number used by this server is 118; this has\nnot always been the defined number, and some clients may use a different value. Use of this\noption should be regarded as slightly experimental!\n\nThis option is not user configurable in the server.\n\noption swap-server ip-address;\n\nThis specifies the IP address of the client's swap server.\n\noption tftp-server-address ip-address [, ip-address... ];\n\nThis option configures a list of one or more IPv4 addresses of tftp servers a client may\nuse.\n\nThis option is included based on RFC 5859\n\noption tcp-keepalive-garbage flag;\n\nThis option specifies whether or not the client should send TCP keepalive messages with an\noctet of garbage for compatibility with older implementations. A value of false indicates\nthat a garbage octet should not be sent. A value of true indicates that a garbage octet\nshould be sent.\n\noption tcp-keepalive-interval uint32;\n\nThis option specifies the interval (in seconds) that the client TCP should wait before\nsending a keepalive message on a TCP connection. The time is specified as a 32-bit un‐\nsigned integer. A value of zero indicates that the client should not generate keepalive\nmessages on connections unless specifically requested by an application.\n\noption tcode text;\n\nThis option specifies a name of a zone entry in the TZ database.\n\nThis option is included based on RFC 4833.\n\noption tftp-server-name text;\n\nThis option is used to identify a TFTP server and, if supported by the client, should have\nthe same effect as the server-name declaration. BOOTP clients are unlikely to support this\noption. Some DHCP clients will support it, and others actually require it.\n\noption time-offset int32;\n\nThe time-offset option specifies the offset of the client's subnet in seconds from Coordi‐\nnated Universal Time (UTC).\n\noption time-servers ip-address [, ip-address... ];\n\nThe time-server option specifies a list of RFC 868 time servers available to the client.\nServers should be listed in order of preference.\n\noption trailer-encapsulation flag;\n\nThis option specifies whether or not the client should negotiate the use of trailers (RFC\n893 [14]) when using the ARP protocol. A value of false indicates that the client should\nnot attempt to use trailers. A value of true means that the client should attempt to use\ntrailers.\n\noption uap-servers text;\n\nThis option specifies a list of URLs, each pointing to a user authentication service that\nis capable of processing authentication requests encapsulated in the User Authentication\nProtocol (UAP). UAP servers can accept either HTTP 1.1 or SSLv3 connections. If the list\nincludes a URL that does not contain a port component, the normal default port is assumed\n(i.e., port 80 for http and port 443 for https). If the list includes a URL that does not\ncontain a path component, the path /uap is assumed. If more than one URL is specified in\nthis list, the URLs are separated by spaces.\n\noption user-class string;\n\nThis option is used by some DHCP clients as a way for users to specify identifying informa‐\ntion to the client. This can be used in a similar way to the vendor-class-identifier op‐\ntion, but the value of the option is specified by the user, not the vendor. Most recent\nDHCP clients have a way in the user interface to specify the value for this identifier,\nusually as a text string.\n\noption v4-access-domain domain-name;\n\nThe domain name associated with the access network for use with LIS Discovery.\n\nThis option is included based on RFC 5986.\n\noption v4-lost domain-name;\n\nThe domain name of the LoST server for the client to use.\n\nThis option is included based on RFC 5223.\n\noption vendor-class-identifier string;\n\nThis option is used by some DHCP clients to identify the vendor type and possibly the con‐\nfiguration of a DHCP client. The information is a string of bytes whose contents are spe‐\ncific to the vendor and are not specified in a standard. To see what vendor class identi‐\nfier clients are sending, you can write the following in your DHCP server configuration\nfile:\n\nset vendor-string = option vendor-class-identifier;\n\nThis will result in all entries in the DHCP server lease database file for clients that\nsent vendor-class-identifier options having a set statement that looks something like this:\n\nset vendor-string = \"SUNW.Ultra-510\";\n\nThe vendor-class-identifier option is normally used by the DHCP server to determine the op‐\ntions that are returned in the vendor-encapsulated-options option. Please see the VENDOR\nENCAPSULATED OPTIONS section later in this manual page for further information.\n\noption vendor-encapsulated-options string;\n\nThe vendor-encapsulated-options option can contain either a single vendor-specific value or\none or more vendor-specific suboptions. This option is not normally specified in the DHCP\nserver configuration file - instead, a vendor class is defined for each vendor, vendor\nclass suboptions are defined, values for those suboptions are defined, and the DHCP server\nmakes up a response on that basis.\n\nSome default behaviours for well-known DHCP client vendors (currently, the Microsoft Win‐\ndows 2000 DHCP client) are configured automatically, but otherwise this must be configured\nmanually - see the VENDOR ENCAPSULATED OPTIONS section later in this manual page for de‐\ntails.\n\noption vivso string;\n\nThe vivso option can contain multiple separate options, one for each 32-bit Enterprise ID.\nEach Enterprise-ID discriminated option then contains additional options whose format is\ndefined by the vendor who holds that ID. This option is usually not configured manually,\nbut rather is configured via intervening option definitions. Please also see the VENDOR\nENCAPSULATED OPTIONS section later in this manual page for details.\n\noption www-server ip-address [, ip-address... ];\n\nThe WWW server option specifies a list of WWW servers available to the client. Servers\nshould be listed in order of preference.\n\noption x-display-manager ip-address [, ip-address... ];\n\nThis option specifies a list of systems that are running the X Window System Display Man‐\nager and are available to the client. Addresses should be listed in order of preference.\n", "subsections": [] }, "RELAY AGENT INFORMATION OPTION": { "content": "An IETF draft, draft-ietf-dhc-agent-options-11.txt, defines a series of encapsulated options\nthat a relay agent can add to a DHCP packet when relaying it to the DHCP server. The server\ncan then make address allocation decisions (or whatever other decisions it wants) based on\nthese options. The server also returns these options in any replies it sends through the re‐\nlay agent, so that the relay agent can use the information in these options for delivery or\naccounting purposes.\n\nThe current draft defines two options. To reference these options in the dhcp server, spec‐\nify the option space name, \"agent\", followed by a period, followed by the option name. It is\nnot normally useful to define values for these options in the server, although it is permis‐\nsible. These options are not supported in the client.\n\noption agent.circuit-id string;\n\nThe circuit-id suboption encodes an agent-local identifier of the circuit from which a DHCP\nclient-to-server packet was received. It is intended for use by agents in relaying DHCP\nresponses back to the proper circuit. The format of this option is currently defined to be\nvendor-dependent, and will probably remain that way, although the current draft allows for\nthe possibility of standardizing the format in the future.\n\noption agent.remote-id string;\n\nThe remote-id suboption encodes information about the remote host end of a circuit. Exam‐\nples of what it might contain include caller ID information, username information, remote\nATM address, cable modem ID, and similar things. In principal, the meaning is not well-\nspecified, and it should generally be assumed to be an opaque object that is administra‐\ntively guaranteed to be unique to a particular remote end of a circuit.\n\noption agent.DOCSIS-device-class uint32;\n\nThe DOCSIS-device-class suboption is intended to convey information about the host end‐\npoint, hardware, and software, that either the host operating system or the DHCP server may\nnot otherwise be aware of (but the relay is able to distinguish). This is implemented as a\n32-bit field (4 octets), each bit representing a flag describing the host in one of these\nways. So far, only bit zero (being the least significant bit) is defined in RFC3256. If\nthis bit is set to one, the host is considered a CPE Controlled Cable Modem (CCCM). All\nother bits are reserved.\n\noption agent.link-selection ip-address;\n\nThe link-selection suboption is provided by relay agents to inform servers what subnet the\nclient is actually attached to. This is useful in those cases where the giaddr (where re‐\nsponses must be sent to the relay agent) is not on the same subnet as the client. When\nthis option is present in a packet from a relay agent, the DHCP server will use its con‐\ntents to find a subnet declared in configuration, and from here take one step further back‐\nwards to any shared-network the subnet may be defined within; the client may be given any\naddress within that shared network, as normally appropriate.\n", "subsections": [] }, "THE CLIENT FQDN SUBOPTIONS": { "content": "The Client FQDN option, currently defined in the Internet Draft draft-ietf-dhc-fqdn-op‐\ntion-00.txt is not a standard yet, but is in sufficiently wide use already that we have im‐\nplemented it. Due to the complexity of the option format, we have implemented it as a subop‐\ntion space rather than a single option. In general this option should not be configured by\nthe user - instead it should be used as part of an automatic DNS update system.\n\noption fqdn.no-client-update flag;\n\nWhen the client sends this, if it is true, it means the client will not attempt to update\nits A record. When sent by the server to the client, it means that the client should not\nupdate its own A record.\n\noption fqdn.server-update flag;\n\nWhen the client sends this to the server, it is requesting that the server update its A\nrecord. When sent by the server, it means that the server has updated (or is about to up‐\ndate) the client's A record.\n\noption fqdn.encoded flag;\n\nIf true, this indicates that the domain name included in the option is encoded in DNS wire\nformat, rather than as plain ASCII text. The client normally sets this to false if it\ndoesn't support DNS wire format in the FQDN option. The server should always send back the\nsame value that the client sent. When this value is set on the configuration side, it con‐\ntrols the format in which the fqdn.fqdn suboption is encoded.\n\noption fqdn.rcode1 flag;\n\noption fqdn.rcode2 flag;\n\nThese options specify the result of the updates of the A and PTR records, respectively, and\nare only sent by the DHCP server to the DHCP client. The values of these fields are those\ndefined in the DNS protocol specification.\n\noption fqdn.fqdn text;\n\nSpecifies the domain name that the client wishes to use. This can be a fully-qualified do‐\nmain name, or a single label. If there is no trailing ´.´ character in the name, it is not\nfully-qualified, and the server will generally update that name in some locally-defined do‐\nmain.\n\noption fqdn.hostname --never set--;\n\nThis option should never be set, but it can be read back using the option and config-option\noperators in an expression, in which case it returns the first label in the fqdn.fqdn sub‐\noption - for example, if the value of fqdn.fqdn is \"foo.example.com.\", then fqdn.hostname\nwill be \"foo\".\n\noption fqdn.domainname --never set--;\n\nThis option should never be set, but it can be read back using the option and config-option\noperators in an expression, in which case it returns all labels after the first label in\nthe fqdn.fqdn suboption - for example, if the value of fqdn.fqdn is \"foo.example.com.\",\nthen fqdn.domainname will be \"example.com.\". If this suboption value is not set, it means\nthat an unqualified name was sent in the fqdn option, or that no fqdn option was sent at\nall.\n\nIf you wish to use any of these suboptions, we strongly recommend that you refer to the\nClient FQDN option draft (or standard, when it becomes a standard) - the documentation here\nis sketchy and incomplete in comparison, and is just intended for reference by people who al‐\nready understand the Client FQDN option specification.\n", "subsections": [] }, "THE NETWARE/IP SUBOPTIONS": { "content": "RFC2242 defines a set of encapsulated options for Novell NetWare/IP clients. To use these\noptions in the dhcp server, specify the option space name, \"nwip\", followed by a period, fol‐\nlowed by the option name. The following options can be specified:\n\noption nwip.nsq-broadcast flag;\n\nIf true, the client should use the NetWare Nearest Server Query to locate a NetWare/IP\nserver. The behaviour of the Novell client if this suboption is false, or is not present,\nis not specified.\n\noption nwip.preferred-dss ip-address [, ip-address... ];\n\nThis suboption specifies a list of up to five IP addresses, each of which should be the IP\naddress of a NetWare Domain SAP/RIP server (DSS).\n\noption nwip.nearest-nwip-server ip-address\n[, ip-address...];\n\nThis suboption specifies a list of up to five IP addresses, each of which should be the IP\naddress of a Nearest NetWare IP server.\n\noption nwip.autoretries uint8;\n\nSpecifies the number of times that a NetWare/IP client should attempt to communicate with a\ngiven DSS server at startup.\n\noption nwip.autoretry-secs uint8;\n\nSpecifies the number of seconds that a Netware/IP client should wait between retries when\nattempting to establish communications with a DSS server at startup.\n\noption nwip.nwip-1-1 uint8;\n\nIf true, the NetWare/IP client should support NetWare/IP version 1.1 compatibility. This\nis only needed if the client will be contacting Netware/IP version 1.1 servers.\n\noption nwip.primary-dss ip-address;\n\nSpecifies the IP address of the Primary Domain SAP/RIP Service server (DSS) for this Net‐\nWare/IP domain. The NetWare/IP administration utility uses this value as Primary DSS\nserver when configuring a secondary DSS server.\n", "subsections": [] }, "STANDARD DHCPV6 OPTIONS": { "content": "DHCPv6 options differ from DHCPv4 options partially due to using 16-bit code and length tags,\nbut semantically zero-length options are legal in DHCPv6, and multiple options are treated\ndifferently. Whereas in DHCPv4 multiple options would be concatenated to form one option, in\nDHCPv6 they are expected to be individual instantiations. Understandably, many options are\nnot \"allowed\" to have multiple instances in a packet - normally these are options which are\ndigested by the DHCP protocol software, and not by users or applications.\n\noption dhcp6.client-id string;\n\nThis option specifies the client's DUID identifier. DUIDs are similar but different from\nDHCPv4 client identifiers - there are documented duid types:\n\nduid-llt\n\nduid-en\n\nduid-ll\n\nThis value should not be configured, but rather is provided by clients and treated as an\nopaque identifier key blob by servers.\n\noption dhcp6.server-id string;\n\nThis option specifies the server's DUID identifier. One may use this option to configure\nan opaque binary blob for your server's identifier.\n\noption dhcp6.ia-na string;\n\nThe Identity Association for Non-temporary Addresses (ia-na) carries assigned addresses\nthat are not temporary addresses for use by the DHCPv6 client. This option is produced by\nthe DHCPv6 server software, and should not be configured.\n\noption dhcp6.ia-ta string;\n\nThe Identity Association for Temporary Addresses (ia-ta) carries temporary addresses, which\nmay change upon every renewal. There is no support for this in the current DHCPv6 soft‐\nware.\n\noption dhcp6.ia-addr string;\n\nThe Identity Association Address option is encapsulated inside ia-na or ia-ta options in\norder to represent addresses associated with those IA's. These options are manufactured by\nthe software, so should not be configured.\n\noption dhcp6.oro uint16 [ , uint16, ... ];\n\nThe Option Request Option (\"ORO\") is the DHCPv6 equivalent of the parameter-request-list.\nClients supply this option to ask servers to reply with options relevant to their needs and\nuse. This option must not be directly configured, the request syntax in dhclient.conf (5)\nshould be used instead.\n\noption dhcp6.preference uint8;\n\nThe preference option informs a DHCPv6 client which server is ´preferred´ for use on a\ngiven subnet. This preference is only applied during the initial stages of configuration -\nonce a client is bound to an IA, it will remain bound to that IA until it is no longer\nvalid or has expired. This value may be configured on the server, and is digested by the\nclient software.\n\noption dhcp6.elapsed-time uint16;\n\nThe elapsed-time option is constructed by the DHCPv6 client software, and is potentially\nconsumed by intermediaries. This option should not be configured.\n\noption dhcp6.relay-msg string;\n\nThe relay-msg option is constructed by intervening DHCPv6 relay agent software. This op‐\ntion is entirely used by protocol software, and is not meant for user configuration.\n\noption dhcp6.unicast ip6-address;\n\nThe unicast option is provided by DHCPv6 servers which are willing (or prefer) to receive\nRequest, Renew, Decline, and Release packets from their clients via unicast. Normally,\nDHCPv6 clients will multicast these messages. Per RFC 3315, the server will reject a uni‐\ncast message received from a client unless it previously sent (or would have sent) the uni‐\ncast option to that client. This option may be configured on the server at the global and\nshared network level. When a unicast message is received, the server will check for an ap‐\nplicable definition of the unicast option. If such an option is found the message will be\naccepted, if not it will be rejected.\n\noption dhcp6.status-code status-code [ string ] ;\n\nThe status-code option is provided by DHCPv6 servers to inform clients of error conditions\nduring protocol communication. This option is manufactured and digested by protocol soft‐\nware, and should not be configured.\n", "subsections": [ { "name": "option dhcp6.rapid-commit ;", "content": "The rapid-commit option is a zero-length option that clients use to indicate their desire\nto enter into rapid-commit with the server.\n\noption dhcp6.vendor-opts string;\n\nThe vendor-opts option is actually an encapsulated sub-option space, in which each Vendor-\nspecific Information Option (VSIO) is identified by a 32-bit Enterprise-ID number. The en‐\ncapsulated option spaces within these options are defined by the vendors.\n\nTo make use of this option, the best way is to examine the section titled VENDOR ENCAPSU‐\nLATED OPTIONS below, in particular the bits about the \"vsio\" option space.\n\noption dhcp6.interface-id string;\n\nThe interface-id option is manufactured by relay agents, and may be used to guide configu‐\nration differentiating clients by the interface they are remotely attached to. It does not\nmake sense to configure a value for this option, but it may make sense to inspect its con‐\ntents.\n\noption dhcp6.reconf-msg dhcpv6-message;\n\nThe reconf-msg option is manufactured by servers, and sent to clients in Reconfigure mes‐\nsages to inform them of what message the client should Reconfigure using. There is no sup‐\nport for DHCPv6 Reconfigure extensions, and this option is documented informationally only.\n" }, { "name": "option dhcp6.reconf-accept ;", "content": "The reconf-accept option is included by DHCPv6 clients that support the Reconfigure exten‐\nsions, advertising that they will respond if the server were to ask them to Reconfigure.\nThere is no support for DHCPv6 Reconfigure extensions, and this option is documented infor‐\nmationally only.\n\noption dhcp6.sip-servers-names domain-list;\n\nThe sip-servers-names option allows SIP clients to locate a local SIP server that is to be\nused for all outbound SIP requests, a so-called\"outbound proxy server.\" If you wish to use\nmanually entered IPv6 addresses instead, please see the sip-servers-addresses option below.\n\noption dhcp6.sip-servers-addresses ip6-address [, ip6-address ... ] ;\n\nThe sip-servers-addresses option allows SIP clients to locate a local SIP server that is to\nbe used for all outbound SIP requests, a so-called \"outbound proxy servers.\" If you wish\nto use domain names rather than IPv6 addresses, please see the sip-servers-names option\nabove.\n\noption dhcp6.name-servers ip6-address [, ip6-address ... ] ;\n\nThe name-servers option instructs clients about locally available recursive DNS servers.\nIt is easiest to describe this as the \"nameserver\" line in /etc/resolv.conf.\n\noption dhcp6.domain-search domain-list;\n\nThe domain-search option specifies the client's domain search path to be applied to recur‐\nsive DNS queries. It is easiest to describe this as the \"search\" line in /etc/resolv.conf.\n\noption dhcp6.ia-pd string;\n\nThe ia-pd option is manufactured by clients and servers to create a Prefix Delegation bind‐\ning - to delegate an IPv6 prefix to the client. It is not directly edited in dhcpd.conf(5)\nor dhclient.conf(5), but rather is manufactured and consumed by the software.\n\noption dhcp6.ia-prefix string;\n\nThe ia-prefix option is placed inside ia-pd options in order to identify the prefix(es) al‐\nlocated to the client. It is not directly edited in dhcpd.conf(5) or dhclient.conf(5), but\nrather is manufactured and consumed by the software.\n\noption dhcp6.nis-servers ip6-address [, ip6-address ... ] ;\n\nThe nis-servers option identifies, in order, NIS servers available to the client.\n\noption dhcp6.nisp-servers ip6-address [, ip6-address ... ] ;\n\nThe nisp-servers option identifies, in order, NIS+ servers available to the client.\n\noption nis-domain-name domain-list;\n\nThe nis-domain-name option specifies the NIS domain name the client is expected to use, and\nis related to the nis-servers option.\n\noption dhcp6.nis-domain-name domain-name;\n\nThe dhcp6.nis-domain-name option specifies NIS domain name the client is expected to use,\nand is related to dhcp6.nis-servers option.\n\noption nisp-domain-name domain-list;\n\nThe nisp-domain-name option specifies the NIS+ domain name the client is expected to use,\nand is related to the nisp-servers option.\n\noption dhcp6.nisp-domain-name domain-name;\n\nThe dhcp6.nis-domain-name option specifies NIS+ domain name the client is expected to use,\nand is related to dhcp6.nisp-servers option.\n\noption dhcp6.sntp-servers ip6-address [, ip6-address ... ] ;\n\nThe sntp-servers option specifies a list of local SNTP servers available for the client to\nsynchronize their clocks.\n\noption dhcp6.info-refresh-time uint32;\n\nThe info-refresh-time option gives DHCPv6 clients using Information-request messages a hint\nas to how long they should between refreshing the information they were given. Note that\nthis option will only be delivered to the client, and be likely to affect the client's be‐\nhaviour, if the client requested the option.\n\noption dhcp6.bcms-server-d domain-list;\n\nThe bcms-server-d option contains the domain names of local BCMS (Broadcast and Multicast\nControl Services) controllers which the client may use.\n\noption dhcp6.bcms-server-a ip6-address [, ip6-address ... ] ;\n\nThe bcms-server-a option contains the IPv6 addresses of local BCMS (Broadcast and Multicast\nControl Services) controllers which the client may use.\n\noption dhcp6.geoconf-civic string;\n\nA string to hold the geoconf civic structure.\n\nThis option is included based on RFC 4776.\n\noption dhcp6.remote-id string;\n\nThe remote-id option is constructed by relay agents, to inform the server of details per‐\ntaining to what the relay knows about the client (such as what port it is attached to, and\nso forth). The contents of this option have some vendor-specific structure (similar to\nVSIO), but we have chosen to treat this option as an opaque field.\n\noption dhcp6.subscriber-id string;\n\nThe subscriber-id option is an opaque field provided by the relay agent, which provides ad‐\nditional information about the subscriber in question. The exact contents of this option\ndepend upon the vendor and/or the operator's configuration of the remote device, and as\nsuch is an opaque field.\n\noption dhcp6.fqdn string;\n\nThe fqdn option is normally constructed by the client or server, and negotiates the\nclient's Fully Qualified Domain Name, as well as which party is responsible for Dynamic DNS\nUpdates. See the section on the Client FQDN SubOptions for full details (the DHCPv4 and\nDHCPv6 FQDN options use the same \"fqdn.\" encapsulated space, so are in all ways identical).\n\noption dhcp6.pana-agent ip6-address [, ip6-address ... ] ;\n\nA set of IPv6 addresses of a PAA for the client to use. The addresses are listed in pre‐\nferred order.\n\nThis option is included based on RFC 5192.\n\noption dhcp6.new-posix-timezone text;\n\nThis option specifies a string suitable for the TZ variable.\n\nThis option is included based on RFC 4833.\n\noption dhcp6.new-tzdb-timezone text;\n\nThis option specifies a name of a zone entry in the TZ database.\n\nThis option is included based on RFC 4833.\n\noption dhcp6.ero uint16 [, uint16 ... ] ;\n\nA list of the options requested by the relay agent.\n\nThis option is included based on RFC 4994.\n\noption dhcp6.lq-query string;\n\nThe lq-query option is used internally for lease query.\n\noption dhcp6.client-data string;\n\nThe client-data option is used internally for lease query.\n\noption dhcp6.clt-time uint32;\n\nThe clt-time option is used internally for lease query.\n\noption dhcp6.lq-relay-data ip6-address string;\n\nThe lq-relay-data option is used internally for lease query.\n\noption dhcp6.lq-client-link ip6-address [, ip6-address ... ] ;\n\nThe lq-client-link option is used internally for lease query.\n\noption dhcp6.v6-lost domain-name;\n\nThe domain name of the LoST server for the client to use.\n\nThis option is included based on RFC 5223.\n\noption dhcp6.capwap-ac-v6 ip6-address [, ip6-address ... ] ;\n\nA list of IPv6 addresses of CAPWAP ACs that the WTP may use. The addresses are listed in\npreference order.\n\nThis option is included based on RFC 5417.\n\noption dhcp6.relay-id string;\n\nThe DUID for the relay agent.\n\nThis option is included based on RFC 5460.\n\noption dhcp6.v6-access-domain domain-name;\n\nThe domain name associated with the access network for use with LIS Discovery.\n\nThis option is included based on RFC5986.\n\noption dhcp6.sip-ua-cs-list domain-list;\n\nThe list of domain names in the SIP User Agent Configuration Service Domains.\n\nThis option is included based on RFC 6011.\n\noption dhcp6.bootfile-url text;\n\nThe URL for a boot file.\n\nThis option is included based on RFC 5970.\n\noption dhcp6.bootfile-param string;\n\nA string for the parameters to the bootfile. See RFC 5970 for more description of the lay‐\nout of the parameters within the string.\n\nThis option is included based on RFC 5970.\n\noption dhcp6.client-arch-type uint16 [, uint16 ... ] ;\n\nA list of one or more architecture types described as 16 bit values.\n\nThis option is included based on RFC 5970.\n\noption dhcp6.nii uint8 uint8 uint8;\n\nThe client network interface identitier option supplies information about a client's level\nof UNDI support. The values are, in order, the type, the major value and the minor value.\n\nThis option is included based on RFC5970.\n\noption dhcp6.aftr-name domain-name;\n\nA domain name of the AFTR tunnel endpoint.\n\nThis option is included based on RFC 6334.\n\noption dhcp6.erp-local-domain-name domain-name;\n\nA domain name for the ERP domain.\n\nThis option is included based on RFC 6440.\n\noption dhcp6.rdnss-selection ip6-address uint8 domain-name;\n\nRDNSS information consists of an IPv6 address of RDNSS, an 8 bit flags field and a domain-\nlist of domains for which the RDNSS has special knowledge.\n\nThis option is included based on RFC 6731.\n\noption dhcp6.client-linklayer-addr string;\n\nA client link-layer address. The first two bytes must be the type of the link-layer fol‐\nlowed by the address itself.\n\nThis option is included based on RFC 6939.\n\noption dhcp6.link-address ip6-address;\n\nAn IPv6 address used by a relay agent to indicate to the server the link on which the\nclient is located.\n\nThis option is included based on RFC 6977.\n\noption dhcp6.solmax-rt uint32;\n\nA value to override the default for SOLMAXRT. This is a 32 bit value.\n\nThis option is included based on RFC 7083.\n\noption dhcp6.inf-max-rt uint32;\n\nA value to override the default for INFMAXRT. This is a 32 bit value.\n\nThis option is included based on RFC 7083.\n" } ] }, "ACCESSING DHCPV6 RELAY OPTIONS": { "content": "v6relay (relay-number, option) This option allows access to an option that has been added to\na packet by a relay agent. Relay-number value selects the relay to examine and option is the\noption to find. In DHCPv6 each relay encapsulates the entire previous message into an op‐\ntion, adds its own options (if any) and sends the result onwards. The RFC specifies a limit\nof 32 hops. A relay-number of 0 is a no-op and means don't look at the relays. 1 is the re‐\nlay that is closest to the client, 2 would be the next in from the client and so on. Any\nvalue greater than the max number of hops is which is closest to the server independent of\nnumber. To use this option in a class statement you would have something like this:\n\nmatch if v6relay(1, option dhcp6.subscriber-id) = \"client1\";\n", "subsections": [] }, "DEFINING NEW OPTIONS": { "content": "The Internet Systems Consortium DHCP client and server provide the capability to define new\noptions. Each DHCP option has a name, a code, and a structure. The name is used by you to\nrefer to the option. The code is a number, used by the DHCP server and client to refer to an\noption. The structure describes what the contents of an option looks like.\n\nTo define a new option, you need to choose a name for it that is not in use for some other\noption - for example, you can't use \"host-name\" because the DHCP protocol already defines a\nhost-name option, which is documented earlier in this manual page. If an option name doesn't\nappear in this manual page, you can use it, but it's probably a good idea to put some kind of\nunique string at the beginning so you can be sure that future options don't take your name.\nFor example, you might define an option, \"local-host-name\", feeling some confidence that no\nofficial DHCP option name will ever start with \"local\".\n\nOnce you have chosen a name, you must choose a code. All codes between 224 and 254 are re‐\nserved as ´site-local´ DHCP options, so you can pick any one of these for your site (not for\nyour product/application). In RFC3942, site-local space was moved from starting at 128 to\nstarting at 224. In practice, some vendors have interpreted the protocol rather loosely and\nhave used option code values greater than 128 themselves. There's no real way to avoid this\nproblem, and it was thought to be unlikely to cause too much trouble in practice. If you\ncome across a vendor-documented option code in either the new or old site-local spaces,\nplease contact your vendor and inform them about rfc3942.\n\nThe structure of an option is simply the format in which the option data appears. The ISC\nDHCP server currently supports a few simple types, like integers, booleans, strings and IP\naddresses, and it also supports the ability to define arrays of single types or arrays of\nfixed sequences of types.\n\nNew options are declared as follows:\n\noption new-name code new-code = definition ;\n\nThe values of new-name and new-code should be the name you have chosen for the new option and\nthe code you have chosen. The definition should be the definition of the structure of the\noption.\n\nThe following simple option type definitions are supported:\n\nBOOLEAN\n\noption new-name code new-code = boolean ;\n\nAn option of type boolean is a flag with a value of either on or off (or true or false). So\nan example use of the boolean type would be:\n\noption use-zephyr code 180 = boolean;\noption use-zephyr on;\n\nINTEGER\n\noption new-name code new-code = sign integer width ;\n\nThe sign token should either be blank, unsigned or signed. The width can be either 8, 16 or\n32, and refers to the number of bits in the integer. So for example, the following two lines\nshow a definition of the sql-connection-max option and its use:\n\noption sql-connection-max code 192 = unsigned integer 16;\noption sql-connection-max 1536;\n\nIP-ADDRESS\n\noption new-name code new-code = ip-address ;\n\nAn option whose structure is an IP address can be expressed either as a domain name or as a\ndotted quad. So the following is an example use of the ip-address type:\n\noption sql-server-address code 193 = ip-address;\noption sql-server-address sql.example.com;\n\nIP6-ADDRESS\n\noption new-name code new-code = ip6-address ;\n\nAn option whose structure is an IPv6 address must be expressed as a valid IPv6 address. The\nfollowing is an example use of the ip6-address type:\n\noption dhcp6.some-server code 1234 = array of ip6-address;\noption dhcp6.some-server 3ffe:bbbb:aaaa:aaaa::1, 3ffe:bbbb:aaaa:aaaa::2;\n\n\nTEXT\n\noption new-name code new-code = text ;\n\nAn option whose type is text will encode an ASCII text string. For example:\n\noption sql-default-connection-name code 194 = text;\noption sql-default-connection-name \"PRODZA\";\n\n\nDATA STRING\n\noption new-name code new-code = string ;\n\nAn option whose type is a data string is essentially just a collection of bytes, and can be\nspecified either as quoted text, like the text type, or as a list of hexadecimal contents\nseparated by colons whose values must be between 0 and FF. For example:\n\noption sql-identification-token code 195 = string;\noption sql-identification-token 17:23:19:a6:42:ea:99:7c:22;\n\n\nDOMAIN-LIST\n\noption new-name code new-code = domain-list [compressed] ;\n\nAn option whose type is domain-list is an RFC1035 formatted (on the wire, \"DNS Format\") list\nof domain names, separated by root labels. The optional compressed keyword indicates if the\noption should be compressed relative to the start of the option contents (not the packet con‐\ntents).\n\nWhen in doubt, omit the compressed keyword. When the software receives an option that is\ncompressed and the compressed keyword is omitted, it will still decompress the option (rela‐\ntive to the option contents field). The keyword only controls whether or not transmitted\npackets are compressed.\n\nNote that when domain-list formatted options are output as environment variables to dhclient-\nscript(8), the standard DNS -escape mechanism is used: they are decimal. This is appropriate\nfor direct use in eg /etc/resolv.conf.\n\n\nENCAPSULATION\n\noption new-name code new-code = encapsulate identifier ;\n\nAn option whose type is encapsulate will encapsulate the contents of the option space speci‐\nfied in identifier. Examples of encapsulated options in the DHCP protocol as it currently\nexists include the vendor-encapsulated-options option, the netware-suboptions option and the\nrelay-agent-information option.\n\noption space local;\noption local.demo code 1 = text;\noption local-encapsulation code 197 = encapsulate local;\noption local.demo \"demo\";\n\n\nARRAYS\n\nOptions can contain arrays of any of the above types except for the text and data string\ntypes, which aren't currently supported in arrays. An example of an array definition is as\nfollows:\n\noption kerberos-servers code 200 = array of ip-address;\noption kerberos-servers 10.20.10.1, 10.20.11.1;\n\nRECORDS\n\nOptions can also contain data structures consisting of a sequence of data types, which is\nsometimes called a record type. For example:\n\noption contrived-001 code 201 = { boolean, integer 32, text };\noption contrived-001 on 1772 \"contrivance\";\n\nIt's also possible to have options that are arrays of records, for example:\n\noption new-static-routes code 201 = array of {\nip-address, ip-address, ip-address, integer 8 };\noption static-routes\n10.0.0.0 255.255.255.0 net-0-rtr.example.com 1,\n10.0.1.0 255.255.255.0 net-1-rtr.example.com 1,\n10.2.0.0 255.255.224.0 net-2-0-rtr.example.com 3;\n\n", "subsections": [] }, "VENDOR ENCAPSULATED OPTIONS": { "content": "The DHCP protocol defines the vendor-encapsulated-options option, which allows vendors to de‐\nfine their own options that will be sent encapsulated in a standard DHCP option. It also de‐\nfines the Vendor Identified Vendor Sub Options option (\"VIVSO\"), and the DHCPv6 protocol de‐\nfines the Vendor-specific Information Option (\"VSIO\"). The format of all of these options is\nusually internally a string of options, similarly to other normal DHCP options. The VIVSO\nand VSIO options differ in that they contain options that correspond to vendor Enterprise-ID\nnumbers (assigned by IANA), which then contain options according to each Vendor's specifica‐\ntions. You will need to refer to your vendor's documentation in order to form options to\ntheir specification.\n\nThe value of these options can be set in one of two ways. The first way is to simply specify\nthe data directly, using a text string or a colon-separated list of hexadecimal values. For\nhelp in forming these strings, please refer to RFC2132 for the DHCPv4 Vendor Specific Infor‐‐\nmation Option, RFC3925 for the DHCPv4 Vendor Identified Vendor Sub Options, or RFC3315 for\nthe DHCPv6 Vendor-specific Information Option. For example:\n\noption vendor-encapsulated-options\n2:4:\nAC:11:41:1:\n3:12:\n73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:\n4:12:\n2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;\noption vivso\n00:00:09:bf:0E:\n01:0c:\n48:65:6c:6c:6f:20:77:6f:72:6c:64:21;\noption dhcp6.vendor-opts\n00:00:09:bf:\n00:01:00:0c:\n48:65:6c:6c:6f:20:77:6f:72:6c:64:21;\n\nThe second way of setting the value of these options is to have the DHCP server generate a\nvendor-specific option buffer. To do this, you must do four things: define an option space,\ndefine some options in that option space, provide values for them, and specify that that op‐\ntion space should be used to generate the relevant option.\n\nTo define a new option space in which vendor options can be stored, use the option space\nstatement:\n\noption space name [ [ code width number ] [ length width number ] [ hash size number ] ] ;\n\nWhere the numbers following code width, length width, and hash size respectively identify the\nnumber of bytes used to describe option codes, option lengths, and the size in buckets of the\nhash tables to hold options in this space (most DHCPv4 option spaces use 1 byte codes and\nlengths, which is the default, whereas most DHCPv6 option spaces use 2 byte codes and\nlengths).\n\nThe code and length widths are used in DHCP protocol - you must configure these numbers to\nmatch the applicable option space you are configuring. They each default to 1. Valid values\nfor code widths are 1, 2 or 4. Valid values for length widths are 0, 1 or 2. Most DHCPv4\noption spaces use 1 byte codes and lengths, which is the default, whereas most DHCPv6 option\nspaces use 2 byte codes and lengths. A zero-byte length produces options similar to the\nDHCPv6 Vendor-specific Information Option - but not their contents!\n\nThe hash size defaults depend upon the code width selected, and may be 254 or 1009. Valid\nvalues range between 1 and 65535. Note that the higher you configure this value, the more\nmemory will be used. It is considered good practice to configure a value that is slightly\nlarger than the estimated number of options you plan to configure within the space. Previous\nversions of ISC DHCP (up to and including DHCP 3.0.*), this value was fixed at 9973.\n\nThe name can then be used in option definitions, as described earlier in this document. For\nexample:\n\noption space SUNW code width 1 length width 1 hash size 3;\noption SUNW.server-address code 2 = ip-address;\noption SUNW.server-name code 3 = text;\noption SUNW.root-path code 4 = text;\n\noption space ISC code width 1 length width 1 hash size 3;\noption ISC.sample code 1 = text;\noption vendor.ISC code 2495 = encapsulate vivso-sample;\noption vendor-class.ISC code 2495 = text;\n\noption ISC.sample \"configuration text here\";\noption vendor-class.ISC \"vendor class here\";\n\noption space docsis code width 2 length width 2 hash size 17;\noption docsis.tftp-servers code 32 = array of ip6-address;\noption docsis.cablelabs-configuration-file code 33 = text;\noption docsis.cablelabs-syslog-servers code 34 = array of ip6-address;\noption docsis.device-id code 36 = string;\noption docsis.time-servers code 37 = array of ip6-address;\noption docsis.time-offset code 38 = signed integer 32;\noption vsio.docsis code 4491 = encapsulate docsis;\n\nOnce you have defined an option space and the format of some options, you can set up scopes\nthat define values for those options, and you can say when to use them. For example, suppose\nyou want to handle two different classes of clients. Using the option space definition shown\nin the previous example, you can send different option values to different clients based on\nthe vendor-class-identifier option that the clients send, as follows:\n\nclass \"vendor-classes\" {\nmatch option vendor-class-identifier;\n}\n\nsubclass \"vendor-classes\" \"SUNW.Ultra-510\" {\nvendor-option-space SUNW;\noption SUNW.root-path \"/export/root/sparc\";\n}\n\nsubclass \"vendor-classes\" \"SUNW.i86pc\" {\nvendor-option-space SUNW;\noption SUNW.root-path \"/export/root/i86pc\";\n}\n\noption SUNW.server-address 172.17.65.1;\noption SUNW.server-name \"sundhcp-server17-1\";\n\noption vivso-sample.sample \"Hello world!\";\n\noption docsis.tftp-servers ::1;\n\n\nAs you can see in the preceding example, regular scoping rules apply, so you can define val‐\nues that are global in the global scope, and only define values that are specific to a par‐\nticular class in the local scope. The vendor-option-space declaration tells the DHCP server\nto use options in the SUNW option space to construct the DHCPv4 vendor-encapsulated-options\noption. This is a limitation of that option - the DHCPv4 VIVSO and the DHCPv6 VSIO options\ncan have multiple vendor definitions all at once (even transmitted to the same client), so it\nis not necessary to configure this.\n", "subsections": [] }, "SEE ALSO": { "content": "dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-eval(5), dhcpd(8), dhclient(8),\nRFC2132, RFC2131, RFC3046, RFC3315.\n", "subsections": [] }, "AUTHOR": { "content": "Information about Internet Systems Consortium can be found at https://www.isc.org.\n\n\n\ndhcp-options(5)", "subsections": [] } }, "summary": "dhcp-options - Dynamic Host Configuration Protocol options", "flags": [], "examples": [], "see_also": [ { "name": "dhcpd.conf", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/dhcpd.conf/5/json" }, { "name": "dhcpd.leases", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/dhcpd.leases/5/json" }, { "name": "dhclient.conf", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/dhclient.conf/5/json" }, { "name": "dhcp-eval", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/dhcp-eval/5/json" }, { "name": "dhcpd", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/dhcpd/8/json" }, { "name": "dhclient", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/dhclient/8/json" } ] }