1. Introduction

DHCP Broadband is a carrier-grade provisioning DHCP server platform for high volume next-generation public access networks. With dual multi-threaded engines supporting both IPv4 and IPv6, it has been engineered from the ground up to provide extreme reliability, performance and scalability under all network conditions.

In addition to providing a single unified model for DHCP across IPv4 and IPv6 networks, DHCP Broadband is highly flexible, with more than 20 optional plugins that extend and enhance the basic DHCP services.

1.1. Standards Compliance

DHCP Broadband is compliant with more than 40 IETF standards, as well as standards from the Cablelabs® Consortium and various other entities. This list is not exhaustive, as new standards are added regularly.

IETF Standards
  • RFC 951, Bootstrap Protocol

  • RFC 2131, Dynamic Host Configuration Protocol

  • RFC 2132, DHCP Options and BOOTP Vendor Extensions

  • RFC 2241, DHCP Optios for Novell Directory Services

  • RFC 2242, Netware/IP Domain Name and Information

  • RFC 2485, DHCP Option for the Open Group’s User Authentication

  • RFC 2563, DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients

  • RFC 2610, DHCP Options for Service Location Protocol

  • RFC 2865, Remote Authentication Dial-In User Service (RADIUS)*

  • RFC 2937, The Name Service Search Option for DHCP

  • RFC 3004, The User Class Option for DHCP

  • RFC 3011, The IPv4 Subnet Selection Option for DHCP

  • RFC 3046, DHCP Relay Agent Information Option

  • RFC 3074, DHCP Load Balancing Algorithm

  • RFC 3256, The DOCSIS® Device Class DHCP Relay Agent Information Sub-option

  • RFC 3315, Dynamic Host Configuration Protocol for IPv6

  • RFC 3361, DHCPv4 Option for SIP servers

  • RFC 3397, DHCP Domain Search Option

  • RFC 3442, The Classless Static Route Option for DHCPv4

  • RFC 3495, DHCP Option for CableLabs Client Configuration

  • RFC 3527, DHCPv4 Link Selection Suboption for the Relay Agent Information Option

  • RFC 3736, Stateless DHCP Service for IPv6

  • RFC 3825, DHCP Option for Coordinate-based Location Configuration Information

  • RFC 3925, Vendor-Identifying Vendor Options for DHCPv4

  • RFC 3993, Subscriber-ID Suboption for the DHCP Relay Agent Option

  • RFC 4014, RADIUS Suboption for the DHCP Relay Agent Information Option

  • RFC 4174, The IPv4 Option for Internet Storage Name Service

  • RFC 4243, Vendor-Specific Information Suboption for the DHCP Relay Agent Option

  • RFC 4280, DHCP Options for Broadcast and Multicast Control Servers

  • RFC 4388, DHCPv4 Leasequery

  • RFC 4578, DHCP Options for the Intel Preboot Execution Environment (PXE)

  • RFC 4649, DHCPv6 Relay Agent Remote-ID Option

  • RFC 4702, DHCPv4 Client Fully Qualified Domain Name Option

  • RFC 4704, DHCPv6 Client Fully Qualified Domain Name Option

  • RFC 4776, DHCPv4 and DHCPv6 Option for Civic Addresses Configuration Information

  • RFC 4833, Timezone Options for DHCP

  • RFC 5007, DHCPv6 Leasequery

  • RFC 5010, The DHCPv4 Relay Agent Flags Suboption

1.2. Features

  • Hardened engines withstand even the most sophisticated attacks from malicious devices

  • Provisions IP addresses, networks and DHCP options using a simple yet highly flexible domain model

  • Multi-platform architecture gives you the freedom to choose the system that best suits your needs

  • ACID transactions provide guaranteed database consistency

  • Advanced plugin architecture allows for future extensions

  • First-time devices can be automatically classified and assigned to domains of your choosing

  • Compliant with more international DHCP standards than any other server

  • Full and seamless support for IPv6

  • Runtime expression evaluation provides the ultimate in flexibility; DHCP option values can be automatically varied using almost any criteria

  • Full-featured user interface manages any number of servers

  • Flexible event publishing

  • Multi-way Dynamic DNS synchronizes host names and addresses with your DNS server(s) using a flexible model

  • Hundreds of system counters for analyzing the behavior of your network

  • Complete packet collection provides a wealth of historical information

  • Online re-configuration guarantees zero downtime

  • Easily integrates with Operational Support Systems

  • Scales to millions of leases

  • Supports clustering and load balancing

  • Choose from three query syntaxes ranging from super-simplified to full SQL 92

  • Load balancing for external network services

  • High Availability option for multiple redundant servers

  • Peer-to-peer distributed synchronization across multiple cooperating servers

