// This is an example configuration file for the DHCPv4 server in Kea.
// It contains one subnet in which there are two static address reservations
// for the clients identified by the MAC addresses.
{ "Dhcp4":

{
// Kea is told to listen on eth0 interface only.
  "interfaces-config": {
    "interfaces": [ "eth0" ]
  },

// We need to specify the database used to store leases. As of April
// 2022, three database backends are supported: MySQL, PostgreSQL, and the
// in-memory database, Memfile.  We'll use memfile because it doesn't
// require any prior set up.
  "lease-database": {
      "type": "memfile",
      "lfc-interval": 3600
  },

// Addresses will be assigned with a lifetime of 4000 seconds.
  "valid-lifetime": 4000,

// Renew and rebind timers are commented out. This implies that options
// 58 and 59 will not be sent to the client. In this case it is up to
// the client to pick the timer values according to RFC2131. Uncomment the
// timers to send these options to the client.
//  "renew-timer": 1000,
//  "rebind-timer": 2000,

// Kea supports reservations by several different types of identifiers:
// hw-address (hardware/MAC address of the client), duid (DUID inserted by the
// client), client-id (client identifier inserted by the client), circuit-id
// (circuit identifier inserted by the relay agent) and flex-id (flexible
// identifier available when flex_id hook library is loaded). When told to do
// so, Kea can check for all of those identifier types, but it takes a costly
// database lookup to do so. It is therefore useful from a performance
// perspective to use only the reservation types that are actually used in a
// given network.

// The example below is not optimal from a performance perspective, but it
// nicely showcases the host reservation capabilities. Please use the minimum
// set of identifier types used in your network.
"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid",
                                  "client-id", "flex-id" ],

// Define a subnet with four reservations. Some of the reservations belong
// to the dynamic pool. Kea is able to handle this case, but it is not
// recommended from a performance perspective, as Kea would not only need to
// check if a given address is free, but also whether it is reserved.
// To avoid this check, one can change reservation-mode to out-of-pool, rather
// than 'all'. If a subnet does not have reservations at all, the reservation
// lookup can be skipped altogether (reservation-mode is set to 'disabled').
// The reservation-mode has been replaced by reservations-global,
// reservations-in-subnet and reservations-out-of-pool.

// Note that the second reservation is for an address which is within the
// range of the pool of the dynamically allocated address. The server will
// exclude this address from this pool and only assign it to the client which
// has a reservation for it.
  "subnet4": [
    {
        "pools": [ { "pool":  "192.0.2.1 - 192.0.2.200" } ],
        "subnet": "192.0.2.0/24",
        "interface": "eth0",
        // This directive tells Kea that reservations may be made both in-pool
        // and out-of-pool. For improved performance, you may move all reservations
        // out of the dynamic pool and change reservation-mode to "out-of-pool".
        // Kea will then be able to skip querying for host reservations when
        // assigning leases from dynamic pool.
        // "reservation-mode": "all",
        // It is replaced by the "reservations-global", "reservations-in-subnet"
        // and "reservations-out-of-pool" parameters.

        // Specify if server should lookup global reservations.
        "reservations-global": false,

        // Specify if server should lookup in-subnet reservations.
        "reservations-in-subnet": true,

        // Specify if server can assume that all reserved addresses
        // are out-of-pool.
        // Ignored when reservations-in-subnet is false.
        // If specified, it is inherited by "shared-networks" and
        // "subnet4" levels.
        "reservations-out-of-pool": false,

        "reservations": [

// This is a reservation for a specific hardware/MAC address. It's a very
// simple reservation: just an address and nothing else.
        {
            "hw-address": "1a:1b:1c:1d:1e:1f",
            "ip-address": "192.0.2.201"
        },

// This is a reservation for a specific client-id. It also shows
// the this client will get a reserved hostname. A hostname can be defined
// for any identifier type, not just client-id.
        {
            "client-id": "01:11:22:33:44:55:66",
            "ip-address": "192.0.2.202",
            "hostname": "special-snowflake"
        },

// The third reservation is based on DUID. This reservation also
// defines special option values for this particular client. If
// the domain-name-servers option would have been defined on a global,
// subnet or class level, the host specific values take preference.
        {
            "duid": "01:02:03:04:05",
            "ip-address": "192.0.2.203",
            "option-data": [ {
                "name": "domain-name-servers",
                "data": "10.1.1.202,10.1.1.203"
            } ]
        },

// The fourth reservation is based on circuit-id. This is an option inserted
// by the relay agent that forwards the packet from client to the server.
// In this example the host is also assigned vendor specific options.
        {
            "circuit-id": "01:11:22:33:44:55:66",
            "ip-address": "192.0.2.204",
            "option-data": [
                {
                    "name": "vivso-suboptions",
                    "data": "4491"
                },
                {
                    "name": "tftp-servers",
                    "space": "vendor-4491",
                    "data": "10.1.1.202,10.1.1.203"
                }
            ]
        },
// This reservation is for a client that needs specific DHCPv4 fields to be
// set. Three supported fields are next-server, server-hostname and
// boot-file-name
        {
            "client-id": "01:0a:0b:0c:0d:0e:0f",
            "ip-address": "192.0.2.205",
            "next-server": "192.0.2.1",
            "server-hostname": "hal9000",
            "boot-file-name": "/dev/null"
        },

// 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": "'s0mEVaLue'",
            "ip-address": "192.0.2.206"
        }

      ]
    }
  ],

// The following configures logging. It assumes that messages with at
// least informational level (info, warn, error and fatal) should be
// logged to stdout.
    "loggers": [
        {
            "name": "kea-dhcp4",
            "output_options": [
                {
                    "output": "stdout"
                }
            ],
            "severity": "INFO"
        }
    ]
}

}