Adding upstream version 2.4.1.upstream/2.4.1upstream

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

1 files changed, 427 insertions, 0 deletions

diff --git a/src/bin/keactrl/kea-dhcp6.conf.pre b/src/bin/keactrl/kea-dhcp6.conf.pre
new file mode 100644
index 0000000..b167e1f
--- /dev/null
+++ b/src/bin/keactrl/kea-dhcp6.conf.pre
@@ -0,0 +1,427 @@
+// 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": "/tmp/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). 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.
+    // If both "flush-reclaimed-timer-wait-time" and "hold-reclaimed-time" are
+    // not 0, when the client sends a release message the lease is expired
+    // instead of being deleted from the lease storage.
+    "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.
+
+            // Subnet identifier should be unique for each subnet.
+            "id": 1,
+
+            // 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-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
+    }
+  ]
+}
+}