1.3. Supported Platforms

  • RHEL5 x86_64

  • RHEL5 i686

  • RHEL6 x86_64

  • RHEL6 i686

  • Solaris 10 sparc

Microsoft Windows
  • Windows Server 2000/2003/2008

  • Windows XP/Vista/7

1.4. System Requirements

  • CPU: 2GHz dual-core x86_64 or i686

  • RAM: 1GB

  • DISK: 2GB

Recommended (per million leases)
  • CPU: 8+ x86_64 cores

  • RAM: 4GB

  • DISK: 20GB

1.5. Installing on Linux®

images/linux_install.png The software ships as a single tar.gz file containing RPMs for the daemon and various plugins. You may elect to install only the plugins you require for your particular deployment.

To install the packages, first untar the distribution file, then install the prerequisites, and afterwards install the services and plugins.

The daemon is registered automatically during installation, but the service is not automatically started.

Use the sysv script (/etc/init.d/dhcptd) to start the service.

1.6. Installing on Solaris®

images/cde_install.png Before installing this product you must ensure that the libgcc and firebird packages are installed. The libgcc package can be obtained from, and the firebird package is distributed with this software.

The software ships as a single tar.gz file containing Solaris package files for the daemon and various plugins. You may elect to install only the plugins you require for your particular deployment.

To install the packages, first untar the distribution file. Then install the prerequisites, and afterwards install the service and plugins using the pkgadd command.

You may want to create a startup script to launch the daemon (dhcptd) each time the machine is started.

1.7. Installing on Windows®


1.7.1. If you received a CD

Insert the CD into the drive. The installation should start automatically. Alternatively, run SETUP.EXE to begin installation.

1.7.2. If you received the software electronically

The DHCP Broadband software package is transmitted as a single file. Copy this file to a temporary directory on your hard drive, then double-click the file to start the installation process. Setup allows you to specify Full or Custom installations. If this is your first time installing the DHCP Broadband package you’ll want to choose a Full install.

After selecting the installation directory and program group, the setup program copies the necessary files to your hard disk and registers the services. Once this is complete you should configure the software by clicking theDHCP Broadband icon on your desktop.

1.8. Uninstalling the software

1.8.1. Linux

Use the distribution specific add/remove software utility or open a super-user terminal window and use rpm -e to remove each of the packages.

1.8.2. Solaris

Open a su terminal and use pkgrm to remove each of the packages.

1.8.3. Windows

Click the uninstall icon in the DHCP Broadband program group, or, alternately, use the Control Panel’s Add/Remove Programs applet.

1.9. Registering your product

When you first start the user interface, DHCP Broadband will ask you to activate your product. If you are deploying the product yourself, mail your activation code to to receive a product serial number, otherwise obtain the serial number from your local support representative.

2. DHCP Reference

2.1. Login

To log into the system, open the user interface and double-click the "localhost" server in the upper left. If this is a first-time installation, the user name is admin, and the password is admin.


After login, you are presented with the main interface for managing your DHCP server. This interface can be used to add and remove address pools, device accounts, option policies, users, and much more.


When you first connect to the DHCP server you are asked to register the software. Registration creates a unique id for your installation and offers to register the software with Weird Solutions. Registration is completely optional and can be completed at any time prior to purchasing the software.

After registration is complete, you are presented with a one-time system configuration screen. This configuration screen will create some basic rules for your DHCP server, allowing it to classify all of the devices on your network as they receive IP addresses.

Note If you are installing a failover backup server, skip the configuration screen.

2.2. Basic Configuration

Basic configuration of your DHCP server is straightforward. You must define one or more address pools from which the DHCP server will assign IP address leases.

2.3. Address Pools

An address pool specifies a range of addresses that the server can lease to your devices. This is the primary means of automatically managing the IP addresses on your network.

To create an address pool, choose File→New→Address Pool in the user interface.


The fields for an address pool are:

Field Description


The name of this address pool. Must be unique for all address pools in this DHCP context.


