diff --git a/ChangeLog b/ChangeLog
index d70adcda7bc76f6388d9f429beb3e98b85757415..d1f5ec4a5d5161b6dd09e41d7ffd2c5343118484 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+7XX. [func]* tomek
+ b10-dhcp6: New parameter added to configure: --with-kea-config.
+ It allows selecting configuration backend and accepts one of two
+ values: BIND10, which uses BIND10 framework as Kea 0.8 did, or
+ JSON, which reads configuration from a JSON file.
+ (Trac #3400, git TBD)
+
782. [func] tmark
Added sender-ip, sender-port, and max-queue-size parameters to
the dhcp-ddns configuration section of both b10-dhcp4 and b10-dhcp6.
diff --git a/configure.ac b/configure.ac
index 58658a9c90958dc3867d2b7d252fb669d79a1183..3d13aa850e6bfe7e43a3516e6bef0bc11e3fe294 100644
--- a/configure.ac
+++ b/configure.ac
@@ -565,6 +565,9 @@ AC_SUBST(PYCOVERAGE)
AC_SUBST(PYCOVERAGE_RUN)
AC_SUBST(USE_PYCOVERAGE)
+
+
+
enable_gtest="no"
GTEST_INCLUDES=
@@ -1282,6 +1285,34 @@ AC_SUBST(PERL)
AC_PATH_PROGS(AWK, gawk awk)
AC_SUBST(AWK)
+
+# Kea configuration backend section
+# Currently there are 2 backends available: BUNDY and JSON
+# It is possible that we may extend this to accept additional backends.
+AC_ARG_WITH(kea-config,
+ AC_HELP_STRING([--with-kea-config],
+ [Selects configuration backend; currently available options are: BUNDY (default,
+ Kea reads configuration and commands from Bundy framework) or JSON (Kea reads
+ configuration from a JSON file from disk)]),
+ [CONFIG_BACKEND="$withval"],
+ [CONFIG_BACKEND=BUNDY])
+
+AM_CONDITIONAL(CONFIG_BACKEND_BUNDY, test "x$CONFIG_BACKEND" = "xBUNDY")
+AM_CONDITIONAL(CONFIG_BACKEND_JSON, test "x$CONFIG_BACKEND" = "xJSON")
+
+if test "x$CONFIG_BACKEND" = "xBUNDY"; then
+ AC_DEFINE(CONFIG_BACKEND_BUNDY, 1, [Define to 1 if Kea config was set to BUNDY])
+fi
+
+if test "x$CONFIG_BACKEND" = "xJSON"; then
+ AC_DEFINE(CONFIG_BACKEND_JSON, 1, [Define to 1 if Kea config was set to JSON])
+fi
+
+# Let's sanity check if the specified backend value is allowed
+if test "x$CONFIG_BACKEND" != "xBUNDY" && test "x$CONFIG_BACKEND" != "xJSON"; then
+ AC_MSG_ERROR("Invalid configuration backend specified: $CONFIG_BACKEND. The only supported are: BUNDY JSON")
+fi
+
AC_ARG_ENABLE(generate_docs, [AC_HELP_STRING([--enable-generate-docs],
[regenerate documentation using Docbook [default=no]])],
enable_generate_docs=$enableval, enable_generate_docs=no)
@@ -1620,6 +1651,9 @@ SQLite:
SQLITE_VERSION: ${SQLITE_VERSION}
SQLITE_CFLAGS: ${SQLITE_CFLAGS}
SQLITE_LIBS: ${SQLITE_LIBS}
+
+Kea config backend:
+ CONFIG_BACKEND: ${CONFIG_BACKEND}
END
# Avoid confusion on DNS/DHCP and only mention MySQL if it
diff --git a/doc/devel/mainpage.dox b/doc/devel/mainpage.dox
index 7847f2530e466d1f0ba5f82541afa51b77557a33..b775fe024f3c00e32c6121b42b81e147da34585f 100644
--- a/doc/devel/mainpage.dox
+++ b/doc/devel/mainpage.dox
@@ -63,6 +63,7 @@
* - @subpage dhcpv6DDNSIntegration
* - @subpage dhcpv6OptionsParse
* - @subpage dhcpv6Classifier
+ * - @subpage dhcpv6ConfigBackend
* - @subpage dhcpv6Other
* - @subpage d2
* - @subpage d2CPL
diff --git a/doc/examples/kea6/several-subnets.json b/doc/examples/kea6/several-subnets.json
new file mode 100644
index 0000000000000000000000000000000000000000..1fe7254e694ee70b7234624007e830f7ecbe86a6
--- /dev/null
+++ b/doc/examples/kea6/several-subnets.json
@@ -0,0 +1,36 @@
+# This is an example configuration file for DHCPv6 server in Kea.
+# It's a basic scenario with four IPv6 subnets configured. In each
+# subnet, there's a smaller pool of dynamic addresses.
+
+{ "Dhcp6":
+
+{
+# Kea is told to listen on eth0 interface only.
+ "interfaces": [ "eth0" ],
+
+# 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 repond
+# 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.
+ "subnet6": [
+ { "pool": [ "2001:db8:1::/80" ],
+ "subnet": "2001:db8:1::/64" },
+ { "pool": [ "2001:db8:2::/80" ],
+ "subnet": "2001:db8:2::/64" },
+ { "pool": [ "2001:db8:3::/80" ],
+ "subnet": "2001:db8:3::/64" },
+ { "pool": [ "2001:db8:4::/80" ],
+ "subnet": "2001:db8:4::/64" } ]
+}
+
+}
+
diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml
index 44d804c7c1b32da46154c366bd8f058f8c3fd7ae..9bf190395ee1c6c7ef10f322ed5109173917bfca 100644
--- a/doc/guide/bind10-guide.xml
+++ b/doc/guide/bind10-guide.xml
@@ -710,7 +710,9 @@ as a dependency earlier -->
For additional instructions concerning the building and installation of
- Kea, see .
+ Kea for various databases, see .
+ For additional instructions concerning configuration backends, see
+ .
@@ -1864,6 +1866,46 @@ address, but the usual ones don't." mean? -->
The DHCP-DDNS server details are covered in
+
+
+ Selecting configuration backend
+ Kea 0.9 introduces configuration backends that are switchable during
+ compilation phase. There is a new parameter for configure script:
+ --with-kea-config. It currently supports two values: BIND10 and
+ JSON. This is currently only supported by DHCPv6 component.
+
+
+
+
+ BIND10
+
+ BIND10 (which is the default value as of April 2014) means
+ that Kea6 is linked with the BIND10 configuration backend that
+ connects to the BIND10 framework and in general works exactly the
+ same as Kea 0.8 and earlier versions. The benefits of that backend
+ are uniform integration with BIND10 framework, easy on-line
+ reconfiguration using bindctl, available RESTful API. On the other
+ hand, it requires the whole heavy BIND10 framework that requires
+ Python3 to be present. That backend is likely to go away with the
+ release of Kea 0.9.
+
+
+
+
+ JSON
+
+ JSON is a new configuration backend that causes Kea to read
+ JSON configuration file from disk. It does not require any framework
+ and thus is considered more lightweight. It will allow dynamic
+ on-line reconfiguration, but will lack remote capabilities (i.e. no
+ RESTful API). This configuration backend is expected to be the
+ default for upcoming Kea 0.9.
+
+
+
+
+
+