| 1 | default-lease-time | Specify the length of time in seconds to be assigned to a lease if the client requesting the lease doesn't provide a specific expiration time. This applies to both DHCPv4 and DHCPv6 leases, also referred to as the "valid lifetime" in DHCPv6. The default duration is set to 43200 seconds. | uint32 | True | True | time | Range : 0-4,294,967,295\nExample : 12345 |
| 2 | max-lease-time | Time should be the maximum length in seconds that will be assigned to a lease. If not defined, the default maximum lease time is 86400. The only exception to this is that Dynamic BOOTP lease lengths, which are not specified by the client, are not limited by this maximum. | uint32 | True | True | time | Range : 0-4,294,967,295\nExample : 12345 |
| 3 | min-lease-time | Time should be the minimum length in seconds that will be assigned to a lease. The default is the minimum of 300 seconds or max-lease-time. | uint32 | True | True | time | Range : 0-4,294,967,295\nExample : 12345 |
| 4 | dynamic-bootp-lease-cutoff | The "dynamic-bootp-lease-cutoff" DHCP parameter is used to set a time limit for dynamically allocated BOOTP leases. When configured, this parameter determines the maximum duration for BOOTP leases obtained dynamically from the DHCP server. After this specified cutoff time, BOOTP leases expire, and clients need to renew their leases or request new ones. This parameter helps in managing lease durations for BOOTP clients, ensuring efficient address allocation within the network. | uint32 | True | True | date | Range : 0-4,294,967,295\nExample : 12345 |
| 5 | dynamic-bootp-lease-length | The dynamic-bootp-lease-length DHCP parameter sets the duration, in seconds, for a dynamic BOOTP lease. This parameter influences the length of time an IP address is leased to a client that uses BOOTP to obtain its configuration. If a client doesn't request a specific lease duration, this parameter determines the default length of the lease. Adjusting this parameter allows administrators to control the lease duration for BOOTP clients in a DHCP environment. | string | True | True | length | Example : string_lease_length |
| 6 | boot-unknown-clients | If the boot-unknown-clients statement is present and has a value of false or off, then clients for which there is no host declaration will not be allowed to obtain IP addresses. If this statement is not present or has a value of true or on, then clients without host declarations will be allowed to obtain IP addresses, as long as those addresses are not restricted by allow and deny statements within their pool declarations. | control | True | True | allow unknown-clients;\ndeny unknown-clients;\nignore unknown-clients; | Example : allow unknown-clients / deny unknown-clients / ignore unknown-clients |
| 7 | dynamic-bootp | The dynamic-bootp DHCP parameter is related to the behavior of the DHCP server in handling BOOTP (Bootstrap Protocol) clients. When set to dynamic-bootp, it allows the DHCP server to dynamically allocate IP addresses to BOOTP clients, treating them similarly to DHCP clients. This parameter enables the DHCP server to respond to BOOTP requests by allocating IP addresses dynamically rather than requiring fixed or manual configurations. This flexibility is particularly useful when dealing with devices that use BOOTP but benefit from dynamic IP assignment, such as diskless workstations or embedded systems. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 8 | bootp | The bootp flag is used to tell dhcpd whether or not to respond to bootp queries. Bootp queries are allowed by default. | control | True | True | allow bootp;\ndeny bootp;\nignore bootp; | Example : allow bootp / deny bootp / ignore bootp |
| 9 | booting | The booting flag is used to tell dhcpd whether or not to respond to queries from a particular client. This keyword only has meaning when it appears in a host declaration. By default, booting is allowed, but if it is disabled for a particular client, then that client will not be able to get an address from the DHCP server. | control | True | True | allow booting;\ndeny booting;\nignore booting; | Example : allow booting / deny booting / ignore booting |
| 10 | one-lease-per-client | If this flag is enabled, whenever a client sends a DHCPREQUEST for a particular lease, the server will automatically free any other leases the client holds. This presumes that when the client sends a DHCPREQUEST, it has forgotten any lease not mentioned in the DHCPREQUEST - i.e., the client has only a single network interface and it does not remember leases it’s holding on networks to which it is not currently attached. Neither of these assumptions are guaranteed or provable, so we urge caution in the use of this statement. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 11 | get-lease-hostnames | The get-lease-hostnames statement is used to tell dhcpd whether or not to look up the domain name corresponding to the IP address of each address in the lease pool and use that address for the DHCP hostname option. If flag is true, then this lookup is done for all addresses in the current scope. By default, or if flag is false, no lookups are done. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 12 | use-host-decl-names | The use-host-decl-names DHCP parameter determines whether the DHCP server should use the host declarations' names as unique identifiers. When enabled, the server utilizes the names specified in the host declarations to identify clients. This parameter is useful for cases where host names are unique and provide an additional layer of identification, allowing for more straightforward and intuitive DHCP configuration management. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 13 | use-lease-addr-for-default-route | If the use-lease-addr-for-default-route parameter is true in a given scope, then instead of sending the value specified in the routers option (or sending no value at all), the IP address of the lease being assigned is sent to the client. This supposedly causes Win95 machines to ARP for all IP addresses, which can be helpful if your router is configured for proxy ARP. The use of this feature is not recommended, because it won’t work for many DHCP clients. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 14 | min-secs | The min-secs DHCP parameter specifies the minimum elapsed time, in seconds, that a DHCP client must wait before sending a DHCPREQUEST message. This parameter helps prevent DHCP clients from immediately renewing their lease, allowing the DHCP server sufficient time to process requests and allocate IP addresses. It contributes to the efficient and orderly operation of the DHCP protocol. | uint8 | True | True | seconds | Range : 0-255\nExample : 5 |
| 15 | filename | The filename statement can be used to specify the name of the initial boot file which is to be loaded by a client. The filename should be a filename recognizable to whatever file transfer protocol the client can be expected to use to load the file. | quoted_string | True | True | filename | Example : /tftpboot/netbsd.alphapc-diskless |
| 16 | server-name | The server-name DHCP parameter is used to specify the hostname of the DHCP server. This information is provided to DHCP clients during the lease negotiation process. Clients can use the server name for identification or informational purposes. The server-name parameter is part of DHCP option 66 and is commonly used in scenarios where clients need to know the name of the server from which they are obtaining their configuration. | quoted_string | True | True | name | Example : server_name |
| 17 | next-server | The next-server statement is used to specify the host address of the server from which the initial boot file (specified in the filename statement) is to be loaded. Server-name should be a numeric IP address or a domain name. | ipv4address | True | True | ip-address | Type : ipv4\nExample : 1.1.1.1 |
| 18 | authoritative | The authoritative statement in DHCP configuration indicates whether the server should consider configuration information for a network segment as authoritative. By default, DHCP servers assume a non-authoritative stance to avoid disruptions. For authoritative networks, include authoritative; at the top of the configuration file, allowing sending DHCPNAK messages to misconfigured clients, crucial for correct IP address acquisition during subnet changes. | flag | True | True | authoritative;\nnot authoritative; | Example : authoritative / not authoritative |
| 19 | vendor-option-space | This allows administrators to specify custom DHCP options tailored for specific vendors or devices. Each vendor-option-space can include unique configuration parameters that are applicable only to devices from a particular vendor. This parameter provides a flexible way to customize DHCP settings for diverse network environments and ensure compatibility with devices that have vendor-specific requirements. | string | True | True | string | Example : string_value |
| 20 | always-reply-rfc1048 | The always-reply-rfc1048 flag in DHCP addresses issues with BOOTP clients expecting RFC1048-style responses but deviating when sending requests. If clients are not receiving configured options, setting this flag in the client's host declaration ensures the DHCP server responds with an RFC-1048-style vendor options field, applicable at any scope level. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 21 | site-option-space | The site-option-space DHCP parameter is used to define a custom option space that can be associated with a particular site or location within a DHCP server configuration. This parameter allows network administrators to tailor and configure specific DHCP options for a defined site, enabling customized settings and parameters for devices within that location. By using site-option-space, administrators can efficiently manage and apply distinct DHCP configurations based on the requirements of different sites or geographical segments within a network. | quoted_string | True | True | name | Example : string_value |
| 22 | always-broadcast | To ensure DHCP and BOOTP clients adhere to the protocol requirements, it is necessary for them to set the broadcast bit in the flags field of the BOOTP message header. Regrettably, some clients neglect this step, risking non-receipt of responses from the DHCP server. To address this, the DHCP server can consistently broadcast its responses to clients by activating this flag for the relevant scope. These scopes can be defined within a conditional statement, as a parameter for a class, or as a parameter for a host declaration. To mitigate excessive broadcast traffic on your network, it is advisable to limit the use of this option to as few clients as possible. Notably, certain clients like the Microsoft DHCP client, OpenTransport, and ISC DHCP clients do not exhibit this issue. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 23 | ddns-domainname | The name parameter should be the domain name that will be appended to the client’s hostname to form a fully-qualified domain-name (FQDN). | quoted_string | True | True | name | Example : domainname.com |
| 24 | ddns-hostname | The name parameter should be the hostname that will be used in setting up the client’s A and PTR records. If no ddns-hostname is specified in scope, then the server will derive the hostname automatically, using an algorithm that varies for each of the different update methods. | quoted_string | True | True | name | Example : string_hostname |
| 25 | ddns-rev-domainname | The name parameter should be the domain name that will be appended to the client’s reversed IP address to produce a name for use in the client’s PTR record. By default, this is "in-addr.arpa.", but the default can be overridden here.\n\nThe reversed IP address to which this domain name is appended is always the IP address of the client, in dotted quad notation, reversed - for example, if the IP address assigned to the client is 10.17.92.74, then the reversed IP address is 74.92.17.10. So a client with that IP address would, by default, be given a PTR record of 10.17.92.74.in-addr.arpa. | quoted_string | True | True | name | Example : domainname.com |
| 26 | lease-file-name | The lease-file-name parameter in DHCP configuration specifies the file name and location where the DHCP server stores information about active leases. This file is crucial for maintaining a record of leased IP addresses, lease durations, and associated client information. Accurate management of the lease file is essential for the DHCP server to allocate and renew leases effectively. | quoted_string | True | True | name | Example : string_lease_file_name |
| 27 | pid-file-name | The pid-file-name parameter designates the file name and location where the DHCP server stores its process ID (PID). The PID file is essential for system administration, enabling easy identification and control of the DHCP server's process. It is commonly used in scripts or commands to manage the DHCP server, such as starting, stopping, or restarting the server process. | quoted_string | True | True | name | Example : string_value |
| 28 | duplicates | The "duplicates" DHCP parameter is used to control how the DHCP server handles duplicate client identifiers within the same network segment. This parameter is crucial in scenarios where multiple clients attempt to obtain IP addresses with the same client identifier, creating potential conflicts. By setting the "duplicates" parameter, administrators can determine whether the DHCP server allows or denies such duplicate client identifiers. The two main values for this parameter are "deny" (default) and "allow," each dictating the server's response to conflicting client identifiers. This parameter helps manage IP address allocation and prevent issues arising from duplicate client identifiers on the network. | control | True | True | allow duplicates;\ndeny duplicates; | Example : allow duplicates / deny duplicates |
| 29 | declines | The "declines" DHCP parameter refers to a mechanism in DHCP (Dynamic Host Configuration Protocol) where a client can inform the DHCP server that it is rejecting or declining a offered lease. When a client declines a lease, it indicates that it cannot or does not want to use the provided network configuration. This could happen, for example, if the client detects a conflict with the offered IP address. The DHCP server keeps track of declined leases, helping to manage IP address assignments and avoid potential conflicts. | control | True | True | allow declines;\ndeny declines;\nignore declines; | Example : allow declines / deny declines / ignore declines |
| 30 | ddns-updates | The ddns-updates parameter controls whether or not the server will attempt to do a DNS update when a lease is confirmed. Set this to off if the server should not attempt to do updates within a certain scope. The ddns-updates parameter is on by default. To disable DNS updates in all scopes, it is preferable to use the ddns-update-style statement, setting the style to none. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 31 | omapi-port | The omapi-port statement causes the DHCP server to listen for OMAPI connections on the specified port. This statement is required to enable the OMAPI protocol, which is used to examine and modify the state of the DHCP server as it is running. | uint16 | True | True | port | Range : 0-65535\nExample : 8000 |
| 32 | local-port | This statement causes the DHCP server to listen for DHCP requests on the UDP port specified in port, rather than on port 67. | uint16 | True | True | port | Range : 0-65535\nExample : 8000 |
| 33 | limited-broadcast-address | Specifies the limited broadcast address that the DHCP server should use when responding to DHCPINFORM messages. DHCPINFORM messages are typically used by clients to request specific configuration information without obtaining a new IP address lease. The limited broadcast address is a broadcast address that restricts the scope of the response to the local network segment, preventing unnecessary traffic propagation. This parameter helps optimize the handling of DHCPINFORM requests by ensuring that responses are directed only to the local network, improving network efficiency. | ipv4address | True | True | ip-address | Type : ipv4\nExample : 1.1.1.1 |
| 34 | remote-port | This statement causes the DHCP server to transmit DHCP responses to DHCP clients upon the UDP port specified in port, rather than on port 68. In the event that the UDP response is transmitted to a DHCP Relay, the server generally uses the local-port configuration value. Should the DHCP Relay happen to be addressed as 127.0.0.1, however, the DHCP Server transmits its response to the remote-port configuration value. This is generally only useful for testing purposes, and this configuration value should generally not be used. | uint16 | True | True | port | Range : 0-65535\nExample : 8000 |
| 35 | local-address | Used to specify the local address that the DHCP server should use for outgoing packets. It allows network administrators to set a specific source address for DHCP messages, ensuring they are sent from a designated IP address on the server. This parameter can be beneficial in multi-homed or complex network configurations where the DHCP server has multiple network interfaces, and administrators want to control the source address for DHCP communication. The local-address parameter helps in managing network traffic and ensuring DHCP messages are appropriately sourced from a specified IP address on the server. | ipv4address | True | True | ip-address | Type : ipv4\nExample : 1.1.1.1 |
| 36 | omapi-key | Used to define the key that grants access to the OMAPI (Object Management Application Programming Interface) in ISC DHCP. OMAPI is a feature that enables external applications to manage and manipulate DHCP server configuration dynamically.\n\nThis parameter involves setting up a cryptographic key, and the omapi-key specifies the key's value. The key acts as a form of authentication, allowing external applications to securely interact with the DHCP server through OMAPI. It enhances security by ensuring that only authorized entities with the correct key can make dynamic changes to the DHCP server configuration using OMAPI. | quoted_string | False | True | NaN | NaN |
| 37 | stash-agent-options | used to store DHCP options received from clients in a temporary storage, commonly known as a "stash." This feature is particularly useful when DHCP servers receive options from DHCP relay agents but need to process them later or under specific conditions. The stash-agent-options parameter allows DHCP servers to retain the received options until they are explicitly referenced or needed for further processing, enabling more flexible and controlled DHCP option handling. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 38 | ddns-ttl | The ddns-ttl DHCP parameter governs the Time-To-Live (TTL) value for Dynamic DNS (DDNS) updates. It specifies the duration for which DDNS records should be considered valid. When set, this parameter influences how long DNS servers cache and use DDNS records, ensuring timely updates and efficient management of DNS entries related to DHCP-assigned addresses. Adjusting ddns-ttl allows network administrators to control the lifespan of DDNS records in DHCP environments. | uint32 | True | True | uint32 | Range : 0-4,294,967,295\nExample : 12345 |
| 39 | ddns-update-style | The style parameter must be one of ad-hoc, interim or none. The ddns-update-style statement is only meaningful in the outer scope - it is evaluated once after reading the dhcpd.conf file, rather than each time a client is assigned an IP address, so there is no way to use different DNS update styles for different clients. The default is none. | string | True | True | style | Example : string_style |
| 40 | client-updates | The client-updates flag tells the DHCP server whether or not to honor the client’s intention to do its own update of its A record. This is only relevant when doing interim DNS updates. See the documentation under the heading THE INTERIM DNS UPDATE SCHEME for details. | control | True | True | allow client-updates;\ndeny client-updates; | Example : allow client-updates / deny client-updates |
| 41 | update-optimization | The update-optimization DHCP parameter is related to DNS updates in DHCP. It optimizes the process of updating DNS records by allowing the DHCP server to determine whether an update is necessary before attempting to update the DNS server. This parameter helps improve efficiency by reducing unnecessary DNS update traffic, ensuring that DNS records are updated only when required, and minimizing the impact on both DHCP and DNS servers. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 42 | ping-check | The ping-check DHCP parameter is used to enable or disable the DHCP server's ability to perform a ping check before allocating an IP address to a client. When enabled, the DHCP server sends an ICMP echo (ping) request to the IP address it intends to assign to the client. If the address responds, it is considered in use, and the server will not assign it to the client. This helps prevent IP address conflicts. If disabled, the server assigns the IP address without checking for its current usage. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 43 | update-static-leases | The update-static-leases DHCP parameter is a configuration option that, when enabled, allows the DHCP server to update static leases in its database dynamically. This means that if a client with a static lease configuration sends a DHCP request with a different IP address, the server will update its records to reflect the new address. This parameter is useful in scenarios where administrators want to accommodate changes in network configurations without manually adjusting static lease entries. Enabling update-static-leases ensures that static lease information remains synchronized with the actual IP addresses assigned to clients, providing greater flexibility in network management. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 44 | log-facility | The log-facility DHCP parameter determines the facility or destination where DHCP server log messages are sent. It specifies the syslog facility that will record DHCP-related events, aiding in monitoring and troubleshooting. This parameter allows administrators to customize log handling, directing DHCP logs to specific locations or systems for efficient management of DHCP server activities. | string | True | True | facility | values : auth, authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, ntp, security, syslog, user, uucp, and local0 through local7\nExample : local7 |
| 45 | do-forward-updates | The do-forward-updates DHCP parameter determines whether the DHCP server should forward DNS updates that it receives from clients. When set to "true," the server forwards these updates to the DNS server. This parameter is particularly relevant in environments where DHCP is integrated with DNS to ensure that DNS records are accurately updated when clients obtain or release IP addresses. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 46 | ping-timeout | The ping-timeout DHCP parameter determines the maximum duration the DHCP server will wait for a response to a ping before considering the IP address as available for assignment. If a client doesn't respond to the ping within the specified timeout, the DHCP server assumes the address is unused and may offer it to a requesting client. This parameter helps manage IP address allocation by setting a threshold for determining the availability of addresses based on client responsiveness to ping requests. | uint32 | True | True | seconds | Range : 0-4,294,967,295\nExample : 12345 |
| 47 | infinite-is-reserved | The infinite-is-reserved DHCP parameter is used to reserve the IP address representing infinity or unlimited time within the DHCP lease duration. By default, the concept of "infinite" in DHCP leases implies an indefinite lease time. However, certain scenarios or implementations might require reserving a specific IP address to represent infinity, and the infinite-is-reserved parameter facilitates this customization within the DHCP server configuration. When enabled, the DHCP server designates a reserved IP address to represent infinite lease times, providing flexibility in managing lease durations for specific clients or purposes. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 48 | update-conflict-detection | If the update-conflict-detection parameter is true, the server will perform standard DHCID multiple-client, one-name conflict detection. If the parameter has been set false, the server will skip this check and instead simply tear down any previous bindings to install the new binding without question. The default is true. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 49 | leasequery | The leasequery flag tells the DHCP server whether or not to answer DHCPLEASEQUERY packets. The answer to a DHCPLEASEQUERY packet includes information about a specific lease, such as when it was issued and when it will expire. By default, the server will not respond to these packets. | control | True | True | allow leasequery;\ndeny leasequery; | Example : allow leasequery / deny leasequery |
| 50 | adaptive-lease-time-threshold | When the number of allocated leases within a pool rises above the percentage specified along with this option, the DHCP server decreases the lease length for new clients within this pool to min-lease-time seconds. Clients renewing an already valid (long) leases get at least the remaining time from the current lease. Since the leases expire faster, the server may either recover more quickly or avoid pool exhaustion entirely. Once the number of allocated leases drop below the threshold, the server reverts back to normal lease times. Valid percentages are between 1 and 99. | uint8 | True | True | percentage | Range : 0-255\nExample : 5 |
| 51 | do-reverse-updates | The do-reverse-updates DHCP parameter is used to control whether the DHCP server will perform reverse DNS updates for dynamically assigned IP addresses. When this parameter is set to "true," the DHCP server will attempt to update the reverse DNS mapping (PTR record) in the DNS server corresponding to the dynamically assigned IP address. If set to "false," the DHCP server will refrain from performing reverse DNS updates. This parameter provides administrators with flexibility in managing DNS records associated with dynamically assigned addresses, allowing them to align DHCP and DNS configurations based on specific network requirements. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 52 | fqdn-reply | The fqdn-reply DHCP parameter is used to control how the DHCP server responds to Fully Qualified Domain Name (FQDN) requests from DHCP clients. When enabled, it allows the DHCP server to include the FQDN option in the DHCPACK response, providing the client with its fully qualified domain name. This parameter is particularly useful in scenarios where DHCP clients need to obtain their FQDN dynamically. The FQDN can be utilized for various network operations, including hostname resolution. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 53 | preferred-lifetime | Determines the preferred duration, in seconds, for which a client can retain a dynamically assigned IP address. This parameter is primarily associated with DHCPv6 (Dynamic Host Configuration Protocol for IPv6). During the preferred lifetime, the client is encouraged to renew its lease, and the DHCP server may extend the lease if the client requests. After the preferred lifetime elapses, the client is still able to use the assigned IP address until the lease expires, but the server may offer a different address upon renewal. The preferred-lifetime parameter helps manage IP address assignment and renewal in IPv6 networks. | uint32 | True | True | seconds | Range : 0-4,294,967,295\nExample : 12345 |
| 54 | dhcpv6-lease-file-name | The dhcpv6-lease-file-name DHCP parameter refers to the configuration setting specifying the file name used to store DHCPv6 lease information. This parameter defines the location and name of the file where the DHCP server records lease details for IPv6 addresses assigned to clients. It plays a crucial role in DHCPv6 server management, ensuring the persistence and retrieval of lease data even in the event of server restarts or failures. The specified file captures essential information about leased IPv6 addresses, aiding in the efficient allocation and tracking of address assignments within the DHCPv6 environment. | quoted_string | True | True | name | Example : string_file_name |
| 55 | dhcpv6-pid-file-name | The dhcpv6-pid-file-name DHCP parameter is used to specify the file where the DHCPv6 server process ID (PID) is stored. This file contains the unique identifier assigned to the DHCPv6 server process, facilitating monitoring, control, and management of the DHCPv6 service. This parameter allows administrators to customize the location and filename for storing the DHCPv6 server process ID information. | quoted_string | True | True | name | Example : string_file_name |
| 56 | limit-addrs-per-ia | By default, the DHCPv6 server will limit clients to one IAADDR per IA option, meaning one address. If you wish to permit clients to hang onto multiple addresses at a time, configure a larger number here.\n\nNote that there is no present method to configure the server to forcibly configure the client with one IP address per each subnet on a shared network. This is left to future work. | uint32 | True | True | number | Range : 0-4,294,967,295\nExample : 12345 |
| 57 | limit-prefs-per-ia | The limit-prefs-per-ia DHCP parameter is designed to restrict the number of preference values assigned to individual Identity Associations (IA) within DHCPv6. In DHCPv6, Identity Associations represent address assignments to clients. This parameter enables administrators to set a limit on the number of preferences (IA_Prefix and IA_NA options) a client can include in its requests. By controlling the preferences per IA, network administrators can manage address assignment policies more effectively and prevent potential misconfigurations or excessive requests from clients. | uint32 | True | True | uint32 | Range : 0-4,294,967,295\nExample : 12345 |
| 58 | delayed-ack | The delayed-ack DHCP parameter is designed to introduce a delay before sending acknowledgment (ACK) messages in response to DHCP requests.\nBy enabling delayed-ack, the DHCP server intentionally delays sending ACK messages to clients, which can help optimize network performance and reduce the potential for network congestion. | uint16 | False | True | count | NaN |
| 59 | max-ack-delay | The max-ack-delay DHCP parameter sets a maximum limit on the delay introduced by the delayed-ack feature. Admins can configure max-ack-delay to control the upper limit of the delay before ACK messages are sent. This ensures that the delay introduced by delayed-ack does not exceed a specified threshold, providing a balance between optimization and timely responses. | uint32 | False | True | microseconds | NaN |
| 78 | dhcp-cache-threshold | The dhcp-cache-threshold parameter in DHCP configuration determines the threshold at which the DHCP server starts caching information about clients. When the number of active leases exceeds this threshold, the server initiates caching, improving performance by storing client information. This parameter helps optimize DHCP server efficiency, particularly in environments with a large number of active leases. Adjusting the dhcp-cache-threshold value allows administrators to tailor caching behavior based on network dynamics and resource considerations. | uint8 | False | True | percentage | NaN |
| 79 | dont-use-fsync | The dont-use-fsync DHCP parameter is a configuration option that advises the DHCP server not to use the fsync system call when writing lease state information to disk. By default, DHCP servers often use fsync to ensure that lease information is durably stored on disk. However, using fsync can impact performance, and in some cases, administrators might choose to disable it using the dont-use-fsync parameter to optimize DHCP server performance at the cost of potential data loss in the event of a server crash or failure. | flag | False | True | flag | NaN |
| 80 | ddns-local-address4 | The ddns-local-address4 DHCP parameter is used to specify the local IPv4 address that the DHCP server should use when communicating with the Dynamic Domain Name System (DDNS) server for updates. It allows administrators to define a specific IPv4 address for the DHCP server to utilize when performing updates to the DDNS, providing flexibility in network configurations. This parameter is particularly useful when the DHCP server has multiple network interfaces, and the administrator wants to designate a specific source address for DDNS updates. | ipv4address | False | True | ip-address | NaN |
| 81 | ddns-local-address6 | The ddns-local-address6 DHCP parameter is used to specify the local IPv6 address that the DHCP server should use when sending Dynamic DNS (DDNS) updates. This parameter allows administrators to control which IPv6 address the server uses for DDNS updates, providing flexibility in network configurations. The specified IPv6 address is used as the source address for the updates sent to the DNS server, ensuring accurate and secure updates to the DNS records associated with DHCP clients. | ipv6address | False | True | ip6-address | NaN |
| 82 | ignore-client-uids | The ignore-client-uids DHCP parameter is utilized to handle situations where clients might send non-standard or inconsistent Client Identifier (UID) information. When enabled, this parameter instructs the DHCP server to disregard irregular client UIDs and focus on other identification methods. This can be useful in scenarios where clients deviate from standard UID formats, ensuring more robust and flexible DHCP service delivery. | flag | True | True | flag | values : true or false or on or off\nExample : true |
| 83 | log-threshold-low | The log-threshold-low DHCP parameter establishes a threshold for logging low-level informational messages in the DHCP server's log. When set, it determines the lower limit for messages that will be recorded, helping administrators manage the volume of log entries. Fine-tuning this parameter allows DHCP server operators to control the verbosity of log information, aiding in efficient log analysis and troubleshooting. | uint8 | False | True | percentage | NaN |
| 84 | log-threshold-high | The log-threshold-high DHCP parameter sets the threshold for high-level logging in the DHCP server. This parameter controls when the server should generate detailed log entries, helping administrators monitor and troubleshoot DHCP activity. By adjusting the log-threshold-high value, administrators can control the level of detail recorded in logs, striking a balance between comprehensive logging for diagnostic purposes and minimizing unnecessary log entries. | uint8 | False | True | percentage | NaN |
| 85 | echo-client-id | The echo-client-id DHCP parameter controls whether the DHCP server echoes back the Client Identifier (option 61) in its response. When set, the server includes the received Client Identifier in the DHCP Offer or ACK messages. If not configured, the server generates its own Client Identifier. This parameter is useful in scenarios where the client relies on a specific identifier for consistent lease management. The echo-client-id parameter provides control over whether the server echoes the client's identifier or assigns its own. | flag | False | True | flag | NaN |
| 86 | server-id-check | The server-id-check DHCP parameter is used to enforce stricter checking of DHCP server identifiers in incoming DHCP messages. When enabled, this parameter ensures that the DHCP server only responds to messages if the server identifier matches the server's own identifier. This helps enhance security by mitigating the risk of unauthorized or rogue DHCP servers on the network. The server-id-check parameter adds an extra layer of validation to DHCP communications, reducing the likelihood of unintended interactions with unauthorized DHCP servers. | flag | False | True | flag | NaN |
| 87 | prefix-length-mode | The prefix-length-mode DHCP parameter is used to define the mode for specifying prefix lengths in DHCP configurations. It allows the network administrator to choose how to specify the length of IPv6 prefixes assigned by the DHCP server. This parameter supports two modes:\n\nnon-strict: In this mode, the prefix length can be specified without adhering strictly to the standards, allowing flexibility in configuration. It provides a lenient approach to accommodate various network requirements.\n\nstrict: This mode enforces strict adherence to the standards when specifying IPv6 prefix lengths. It ensures that the configured prefix lengths align precisely with the established standards, promoting consistency and compliance with IPv6 addressing norms.\n\nNetwork administrators can choose the appropriate prefix-length-mode based on their specific needs and the desired level of adherence to IPv6 standards in their DHCP configurations. | string | False | True | mode | NaN |
| 88 | dhcpv6-set-tee-times | The "dhcpv6-set-tee-times" flag, when enabled, allows for the automatic setting of T1 and T2 timers. T1 and T2 values are derived from dhcp-renewal-time and dhcp-rebinding-time, respectively, or can be left for the client to choose with a value of zero. It's essential to note that "dhcpv6-set-tee-times" is intended as a transitional feature and may be removed in future releases. Once removed, DHCPv6 servers by default will be using configured values. | flag | False | True | flag | NaN |
| 89 | abandon-lease-time | Specifies the maximum amount of time (in seconds) that an abandoned IPv4 lease remains unavailable for assignment to a client. Abandoned leases will only be offered to clients if there are no free leases. If not defined, the default abandon lease time is 86400 seconds (24 hours). Note the abandoned lease time for a given lease is preserved across server restarts. The parameter may only be set at the global scope and is evaluated only once during server startup.\n\nValues less than sixty seconds are not recommended as this is below the ping check threshold and can cause leases once abandoned but since returned to the free state to not be pinged before being offered. If the requested time is larger than 0x7FFFFFFF - 1 or the sum of the current time plus the abandoned time isgreater than 0x7FFFFFFF it is treated as infinite. | uint32 | False | True | time | NaN |
| 90 | use-eui-64 | The use-eui-64 DHCP parameter is employed to enable or disable the generation of IPv6 addresses based on the EUI-64 format. When activated, this parameter allows DHCPv6 to construct IPv6 addresses using the Extended Unique Identifier (EUI-64) derived from the client's MAC address. This setting enhances address predictability and simplifies IPv6 address configuration. However, its use depends on network policies and security considerations, as it may expose information about the device's network interface. | flag | False | True | flag | NaN |
| 91 | check-secs-byte-order | deprecated | flag | False | True | flag | NaN |
| 92 | persist-eui-64-leases | The persist-eui-64-leases DHCP parameter is used to enable the persistence of leases based on Extended Unique Identifier (EUI-64) for IPv6 addresses. When set, this parameter ensures that DHCPv6 leases, specifically those generated using the EUI-64 mechanism, persist across server restarts. EUI-64 is a method for deriving IPv6 addresses from MAC addresses. Enabling persist-eui-64-leases helps maintain consistent addressing for devices using EUI-64 when the DHCPv6 server undergoes restarts or reboots. | flag | False | True | flag | NaN |
| 93 | ddns-dual-stack-mixed-mode | The ddns-dual-stack-mixed-mode DHCP parameter enables dual-stack operation with mixed-mode support for Dynamic Domain Name System (DDNS) updates. This parameter is relevant in environments where both IPv4 and IPv6 addresses are utilized. When enabled, it allows DHCP servers to handle DDNS updates for both IPv4 and IPv6 addresses simultaneously, ensuring compatibility and efficient management in dual-stack network configurations. | flag | False | True | flag | NaN |
| 94 | ddns-guard-id-must-match | The ddns-guard-id-must-match DHCP parameter is used to enforce consistency between the Guard ID in the DNS Update message and the client's Client Identifier (DUID-LLT or DUID-EN). This ensures that the Guard ID, a security feature in Dynamic DNS (DDNS), matches the Client Identifier, enhancing security by preventing unauthorized updates. When set, this parameter mandates that the Guard ID and Client Identifier must align, providing an additional layer of validation in DDNS updates. | flag | False | True | flag | NaN |
| 95 | ddns-other-guard-is-dynamic | The ddns-other-guard-is-dynamic DHCP parameter is used to guard against dynamic DNS (DDNS) updates from non-ISC DHCP servers. When enabled, this parameter ensures that only updates from ISC DHCP servers are accepted, preventing potential issues that might arise from updates initiated by non-ISC DHCP servers. It adds a layer of security and control to the dynamic DNS update process within a DHCP environment, promoting consistency and reliability in DNS records. | flag | False | True | flag | NaN |
| 96 | release-on-roam | deprecated | flag | False | True | flag | NaN |
| 97 | local-address6 | The local-address6 DHCP parameter allows the specification of the IPv6 address that the DHCPv6 server should use as its source address when communicating with clients. By setting this parameter, administrators can control the server's outgoing IPv6 address, influencing communication in DHCPv6 processes. It provides flexibility in network configurations and ensures proper addressing for DHCPv6 interactions. | ipv6address | False | True | ip6-address | NaN |
| 98 | bind-local-address6 | The bind-local-address6 DHCP parameter is utilized to specify the local IPv6 address that the DHCPv6 server binds to. This parameter allows network administrators to control the IPv6 address on which the DHCPv6 server listens for incoming requests. By setting the bind-local-address6 parameter in the DHCPv6 server configuration, administrators can influence the server's behavior in handling IPv6 communication. | flag | False | True | flag | NaN |
| 99 | ping-cltt-secs | Specifies the time, in seconds, that a client must remain silent before the DHCP server considers the client as unreachable or "dead." This parameter is part of the DHCP protocol's mechanism for checking the liveness of DHCP clients. If a client fails to communicate within the defined duration (specified by ping-cltt-secs), the DHCP server may assume that the client is no longer reachable and may release the associated lease. This helps manage and reclaim IP addresses in cases where clients become unresponsive or disconnected from the network. | uint32 | False | True | seconds | NaN |
| 100 | ping-timeout-ms | If the DHCP server determined it should send an ICMP echo request (a ping) because the ping-check statement is true, ping-timeout allows you to configure how many seconds the DHCP server should wait for an ICMP Echo response to be heard, if no ICMP Echo response has been received before the timeout expires, it assigns the address. If a response is heard, the lease is abandoned, and the server does not respond to the client. If no value is set, ping-timeout defaults to 1 second. | uint32 | False | True | milliseconds | NaN
|