mirror of
https://gitlab.isc.org/isc-projects/kea
synced 2025-08-29 04:57:52 +00:00
[2269] Developer's guide updated.
This commit is contained in:
parent
43636d3f31
commit
5b9ab4bc5c
@ -15,12 +15,17 @@
|
|||||||
* <a href="http://bind10.isc.org/">BIND10 webpage (http://bind10.isc.org)</a>
|
* <a href="http://bind10.isc.org/">BIND10 webpage (http://bind10.isc.org)</a>
|
||||||
*
|
*
|
||||||
* @section DNS
|
* @section DNS
|
||||||
|
* - Authoritative DNS (todo)
|
||||||
|
* - Recursive resolver (todo)
|
||||||
* - @subpage DataScrubbing
|
* - @subpage DataScrubbing
|
||||||
*
|
*
|
||||||
* @section DHCP
|
* @section DHCP
|
||||||
* - @subpage dhcpv4
|
* - @subpage dhcpv4
|
||||||
* - @subpage dhcpv4Session
|
* - @subpage dhcpv4Session
|
||||||
* - @subpage dhcpv6
|
* - @subpage dhcpv6
|
||||||
|
* - @subpage dhcpv6-session
|
||||||
|
* - @subpage dhcpv6-config-parser
|
||||||
|
* - @subpage dhcpv6-config-inherit
|
||||||
* - @subpage libdhcp
|
* - @subpage libdhcp
|
||||||
* - @subpage libdhcpIntro
|
* - @subpage libdhcpIntro
|
||||||
* - @subpage libdhcpIfaceMgr
|
* - @subpage libdhcpIfaceMgr
|
||||||
|
@ -1,71 +1,72 @@
|
|||||||
/**
|
/**
|
||||||
* @page dhcpv6 DHCPv6 Server Component
|
@page dhcpv6 DHCPv6 Server Component
|
||||||
*
|
|
||||||
* BIND10 offers DHCPv6 server implementation. It is implemented as
|
BIND10 offers DHCPv6 server implementation. It is implemented as
|
||||||
* b10-dhcp6 component. Its primary code is located in
|
b10-dhcp6 component. Its primary code is located in
|
||||||
* isc::dhcp::Dhcpv6Srv class. It uses \ref libdhcp extensively,
|
isc::dhcp::Dhcpv6Srv class. It uses \ref libdhcp extensively,
|
||||||
* especially lib::dhcp::Pkt6, isc::dhcp::Option and
|
especially lib::dhcp::Pkt6, isc::dhcp::Option and
|
||||||
* isc::dhcp::IfaceMgr classes. Currently this code offers skeleton
|
isc::dhcp::IfaceMgr classes. Currently this code offers skeleton
|
||||||
* functionality, i.e. it is able to receive and process incoming
|
functionality, i.e. it is able to receive and process incoming
|
||||||
* requests and trasmit responses. However, it does not have database
|
requests and trasmit responses. However, it does not have database
|
||||||
* management, so it returns only one, hardcoded lease to whoever asks
|
management, so it returns only one, hardcoded lease to whoever asks
|
||||||
* for it.
|
for it.
|
||||||
*
|
|
||||||
* DHCPv6 server component does not support relayed traffic yet, as
|
DHCPv6 server component does not support relayed traffic yet, as
|
||||||
* support for relay decapsulation is not implemented yet.
|
support for relay decapsulation is not implemented yet.
|
||||||
*
|
|
||||||
* DHCPv6 server component does not use BIND10 logging yet.
|
DHCPv6 server component does not use BIND10 logging yet.
|
||||||
*
|
|
||||||
* @section dhcpv6Session BIND10 message queue integration
|
@section dhcpv6-session BIND10 message queue integration
|
||||||
*
|
|
||||||
* DHCPv4 server component is now integrated with BIND10 message queue.
|
DHCPv4 server component is now integrated with BIND10 message queue.
|
||||||
* It follows the same principle as DHCPv4. See \ref dhcpv4Session for
|
It follows the same principle as DHCPv4. See \ref dhcpv4Session for
|
||||||
* details.
|
details.
|
||||||
|
|
||||||
@section dhcpv6-config-parser Configuration Parser in DHCPv6
|
@section dhcpv6-config-parser Configuration Parser in DHCPv6
|
||||||
|
|
||||||
b10-dhcp6 component uses BIND10 cfgmgr for commands and configuration. During
|
b10-dhcp6 component uses BIND10 cfgmgr for commands and configuration. During
|
||||||
initial configuration (See \ref ControlledDhcpv6Srv::establishSession()),
|
initial configuration (See \ref
|
||||||
the configuration handler callback is installed
|
isc::dhcp::ControlledDhcpv6Srv::establishSession()), the configuration handler
|
||||||
(see ControlledDhcpv6Srv::dhcp6ConfigHandler(). It is called every time there
|
callback is installed (see isc::dhcp::ControlledDhcpv6Srv::dhcp6ConfigHandler().
|
||||||
is a new configuration. In particular, it is called every time during daemon
|
It is called every time there is a new configuration. In particular, it is
|
||||||
start process. It contains a ConstElementPtr to a new configuration. This
|
called every time during daemon start process. It contains a
|
||||||
simple handler calls \ref isc::dhcp::configureDhcp6Server() method that
|
isc::data::ConstElementPtr to a new configuration. This simple handler calls
|
||||||
processes received configuration.
|
\ref isc::dhcp::configureDhcp6Server() method that processes received configuration.
|
||||||
|
|
||||||
This method iterates over list of received configuration elements and creates
|
This method iterates over list of received configuration elements and creates a
|
||||||
a list of parsers for each received entry. Parser is an object that is derived
|
list of parsers for each received entry. Parser is an object that is derived
|
||||||
from a \ref Dhcp6ConfigParser class. Once a parser is created (constructor),
|
from a \ref isc::dhcp::Dhcp6ConfigParser class. Once a parser is created
|
||||||
its value is set (using build() method). Once all parsers are build, the
|
(constructor), its value is set (using build() method). Once all parsers are
|
||||||
configuration is then applied ("commited") and commit() method is called.
|
build, the configuration is then applied ("commited") and commit() method is
|
||||||
|
called.
|
||||||
|
|
||||||
All parsers are defined in src/bin/dhcp6/config_parser.cc file. Some
|
All parsers are defined in src/bin/dhcp6/config_parser.cc file. Some of them
|
||||||
of them are generic (e.g. \ref Uint32Parser that is able to handle
|
are generic (e.g. \ref isc::dhcp::Uint32Parser that is able to handle any
|
||||||
any unsigned 32 bit integer), but some are very specialized
|
unsigned 32 bit integer), but some are very specialized (e.g. \ref
|
||||||
(e.g. \ref Subnets6ListConfigParser parses definitions of Subnet6 lists). In
|
isc::dhcp::Subnets6ListConfigParser parses definitions of Subnet6 lists). In
|
||||||
some cases, e.g. subnet6 definitions, the configuration entry is not a simple
|
some cases, e.g. subnet6 definitions, the configuration entry is not a simple
|
||||||
value, but a map or a list itself. In such case, the parser iterates over
|
value, but a map or a list itself. In such case, the parser iterates over all
|
||||||
all elements and creates parsers for a given scope. This process may be
|
elements and creates parsers for a given scope. This process may be repeated
|
||||||
repeated (sort of) recursively.
|
(sort of) recursively.
|
||||||
|
|
||||||
@section dhcpv6-config-inherit DHCPv6 Configuration Inheritance
|
@section dhcpv6-config-inherit DHCPv6 Configuration Inheritance
|
||||||
|
|
||||||
One notable useful features of DHCP configuration is its parameter inheritance.
|
One notable useful features of DHCP configuration is its parameter inheritance.
|
||||||
For example, renew-timer value may be specified at a global scope and it
|
For example, renew-timer value may be specified at a global scope and it then
|
||||||
then applies to all subnets. However, some subnets may have it overwritten
|
applies to all subnets. However, some subnets may have it overwritten with more
|
||||||
with more specific values that takes precedence over global values that are
|
specific values that takes precedence over global values that are considered
|
||||||
considered defaults. Some parsers (e.g. \ref Uint32ConfigParser and
|
defaults. Some parsers (e.g. \ref isc::dhcp::Uint32Parser and \ref
|
||||||
\StringParser) implement that inheritance. By default, they store values in
|
isc::dhcp::StringParser) implement that inheritance. By default, they store
|
||||||
global uint32_defaults and string_defaults storages. However, it is possible
|
values in global uint32_defaults and string_defaults storages. However, it is
|
||||||
to instruct them to store parsed values in more specific storages. That
|
possible to instruct them to store parsed values in more specific
|
||||||
capability is used, e.g. in \ref Subnet6ConfigParser that has its own storage
|
storages. That capability is used, e.g. in \ref isc::dhcp::Subnet6ConfigParser
|
||||||
that is unique for each subnet. Finally, during commit phase (commit() method),
|
that has its own storage that is unique for each subnet. Finally, during commit
|
||||||
appropriate parsers can use apply parameter inheritance.
|
phase (commit() method), appropriate parsers can use apply parameter inheritance.
|
||||||
|
|
||||||
Debugging configuration parser may be confusing. Therefore there is a special
|
Debugging configuration parser may be confusing. Therefore there is a special
|
||||||
class called \ref DummyParser. It does not configure anything, but just accepts
|
class called \ref isc::dhcp::DummyParser. It does not configure anything, but just
|
||||||
any parameter of any type. If requested to commit configuration, it will print
|
accepts any parameter of any type. If requested to commit configuration, it will
|
||||||
out received parameter name and its value. This class is not currently used,
|
print out received parameter name and its value. This class is not currently used,
|
||||||
but it is convenient to have it every time a new parameter is added to DHCP
|
but it is convenient to have it every time a new parameter is added to DHCP
|
||||||
configuration. For that purpose it should be left in the code.
|
configuration. For that purpose it should be left in the code.
|
||||||
|
|
||||||
@ -76,5 +77,3 @@
|
|||||||
do not implement any fancy inheritance logic.
|
do not implement any fancy inheritance logic.
|
||||||
|
|
||||||
*/
|
*/
|
||||||
|
|
||||||
|
|
||||||
|
Loading…
x
Reference in New Issue
Block a user