Adding upstream version 2.5.7.upstream/2.5.7upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

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"
+        }
+    ]
+}
+
+}