Basic class configuration
Class definition sections start with [class_], e.g.:
The minimal attribute a class has to have is the definition of the address(es) belonging to it. Addresses are defined in [address_] sections.
In the class section the keyword for addresses is – surprisingly – addresses:
[class_clients] addresses = client_local
A class can use several address definitions, if clients should have more than one address.
[class_clients] addresses = client_local client_global
The same procedure applies to the definition of prefixes. Simply add a prefixes line with just one previously defined prefix:
[class_clients] prefixes = client_global
Additional options for classes
Each class can have some additional options. These are
Normally a client will get an answer, but if for whatever reason is a need to give it an NoAddrAvail message back or completely ignore the client it can be set here. Valid answer types are “normal”, “noaddress” and “none”:
[class_to_be_ignored] answer = none
Nameservers can be specified individually for every class. This allows to use different nameservers e.g. for valid and invalid hosts. They are set by nameserver. More than one have to be separated by spaces.
[class_valid] addresses = valid_global valid_local nameserver = fd00:0:0:900d::53:1 fd00:0:0:900d::53:2
addresses = invalid
nameserver = fd00:0:0:bad::53:
NTP servers can be defined for every class separately. The ntp_server can be unicast addresses, multicast addresses or FQDNs following RFC 5908 for DHCPv6 option 56.
addresses = valid_global valid_local
ntp_server = 2001:db8::123
Every class might have different t1 and t2 values. This might make sense for invalid clients which could have shorter refresh cycles to check if they are valid again.
[class_invalid] addresses = invalid t1 = 1200 t2 = 1500
Filters allow to configure clients by attributes and not by static configuration information. Filters use Python regular expressions. Possible keywords are filter_hostname, filter_duid and filter_mac. If for example all Windows clients’ hostnames start with “win” a class could be created to use that information.
[class_windows] addresses = valid_local filter_hostname = win*
If multiple interfaces are configured, a class has to belong to at least one interface. If none is specified, all interfaces dhcpy6d listens to are used.
[class_clients] addresses = clients interface = eth0
addresses = servers
interface = eth1
As default addresses and prefixes will be advertised – if defined. When only addresses or only prefixes should be used by this class, the option advertise defines which ones apply:
advertise = prefixes
When delegating prefixes, somewhere the route into the new prefix subnet has to be set. Either the dhcpy6d host routes too or some remote router does. In either case some external executable has to be called. The same applies when the prefix gets released. For this purposes the options call_up and call_down exist. Both are freely adjustable and can get the 3 variables $prefix$, $length$ and $router$. The last one contains the IPv6 address of the requesting client:
call_up = /usr/local/bin/update_route.sh $prefix$ $length$ $router$ call_down = /usr/local/bin/update_route.sh $prefix$ $length$ $router$
The class “default” always exists and applies to clients that do not match otherwise. It uses the address “default” which has to be set in the [address_default] section. See minimal configuration for example.
If default clients need extra configuration edit [class_default]:
[class_default] nameserver = fd00::bad:53
Default classes when using multiple interfaces
If dhcpy6d listens on multiple interfaces one default class per interface can be defined. This will be useful to configure several subnets on different segments. A default class definition starts with [class_default_], which looks like this:
[class_default_eth1] addresses = subnet1
[class_default_eth2] addresses = subnet2
Example for classes
Clients can be assigned to different classes. Lets assume there are 3 classes:
- known valid clients – class “valid“
- known invalid clients, e.g. with invalid antivirus patterns – class “invalid“
- unknown clients which per default belong to class “default“
Valid clients should get 2 addresses each, one unique local and one global address. The local address will be an ID-based one, the global one a random address for privacy. Let the local addresses be in subnet fd00:0:0:900d::/64 and the global one in 2001:db8::/64.
Invalid clients will get only one unique local address based on ID for easier identification of the host. The subnet shall be fd00:0:0:bad::/64.
Unknown clients also will get only one unique local address. Their MAC address should be included for easier tracing and the subnet might be fd00:bad:dead:beef::/64.
Prefix length is 64 per default so it is not necessary to be defined again.
The addresses are defined like this:
# local address for valid clients
category = idpattern = fd00:0:0:900d::$id$
# global address for valid clients
category = randompattern = 2001:db8::$random64$# local address for invalid clients
category = id
pattern = fd00:0:0:bad::$id$
# default address for unknown clients
# the class "default" exists per default and there is no need
# to define it here again, only if it needs some special options
# because it automatically uses this address_default
category = mac
pattern = fd00:bad:dead:beef::$mac$
# class for valid clients
addresses = valid_local valid_global
# class for invalid clients
addresses = invalid