DHCP Broadband Reference

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.

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.

Before installing this product you must ensure that the libgcc and firebird packages are installed. The libgcc package can be obtained from www.sunfreeware.com, 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.

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 activation@weird-solutions.com to receive a product serial number, otherwise obtain the serial number from your local support representative.

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.

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.

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:

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:

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.

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:

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.

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 255.255.255.255 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.

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

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.

Dynamic network bindings are functionally similar to Dynamic Address Bindings.

Fixed network bindings are functionally similar to Fixed Address Bindings.

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:

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.

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.

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 192.168.1.1 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.

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.

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

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:

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.