// This is an example configuration file for DHCPv6 server in Kea. // It demonstrates simple configuration of the options for a subnet. { "Dhcp6": { // Kea is told to listen on ethX interface only. "interfaces-config": { "interfaces": [ "ethX" ] }, // We need to specify the the database used to store leases. As of // September 2016, four database backends are supported: MySQL, // PostgreSQL, Cassandra, and the in-memory database, Memfile. // We'll use memfile because it doesn't require any prior set up. "lease-database": { "type": "memfile" }, // 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, client is supposed // to start REBIND procedure (emergency renewal that allows switching // to a different server). "preferred-lifetime": 3000, "valid-lifetime": 4000, "renew-timer": 1000, "rebind-timer": 2000, // Defining a subnet. There are 2 DHCP options returned to the // clients connected to this subnet. The first option is identified // by the name. The second option is identified by the code. // There are two address pools defined within this subnet. Pool // specific value for option 12 is defined for the pool: // 2001:db8:1::1 - 2001:db8:1::100. Clients obtaining an address // from this pool will be assigned option 12 with a value of // 3001:cafe::21. Clients belonging to this subnet but obtaining // addresses from the other pool, or the clients obtaining // stateless configuration will be assigned subnet specific value // of option 12, i.e. 2001:db8:1:0:ff00::1. "subnet6": [ { // This is how option values are defined for this particular subnet. "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. { "code": 12, "data": "2001:db8:1:0:ff00::1" } ], "pools": [ { "pool": "2001:db8:1::1 - 2001:db8:1::100", "option-data": [ { "code": 12, "data": "3001:cafe::21" } ] }, { "pool": "2001:db8:1::500 - 2001:db8:1::1000" } ], "subnet": "2001:db8:1::/64", "interface": "ethX" } ] }, // The following configures logging. It assumes that messages with at least // informational level (info, warn, error and fatal) should be logged to stdout. "Logging": { "loggers": [ { "name": "kea-dhcp6", "output_options": [ { "output": "stdout" } ], "debuglevel": 0, "severity": "INFO" } ] } }