If this pool is for DHCP clients on the same network segment as the DHCP server, enter a value of If this pool is for clients on a remote network segment, enter the IP address of the interface on the relay agent that’s closest to the client. Specify multiple relay agent addresses by separating them with a comma.

Range start

The first IP address in the range of addresses to be leased.

Range stop

The last IP address in the range of addresses to be leased.


The network number on which the IP address range resides, e.g. is the network for address

Prefix length

The number of significant bits in the prefix part of the network. 8, 16 and 24 are common prefix lengths.

Valid lifetime

The total amount of time, in seconds, that an address from this range can be leased. Leases that have been inactive for this amount of time are considered abandoned.

Preferred lifetime

The amount of time, in seconds, before an address leased from this pool must have the lease extended.


A DHCP client may be able to pick from multiple pools for a specific network segment. Setting the pool weight allows you to induce the server to prefer some pools over others. Use a higher number to give the pool preference over other available pools. The default weight is 0.


This field lists addresses within the pool range that should not be leased.


A comma-delimited list of policies to be used for every device that receives an address from this pool

For each pool there is also a pool-specific policy that can hold configuration information specific to the network on which this pool resides. The most common use of the pool-specific policy is to define the Gateways option (default gateway).

When a DHCP client on your network requests an address from the DHCP server, the server chooses a pool using a four stage process of reduction:

  1. Find the relay agent address the client is booting through and search for all pools associated with that address.

  2. Using the security access token assigned by the provisioner subsystem, discard pools the client doesn’t have authorization for.

  3. Check the Allow and Deny expressions for each pool. Discard pools that are disallowed by these expressions.

  4. Of the remaining pools, choose the one with the highest weight that still has available addresses.

If a pool belongs to the All devices domain (the default), step 2 will not discard the pool. By moving the pool from the All devices domain to a more restricted domain you can effectively allow or deny access to the pool based on the domains to which the DHCP client belongs.

Note By default, new pools belong to the All devices domain. This ensures that, unless you specify otherwise, pools you create are available to all DHCP clients on your network.

2.4. Dynamic Address Bindings

Dynamic address bindings are automatically created by the DHCP server using the information provided from your address pools. A dynamic address binding is a DHCP lease that allots an IP address to a specific device for a certain amount of time.

A dynamic address binding contains these fields:

Field Description
Client identifier The unique device identifier
Fixed This setting is false for dynamic bindings
IP address The leased address
Commit time The time at which this lease was last obtained or extended
Duration The length of time this lease is valid
Relay The relay agent the client booted through
Protocol The specific protocol the client used to obtain this address lease
Pool The name of the address pool used to create this lease
Trusted ID An identifier for the device or circuit provided by the relay agent
Trusted ID type The type of trusted identifier provided by the relay agent

The DHCP server automatically associates dynamic address bindings with one or more domains. If a device is able to obtain a lease from an address pool, it will be able to extend that lease as long as it still has access to the pool.

Tip To "take away" a lease from a device, locate the lease, then under Permissions remove all domains from the lease. This ensures that the lease cannot be renewed, but the original contract time is still honored. Eventually the lease will expire and the IP address will be available for re-use.

2.5. Fixed Address Bindings

A fixed address binding is a specific kind of DHCP lease that guarantees that the recorded IP address will always be associated with the device named in the lease. Once a fixed address binding is made, the DHCP server will never use the binding’s address with another client until you delete the binding or convert it to a dynamic binding.

You can create fixed address bindings manually or you can convert a dynamic binding to a fixed binding. To convert a dynamic binding to fixed, simply change the Fixed field in the binding to true.

When creating a fixed address binding you must specify the relay agent address to be associated with the binding. You can create different bindings for the same device on different network segments by specifying different relay addresses.

For DHCP over IPv4 (DHCPv4), creating fixed address bindings with the relay agent set to instructs the server to assume that the device is always on segment. This is legacy behavior; new bindings should specify the relay address associated with the subnet for the IP address to be leased.

Tip It’s possible to create Unbound bindings, i.e. bindings with no associated client identifier. In this case, the server automatically populates the binding’s client identifier field the first time the binding is selected for use by any elegible device.
Note A fixed address binding is not required to be associated with any address pool. It is a perfectly acceptable configuration to create fixed bindings without having any address pools.

When creating a fixed address binding from the command line interface, the following fields are not required:

  • Commit time

  • Protocol

  • Pool

  • Trusted ID

  • Trusted ID type

