DHCPv6 containers

Edit online

When the DHCP server receives a request, the packet is parsed and identifying keys determine which containers, options, and addresses are extracted.

Each type of container uses a different option to identify a client:
  • The subnet container uses the hintlist field or the interface address of the receiving interface to determine from which subnet the client belongs.
  • The class container uses the value in option 15 (OPTION_USER_CLASS Identifier).
  • The vendor uses the value in option 16 (OPTION_VENDOR_CLASS).
  • The client container uses the option 1 (OPTION_CLIENTID) from the DHCP client's DUID.
  • The inoption container matches the client's requested option.

Except for subnets, each container allows the specification of the value that matches it, including regular expression matching.

There is also an implicit container, the global container. Options and modifiers are placed in the global container unless overridden or denied. Most containers can be placed inside other containers implying a scope of visibility. Containers may or may not have address ranges associated with them. Subnets, by their nature, have ranges associated with them.

The basic rules for containers and subcontainers are:
  • Only subnet containers are valid at the global level.
  • Subnets cannot be placed inside other containers, including itself.
  • Restricted containers cannot have regular containers of the same type within them. (For example, a container with an option that only allows a class of Accounting cannot include a container with an option that allows all classes that start with the letter a.)
  • Restricted client containers cannot have subcontainers.
  • Inoption containers cannot have subcontainers

Given the above rules, you can generate a hierarchy of containers that segment your options into groups for specific clients or sets of clients.

If a client matches multiple containers, The DHCP server passes the request to the database, and a container list is generated. The list is presented in order of depth and priority. Priority is defined as an implicit hierarchy in the containers. Strict containers are higher priority than regular containers. Clients, classes, vendors, and subnets are sorted, in that order, and within container type by depth. This generates a list ordered by most specific to least specific. For example: 
Subnet 1
    --Class 1
    --Client 1
Subnet 2
    --Class 1
    ----Vendor 1
    ----Client 1
    --Client 1
The example shows two subnets, Subnet 1 and Subnet 2. There is one class name, Class 1, one vendor name, Vendor 1, and one client name, Client 1. Class 1 and Client 1 are defined in multiple places. Because they are in different containers, their names can be the same but values inside them can be different. If Client 1 sends a message to the DHCP server from Subnet 1 with Class 1 specified in its option list, the DHCP server would generate the following container path: 
Subnet 1, Class 1, Client 1
The most specific container is listed last. To get an address, the list is examined in reverse hierarchy to find the first available address. Then, the list is examined in forward hierarchy to get the options. Options override previous values unless an option deny is present in the container. Also, because Class 1 and Client 1 are in Subnet 1, they are ordered according to the container priority. If the same client is in Subnet 2 and sends the same message, the container list generated is: 
Subnet 2, Class 1, Client 1 (at the Subnet 2 level), Client 1 (at the Class 1 level)

Subnet 2 is listed first, then Class 1, then the Client 1 at the Subnet 2 level (because this client statement is only one level down in the hierarchy). The hierarchy implies that a client matching the first client statement is less specific than the client matching Client 1 of Class 1 within Subnet 2.

Priority selected by depth within the hierarchy is not superseded by the priority of the containers themselves. For example, if the same client issues the same message and specifies a vendor identifier, the container list is: 
Subnet 2, Class 1, Vendor 1, Client 1 (at Subnet 2 level), Client 1 (at Class 1 level)

Container priority improves search performance because it follows a general concept that client containers are the most specific way to define one or more clients. The class container holds less specific addresses than a client container; vendor is even less specific; and subnet is the least specific.