Commit 80ef9a69 authored by Tomek Mrugalski's avatar Tomek Mrugalski

[3400] Merge remote-tracking branch 'origin/trac3449' into trac3400

Conflicts:
	ChangeLog
parents 21369c11 a1d6621e
......@@ -5,6 +5,18 @@
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.
(Trac #3328, git 8d8d0b5eedaab20bf1008dfb3a6913eb006a6e73)
781. [func] marcin
libkea-dhcpsrv: the Memfile lease storage backend returns leases
of a specified type. Previously, it ignored the lease type parameter
and returned all leases for a particular client. Thanks to David
Carlier for helping to implement this ticket.
(Trac #3148, git d2f0edf473716cd747a21d6917e89ba55c148d8e)
780. [func] marcin
libkea-cc: JSON parser stores information about the position
of the data element values in the JSON string. The position
......
......@@ -292,7 +292,7 @@ case "$host" in
;;
esac
m4_define([_AM_PYTHON_INTERPRETER_LIST], [python python3.3 python3.2 python3.1 python3])
m4_define([_AM_PYTHON_INTERPRETER_LIST], [python python3.4 python3.3 python3.2 python3.1 python3])
AC_ARG_WITH([pythonpath],
AC_HELP_STRING([--with-pythonpath=PATH],
[specify an absolute path to python executable when automatic version check (incorrectly) fails]),
......@@ -916,7 +916,7 @@ if test "$MYSQL_CONFIG" != "" ; then
fi
# Solaris puts FIONREAD in filio.h
AC_CHECK_HEADER(sys/filio.h)
AC_CHECK_HEADERS(sys/filio.h,,,)
# ... and at the shell level, so Makefile.am can take action depending on this.
AM_CONDITIONAL(HAVE_MYSQL, test "$MYSQL_CONFIG" != "")
......@@ -1495,6 +1495,7 @@ AC_CONFIG_FILES([compatcheck/Makefile
src/lib/dhcp_ddns/tests/Makefile
src/lib/dhcp/Makefile
src/lib/dhcpsrv/Makefile
src/lib/dhcpsrv/testutils/Makefile
src/lib/dhcpsrv/tests/Makefile
src/lib/dhcpsrv/tests/test_libraries.h
src/lib/dhcp/tests/Makefile
......
......@@ -324,22 +324,6 @@ INLINE_SIMPLE_STRUCTS = NO
TYPEDEF_HIDES_STRUCT = NO
# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to
# determine which symbols to keep in memory and which to flush to disk.
# When the cache is full, less often used symbols will be written to disk.
# For small to medium size projects (<1000 input files) the default value is
# probably good enough. For larger projects a too small cache size can cause
# doxygen to be busy swapping symbols to and from disk most of the time
# causing a significant performance penalty.
# If the system has enough physical memory increasing the cache will improve the
# performance by keeping more symbols in memory. Note that the value works on
# a logarithmic scale so increasing the size by one will roughly double the
# memory usage. The cache size is given by this formula:
# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0,
# corresponding to a cache size of 2^16 = 65536 symbols.
SYMBOL_CACHE_SIZE = 0
# Similar to the SYMBOL_CACHE_SIZE the size of the symbol lookup cache can be
# set using LOOKUP_CACHE_SIZE. This cache is used to resolve symbols given
# their name and scope. Since this can be an expensive process and often the
......@@ -678,7 +662,6 @@ INPUT = ../src/bin/d2 \
../src/lib/hooks \
../src/lib/log \
../src/lib/log/compiler \
../src/lib/resolve \
../src/lib/testutils \
../src/lib/util \
../src/lib/util/io \
......@@ -1660,18 +1643,18 @@ DOT_NUM_THREADS = 0
# the DOTFONTPATH environment variable or by setting DOT_FONTPATH to the
# directory containing the font.
DOT_FONTNAME = FreeSans
#DOT_FONTNAME = FreeSans
# The DOT_FONTSIZE tag can be used to set the size of the font of dot graphs.
# The default size is 10pt.
DOT_FONTSIZE = 10
#DOT_FONTSIZE = 10
# By default doxygen will tell dot to use the Helvetica font.
# If you specify a different font using DOT_FONTNAME you can use DOT_FONTPATH to
# set the path where dot can find it.
DOT_FONTPATH =
#DOT_FONTPATH =
# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
# will generate a graph for each documented class showing the direct and
......
/**
* @page dhcpv4 DHCPv4 Server Component
*
* BIND10 offers DHCPv4 server implementation. It is implemented as
* b10-dhcp4 component. Its primary code is located in
* isc::dhcp::Dhcpv4Srv class. It uses \ref libdhcp extensively,
* especially isc::dhcp::Pkt4, isc::dhcp::Option and
* isc::dhcp::IfaceMgr classes. Currently this code offers skeleton
* functionality, i.e. it is able to receive and process incoming
* requests and trasmit responses. However, it does not have database
* management, so it returns only one, hardcoded lease to whoever asks
* for it.
*
* DHCPv4 server component does not support direct traffic (relayed
* only), as support for transmission to hosts without IPv4 address
* assigned is not implemented in IfaceMgr yet.
*
* DHCPv4 server component does not use BIND10 logging yet.
*
* @section dhcpv4Session BIND10 message queue integration
*
* DHCPv4 server component is now integrated with the BIND10 message queue.
* The integration is performed by establishSession() and disconnectSession()
* functions in isc::dhcp::ControlledDhcpv4Srv class. main() method defined
* in the src/bin/dhcp4/main.cc file instantiates isc::dhcp::ControlledDhcpv4Srv
* class that establishes connection with msgq and install necessary handlers
* for receiving commands and configuration updates. It is derived from
* a base isc::dhcp::Dhcpv4Srv class that implements DHCPv4 server functionality,
* without any controlling mechanisms.
*
* ControlledDhcpv4Srv instantiates several components to make management
* session possible. In particular, isc::cc::Session cc_session
* object uses ASIO for establishing connection. It registers its socket
* in isc::asiolink::IOService io_service object. Typically, other components
* (e.g. auth or resolver) that use ASIO for their communication, register their
* other sockets in the
* same io_service and then just call io_service.run() method that does
* not return, until one of the callback decides that it is time to shut down
* the whole component cal calls io_service.stop(). DHCPv4 works in a
* different way. It does receive messages using select()
* (see isc::dhcp::IfaceMgr::receive4()), which is incompatible with ASIO.
* To solve this problem, socket descriptor is extracted from cc_session
* object and is passed to IfaceMgr by using isc::dhcp::IfaceMgr::set_session_socket().
* IfaceMgr then uses this socket in its select() call. If there is some
* data to be read, it calls registered callback that is supposed to
* read and process incoming data.
*
* This somewhat complicated approach is needed for a simple reason. In
* embedded deployments there will be no message queue. Not referring directly
* to anything related to message queue in isc::dhcp::Dhcpv4Srv and
* isc::dhcp::IfaceMgr classes brings in two benefits. First, the can
* be used with and without message queue. Second benefit is related to the
* first one: \ref libdhcp is supposed to be simple and robust and not require
* many dependencies. One notable example of a use case that benefits from
* this approach is a perfdhcp tool. Finally, the idea is that it should be
* possible to instantiate Dhcpv4Srv object directly, thus getting a server
* that does not support msgq. That is useful for embedded environments.
* It may also be useful in validation.
*
*/
// Copyright (C) 2014 Internet Systems Consortium, Inc. ("ISC")
//
// Permission to use, copy, modify, and/or distribute this software for any
// purpose with or without fee is hereby granted, provided that the above
// copyright notice and this permission notice appear in all copies.
//
// THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
// REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
// AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
// INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
// LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
// OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
// PERFORMANCE OF THIS SOFTWARE.
/**
@page configBackend Kea Configuration Backends
@section configBackendIntro Introduction
Kea is a flexible DHCP protocol engine. It offers a selection of lease database
backends, extensibility via the hooks API and the definition of custom options.
Depending on the environment, one lease database backend may be better than
other. Similarly, because the best way of configuring the server can depend on
the environment, Kea provides different ways of obtaining configuration
information, through the Configuration Backend. Since the means by which
configuration information is received cannot be part of the configuration itself, it
has to be chosen at the compilation time (when configuring the sources).
This page explains the background to the Configuration Backend and how
it is implemented. It is aimed at people who want to develop and
maintain their own backends.
@section configBackendMotivation Motivation for Different Backends
BIND10 (the project under which the first stages of Keas were developed)
used to maintain an extensive framework that was responsible for the
configuration of components. After BIND10 was cancelled, two projects
were created: <a href="http://kea.isc.org">Kea</a> (focused on DHCP)
and <a href="http://www.bundy-dns.de">Bundy</a> (aimed at DNS). The
Kea team decided to remove the BIND10 framework, while the Bundy team
decided to keep it. However, even though the Kea team is focused on a
backend that reads a JSON configuration file from disk, it decided to
make it easy for others to use different backends.
While ISC currently (May 2014) plans to maintain only one configuration backend
(a JSON file read from disk), there may be other organizations (e.g.
the Bundy project community) that will maintain other backends. It is quite
possible that additional backends (e.g. using LDAP or XML) will be
developed and maintained by other organizations.
@section configBackendAdding How to Add a New Configuration Backend
@todo Will be covered in ticket #3400.
@section configBackendJSONDesign The JSON Configuration Backend
The following are some considerations that shaped the design of the configuration
backend framework.
-# A new parameter called --with-kea-config will be implemented in the
configure script. It will allow the selection at compilation time of how the
servers will be configured. For the next 2-3 months (until around June 2014),
there will be two values: JSON (read from file) and BIND10 (use the BIND10 framework).
Once the file based configuration is implemented and the Kea team is ready to switch
(i.e. enough confidence, Forge tests updated for new configuration
mechanism), the BIND10 backend will be removed from the Kea repository. Other projects
(e.g. Bundy) who want to maintain it, are advised to just revert the single
commit that will bring the BIND10 framework back to their repositories.<br/><br/>
This switchable backend concept is quite simple. There are just different
implementations of ControlledXSrv class, so it is a matter of compiling/linking
one file or another. Hence it is easy to remove the old backend (and for
Bundy to keep it if they desire so). It is also easy for other
organizations to add and maintain their own backends (e.g. LDAP).<br/><br/>
-# Each backend must use the common code
for configuration and command processing callbacks. They all assume that
JSON formatted parameters are sent and they are expected to return well
formatted JSON responses. The exact format of configuration and commands is
module specific.<br/><br/>
-# After Kea 0.9 is released, a form of secure socket will be implemented through
which commands can be sent. Whatever the design, it
will allow the sending of configurations and commands in JSON format and
the receiving of responses.<br/><br/>
Once that is done, Kea will have the same capability the BIND10
framework to send additional parameters. One obvious use case will be
to send a new configuration file name as the parameter for "reload".<br/><br/>
-# A command handler needs to be added for reading the configuration from a file. Its main
responsibility is to load the configuration and process it. The JSON backend
must call that handler when starting up the server.<br/><br/>
-# Extend the existing JSON parser. The current JSON parser in
@ref isc::data::Element::fromJSON() needs to be extended to allow optional preprocessing.
For now that capability will simply remove whole-line comments staring with the hash
character, but it is expected
to grow over time (in-line comments and file inclusions are the obvious
envisaged additions).<br/><br/>
-# Implement a common base class for the Kea4, Kea6, and D2 servers. Some operations will be
common for all three components: logger initialization, handling and, at some future point,
control socket. This calls for a small base class that @ref isc::dhcp::Dhcpv4Srv "Dhcpv4Srv",
@ref isc::dhcp::Dhcpv6Srv "Dhcpv6Srv" and the @ref isc::d2::D2Controller "D2Controller" classes can use.
It is expected that the base class
(@ref isc::dhcp::Daemon) will be a small one but will grow over time as the code is unified.<br/><br/>
-# A way is needed to initialize stand-alone logging (i.e. each
Kea component will initialize it on its own).<br/><br/>
-# The current format of the BIND10 configuration file, b10-config.db will be
retained as the configuration file format. This is slight change
from the BIND10 days, as then a subset of the configuration was received by
the daemon processes.<br/><br/>
To take a specific example, the following is how b10-config.db
looks today:<br/><br/>
@code
{
"Init": { ... }
"Dhcp4": {
"subnet4" { subnet definitions here },
"option-data" { option data here },
"interfaces": [ "eth0" ],
...
},
"Dhcp6": {
"subnet6" { subnet definitions here },
"option-data" { option data here },
"interfaces": [ "eth0" ],
...
},
"Logging": {
"Loggers": [{"name": *, "severity": "DEBUG" }]
}
}
@endcode
<br/>
The Kea components used to receive only relevant parts of it (e.g. Kea4
received config that contained content of the Dhcp4 element). Now they
will receive all of it. The modification in the code to handle this
is really minor: just iterate over the top level elements and pick the appropriate
tree (or get the element by name). Also, that approach makes the logging
initialization code very easy to share among Kea4, Kea6 and D2.<br/><br/>
-# The .spec files used in BIND 10 by the control program to validate commands
will be retained. They will be kept and maintained even though no use of
them is planned. At some future time syntax validation may be implemented,
although it is out of scope for Kea 0.9 (and probably
for 1.0 as it is pretty big task).<br/><br/>
-# Addition of a shell script to start/stop Kea4,Kea6 and D2. There will be a script that will
start, stop and reconfigure the daemons. Its only
job will be to pass the configuration file to each daemon and remember its PID file, so
that sending signals will be be possible (for configuration reload or shutdown). Optionally,
it could also print out a status based on PID, but that may be tricky to
implement in a portable way. The minimum set of commands will be:
-# Start the processes
- eventually based on configuration, initially start them all
- it could launch a nanny script which restarts them on a crash (past 0.9)
-# Prompt the processes to reload configuration
- for now it will be a matter of sending singal to the right process
- this could also decide if D2 should still be running or not, and react accordingly (post 0.9)
-# Stop the processes in an orderly fashion
-# Perhaps return status of each process
*/
......@@ -87,6 +87,10 @@
* - @subpage cfgmgr
* - @subpage allocengine
* - @subpage dhcpDatabaseBackends
* - @subpage configBackend
* - @subpage configBackendMotivation
* - @subpage configBackendJSONDesign
* - @subpage configBackendAdding
* - @subpage perfdhcpInternals
* - @subpage libdhcp_ddns
*
......@@ -95,6 +99,7 @@
* - @subpage logBasicIdeas
* - @subpage logDeveloperUse
* - @subpage logNotes
* - @subpage LoggingApi
* - @subpage SocketSessionUtility
* - <a href="./doxygen-error.log">Documentation warnings and errors</a>
*
......
......@@ -2167,6 +2167,9 @@ Dhcp4/subnet4/ list
Dhcp4/dhcp-ddns/enable-updates true boolean
Dhcp4/dhcp-ddns/server-ip "127.0.0.1" string
Dhcp4/dhcp-ddns/server-port 53001 integer
Dhcp4/dhcp-ddns/sender-ip "" string
Dhcp4/dhcp-ddns/sender-port 0 integer
Dhcp4/dhcp-ddns/max-queue-size 1024 integer
Dhcp4/dhcp-ddns/ncr-protocol "UDP" string
Dhcp4/dhcp-ddns/ncr-format "JSON" string
Dhcp4/dhcp-ddns/override-no-update false boolean
......@@ -3052,7 +3055,7 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
<section id="dhcp4-ddns-config">
<title>Configuring DHCPv4 for DDNS</title>
<para>
As mentioned earlier, DHCPv4 can be configured to generate requests to the
As mentioned earlier, b10-dhcp4 can be configured to generate requests to the
DHCP-DDNS server to update DNS entries. These requests are known as
NameChangeRequests or NCRs. Each NCR contains the following information:
<orderedlist>
......@@ -3068,13 +3071,16 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
</para></listitem>
</orderedlist>
The parameters for controlling the generation of NCRs for submission to D2
are contained in the "dhcp-ddns" section of the DHCPv4 server
are contained in the "dhcp-ddns" section of the b10-dhcp4 server
configuration. The default values for this section appears as follows:
<screen>
&gt; <userinput>config show Dhcp4/dhcp-ddns</userinput>
Dhcp4/dhcp-ddns/enable-updates true boolean
Dhcp4/dhcp-ddns/server-ip "127.0.0.1" string
Dhcp4/dhcp-ddns/server-port 53001 integer
Dhcp4/dhcp-ddns/sender-ip "" string
Dhcp4/dhcp-ddns/sender-port 0 integer
Dhcp4/dhcp-ddns/max-queue-size 1024 integer
Dhcp4/dhcp-ddns/ncr-protocol "UDP" string
Dhcp4/dhcp-ddns/ncr-format "JSON" string
Dhcp4/dhcp-ddns/override-no-update false boolean
......@@ -3085,7 +3091,7 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
</screen>
</para>
<para>
The "enable-updates" parameter determines whether or not DHCPv4 will
The "enable-updates" parameter determines whether or not b10-dhcp4 will
generate NCRs. By default, this value is false hence DDNS updates are
disabled. To enable DDNS updates set this value to true:
</para>
......@@ -3096,47 +3102,74 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
<section id="dhcpv4-d2-io-config">
<title>DHCP-DDNS Server Connectivity</title>
<para>
In order for NCRs to reach the D2 server, DHCPv4 must be able
to communicate with it and so the relevant parameters must be set
appropriately. The parameters, "server-ip" and "server-port", specify
the address of the D2 server. By default, D2 is assumed to running
on the same machine as DHCPv4, and the default values for these two
parameters should be sufficient. However, if D2 has been configured
to listen on a different address or port, these values must altered
accordingly. For example, if D2 has been configured to listen on
198.162.1.10 port 900, the following commands would be required:
In order for NCRs to reach the D2 server, b10-dhcp4 must be able
to communicate with it. b10-dhcp4 uses the following configuration
parameters to control how it communications with D2:
<orderedlist>
<listitem><para>
server-ip - IP address on which D2 listens for requests. The default is
the local loopback interface at address 127.0.0.1. You may specify
either an IPv4 or IPv6 address.
</para></listitem>
<listitem><para>
server-port - port on which D2 listens for requests. The default value
is 53001.
</para></listitem>
<listitem><para>
sender-ip - IP address which b10-dhcp4 should use to send requests to D2.
The default value is blank which instructs b10-dhcp4 to select a suitable
address.
</para></listitem>
<listitem><para>
sender-port - port which b10-dhcp4 should use to send requests to D2. The
default value of 0 instructs b10-dhcp4 to select suitable port.
</para></listitem>
<listitem><para>
ncr-format - Socket protocol use when sending requests to D2. Currently
only UDP is supported. TCP may be available in an upcoming release.
</para></listitem>
<listitem><para>
ncr-protocol - Packet format to use when sending requests to D2.
Currently only JSON format is supported. Other formats may be available
in future releases.
</para></listitem>
<listitem><para>
max-queue-size - maximum number of requests allowed to queue waiting to
be sent to D2. This value guards against requests accumulating
uncontrollably if they are being generated faster than they can be
delivered. If the number of requests queued for transmission reaches
this value, DDNS updating will be turned off until the queue backlog has
been sufficiently reduced. The intent is allow the b10-dhcp4 server to
continue lease operations. The default value is 1024.
</para></listitem>
</orderedlist>
By default, D2 is assumed to running on the same machine as b10-dhcp4, and
all of the default values mentioned above should be sufficient.
If, however, D2 has been configured to listen on a different address or
port, these values must altered accordingly. For example, if D2 has been
configured to listen on 198.162.1.10 port 900, the following commands
would be required:
<screen>
&gt; <userinput>config set Dhcp4/dhcp-ddns/server-ip "198.162.1.10"</userinput>
&gt; <userinput>config set Dhcp4/dhcp-ddns/server-port 900</userinput>
&gt; <userinput>config commit</userinput>
</screen>
D2 can be configured to listen over IPv4 or IPv6, therefore server-ip
may be either an IPv4 or IPv6 address.
</para>
<para>
The socket protocol that DHCPv4 should use to communicate with D2 is
specified with the "ncr-protocol" parameter. Currently only UDP is
supported.
</para>
<para>
The internal format for DDNS update requests sent by DHCPv4 is specified
with the "ncr-format" parameter. Currently only JSON is supported.
</para>
</section>
<section id="dhcpv4-d2-rules-config">
<title>When does the DHCPv4 server generate DDNS requests?</title>
DHCPv4 follows the behavior prescribed for DHCP servers in RFC 4702.
It is important to keep in mind that DHCPv4 provides the initial decision
<title>When does the b10-dhcp4 server generate DDNS requests?</title>
b10-dhcp4 follows the behavior prescribed for DHCP servers in RFC 4702.
It is important to keep in mind that b10-dhcp4 provides the initial decision
making of when and what to update and forwards that information to D2 in
the form of NCRs. Carrying out the actual DNS updates and dealing with
such things as conflict resolution are the purview of D2 (<xref linkend="dhcp-ddns-server"/>).
<para>
This section describes when DHCPv4 will generate NCRs and the
This section describes when b10-dhcp4 will generate NCRs and the
configuration parameters that can be used to influence this decision.
It assumes that the "enable-updates" parameter is true.
</para>
<para>
In general, DHCPv4 will generate DDNS update requests when:
In general, b10-dhcp4 will generate DDNS update requests when:
<orderedlist>
<listitem><para>
A new lease is granted in response to a DHCP REQUEST
......@@ -3157,10 +3190,10 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
involved and is discussed next.
</para>
<para>
When a new lease is granted, the DHCPv4 server will generate a DDNS
When a new lease is granted, b10-dhcp4 will generate a DDNS
update request if the DHCP REQUEST contains either the FQDN option
(code 81) or the Host Name option (code 12). If both are present,
the server will use the FQDN option. By default the DHCPv4 server
the server will use the FQDN option. By default b10-dhcp4
will respect the FQDN N and S flags specified by the client as shown
in the following table:
</para>
......@@ -3206,11 +3239,11 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
<para>
The first row in the table above represents "client delegation". Here
the DHCP client states that it intends to do the forward DNS updates and
the server should do the reverse updates. By default, DHCPv4 will honor
the server should do the reverse updates. By default, b10-dhcp4 will honor
the client's wishes and generate a DDNS request to D2 to update only
reverse DNS data. The parameter, "override-client-update", can be used
to instruct the server to override client delegation requests. When
this parameter is true, DHCPv4 will disregard requests for client
this parameter is true, b10-dhcp4 will disregard requests for client
delegation and generate a DDNS request to update both forward and
reverse DNS data. In this case, the N-S-O flags in the server's
response to the client will be 0-1-1 respectively.
......@@ -3218,7 +3251,7 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
<para>
(Note that the flag combination N=1, S=1 is prohibited according to
RFC 4702. If such a combination is received from the client, the packet
will be dropped by the DHCPv4 server.)
will be dropped by the b10-dhcp4.)
</para>
<para>
To override client delegation, issue the following commands:
......@@ -3231,7 +3264,7 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
The third row in the table above describes the case in which the client
requests that no DNS updates be done. The parameter, "override-no-update",
can be used to instruct the server to disregard the client's wishes. When
this parameter is true, DHCPv4 will generate DDNS update request to D2
this parameter is true, b10-dhcp4 will generate DDNS update request to D2
even if the client requests no updates be done. The N-S-O flags in the
server's response to the client will be 0-1-1.
</para>
......@@ -3243,7 +3276,7 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
&gt; <userinput>config commit</userinput>
</screen>
<para>
DHCPv4 will always generate DDNS update requests if the client request
b10-dhcp4 will always generate DDNS update requests if the client request
only contains the Host Name option. In addition it will include an FQDN
option in the response to the client with the FQDN N-S-O flags set to
0-1-0 respectively. The domain name portion of the FQDN option will be
......@@ -3251,9 +3284,9 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
</para>
</section>
<section id="dhcpv4-fqdn-name-generation">
<title>DHCPv4 name generation for DDNS update requests</title>
<title>b10-dhcp4 name generation for DDNS update requests</title>
Each NameChangeRequest must of course include the fully qualified domain
name whose DNS entries are to be affected. DHCPv4 can be configured to
name whose DNS entries are to be affected. b10-dhcp4 can be configured to
supply a portion or all of that name based upon what it receives from
the client in the DHCP REQUEST.
<para>
......@@ -3282,7 +3315,7 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
</orderedlist>
</para></listitem>
</orderedlist>
To instruct DHCPv4 to always generate the FQDN for a client, set the
To instruct b10-dhcp4 to always generate the FQDN for a client, set the
parameter "replace-client-name" to true as follows:
</para>
<screen>
......@@ -3310,7 +3343,7 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
</screen>
</section>
<para>
When generating a name, DHCPv4 will construct name of the format:
When generating a name, b10-dhcp4 will construct name of the format:
</para>
<para>
[generated-prefix]-[address-text].[qualifying-suffix].
......@@ -3326,7 +3359,7 @@ Dhcp4/dhcp-ddns/qualifying-suffix "example.com" string
</para>
</section>
</section> <!-- end of configuring DHCPv4 server section with many subsections -->
</section> <!-- end of configuring b10-dhcp4 server section with many subsections -->
<section id="dhcp4-serverid">
<title>Server Identifier in DHCPv4</title>
......@@ -3671,6 +3704,9 @@ Dhcp6/subnet6/ list
Dhcp6/dhcp-ddns/enable-updates true boolean
Dhcp6/dhcp-ddns/server-ip "127.0.0.1" string
Dhcp6/dhcp-ddns/server-port 53001 integer
Dhcp6/dhcp-ddns/sender-ip "" string
Dhcp6/dhcp-ddns/sender-port 0 integer
Dhcp6/dhcp-ddns/max-queue-size 1024 integer
Dhcp6/dhcp-ddns/ncr-protocol "UDP" string
Dhcp6/dhcp-ddns/ncr-format "JSON" string
Dhcp6/dhcp-ddns/always-include-fqdn false boolean
......@@ -4604,7 +4640,7 @@ should include options from the isc option space:
<section id="dhcp6-ddns-config">
<title>Configuring DHCPv6 for DDNS</title>
<para>
As mentioned earlier, DHCPv6 can be configured to generate requests to
As mentioned earlier, b10-dhcp6 can be configured to generate requests to
the DHCP-DDNS server (referred to here as the "D2" server) to update
DNS entries. These requests are known as NameChangeRequests or NCRs.
Each NCR contains the following information:
......@@ -4621,13 +4657,16 @@ should include options from the isc option space:
</para></listitem>
</orderedlist>
The parameters controlling the generation of NCRs for submission to D2
are contained in the "dhcp-ddns" section of the DHCPv6 server
are contained in the "dhcp-ddns" section of b10-dhcp6
configuration. The default values for this section appears as follows:
<screen>
&gt; <userinput>config show Dhcp6/dhcp-ddns</userinput>
Dhcp6/dhcp-ddns/enable-updates true boolean
Dhcp6/dhcp-ddns/server-ip "127.0.0.1" string
Dhcp6/dhcp-ddns/server-port 53001 integer
Dhcp6/dhcp-ddns/sender-ip "" string
Dhcp6/dhcp-ddns/sender-port 0 integer
Dhcp6/dhcp-ddns/max-queue-size 1024 integer
Dhcp6/dhcp-ddns/ncr-protocol "UDP" string
Dhcp6/dhcp-ddns/ncr-format "JSON" string
Dhcp6/dhcp-ddns/override-no-update false boolean
......@@ -4638,7 +4677,7 @@ Dhcp6/dhcp-ddns/qualifying-suffix "example.com" string
</screen>
</para>
<para>
The "enable-updates" parameter determines whether or not DHCPv6 will
The "enable-updates" parameter determines whether or not b10-dhcp6 will
generate NCRs. By default, this value is false hence DDNS updates are
disabled. To enable DDNS updates set this value to true as follows:
</para>
......@@ -4648,58 +4687,84 @@ Dhcp6/dhcp-ddns/qualifying-suffix "example.com" string
</screen>
<section id="dhcpv6-d2-io-config">
<title>DHCP-DDNS Server Connectivity</title>
In order for NCRs to reach D2, DHCPv6 must be able to communicate with it.
The following parameters are used to establish connectivty between DHCPv6
and D2.
<para>
The parameters, "server-ip" and "server-port", specify the address of the
D2 server. By default, D2 is assumed to running on the same machine as
DHCPv6, and the default values for these two parameters should be
sufficient. However, if D2 has been configured to listen on a different
address or port, these values must altered accordingly. For example, if
D2 has been configured to listen on 198.162.1.10 port 900, the following
commands would be required:
</para>
<para>
In order for NCRs to reach the D2 server, b10-dhcp6 must be able
to communicate with it. b10-dhcp6 uses the following configuration
parameters to control how it communications with D2:
<orderedlist>
<listitem><para>
server-ip - IP address on which D2 listens for requests. The default is
the local loopback interface at address 127.0.0.1. You may specify
either an IPv4 or IPv6 address.
</para></listitem>
<listitem><para>
server-port - port on which D2 listens for requests. The default value
is 53001.
</para></listitem>
<listitem><para>
sender-ip - IP address which b10-dhcp6 should use to send requests to D2.
The default value is blank which instructs b10-dhcp6 to select a suitable
address.
</para></listitem>
<listitem><para>
sender-port - port which b10-dhcp6 should use to send requests to D2. The
default value of 0 instructs b10-dhcp6 to select suitable port.
</para></listitem>
<listitem><para>
ncr-format - Socket protocol use when sending requests to D2. Currently
only UDP is supported. TCP may be available in an upcoming release.
</para></listitem>
<listitem><para>
ncr-protocol - Packet format to use when sending requests to D2.