2.6. Prefix Pools (Prefix Delegation)

From the standpoint of configuring DHCP, the IPv6 term prefix is essentially interchangeable with the IPv4 term subnet. (For a description of the difference, refer to RFC 5942.)

DHCP for IPv6 (DHCPv6) allows a DHCP client to request a lease for an entire prefix. When a DHCP server issues a lease for a prefix, this is called Prefix Delegation. The server is effectively delegating all address in the prefix to the DHCP client for however long the prefix lease is valid.

Residential gateways that support IPv6 will typically request one IPv6 address for their public-facing network interface and one IPv6 prefix for their private-facing network interface. This allows the gateway to issue its own leases to the devices that are connecting through the gateway.

When the lease for a delegated prefix expires, the prefix and all associated IP addresses within that prefix are returned to the DHCP server.

Prefix pools are functionally similar to Address Pools. The main difference with prefix pools is that once you’ve defined the number of bits in your prefix, you must then define the number of bits to use when splitting that prefix into smaller prefixes.

Once a prefix pool is defined, the server splits the prefix into sub-prefixes and proceeds to lease the sub-prefixes to the devices on your network that request a delegated prefix.

2.7. Dynamic Network Bindings

Dynamic network bindings are functionally similar to Dynamic Address Bindings.

2.8. Fixed Network Bindings

Fixed network bindings are functionally similar to Fixed Address Bindings.

2.9. Policies

After defining your pools, you may want to define one or more policies to be associated with the different kinds of devices on your network.

A DHCP policy, which is simply a collection of DHCP options, is the primary means for giving a device extra configuration settings. A policy can hold any number of DHCP options, and any number of policies can be applied to a given device. There are two basic kinds of policies: Enforced and Optional.


When a DHCP client device contacts the server, the provisioner module determines the domains the device belongs to, and the DHCP engine uses this information to locate all policies for the device.

For every enforced policy applicable to the device, the DHCP server provides the device with every option in all enforced policies.

Devices are only provided with options from optional policies when the device explicitly requests values for those options.

Every domain you create with the web-based interface has one enforced policy and one optional policy. Having these two policies associated with the domain creates a set of common response options for devices using this domain, with certain options only provided when asked for.

For example, suppose you do the following:

  • Create a domain named Cablemodems

  • Insert option 4, Time servers into the domain’s enforced policy and set an appropriate value

  • Insert option 6, Domain name servers into the domain’s optional policy and set an appropriate value

With this configuration, every will be given the Time servers option, but only cable modems that request the Domain name servers option will receive that information.

Since policies are associated with domains, it’s straightforward to cause a device to receive one set of options or another by moving the device account between domains.

2.10. DHCP Options

DHCP options are operational settings that the DHCP server can distribute to devices on your network. The system is pre-configured with a wide array of IETF-standard DHCP options, as well as a set of Control Options that can alter the DHCP server’s runtime behavior. In addition, the system allows you to define your own site-specific options.

DHCP options are defined in a policy, address pool or prefix pool.

Because policies belong to domains, it’s easy to provision a set of DHCP options to a device: simply associate the device account with the domains that contain the policies the device should use.

Suppose you have two geographical domains, Charlotte and Atlanta, and the policies belonging to these domains specify different DHCP option values. A device that belongs to the Charlotte domain would receive a different set of DHCP options than a device that belongs to the Atlanta domain.

Of course, a network device may belong to as many domains as you require, so you are free to mix and match domains to suit your provisioning model. Having Class-of-Service domains combined with geographical domains is one approach.

Assigning a device to a domain isn’t the only way to provision DHCP options. Each option has an associated value, and that value can be a literal, such as or it can be an expression that’s dynamically calculated based on criteria you choose. For example, the "TFTP server" option could be calculated as:$RELAY.ADDRESS() + 1. This expression simply assumes that the address of a client’s closest TFTP server is the next address in sequence after the relay agent’s address.

2.10.1. Server Control Options

The DHCP server recognizes a set of Control Options that are not standard DHCP options. These options can be used to control various aspects of the DHCP server’s behavior. Control Options are never transmitted to a device.

To define a Control Option in a policy or pool, select the Server Control class of options, then add the option you require.

Control Options can be defined in any resource that accepts standard DHCP options. If a device on your network uses a policy or pool that contains a Control Option, the DHCP server will alter its behavior for that device according to the option setting.

For Example

