15. Client Classification

15.1. Client Classification Overview

In certain cases it is useful to differentiate among different types of clients and treat them accordingly. Common reasons include:

  • The clients represent different pieces of topology, e.g. a cable modem is not the same as the clients behind that modem.
  • The clients have different behavior, e.g. a smartphone behaves differently from a laptop.
  • The clients require different values for some options, e.g. a docsis3.0 cable modem requires different settings from a docsis2.0 cable modem.

To make management easier, different clients can be grouped into a client class to receive common options.

An incoming packet can be associated with a client class in several ways:

  • Implicitly, using a vendor class option or another built-in condition.
  • Using an expression which evaluates to true.
  • Using static host reservations, a shared network, a subnet, etc.
  • Using a hook.

Client classification can be used to change the behavior of almost any part of the DHCP message processing. There are currently six mechanisms that take advantage of client classification: dropping queries, subnet selection, pool selection, definition of DHCPv4 private (codes 224-254) and code 43 options, assignment of different options, and, for DHCPv4 cable modems, the setting of specific options for use with the TFTP server address and the boot file field.

The classification process is conducted in several steps:

  1. The ALL class is associated with the incoming packet.
  2. Vendor class options are processed.
  3. Classes with matching expressions and not marked for later evaluation (“on request” or depending on the KNOWN/UNKNOWN built-in classes) are processed in the order they are defined in the configuration; the boolean expression is evaluated and, if it returns true (a match), the incoming packet is associated with the class.
  4. If a private or code 43 DHCPv4 option is received, it is decoded following its client-class or global (or, for option 43, last-resort) definition.
  5. When the incoming packet belongs to the special class DROP, it is dropped and an informational message is logged with the packet information.
  6. When the early-global-reservations-lookup global parameter is configured to true global reservations are looked for and the 8, 9 and 10 steps are partially performed: the lookup is limited to global reservations, if one is found the KNOWN class is set but if none is found the UNKNOWN class is not set.
  7. A subnet is chosen, possibly based on the class information when some subnets are reserved. More precisely: when choosing a subnet, the server iterates over all of the subnets that are feasible given the information found in the packet (client address, relay address, etc.). It uses the first subnet it finds that either has no class associated with it, or has a class which matches one of the packet’s classes.
  8. The server looks for host reservations. If an identifier from the incoming packet matches a host reservation in the subnet or shared network, the packet is associated with the KNOWN class and all classes of the host reservation. If a reservation is not found, the packet is assigned to the UNKNOWN class.
  9. Classes with matching expressions - directly, or indirectly using the KNOWN/UNKNOWN built-in classes and not marked for later evaluation (“on request”) - are processed in the order they are defined in the configuration; the boolean expression is evaluated and, if it returns true