// Copyright (C) 2012  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 dhcp6 DHCPv6 Server Component

 BIND10 offers DHCPv6 server implementation. It is implemented as
 b10-dhcp6 component. Its primary code is located in
 isc::dhcp::Dhcpv6Srv class. It uses \ref libdhcp extensively,
 especially lib::dhcp::Pkt6, 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.

 DHCPv6 server component does not support relayed traffic yet, as
 support for relay decapsulation is not implemented yet.

 DHCPv6 server component does not use BIND10 logging yet.

 @section dhcpv6Session BIND10 message queue integration

 DHCPv4 server component is now integrated with BIND10 message queue.
 It follows the same principle as DHCPv4. See \ref dhcpv4Session for
 details.

 @section dhcpv6ConfigParser Configuration Parser in DHCPv6

 b10-dhcp6 component uses BIND10 cfgmgr for commands and configuration. During
 initial configuration (See \ref
 isc::dhcp::ControlledDhcpv6Srv::establishSession()), the configuration handler
 callback is installed (see isc::dhcp::ControlledDhcpv6Srv::dhcp6ConfigHandler().
 It is called every time there is a new configuration. In particular, it is
 called every time during daemon start process. It contains a
 isc::data::ConstElementPtr to a new configuration.  This simple handler calls
 \ref isc::dhcp::configureDhcp6Server() method that processes received configuration.

 This method iterates over list of received configuration elements and creates a
 list of parsers for each received entry. Parser is an object that is derived
 from a DhcpConfigParser class. Once a parser is created
 (constructor), its value is set (using build() method). Once all parsers are
 build, the configuration is then applied ("committed") and commit() method is
 called.

 All parsers are defined in src/bin/dhcp6/config_parser.cc file. Some of them
 are generic (e.g. Uint32Parser that is able to handle any
 unsigned 32 bit integer), but some are very specialized (e.g.
 Subnets6ListConfigParser parses definitions of Subnet6 lists). In 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 all elements
 and creates parsers for a given scope. This process may be repeated (sort of)
 recursively.

 @section dhcpv6ConfigInherit DHCPv6 Configuration Inheritance

 One notable useful feature of DHCP configuration is its parameter inheritance.
 For example, renew-timer value may be specified at a global scope and it then
 applies to all subnets. However, some subnets may have it overwritten with more
 specific values that takes precedence over global values that are considered
 defaults. Some parsers (e.g. Uint32Parser and StringParser) implement that
 inheritance. By default, they store values in global uint32_defaults and
 string_defaults storages. However, it is possible to instruct them to store
 parsed values in more specific storages. That capability is used, e.g. in
 Subnet6ConfigParser that has its own storage that is unique for each subnet.
 Finally, during commit phase (commit() method), appropriate parsers can use
 apply parameter inheritance.

 Debugging configuration parser may be confusing. Therefore there is a special
 class called DebugParser. It does not configure anything, but just
 accepts any parameter of any type. If requested to commit configuration, it will
 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
 configuration. For that purpose it should be left in the code.

 Parameter inheritance is done during reconfiguration phase, as reconfigurations
 are rare, so extra logic here is not a problem. On the other hand, values of
 those parameters may be used thousands times per second, so its use must be as
 simple as possible. In fact, currently the code has to call Subnet6->getT1() and
 do not implement any fancy inheritance logic.

 @todo Add section about setting up options and their definitions with bindctl.

 @section dhcpv6Other Other DHCPv6 topics

 For hooks API support in DHCPv6, see @ref dhcpv6Hooks.

 */
