diff options
Diffstat (limited to 'doc/examples/kea6/advanced.json')
| -rw-r--r-- | doc/examples/kea6/advanced.json | 189 |
1 files changed, 189 insertions, 0 deletions
diff --git a/doc/examples/kea6/advanced.json b/doc/examples/kea6/advanced.json new file mode 100644 index 0000000..02ff310 --- /dev/null +++ b/doc/examples/kea6/advanced.json @@ -0,0 +1,189 @@ +// This is an example configuration file for DHCPv6 server in Kea. +// It attempts to showcase some of the more advanced features. +// Topology wise, it's a basic scenario with one IPv6 subnet configured. +// It is assumed that one subnet (2001:db8:1::/64) is available directly +// over eth0 interface. +// +// The following features are currently showcased here: +// 1. Configuration of MAC/hardware address sources in DHCPv6 +// 2. RSOO (Relay supplied options) - Some relays may insert options with the +// intention for the server to insert them into client directed messages. +// 3. Control socket. Kea can open a socket and listen for incoming +// commands. + +{ "Dhcp6": + +{ + // Kea is told to listen on eth0 network interface only. + "interfaces-config": { + "interfaces": [ "eth0" ], + + // This makes interfaces to be re-detected at each (re-)configuration. + // By default it is true. + "re-detect": true + }, + + // We need to specify the database used to store leases. As of + // June 2022, three database backends are supported: MySQL, + // PostgreSQL and the in-memory database, Memfile. + // We will use memfile because it doesn't require any prior set up. + "lease-database": { + "type": "memfile", + "lfc-interval": 3600 + }, + + "sanity-checks": { + // This parameter determines what to do when a new lease appears in the + // system (i.e. either is read from disk during memfile startup or is + // added via lease commands). There are five modes supported: + // none - do nothing, accept them as is + // warn - if subnet-id problems are detected, print a warning, but + // otherwise load the lease as is. This is the default value. + // fix - attempt to fix the lease by finding appropriate subnet-id value. + // if there is no suitable subnet, the lease is loaded as is. + // fix-del - attempt to fix the lease by finding appropriate subnet-id + // value. If there is no suitable subnet, the lease is deleted. + // del - delete leases that have incorrect subnet-id values. + "lease-checks": "fix-del" + }, + + // Kea 0.9.1 introduced MAC/hardware addresses support in DHCPv6. There is + // no single reliable method of getting MAC address information in DHCPv6. + // Kea supports several methods. Depending on your network set up, some + // methods may be more preferable than others, hence the configuration + // parameter. 'mac-sources' is a list of methods. Allowed parameters are: + // any, raw, duid, ipv6-link-local, client-link-addr-option, rfc6939 (which + // is an alias for client-link-addr-option), remote-id, rfc4649 (which is an + // alias for remote-id, subscriber-id, rfc4580 (which is an alias for + // subscriber-id) and docsis. + + // Note that the order matters. Methods are attempted one by one in the + // order specified until hardware address is obtained. If you don't care + // which method is used, using 'any' is marginally faster than enumerating + // them all. + + // If mac-sources are not specified, a default value of 'any' is used. + "mac-sources": [ "client-link-addr-option", "duid", "ipv6-link-local" ], + + // RFC6422 defines a mechanism called relay-supplied options option. The + // relay agent may insert certain options that the server will echo back to + // the client, if certain criteria are met. One condition is that the option + // must be RSOO-enabled (i.e. allowed to be echoed back). IANA maintains a + // list of those options here: + // http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#options-relay-supplied + // However, it is possible to allow the server to echo back additional + // options. This entry marks options 110, 120 and 130 as RSOO-enabled. + "relay-supplied-options": [ "110", "120", "130" ], + + // This defines a control socket. If defined, Kea will open a UNIX socket + // and will listen for incoming commands. See section 15 of the Kea User's + // Guide for list of supported commands. + "control-socket": { + "socket-type": "unix", + "socket-name": "/tmp/kea6-ctrl-socket" + }, + + // 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, + + // The following list defines subnets. Each subnet consists of at + // least subnet and pool entries. Note the user-context being + // used throughout the definitions. This is something that is not + // being used by Kea, it's simply parsed and stored in appropriate + // structures. You can put anything you want in the user-context + // as long as it is a valid JSON and it starts with a map (i.e. + // is enclosed by curly brackets). + // A comment entry is translated into a user-context with a + // "comment" property so you can include comments inside the + // configuration itself. + "subnet6": [ + { + "pools": [ + { + "pool": "2001:db8:1::/80", + + // This is user context specified for this particular + // pool. You can use it to describe the pool in some way. + // Just keep in mind that the structure will not be used + // by Kea itself. It will be made available to hooks if + // they want to use it. + "user-context": { "department": "engineering" } + }], + + // Here's the user-context for the whole subnet. + "user-context": { "comment": "Floor one, west wing" }, + // Equivalent using smart parser + // "comment": "Floor one, west wing", + + // This defines PD (prefix delegation) pools. In this case + // we have only one pool. That consists of /64 prefixes + // being delegated out of large /48 pool. Each delegated + // prefix will contain an excluded-prefix option. + "pd-pools": [ + { + "prefix": "2001:db8:abcd::", + "prefix-len": 48, + "delegated-len": 64, + "excluded-prefix": "2001:db8:abcd:0:1234::", + "excluded-prefix-len": 80, + + // Another user-context for this PD pool. Again, you can put + // anything you want in there as long as it's valid JSON and + // starts with a map. + "user-context": { + "purpose": "For CPE devices" + } + } + ], // end of pools + + "id": 1, + "subnet": "2001:db8:1::/64", + "interface": "eth0", + + // Sometimes the relay may use an odd IPv6 address that's not matching + // the subnet. This is discouraged, but there are valid cases when it + // makes sense. One case is when the relay has only link-local address + // and another is when there is a shared subnet scenario. + "relay": { + "ip-address": "3000::1" + } + } + ], + +// 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-dhcp6", + "output-options": [ + { + "output": "stdout", + // Several additional parameters are possible in addition + // to the typical output. Flush determines whether logger + // flushes output to a file. Maxsize determines maximum + // filesize before the file is rotated. maxver + // specifies the maximum number of rotated files being + // kept. + "flush": true, + "maxsize": 204800, + "maxver": 4, + // We use pattern to specify custom log message layout + "pattern": "%d{%y.%m.%d %H:%M:%S.%q} %-5p [%c/%i] %m\n" + } + ], + "debuglevel": 0, + "severity": "INFO" + } + ] +} + +} |