The Weird Solutions DHCP server sends data to devices using DHCP options. These options are gathered from different sources in the server, merged into a response packet, then transported to the client at the same time as the client’s IP address is delivered.
Options can be defined in:
- a pool (address pool or network pool)
- a policy
- a lease
Options that are defined in a pool are always transmitted to the device if the device is using that pool. Since a pool represents a range of addresses (often a sub-network), it’s a good idea to define options that are specific to the sub-network in the pool. The DHCPv4 default gateway is one such option.
Options that are defined in a policy can either be forcefully sent to a device using that policy (Enforced), or cherry-picked in response to the options the device requested (Not Enforced).
Defining options in a lease is considered bad form; it’s basically supported for compatibility reasons. The problem with defining options in a lease is that, if the lease is dynamic, the server could eventually delete the lease if the device is offline long enough. If this happens, the device will not receive those options if it later comes back online and gets a new lease. If your leases are fixed this will not happen.
Leases are a bad place to define options, and pools should really only contain one or two sub-network specific options. This means that the majority of the options you want to send to your devices should be defined in policies. So, how many policies should you create?
Policies are just groups of options, but you probably don’t want to provide the same group of options for both personal computers and mobile phones. Or maybe you want to provide different sets of options for Windows(R) and Linux. Either way, you will want multiple policies, with each policy holding a set of options that a device can use, but you only want some policies to be used for one kind of device, and other policies to be used for another kind of device. This is where permissions come into play.
You can make a policy belong to one or more domains. If a policy belongs to domain “Windows”, and a device belongs to that same domain, that device is allowed to use that policy.
By default, policies you create are part of the “All Devices” domain. This means that the policy will be used by every device on your network – probably not what you want, because there are already two built-in policies for this purpose, Global Enforced and Global Optional.
To set which devices should use your policy, you simply change the domains, i.e. “Permissions”, on the policy. If a device that requests service belongs to the “Windows” domain, but your policy is in the “Linux” domain, the device will not use that policy.
For more information about how devices become members of domains, see my post on Device Provisioning.