Commit 58de1eed authored by Marcin Siodelski's avatar Marcin Siodelski
Browse files

[3232] Merge branch 'master' into trac3232

Conflicts:
	src/bin/dhcp6/dhcp6_messages.mes
	src/bin/dhcp6/dhcp6_srv.cc
	src/bin/dhcp6/dhcp6_srv.h
	src/bin/dhcp6/tests/dhcp6_test_utils.cc
parents b11c068e 51b46695
769. [bug] tmark
b10-dhcp-ddns now treats a DNS server response code of NXRRSET as a
successful outcome when processing a request to remove DNS data. This
corrects a defect in which b10-dhcp-ddns would incorrectly fail a request
to remove DNS data when the DNS server's response was NXRRSET.
(Trac #3362, git da3b0d4f364d069ffdb47723545798ac589fae42)
768. [bug] tmark
Python configuration library now properly merges changes into
configuration items that are maps of items. This corrects a
defect in which a change to an item in a map of items could
committed, only to be lost upon committing a subsequent change
to same map of items during the same bindctl session.
(Trac #3373, git da3b0d4f364d069ffdb47723545798ac589fae42)
767. [func] tomek
Unit-tests for all database backends are now shared. This improves
test coverage for memfile and any future backends that may appear.
(Trac #3359, git 3d6c11630ada9d0681a813cf026f6bb16aabb9fa)
bind10-1.2.0beta1 released on March 6, 2014
766. [func] muks
--disable-dns and --disable-dhcp configure arguments have been
added to conditionally disable the DNS or DHCP components
respectively. This facility can be used to do a DNS or DHCP-only
build of BIND 10. DNS and DHCP components are both enabled by
default.
(Trac #2367, git 81a689b61b1c4abf8a1a4fcbe41cfc96fd11792a)
765. [bug] tomek
b10-dhcp4: Fixed a minor bug in eRouter1.0 class processing. The
server no longer sets giaddr field.
(Trac #3353, git 23c22e9b1141c699f361d45c309e737dfecf6f3f)
764. [bug] tomek
b10-dhcp4: Fixed a bug caused client classification to not work
properly.
(Trac #3343, git 1801400ac874380e7a565d373b4bae96a49e21f7)
763. [func] tmark
b10-dhcp-ddns may now be configured to disable DNS updates in
in a given direction by simply not defining any domains for that
direction in its configuration. This allows it to be configured to
support either forward DNS or reverse DNS only. Prior to this if
a request was received that could not be matched to servers in a
given direction it was failed immediately.
(Trac #3341, git 01f26bce1d9faaddb8be59802f73891ea065b200)
762. [func] tmark
If configured to do so, b10-dhcp6 will now create DHCP-DDNS update
requests and send them to b10-dhcp-ddns for processing.
(Trac# 3329, git 239956696465a13196a2b6bc0f3a61aed21a5de8)
761. [doc] stephen, jreed
Added "man" page for perfdhcp.
(Trac #2307, git ff2f538912c205fbdb1408ee613c09b90de53514)
760. [bug] tmark
When merging a map of configuration elements into another, elements
that are themselves maps will be merged. In particular, this
corrects a defect which caused a configuration commit error to
occur when using bindctl to modify a single a parameter in
dhcp-ddns portion of b10-dhcp4 configuration.
(Trac# 3339, git 3ae0d93d89f3277a566eeb045191a43b2dd9d9b1)
759. [func] tomek
b10-dhcp4, b10-dhcp6: IP address of the relay agent can now be
specified for both IPv4 and IPv6 subnets. That information allows
the server to properly handle a case where relay agent address
does not match subnet. This is mostly useful in shared subnets
and cable networks.
(Trac #3322, git 5de565baea42c9096dff78ed5fbd05982a174469)
758. [bug] tmark
b10-dhcp4 now correctly handles DHO_HOST_OPTION. This corrects
a bug where the server would fail to recognize the option in the
DHCP request and then skip generating the appropriate DHCP-DDNS
update request.
(Trac #2426, git 985d66cba7665a71e17ef70c5d22c767abaad1b6)
757. [func] tmark
b10-dhcp6 now parses parameters which support DHCP-DDNS updates
via the DHCP-DDNS module, b10-dhcp-ddns. These parameters are
part of new configuration element, dhcp-ddns, defined in
dhcp4.spec. These parameters influence when and how DDNS updates
requests are created but communicating them to b10-dhcp-ddns is
not yet supported. That will be provided under separate ticket,
Trac #3222.
(Trac# 3034, git 22c667a66536ff3e3741bc67025d824644ed4e7d)
756. [bug] marcin
b10-dhcp6: server parses DHCPv6 Vendor Class option. Previously
the server failed to parse Vendor Class option having empty opaque
data field because of the invalid definition in libdhcp++. The
DHCPv6 Vendor Class option and DHCPv4 V-I Vendor Class option is
now represented by the new OptionVendorClass. The b10-dhcp4 is
affected by this change such that it uses new class to parse the
DHCPv4 V-I Vendor Class option.
(Trac #3316, git 1e61d7db5b8dc76682aa568cd62bfae0eeff46e3)
755. [func] muks
Add support for the CAA RR type (RFC 6844).
(Trac #2512, git 39162608985e5c904448f308951c73bb9c32da8f)
754. [func] muks
Add support for the TLSA RR type (RFC 6698).
(Trac #2185, git a168170430f6927f28597b2a6debebe31cf39b13)
753. [func] muks
libdns++: the unknown/generic (RFC 3597) RDATA class now uses the
generic lexer in constructors from text.
(Trac #2426, git 0770d2df84e5608371db3a47e0456eb2a340b5f4)
752. [func] tmark
If configured to do so, b10-dhcp4 will now create DHCP-DDNS update
requests and send them to b10-dhcp-ddns for processing.
(Trac# 3329, git 4546dd186782eec5cfcb4ddb61b0a3aa5c700751)
751. [func] muks
The BIND 10 zone loader now supports the $GENERATE directive (a
BIND 9 extension).
(Trac #2430, git b05064f681231fe7f8571253c5786f4ff0f2ca03)
750. [func] tomek
b10-dhcp4, b10-dhcp6: Simple client classification has been
implemented. Incoming packets can be assigned to zero or more
......@@ -6,9 +130,10 @@
(Trac #3274, git 1791d19899b92a6ee411199f664bdfc690ec08b2)
749. [bug] tmark
b10-dhcp-ddns now sets the TTL value in RRs that add A, AAAA, or PTR DNS
entries to the lease length provided in instigating NameChangeRequest.
This corrected a bug in which the TTL was always set to 0.
b10-dhcp-ddns now sets the TTL value in RRs that add A, AAAA, or
PTR DNS entries to the lease length provided in instigating
NameChangeRequest. This corrected a bug in which the TTL was
always set to 0.
(Trac# 3299, git dbacf27ece77f3d857da793341c6bd31ef1ea239)
748. [bug] marcin
......@@ -32,7 +157,7 @@
method has been removed and replaced with several convenience methods.
(Trac #1485, git ecdb62db16b3f3d447db4a9d2a4079d5260431f0)
745. [bug] muks
745. [bug]* muks
b10-auth now returns rcode=REFUSED for all questions with
qtype=RRSIG (i.e., where RRSIGs are queried directly). This is
because RRSIGs are meaningless without being bundled alongside the
......@@ -40,12 +165,12 @@
(Trac #2226, git 68d24e65c9c3dfee38adfbe1c93367b0083f9a58)
744. [func] marcin
b10-dhcp6: Refactored the code which is processing Client FQDN option.
The major user-visible change is that server generates DDNS
NameChangeRequest for the first IPv6 address (instead of all)
acquired by a client. Also, the server generates fully qualified domain
name from acquired IPv6 address, if the client sends an empty name in
Client FQDN option.
b10-dhcp6: Refactored the code which is processing Client FQDN
option. The major user-visible change is that server generates
DDNS NameChangeRequest for the first IPv6 address (instead of all)
acquired by a client. Also, the server generates fully qualified
domain name from acquired IPv6 address, if the client sends an
empty name in Client FQDN option.
(Trac# 3295, git aa1c94a54114e848c64771fde308fc9ac0c00fd0)
743. [func] tmark
......@@ -92,7 +217,7 @@
DNS messages with unsupported opcodes are received.
(Trac #1516, git 71611831f6d1aaaea09143d4837eddbd1d67fbf4)
736. [bug] wlodek
736. [bug] wlodek
b10-dhcp6 is now capable to determine if a received
message is addressed to it, using server identifier option.
The messages with non-matching server identifier are dropped.
......@@ -116,20 +241,21 @@
732. [func] tomek
b10-dhcp4, b10-dhcp6: Support for simplified client classification
added. Incoming packets are now assigned to a client class based on
the content of the packet's user class option (DHCPv4) or vendor class
option (DHCPv6). Two classes (docsis3.0 and eRouter1.0) have class
specific behavior in b10-dhcp4. See DHCPv4 Client Classification and
DHCPv6 Client Classification in BIND10 Developer's Guide for details.
This is a first ticket in a series of planned at least three tickets.
added. Incoming packets are now assigned to a client class based
on the content of the packet's user class option (DHCPv4) or vendor
class option (DHCPv6). Two classes (docsis3.0 and eRouter1.0) have
class specific behavior in b10-dhcp4. See DHCPv4 Client
Classification and DHCPv6 Client Classification in BIND10
Developer's Guide for details. This is a first ticket in a series
of planned at least three tickets.
(Trac #3203, git afea612c23143f81a4201e39ba793bc837c5c9f1)
731. [func] tmark
b10-dhcp4 now parses parameters which support DHCP-DDNS updates via
the DHCP-DDNS module, b10-dhcp-ddns. These parameters are part of new
configuration element, dhcp-ddns, defined in dhcp4.spec. The parameters
parse, store and retrieve but do not yet govern behavior. That will be
provided under separate ticket.
b10-dhcp4 now parses parameters which support DHCP-DDNS updates
via the DHCP-DDNS module, b10-dhcp-ddns. These parameters are
part of new configuration element, dhcp-ddns, defined in
dhcp4.spec. The parameters parse, store and retrieve but do not
yet govern behavior. That will be provided under separate ticket.
(Trac# 3033, git 0ba859834503f2b9b908cd7bc572e0286ca9201f)
730. [bug] tomek
......@@ -154,7 +280,7 @@
RRset::setName() has now been removed.
(Trac #2335, git c918027a387da8514acf7e125fd52c8378113662)
726. [bug] muks
726. [bug]* muks
Don't print trailing newlines in Question::toText() output by
default. This fixes some logging that were split with a line
feed. It is possible to get the old behavior by passing
......@@ -310,7 +436,7 @@
them to b10-dhcp-ddns will be implemented with the future tickets.
(Trac #3035, git f617e6af8cdf068320d14626ecbe14a73a6da22)
705. [bug] kean
705. [bug]* kean
When commands are piped into bindctl, no longer attempt to query the
user name and password if no default user name and password file is
present, or it contains no valid entries.
......@@ -502,12 +628,11 @@
(Trac #3145, git 3a844e85ecc3067ccd1c01841f4a61366cb278f4)
672. [func] tmark
Added b10-dhcp-ddnsupdate transaction base class,
NameChangeTransaction. This class provides the common
structure and methods to implement the state models described
in the DHCP_DDNS design, plus integration with DNSClient
and its callback mechanism for asynchronous IO with the
DNS servers.
Added b10-dhcp-ddns transaction base class, NameChangeTransaction.
This class provides the common structure and methods to implement
the state models described in the DHCP_DDNS design, plus
integration with DNSClient and its callback mechanism for
asynchronous IO with the DNS servers.
(Trac #3086, git 079b862c9eb21056fdf957e560b8fe7b218441b6)
671. [func] dclink, tomek
......@@ -676,7 +801,7 @@
645. [func] tomek
Added initial set of hooks (pkt4_receive, subnet4_select,
lease4_select, pkt4_send) to the DHCPv6 server.
lease4_select, pkt4_send) to the DHCPv4 server.
(Trac #2994, git be65cfba939a6a7abd3c93931ce35c33d3e8247b)
644. [func] marcin
......@@ -2315,7 +2440,8 @@ bind10-devel-20120517 released on May 17, 2012
now manipulates them in the separate table for the NSEC3 namespace.
As a result b10-xfrin now correctly updates NSEC3-signed zones by
inbound zone transfers.
(Trac #1781, #1788, #1891, git 672f129700dae33b701bb02069cf276238d66be3)
(Trac #1781, #1788, #1891,
git 672f129700dae33b701bb02069cf276238d66be3)
426. [bug] vorner
The NSEC3 records are now included when transferring a
......
......@@ -19,11 +19,11 @@ tests and example programs. (It also includes an experimental proof
of concept recursive or forwarding DNS server, b10-resolver.)
BIND 10 also provides experimental DHCPv4 and DHCPv6 servers,
b10-dhcp4 and b10-dhcp6, a portable DHCP library, libdhcp++, and
a DHCP benchmarking tool, perfdhcp. In this release of BIND 10,
the DHCPv4 and DHCPv6 servers must be considered experimental.
Limitations and known issues with this DHCP release can be found
at http://bind10.isc.org/wiki/KeaKnownIssues
b10-dhcp4 and b10-dhcp6, a dynamic DNS update module, b10-dhcp-ddns,
a portable DHCP library, libdhcp++, and a DHCP benchmarking tool,
perfdhcp. In this release of BIND 10, the DHCPv4 and DHCPv6 servers
must be considered experimental. Limitations and known issues with
this DHCP release can be found at http://bind10.isc.org/wiki/KeaKnownIssues
NOTE: The API/ABI provided by libraries in BIND 10 may change in future
point releases. So please do not assume currently that any code that you
......
......@@ -2,7 +2,7 @@
# Process this file with autoconf to produce a configure script.
AC_PREREQ([2.59])
AC_INIT(bind10, 20130529, bind10-dev@isc.org)
AC_INIT(bind10, 20140306, bind10-dev@isc.org)
AC_CONFIG_SRCDIR(README)
# serial-tests is not available in automake version before 1.13, so
......@@ -24,6 +24,55 @@ AC_CONFIG_MACRO_DIR([m4macros])
# Checks for programs.
AC_PROG_CXX
want_dns=yes
AC_ARG_ENABLE(dns,
[AC_HELP_STRING([--disable-dns],
[disable DNS components])],
[want_dns=$enableval])
AM_CONDITIONAL([WANT_DNS], [test "$want_dns" = "yes"])
if test "$want_dns" = "yes"; then
WANT_DNS=yes
else
WANT_DNS=no
fi
AC_SUBST(WANT_DNS)
want_dhcp=yes
AC_ARG_ENABLE(dhcp,
[AC_HELP_STRING([--disable-dhcp],
[disable DHCP components])],
[want_dhcp=$enableval])
AM_CONDITIONAL([WANT_DHCP], [test "$want_dhcp" = "yes"])
if test "$want_dhcp" = "yes"; then
WANT_DHCP=yes
else
WANT_DHCP=no
fi
AC_SUBST(WANT_DHCP)
want_experimental_resolver=no
AC_ARG_ENABLE(experimental-resolver,
[AC_HELP_STRING([--enable-experimental-resolver],
[enable the experimental resolver [default=no]])],
[want_experimental_resolver=$enableval])
AM_CONDITIONAL([WANT_EXPERIMENTAL_RESOLVER], [test "$want_experimental_resolver" = "yes"])
if test "$want_experimental_resolver" = "yes"; then
WANT_EXPERIMENTAL_RESOLVER=yes
else
WANT_EXPERIMENTAL_RESOLVER=no
fi
AC_SUBST(WANT_EXPERIMENTAL_RESOLVER)
# At least DNS or DHCP components must be enabled
if test "$want_dns" != "yes" -a "$want_dhcp" != "yes"; then
AC_MSG_ERROR([At least one of DNS or DHCP components must be enabled to do a BIND 10 build.])
fi
# Experimental resolver requires DNS components to be enabled
if test "$want_experimental_resolver" = "yes" -a "$want_dns" != "yes"; then
AC_MSG_ERROR([You must also enable DNS components if you want to enable the experimental resolver.])
fi
# Enable low-performing debugging facilities? This option optionally
# enables some debugging aids that perform slowly and hence aren't built
# by default.
......@@ -875,6 +924,10 @@ elif test "${mysql_config}" != "no" ; then
fi
if test "$MYSQL_CONFIG" != "" ; then
if test "$want_dhcp" != "yes"; then
AC_MSG_ERROR([--with-dhcp-mysql should not be used when DHCP components are disabled])
fi
if test -d "$MYSQL_CONFIG" -o ! -x "$MYSQL_CONFIG" ; then
AC_MSG_ERROR([--with-dhcp-mysql should point to a mysql_config program])
fi
......@@ -910,6 +963,9 @@ if test "$MYSQL_CONFIG" != "" ; then
AC_DEFINE([HAVE_MYSQL], [1], [MySQL is present])
fi
# Solaris puts FIONREAD in filio.h
AC_CHECK_HEADER(sys/filio.h)
# ... and at the shell level, so Makefile.am can take action depending on this.
AM_CONDITIONAL(HAVE_MYSQL, test "$MYSQL_CONFIG" != "")
......@@ -998,25 +1054,12 @@ if test "$BOOST_NUMERIC_CAST_WOULDFAIL" = "yes" -a X"$werror_ok" = X1 -a $CLANGP
AC_MSG_ERROR([Failed to compile a required header file. If you are using FreeBSD and Boost installed via ports, retry with specifying --without-werror. See the ChangeLog entry for Trac no. 1991 for more details.])
fi
build_experimental_resolver=no
AC_ARG_ENABLE(experimental-resolver,
[AC_HELP_STRING([--enable-experimental-resolver],
[enable building of the experimental resolver [default=no]])],
[build_experimental_resolver=$enableval])
AM_CONDITIONAL([BUILD_EXPERIMENTAL_RESOLVER], [test "$build_experimental_resolver" = "yes"])
if test "$build_experimental_resolver" = "yes"; then
BUILD_EXPERIMENTAL_RESOLVER=yes
else
BUILD_EXPERIMENTAL_RESOLVER=no
fi
AC_SUBST(BUILD_EXPERIMENTAL_RESOLVER)
use_shared_memory=yes
AC_ARG_WITH(shared-memory,
AC_HELP_STRING([--with-shared-memory],
[Build with Boost shared memory support; for large scale authoritative DNS servers]),
[use_shared_memory=$withval])
if test X$use_shared_memory = Xyes -a "$BOOST_MAPPED_FILE_WOULDFAIL" = "yes"; then
if test X$use_shared_memory = Xyes -a "$BOOST_MAPPED_FILE_WOULDFAIL" = "yes" -a "$want_dns" = "yes"; then
AC_MSG_ERROR([Boost shared memory does not compile on this system. If you don't need it (most normal users won't) build without it by rerunning this script with --without-shared-memory; using a different compiler or a different version of Boost may also help.])
fi
AM_CONDITIONAL([USE_SHARED_MEMORY], [test x$use_shared_memory = xyes])
......@@ -1025,7 +1068,7 @@ if test "x$use_shared_memory" = "xyes"; then
fi
AC_SUBST(BOOST_MAPPED_FILE_CXXFLAG)
if test "$BOOST_OFFSET_PTR_OLD" = "yes" -a "$use_shared_memory" = "yes" ; then
if test "$BOOST_OFFSET_PTR_OLD" = "yes" -a "$use_shared_memory" = "yes" -a "$want_dns" = "yes"; then
AC_MSG_ERROR([You're trying to compile against boost older than 1.48 with
shared memory. Older versions of boost have a bug which causes segfaults in
offset_ptr implementation when compiled by GCC with optimisations enabled.
......@@ -1716,6 +1759,11 @@ fi
cat >> config.report << END
Components:
DHCP: $want_dhcp
DNS: $want_dns
Experimental resolver: $want_experimental_resolver
Features:
$enable_features
......
......@@ -4431,15 +4431,16 @@ Dhcp4/subnet4 [] list (default)
extensions will be using hooks extensions.
</para>
</note>
<para>In certain cases it is useful to differentiate between different types
of clients and treat them differently. The process of doing classification
is conducted in two steps. The first step is to assess incoming packet and
assign it to zero or more classes. This classification is currently simple,
but is expected to grow in capability soon. Currently the server checks whether
incoming packet has vendor class identifier option (60). If it has, content
of that option is interpreted as a class. For example, modern cable modems
will send this option with value &quot;docsis3.0&quot; and as a result the
packet will belong to class &quot;docsis3.0&quot;.
<para>In certain cases it is useful to differentiate between different
types of clients and treat them differently. The process of doing
classification is conducted in two steps. The first step is to assess
incoming packet and assign it to zero or more classes. This classification
is currently simple, but is expected to grow in capability soon. Currently
the server checks whether incoming packet has vendor class identifier
option (60). If it has, content of that option is prepended with
&quot;VENDOR_CLASS_&quot; then is interpreted as a class. For example,
modern cable modems will send this option with value &quot;docsis3.0&quot;
and as a result the packet will belong to class &quot;VENDOR_CLASS_docsis3.0&quot;.
</para>
<para>It is envisaged that the client classification will be used for changing
......@@ -4450,12 +4451,12 @@ Dhcp4/subnet4 [] list (default)
subnet selection.</para>
<para>
For clients that belong to the docsis3.0 class, the siaddr field is set to
the value of next-server (if specified in a subnet). If there is
boot-file-name option specified, its value is also set in the file field
in the DHCPv4 packet. For eRouter1.0 class, the siaddr is always set to
0.0.0.0. That capability is expected to be moved to external hook
library that will be dedicated to cable modems.
For clients that belong to the VENDOR_CLASS_docsis3.0 class, the siaddr
field is set to the value of next-server (if specified in a subnet). If
there is boot-file-name option specified, its value is also set in the
file field in the DHCPv4 packet. For eRouter1.0 class, the siaddr is
always set to 0.0.0.0. That capability is expected to be moved to
external hook library that will be dedicated to cable modems.
</para>
<para>
......@@ -4483,13 +4484,13 @@ Dhcp4/subnet4 [] list (default)
the 192.0.2.0/24 prefix. The Administrator of that network has decided
that addresses from range 192.0.2.10 to 192.0.2.20 are going to be
managed by the Dhcp4 server. Only clients belonging to client class
docsis3.0 are allowed to use this subnet. Such a configuration can be
achieved in the following way:
VENDOR_CLASS_docsis3.0 are allowed to use this subnet. Such a
configuration can be achieved in the following way:
<screen>
&gt; <userinput>config add Dhcp4/subnet4</userinput>
&gt; <userinput>config set Dhcp4/subnet4[0]/subnet "192.0.2.0/24"</userinput>
&gt; <userinput>config set Dhcp4/subnet4[0]/pool [ "192.0.2.10 - 192.0.2.20" ]</userinput>
&gt; <userinput>config set Dhcp4/subnet4[0]/client-class "docsis3.0"</userinput>
&gt; <userinput>config set Dhcp4/subnet4[0]/client-class "VENDOR_CLASS_docsis3.0"</userinput>
&gt; <userinput>config commit</userinput></screen>
</para>
......@@ -4592,6 +4593,11 @@ Dhcp4/subnet4 [] list (default)
If the message is relayed it is accepted through any interface. The giaddr
set by the relay agent is used to select the subnet for the client.
</para>
<para>
It is also possible to specify a relay IPv4 address for a given subnet. It
can be used to match incoming packets into a subnet in uncommon configurations,
e.g. shared subnets. See <xref linkend="dhcp4-relay-override"/> for details.
</para>
<note>
<para>The subnet selection mechanism described in this section is based
on the assumption that client classification is not used. The classification
......@@ -4600,6 +4606,75 @@ Dhcp4/subnet4 [] list (default)
</note>
</section>
<section id="dhcp4-relay-override">
<title>Using specific relay agent for a subnet</title>
<para>
The relay has to have an interface connected to the link on which
the clients are being configured. Typically the relay has an IPv4
address configured on that interface that belongs to the subnet that
the server will assign addresses from. In such typical case, the
server is able to use IPv4 address inserted by the relay (in GIADDR
field of the DHCPv4 packet) to select appropriate subnet.
</para>
<para>
However, that is not always the case. In certain uncommon, but
valid deployments, the relay address may not match the subnet. This
usually means that there is more than one subnet allocated for a given
link. Two most common examples where this is the case are long lasting
network renumbering (where both old and new address space is still being
used) and a cable network. In a cable network both cable modems and the
devices behind them are physically connected to the same link, yet
they use distinct addressing. In such case, the DHCPv4 server needs
additional information (IPv4 address of the relay) to properly select
an appropriate subnet.
</para>
<para>
The following example assumes that there is a subnet 192.0.2.0/24
that is accessible via relay that uses 10.0.0.1 as its IPv4 address.
The server will be able to select this subnet for any incoming packets
that came from a relay that has an address in 192.0.2.0/24 subnet.
It will also select that subnet for a relay with address 10.0.0.1.
<screen>
&gt; <userinput>config add Dhcp4/subnet4</userinput>
&gt; <userinput>config set Dhcp4/subnet4[0]/subnet "192.0.2.0/24"</userinput>
&gt; <userinput>config set Dhcp4/subnet4[0]/pool [ "192.0.2.10 - 192.0.2.20" ]</userinput>
&gt; <userinput>config set Dhcp4/subnet4[0]/relay/ip-address "10.0.0.1"</userinput>
&gt; <userinput>config commit</userinput></screen>
</para>
</section>
<section id="dhcp4-srv-example-client-class-relay">
<title>Segregating IPv4 clients in a cable network</title>
<para>
In certain cases, it is useful to mix relay address information,
introduced in <xref linkend="dhcp4-relay-override"/> with client
classification, explained in <xref linkend="dhcp4-subnet-class"/>.
One specific example is cable network, where typically modems
get addresses from a different subnet than all devices connected
behind them.
</para>
<para>
Let's assume that there is one CMTS (Cable Modem Termination System)
with one CM MAC (a physical link that modems are connected to).
We want the modems to get addresses from the 10.1.1.0/24 subnet, while
everything connected behind modems should get addresses from another
subnet (192.0.2.0/24). The CMTS that acts as a relay an uses address
10.1.1.1. The following configuration can serve that configuration:
<screen>
&gt; <userinput>config add Dhcp4/subnet4</userinput>
&gt; <userinput>config set Dhcp4/subnet4[0]/subnet "10.1.1.0/24"</userinput>
&gt; <userinput>config set Dhcp4/subnet4[0]/pool [ "10.1.1.2 - 10.1.1.20" ]</userinput>
&gt; <userinput>config set Dhcp4/subnet4[0]/client-class "docsis3.0"</userinput>
&gt; <userinput>config set Dhcp4/subnet4[0]/relay/ip-address "10.1.1.1"</userinput>
&gt; <userinput>config add Dhcp4/subnet4</userinput>
&gt; <userinput>config set Dhcp4/subnet4[1]/subnet "192.0.2.0/24"</userinput>
&gt; <userinput>config set Dhcp4/subnet4[1]/pool [ "192.0.2.10 - 192.0.2.20" ]</userinput>
&gt; <userinput>config set Dhcp4/subnet4[1]/relay/ip-address "10.1.1.1"</userinput>
&gt; <userinput>config commit</userinput></screen>
</para>
</section>
<section id="dhcp4-std">
<title>Supported Standards</title>
<para>The following standards and draft standards are currently
......@@ -4691,6 +4766,23 @@ Dhcp4/renew-timer 1000 integer (default)
</itemizedlist>
</section>
<!--
<section id="dhcp4-srv-examples">
<title>Kea DHCPv4 server examples</title>
<para>
This section provides easy to use example. Each example can be read
separately. It is not intended to be read sequentially as there will
be many repetitions between examples. They are expected to serve as
easy to use copy-paste solutions to many common deployments.
</para>
@todo: add simple configuration for direct clients
@todo: add configuration for relayed clients
@todo: add client classification example
</section> -->
</chapter>
<chapter id="dhcp6">
......@@ -5459,17 +5551,17 @@ should include options from the isc option space:
The DHCPv6 server may receive requests from local (connected to the
same subnet as the server) and remote (connecting via relays) clients.
As server may have many subnet configurations defined, it must select
appropriate subnet for a given request. To do this, the server first
checks if there is only one subnet defined and source of the packet is
link-local. If this is the case, the server assumes that the only
subnet defined is local and client is indeed connected to it. This
check simplifies small deployments.
appropriate subnet for a given request.
</para>
<para>
If there are two or more subnets defined, the server can not assume
which of those (if any) subnets are local. Therefore an optional
"interface" parameter is available within a subnet definition to
designate that a given subnet is local, i.e. reachable directly over
The server can not assume which of configured subnets are local. It is
possible in IPv4, where there is reasonable expectation that the
server will have a (global) IPv4 address configured on the interface,
and can use that information to detect whether a subnet is local or
not. That assumption is not true in IPv6, as the DHCPv6 must be able
to operate with having link-local addresses only. Therefore an optional
&quot;interface&quot; parameter is available within a subnet definition
to designate that a given subnet is local, i.e. reachable directly over
specified interface. For example the server that is intended to serve
a local subnet over eth0 may be configured as follows:
<screen>
......@@ -5558,9 +5650,10 @@ should include options from the isc option space:
assign it to zero or more classes. This classification is currently simple,
but is expected to grow in capability soon. Currently the server checks whether
incoming packet has vendor class option (16). If it has, content
of that option is interpreted as a class. For example, modern cable modems
will send this option with value &quot;docsis3.0&quot; and as a result the
packet will belong to class &quot;docsis3.0&quot;.
of that option is prepended with &quot;VENDOR_CLASS_&quot; interpreted as a
class. For example, modern cable modems will send this option with value
&quot;docsis3.0&quot; and as a result the packet will belong to class
&quot;VENDOR_CLASS_docsis3.0&quot;.
</para>
<para>It is envisaged that the client classification will be used for changing
......@@ -5641,6 +5734,78 @@ should include options from the isc option space:
</section>
<section id="dhcp6-relay-override">
<title>Using specific relay agent for a subnet</title>
<para>
The relay has to have an interface connected to the link on which
the clients are being configured. Typically the relay has a global IPv6
address configured on that interface that belongs to the subnet that
the server will assign addresses from. In such typical case, the
server is able to use IPv6 address inserted by the relay (in link-addr
field in RELAY-FORW message) to select appropriate subnet.
</para>
<para>
However, that is not always the case. The relay
address may not match the subnet in certain deployments. This
usually means that there is more than one subnet allocated for a given
link. Two most common examples where this is the case are long lasting
network renumbering (where both old and new address space is still being
used) and a cable network. In a cable network both cable modems and the
devices behind them are physically connected to the same link, yet
they use distinct addressing. In such case, the DHCPv6 server needs
additional information (like the value of interface-id option or IPv6
address inserted in the link-addr field in RELAY-FORW message) to
properly select an appropriate subnet.
</para>
<para>
The following example assumes that there is a subnet 2001:db8:1::/64
that is accessible via relay that uses 3000::1 as its IPv6 address.
The server will be able to select this subnet for any incoming packets
that came from a relay that has an address in 2001:db8:1::/64 subnet.
It will also select that subnet for a relay with address 3000::1.