// This is a basic configuration for the Kea DHCPv6 server. Subnet declarations // are mostly commented out and no interfaces are listed. Therefore, the servers // will not listen or respond to any queries. // The basic configuration must be extended to specify interfaces on which // the servers should listen. There are a number of example options defined. // These probably don't make any sense in your network. Make sure you at least // update the following, before running this example in your network: // - change the network interface names // - change the subnets to match your actual network // - change the option values to match your network // // This is just a very basic configuration. Kea comes with large suite (over 30) // of configuration examples and extensive Kea User's Guide. Please refer to // those materials to get better understanding of what this software is able to // do. Comments in this configuration file sometimes refer to sections for more // details. These are section numbers in Kea User's Guide. The version matching // your software should come with your Kea package, but it is also available // in ISC's Knowledgebase (https://kea.readthedocs.io; the direct link for // the stable version is https://kea.readthedocs.io/). // // This configuration file contains only DHCPv6 server's configuration. // If configurations for other Kea services are also included in this file they // are ignored by the DHCPv6 server. { // DHCPv6 configuration starts here. This section will be read by DHCPv6 server // and will be ignored by other components. "Dhcp6": { // Add names of your network interfaces to listen on. "interfaces-config": { // You typically want to put specific interface names here, e.g. eth0 // but you can also specify unicast addresses (e.g. eth0/2001:db8::1) if // you want your server to handle unicast traffic in addition to // multicast. (DHCPv6 is a multicast based protocol). "interfaces": [ ] }, // Kea supports control channel, which is a way to receive management commands // while the server is running. This is a Unix domain socket that receives // commands formatted in JSON, e.g. config-set (which sets new configuration), // config-reload (which tells Kea to reload its configuration from file), // statistic-get (to retrieve statistics) and many more. For detailed // description, see Sections 9.12, 16 and 15. "control-socket": { "socket-type": "unix", "socket-name": "/run/kea/kea6-ctrl-socket" }, // Use Memfile lease database backend to store leases in a CSV file. // Depending on how Kea was compiled, it may also support SQL databases // (MySQL and/or PostgreSQL) and even Cassandra. Those database backends // require more parameters, like name, host and possibly user and password. // There are dedicated examples for each backend. See Section 8.2.2 "Lease // Storage" for details. "lease-database": { // Memfile is the simplest and easiest backend to use. It's an in-memory // C++ database that stores its state in CSV file. "type": "memfile", "lfc-interval": 3600 }, // Kea allows storing host reservations in a database. If your network is // small or you have few reservations, it's probably easier to keep them // in the configuration file. If your network is large, it's usually better // to use database for it. To enable it, uncomment the following: // "hosts-database": { // "type": "mysql", // "name": "kea", // "user": "kea", // "password": "kea", // "host": "localhost", // "port": 3306 // }, // See Section 8.2.3 "Hosts storage" for details. // Setup reclamation of the expired leases and leases affinity. // Expired leases will be reclaimed every 10 seconds. Every 25 // seconds reclaimed leases, which have expired more than 3600 // seconds ago, will be removed. The limits for leases reclamation // are 100 leases or 250 ms for a single cycle. A warning message // will be logged if there are still expired leases in the // database after 5 consecutive reclamation cycles. "expired-leases-processing": { "reclaim-timer-wait-time": 10, "flush-reclaimed-timer-wait-time": 25, "hold-reclaimed-time": 3600, "max-reclaim-leases": 100, "max-reclaim-time": 250, "unwarned-reclaim-cycles": 5 }, // These parameters govern global timers. Addresses will be assigned with // preferred and valid lifetimes being 3000 and 4000, respectively. Client // is told to start renewing after 1000 seconds. If the server does not // respond after 2000 seconds since the lease was granted, a client is // supposed to start REBIND procedure (emergency renewal that allows // switching to a different server). "renew-timer": 1000, "rebind-timer": 2000, "preferred-lifetime": 3000, "valid-lifetime": 4000, // These are global options. They are going to be sent when a client requests // them, unless overwritten with values in more specific scopes. The scope // hierarchy is: // - global // - subnet // - class // - host // // Not all of those options make sense. Please configure only those that // are actually useful in your network. // // For a complete list of options currently supported by Kea, see // Section 8.2.9 "Standard DHCPv6 Options". Kea also supports // vendor options (see Section 7.2.10) and allows users to define their // own custom options (see Section 7.2.9). "option-data": [ // When specifying options, you typically need to specify // one of (name or code) and data. The full option specification // covers name, code, space, csv-format and data. // space defaults to "dhcp6" which is usually correct, unless you // use encapsulate options. csv-format defaults to "true", so // this is also correct, unless you want to specify the whole // option value as long hex string. For example, to specify // domain-name-servers you could do this: // { // "name": "dns-servers", // "code": 23, // "csv-format": "true", // "space": "dhcp6", // "data": "2001:db8:2::45, 2001:db8:2::100" // } // but it's a lot of writing, so it's easier to do this instead: { "name": "dns-servers", "data": "2001:db8:2::45, 2001:db8:2::100" }, // Typically people prefer to refer to options by their names, so they // don't need to remember the code names. However, some people like // to use numerical values. For example, DHCPv6 can optionally use // server unicast communication, if extra option is present. Option // "unicast" uses option code 12, so you can reference to it either // by "name": "unicast" or "code": 12. If you enable this option, // you really should also tell the server to listen on that address // (see interfaces-config/interfaces list above). { "code": 12, "data": "2001:db8::1" }, // String options that have a comma in their values need to have // it escaped (i.e. each comma is preceded by two backslashes). // That's because commas are reserved for separating fields in // compound options. At the same time, we need to be conformant // with JSON spec, that does not allow "\,". Therefore the // slightly uncommon double backslashes notation is needed. // Legal JSON escapes are \ followed by "\/bfnrt character // or \u followed by 4 hexadecimal numbers (currently Kea // supports only \u0000 to \u00ff code points). // CSV processing translates '\\' into '\' and '\,' into ',' // only so for instance '\x' is translated into '\x'. But // as it works on a JSON string value each of these '\' // characters must be doubled on JSON input. { "name": "new-posix-timezone", "data": "EST5EDT4\\,M3.2.0/02:00\\,M11.1.0/02:00" }, // Options that take integer values can either be specified in // dec or hex format. Hex format could be either plain (e.g. abcd) // or prefixed with 0x (e.g. 0xabcd). { "name": "preference", "data": "0xf0" }, // A few options are encoded in (length, string) tuples // which can be defined using only strings as the CSV // processing computes lengths. { "name": "bootfile-param", "data": "root=/dev/sda2, quiet, splash" } ], // Another thing possible here are hooks. Kea supports a powerful mechanism // that allows loading external libraries that can extract information and // even influence how the server processes packets. Those libraries include // additional forensic logging capabilities, ability to reserve hosts in // more flexible ways, and even add extra commands. For a list of available // hook libraries, see https://gitlab.isc.org/isc-projects/kea/wikis/Hooks-available. // "hooks-libraries": [ // { // // Forensic Logging library generates forensic type of audit trail // // of all devices serviced by Kea, including their identifiers // // (like MAC address), their location in the network, times // // when they were active etc. // "library": "@libdir@/kea/hooks/libdhcp_legal_log.so", // "parameters": { // "path": "/var/lib/kea", // "base-name": "kea-forensic6" // } // }, // { // // Flexible identifier (flex-id). Kea software provides a way to // // handle host reservations that include addresses, prefixes, // // options, client classes and other features. The reservation can // // be based on hardware address, DUID, circuit-id or client-id in // // DHCPv4 and using hardware address or DUID in DHCPv6. However, // // there are sometimes scenario where the reservation is more // // complex, e.g. uses other options that mentioned above, uses part // // of specific options or perhaps even a combination of several // // options and fields to uniquely identify a client. Those scenarios // // are addressed by the Flexible Identifiers hook application. // "library": "@libdir@/kea/hooks/libdhcp_flex_id.so", // "parameters": { // "identifier-expression": "relay6[0].option[37].hex" // } // } // ], // Below an example of a simple IPv6 subnet declaration. Uncomment to enable // it. This is a list, denoted with [ ], of structures, each denoted with // { }. Each structure describes a single subnet and may have several // parameters. One of those parameters is "pools" that is also a list of // structures. "subnet6": [ { // This defines the whole subnet. Kea will use this information to // determine where the clients are connected. This is the whole // subnet in your network. This is mandatory parameter for each // subnet. "subnet": "2001:db8:1::/64", // Pools define the actual part of your subnet that is governed // by Kea. Technically this is optional parameter, but it's // almost always needed for DHCP to do its job. If you omit it, // clients won't be able to get addresses, unless there are // host reservations defined for them. "pools": [ { "pool": "2001:db8:1::/80" } ], // Kea supports prefix delegation (PD). This mechanism delegates // whole prefixes, instead of single addresses. You need to specify // a prefix and then size of the delegated prefixes that it will // be split into. This example below tells Kea to use // 2001:db8:1::/56 prefix as pool and split it into /64 prefixes. // This will give you 256 (2^(64-56)) prefixes. "pd-pools": [ { "prefix": "2001:db8:8::", "prefix-len": 56, "delegated-len": 64 // Kea also supports excluded prefixes. This advanced option // is explained in Section 9.2.9. Please make sure your // excluded prefix matches the pool it is defined in. // "excluded-prefix": "2001:db8:8:0:80::", // "excluded-prefix-len": 72 } ], "option-data": [ // You can specify additional options here that are subnet // specific. Also, you can override global options here. { "name": "dns-servers", "data": "2001:db8:2::dead:beef, 2001:db8:2::cafe:babe" } ], // Host reservations can be defined for each subnet. // // Note that reservations are subnet-specific in Kea. This is // different than ISC DHCP. Keep that in mind when migrating // your configurations. "reservations": [ // This is a simple host reservation. The host with DUID matching // the specified value will get an address of 2001:db8:1::100. { "duid": "01:02:03:04:05:0A:0B:0C:0D:0E", "ip-addresses": [ "2001:db8:1::100" ] }, // This is similar to the previous one, but this time the // reservation is done based on hardware/MAC address. The server // will do its best to extract the hardware/MAC address from // received packets (see 'mac-sources' directive for // details). This particular reservation also specifies two // extra options to be available for this client. If there are // options with the same code specified in a global, subnet or // class scope, the values defined at host level take // precedence. { "hw-address": "00:01:02:03:04:05", "ip-addresses": [ "2001:db8:1::101" ], "option-data": [ { "name": "dns-servers", "data": "3000:1::234" }, { "name": "nis-servers", "data": "3000:1::234" }], // This client will be automatically added to certain // classes. "client-classes": [ "special_snowflake", "office" ] }, // This is a bit more advanced reservation. The client with the // specified DUID will get a reserved address, a reserved prefix // and a hostname. This reservation is for an address that it // not within the dynamic pool. Finally, this reservation // features vendor specific options for CableLabs, which happen // to use enterprise-id 4491. Those particular values will be // returned only to the client that has a DUID matching this // reservation. { "duid": "01:02:03:04:05:06:07:08:09:0A", "ip-addresses": [ "2001:db8:1:0:cafe::1" ], "prefixes": [ "2001:db8:2:abcd::/64" ], "hostname": "foo.example.com", "option-data": [ { "name": "vendor-opts", "data": "4491" }, { "name": "tftp-servers", "space": "vendor-4491", "data": "3000:1::234" } ] }, // This reservation is using flexible identifier. Instead of // relying on specific field, sysadmin can define an expression // similar to what is used for client classification, // e.g. substring(relay[0].option[17],0,6). Then, based on the // value of that expression for incoming packet, the reservation // is matched. Expression can be specified either as hex or // plain text using single quotes. // Note: flexible identifier requires flex_id hook library to be // loaded to work. { "flex-id": "'somevalue'", "ip-addresses": [ "2001:db8:1:0:cafe::2" ] } ] } // More subnets can be defined here. // { // "subnet": "2001:db8:2::/64", // "pools": [ { "pool": "2001:db8:2::/80" } ] // }, // { // "subnet": "2001:db8:3::/64", // "pools": [ { "pool": "2001:db8:3::/80" } ] // }, // { // "subnet": "2001:db8:4::/64", // "pools": [ { "pool": "2001:db8:4::/80" } ] // } ], // Client-classes can be defined here. See "client-classes" in Dhcp4 for // an example. // DDNS information (how the DHCPv6 component can reach a DDNS daemon) // Logging configuration starts here. Kea uses different loggers to log various // activities. For details (e.g. names of loggers), see Chapter 18. "loggers": [ { // This specifies the logging for kea-dhcp6 logger, i.e. all logs // generated by Kea DHCPv6 server. "name": "kea-dhcp6", "output_options": [ { // Specifies the output file. There are several special values // supported: // - stdout (prints on standard output) // - stderr (prints on standard error) // - syslog (logs to syslog) // - syslog:name (logs to syslog using specified name) // Any other value is considered a name of the file "output": "@localstatedir@/log/kea/kea-dhcp6.log" // Shorter log pattern suitable for use with systemd, // avoids redundant information // "pattern": "%-5p %m\n" // This governs whether the log output is flushed to disk after // every write. // "flush": false, // This specifies the maximum size of the file before it is // rotated. // "maxsize": 1048576, // This specifies the maximum number of rotated files to keep. // "maxver": 8 } ], // This specifies the severity of log messages to keep. Supported values // are: FATAL, ERROR, WARN, INFO, DEBUG "severity": "INFO", // If DEBUG level is specified, this value is used. 0 is least verbose, // 99 is most verbose. Be cautious, Kea can generate lots and lots // of logs if told to do so. "debuglevel": 0 } ] } }