The Control Option DDNS update server can be used to specify that a dynamic DNS update be directed to a specific DNS server on your network. If this option is defined in a policy, devices that use the policy will have their DNS updates sent to the DNS server defined in this option. Devices not using this policy will have their DNS updates sent to the system default DNS server.

2.10.2. Vendor-specific options

Vendor-specific options are a special class of DHCP options that are specific to a particular kind of device, model or vendor. The system supports a range of vendor-specific options, and new options can be easily added.

For DHCPv4, you can add a vendor-specific option to a policy by first adding the Class Identifier option and setting its value to anything that matches the vendor class. You can then add vendor-specific options to the policy.

When using vendor-specific options in DHCPv4, only one class of vendor-specific options can be added to any given policy. The system does not support adding vendor-specific options from different vendors to a single DHCPv4 policy.

For DHCPv6, you can add a vendor-specific option to any policy you deem appropriate. Multiple kinds of vendor-specific options can be added to a single policy, but a device will only receive the vendor-specific options that it is capable of understanding.

2.11. Option Types

Option types are declarations of DHCP options. They are not actual options, merely descriptions of options the server should be prepared to encounter. Option types specify a full range of details for DHCP options, including the tag number, data type, value limits, etc.


For every DHCP option the server receives there should be a corresponding Option Type that describes the option. If the DHCP server receives a packet that contains an unknown option, processing for that option is skipped.

Option types are quite complex because they describe in detail the complete characteristics of DHCP options. The fields of an option type are described below, with descriptions for each field.

Field Description
tagpath The option’s unique tag. For many options this may simply be a number, but for options that must be encoded inside other options this will be a path of option tags such as 43/1.
type One of the predefined option type names. Type names are listed in the table below.
name The official name of the option
class An arbitrary name for grouping similar options
description A human-readable description for this option
user_definable Whether or not a user can set a value for this option. Can be allowed, disallowed or required.
max_instances An integer specifying the maximum number of instances of this option that can be defined. 0 means unlimited. Default is 1.
default_value A string representing the default value for this option, if there is one. The default value is used by the user interface when presenting the operator with a suggested value for this option.
arrayed A boolean value indicating whether or not more than one element can exist in the option. The default is false.
unit A string representing the unit of measurement for this option value. This text is displayed for operators when editing option values.
signed A boolean value for numeric types that indicates whether or not the elements are signed. The default is false.
null_terminated A boolean value for string types indicating whether or not to use a null terminator on binary output. The default is false.
min_value An integer value for numeric types that specifies the minimum allowed value this option may hold.
max_value An integer value for numeric types that specifies the maximum allowed value this option may hold.
input_type_encoding_value An integer specifying whether this option has a type field. This input setting is used when reading the option from raw binary format. If this value is -1 (the default), this option does not have a type-encoding field. A value of 0 or greater indicates that this option a specific type encoding, and the specified value denotes the type. Type encodings are option-specific.
output_type_encoding_value An integer specifying whether this option has a type field. This output setting is used when writing the option to raw binary format. If this value is -1 (the default), this option does not have a type-encoding field. A value of 0 or greater indicates that this option a specific type encoding, and the specified value denotes the type. Type encodings are option-specific.
fixed_offsets This field is for fixed_offset type options only. It specifies a set of offsets where each contained tag should be found. The format is tag/offset/width (where width is in bytes), and multiple offsets are separated with a comma.
vendor_id An integer representing the IANA-registered vendor ID. When non-zero, this number indicates to any subencoded options that their metadata is specific to this vendor. The default value is 0, which indicates that any subencoded options are not vendor-specific.
vendor_oro A boolean value indicating whether this option defines a vendor-specific option-request-option (ORO). A vendor-specific ORO is used by a DHCP client to request a specific set of options from a DHCP server.
context_vendor_id This option is used to indicate to the DHCP server that another option in the packet currently being processed holds information about the vendor identifier that should be used when reading suboptions of this option.
len_prefix_width An integer that specifies whether each element in this option should be preceeded with a length field of this size (in bytes). The default value of 0 indicates that option elements are not length prefixed.
subtag_width An integer value for options that hold options which specifies the width of the tag field for suboptions. The default value is the same as the DHCP protocol being used.
sublen_width An integer value for options that hold options which specifies the width of the len field for suboptions. The default value is the same as the DHCP protocol being used.
subtype_width An integer value for options that hold options which specifies the width of the type field for suboptions that are type-encoded. The default value is the same as the DHCP protocol being used.

An option may be declared as one of the following types:

Name Description
8bit An 8 bit integer value
16bit A 16 bit integer value
24bit A 24 bit integer value
32bit A 32 bit integer value
64bit A 64 bit integer value
128bit A 128 bit integer value
string An ASCII string
ipaddress An ip address
ip_endpoint An ip endpoint (ip:port)
boolean An 8 bit boolean value
time A 32 bit time value
byte_sequence A sequence of arbitrary bytes
subencoded An option that can hold child options
topencoded An option that can hold top-level options
dnsname An RFC 1035 DNS name
expression An expression that evaluates to a value at runtime
control A DHCP protocol-control option
fixed_offset An option that holds child options that are not tag/len/data encoded
varbind An snmp variable binding. This may also be written as snmp_oid.

2.12. Vendor Classes

Vendor classes are a convenient way of organizing the different kinds of devices that may appear on your network.

DHCP packets typically contain information that describes the kind of device communicating with the server. Instead of writing an expression to fully analyze all possible combinations of a DHCP packet, you can call the $DEVICE.TYPEID() function. This function returns a number that indicates the exact type of device communicating with the server.

The $DEVICE.TYPEID() function uses vendor classes to determine the type of device that is requesting DHCP service.


The DHCP server package ships with vendor-specific definitions for a few common devices, but more vendor classes can be added at any time.

A vendor class object (and the corresponding definition file) contains these fields:

Field Description
vendor_id A numeric path, where the first element is the IANA-assigned enterprise identifier
for this vendor, followed by one or more numbers (assigned by Weird Solutions) that represent
this specific device model.
vendor_class A string that is used to match the vendor class received from the client (DHCPv4 option 60 or
DHCPv6 option 16/2). For example, if a client sends a vendor class with the text "kazoo", and
there is a vendor class matching this text, the device is assumed to be manufactured by that
vendor_name The full name of the vendor that manufactures this equipment. Used for display purposes when
viewing network devices.
description A description for this vendor. Used for display purposes.

2.12.1. Choosing a vendor_class value

The vendor_class field is the most important part of a DHCPv4 vendor class definition. This is because the text in this field determines how the server identifies the device, and consequently determines whether or not the server is capable of reading device-specific options (option 43 suboptions).

Wildcards can be used to match text in the vendor class field, but you should take care not to make the wildcards match too loosely. For example, if one kind of device sends a vendor class of "kazoo" and another kind of device sends "kazam", having a wildcard entry for kazoo with the text "ka*" would inadvertently match two kinds of devices to one vendor.

You can use the asterisk (*) and question mark (?) characters for wildcard matching. Asterisk matches multiple characters, whereas the question mark matches one character only.

2.12.2. IANA Enterprise Identifiers

IANA enterprise identifiers (EIDs) are unique numbers that are assigned to organizations worldwide by the Internet Assigned Numbers Authority. The IANA website is

The DHCP protocol uses IANA enterprise identifiers to represent specific vendor options. The DHCP server adds further qualifiers to IANA enterprise numbers to denote specific kinds of devices from a single manufacturer. These qualifiers have the form EID/subid.

2.12.3. How vendor classes relate to options

Some subencoded options such as DHCPv4 option 43 and DHCPv6 option 17 can contain suboptions that are specific to a particular vendor. When the server receives a packet that contains option 43, for example, it must be able to figure out which vendor’s options are encoded in the payload.

The server does this by simultaneously holding information about many vendor’s options. Vendor’s options are defined in the files found in the oinc4 and oinc6 directories.

When a vendor-specific option (VSO) such as DHCPv4 option 43 is encountered, the server decides what vendor class the device belongs to by matching the option 60 value against a vendor class record, and then looking for vendor-specific options having that vendor identifier. For DHCPv6, the vendor identifier is encoded directly in the VSO option, so the vendor can be immediately identified without an intermediate lookup.

For example, it’s entirely reasonable to declare two options having tagpath 43/1: one option having vendor id 28551, the other having vendor id 35/1. When parsing a received packet, the server will decide which option declaration is appropriate based on the vendor id it used to classify this device.

2.13. Historical packets

The DHCP server can be configured to store historical DHCP packets. The data contained in these stored packets can be used in response to lease queries, by the GUI (for displaying additional device information) or by an expression that computes a current value based on historical information.