Commit e07be6f5 authored by Mukund Sivaraman's avatar Mukund Sivaraman
Browse files

Merge branch 'master' into trac2168

Conflicts:
	src/lib/dns/tests/rdata_nsec3param_like_unittest.cc
	src/lib/dns/tests/rdata_nsecbitmap_unittest.cc
parents 195af9e4 ff454194
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
client classes. It is possible to restrict subnet usage to a given
client class. User's Guide and Developer's Guide has been updated.
(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.
(Trac# 3299, git dbacf27ece77f3d857da793341c6bd31ef1ea239)
748. [bug] marcin
b10-dhcp4 server picks a subnet, to assign address for a directly
connected client, using IP address of the interface on which the
client's message has been received. If the message is received on
the interface for which there is no suitable subnet, the message
is discarded. Also, the subnet for renewing client which unicasts
its request, is selected using ciaddr.
(Trac #3242, git 9e571cc217d6b1a2fd6fdae1565fcc6fde6d08b1)
747. [bug] marcin
libdhcpsrv: server configuration mechanism allows creating definitions
for standard options for which Kea doesn't provide a definition yet.
Without this, the server administrator couldn't configure options for
which a definition didn't exist.
(Trac# 3309, git 16a6ed6e48a6a950670c4874a2e81b1faf287d99)
746. [func] tomek
IOAddress no longer exposes underlying asio objects. The getAddress()
method has been removed and replaced with several convenience methods.
......
......@@ -39,7 +39,7 @@
servers with development managed by Internet Systems Consortium (ISC).
It includes DNS libraries, modular components for controlling
authoritative and recursive DNS servers, and experimental DHCPv4
and DHCPv6 servers.
and DHCPv6 servers (codenamed Kea).
</para>
<para>
This is the reference guide for BIND 10 version &__VERSION__;.
......@@ -3536,7 +3536,9 @@ then change those defaults with config set Resolver/forward_addresses[0]/address
clients. Even though principles of both DHCPv4 and DHCPv6 are
somewhat similar, these are two radically different
protocols. BIND 10 offers two server implementations, one for DHCPv4
and one for DHCPv6.</para>
and one for DHCPv6. The DHCP part of the BIND 10 project is codenamed
Kea. The DHCPv4 component is colloquially referred to as Kea4 and its
DHCPv6 counterpart is called Kea6.</para>
<para>This chapter covers those parts of BIND 10 that are common to
both servers. DHCPv4-specific details are covered in <xref linkend="dhcp4"/>,
while those details specific to DHCPv6 are described in <xref linkend="dhcp6"/>
......@@ -3644,6 +3646,14 @@ $</screen>
<screen>
&gt; <userinput>config remove Init/components b10-dhcp4</userinput>
&gt; <userinput>config commit</userinput>
</screen>
</para>
<para>
Note that the server was only removed from the list, so BIND10 will not
restart it, but the server itself is still running. Hence it is usually
desired to stop it:
<screen>
&gt; <userinput>Dhcp4 shutdown</userinput>
</screen>
</para>
......@@ -3816,7 +3826,7 @@ Dhcp4/subnet4 [] list (default)
</section>
<section id="dhcp4-address-config">
<title>Configuration of Address Pools</title>
<title>Configuration of IPv4 Address Pools</title>
<para>
The essential role of DHCPv4 server is address assignment. The server
has to be configured with at least one subnet and one pool of dynamic
......@@ -3975,6 +3985,20 @@ Dhcp4/subnet4 [] list (default)
</para>
<!-- @todo: describe record types -->
<para>
The <xref linkend="dhcp4-custom-options"/> describes the configuration
syntax to create custom option definitions (formats). It is generally not
allowed to create custom definitions for standard options, even if the
definition being created matches the actual option format defined in the
RFCs. There is an exception from this rule for standard options for which
Kea does not provide a definition yet. In order to use such options,
a server administrator must create a definition as described in
<xref linkend="dhcp4-custom-options"/> in the 'dhcp4' option space. This
definition should match the option format described in the relevant
RFC but configuration mechanism would allow any option format as it has
no means to validate it at the moment.
</para>
<para>
<table frame="all" id="dhcp4-std-options-list">
<title>List of standard DHCPv4 options</title>
......@@ -4396,7 +4420,87 @@ Dhcp4/subnet4 [] list (default)
e.g. "123" - would then be assigned to the uint16 field in the "container" option.
</para>
</section>
</section>
<section id="dhcp4-client-classifier">
<title>Client Classification in DHCPv4</title>
<note>
<para>
DHCPv4 server has been extended to support limited client classification.
Although the current capability is modest, it is expected to be expanded
in the future. It is envisaged that the majority of client classification
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>
<para>It is envisaged that the client classification will be used for changing
behavior of almost any part of the DHCP message processing, including assigning
leases from different pools, assigning different option (or different values of
the same options) etc. For now, there are only two mechanisms that are taking
advantage of client classification: specific processing for cable modems and
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.
</para>
<para>
Kea can be instructed to limit access to given subnets based on class information.
This is particularly useful for cases where two types of devices share the
same link and are expected to be served from two different subnets. The
primary use case for such a scenario is cable networks. There are two
classes of devices: cable modem itself, which should be handled a lease
from subnet A and all other devices behind modems that should get a lease
from subnet B. That segregation is essential to prevent overly curious
users from playing with their cable modems. For details on how to set up
class restrictions on subnets, see <xref linkend="dhcp4-subnet-class"/>.
</para>
</section>
<section id="dhcp4-subnet-class">
<title>Limiting access to IPv4 subnet to certain classes</title>
<para>
In certain cases it beneficial to restrict access to certain subnets
only to clients that belong to a given subnet. For details on client
classes, see <xref linkend="dhcp4-client-classifier"/>. This is an
extension of a previous example from <xref linkend="dhcp4-address-config"/>.
Let's assume that the server is connected to a network segment that uses
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:
<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 commit</userinput></screen>
</para>
<para>
Care should be taken with client classification as it is easy to prevent
clients that do not meet class criteria to be denied any service altogether.
</para>
</section>
</section> <!-- end of configuring DHCPv4 server section with many subsections -->
<section id="dhcp4-serverid">
<title>Server Identifier in DHCPv4</title>
<para>
......@@ -4414,6 +4518,7 @@ Dhcp4/subnet4 [] list (default)
</para>
</section>
<section id="dhcp4-next-server">
<title>Next server (siaddr)</title>
<para>In some cases, clients want to obtain configuration from the TFTP server.
......@@ -4461,6 +4566,40 @@ Dhcp4/subnet4 [] list (default)
</section>
<section id="dhcp4-subnet-selection">
<title>How DHCPv4 server selects subnet for a client</title>
<para>
The DHCPv4 server differentiates between the directly connected clients,
clients trying to renew leases and clients sending their messages through
relays. For the directly connected clients the server will check the
configuration of the interface on which the message has been received, and
if the server configuration doesn't match any configured subnet the
message is discarded.</para>
<para>Assuming that the server's interface is configured with the 192.0.2.3
IPv4 address, the server will only process messages received through
this interface from the directly connected client, if there is a subnet
configured, to which this IPv4 address belongs, e.g. 192.0.2.0/24.
The server will use this subnet to assign IPv4 address for the client.
</para>
<para>
The rule above does not apply when the client unicasts its message, i.e.
is trying to renew its lease. Such message is accepted through any
interface. The renewing client sets ciaddr to the currently used IPv4
address. The server uses this address to select the subnet for the client
(in particular, to extend the lease using this address).
</para>
<para>
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>
<note>
<para>The subnet selection mechanism described in this section is based
on the assumption that client classification is not used. The classification
mechanism alters the way in which subnet is selected for the client,
depending on the clasess that the client belongs to.</para>
</note>
</section>
<section id="dhcp4-std">
<title>Supported Standards</title>
<para>The following standards and draft standards are currently
......@@ -4480,6 +4619,8 @@ Dhcp4/subnet4 [] list (default)
<listitem>
<simpara><ulink url="http://tools.ietf.org/html/rfc3046">RFC 3046</ulink>:
Relay Agent Information option is supported.</simpara>
</listitem>
<listitem>
<simpara><ulink url="http://tools.ietf.org/html/rfc6842">RFC 6842</ulink>:
Server by default sends back client-id option. That capability may be
disabled. See <xref linkend="dhcp4-echo-client-id"/> for details.
......@@ -4574,13 +4715,21 @@ Dhcp4/renew-timer 1000 integer (default)
</para>
<para>
To remove <command>b10-dhcp6</command> from the set of running services,
the <command>b10-dhcp4</command> is removed from list of Init components:
the <command>b10-dhcp6</command> is removed from list of Init components:
<screen>
&gt; <userinput>config remove Init/components b10-dhcp6</userinput>
&gt; <userinput>config commit</userinput>
</screen>
</para>
<para>
Note that the server was only removed from the list, so BIND10 will not
restart it, but the server itself is still running. Hence it is usually
desired to stop it:
<screen>
&gt; <userinput>Dhcp6 shutdown</userinput>
</screen>
</para>
<para>
During start-up the server will detect available network interfaces
......@@ -4786,7 +4935,7 @@ Dhcp6/subnet6/ list
</para>
</section>
<section>
<section id="dhcp6-address-config">
<title>Subnet and Address Pool</title>
<para>
The essential role of a DHCPv6 server is address assignment. For this,
......@@ -4978,6 +5127,21 @@ Dhcp6/subnet6/ list
<!-- @todo: describe record types -->
<para>
The <xref linkend="dhcp6-custom-options"/> describes the configuration
syntax to create custom option definitions (formats). It is generally not
allowed to create custom definitions for standard options, even if the
definition being created matches the actual option format defined in the
RFCs. There is an exception from this rule for standard options for which
Kea does not provide a definition yet. In order to use such options,
a server administrator must create a definition as described in
<xref linkend="dhcp6-custom-options"/> in the 'dhcp6' option space. This
definition should match the option format described in the relevant
RFC but configuration mechanism would allow any option format as it has
no means to validate it at the moment.
</para>
<para>
<table frame="all" id="dhcp6-std-options-list">
<title>List of standard DHCPv6 options</title>
......@@ -5290,7 +5454,7 @@ should include options from the isc option space:
</section>
<section id="dhcp6-config-subnets">
<title>Subnet Selection</title>
<title>IPv6 Subnet Selection</title>
<para>
The DHCPv6 server may receive requests from local (connected to the
same subnet as the server) and remote (connecting via relays) clients.
......@@ -5378,6 +5542,76 @@ should include options from the isc option space:
</para>
</section>
<section id="dhcp6-client-classifier">
<title>Client Classification in DHCPv6</title>
<note>
<para>
DHCPv6 server has been extended to support limited client classification.
Although the current capability is modest, it is expected to be expanded
in the future. It is envisaged that the majority of client classification
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 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;.
</para>
<para>It is envisaged that the client classification will be used for changing
behavior of almost any part of the DHCP engine processing, including assigning
leases from different pools, assigning different option (or different values of
the same options) etc. For now, there is only one mechanism that is taking
advantage of client classification: subnet selection.</para>
<para>
Kea can be instructed to limit access to given subnets based on class information.
This is particularly useful for cases where two types of devices share the
same link and are expected to be served from two different subnets. The
primary use case for such a scenario are cable networks. There are two
classes of devices: cable modem itself, which should be handled a lease
from subnet A and all other devices behind modems that should get a lease
from subnet B. That segregation is essential to prevent overly curious
users from playing with their cable modems. For details on how to set up
class restrictions on subnets, see <xref linkend="dhcp6-subnet-class"/>.
</para>
</section>
<section id="dhcp6-subnet-class">
<title>Limiting access to IPv6 subnet to certain classes</title>
<para>
In certain cases it beneficial to restrict access to certains subnets
only to clients that belong to a given subnet. For details on client
classes, see <xref linkend="dhcp6-client-classifier"/>. This is an
extension of a previous example from <xref linkend="dhcp6-address-config"/>.
Let's assume that the server is connected to a network segment that uses
the 2001:db8:1::/64 prefix. The Administrator of that network has
decided that addresses from range 2001:db8:1::1 to 2001:db8:1::ffff are
going to be managed by the Dhcp6 server. Only clients belonging to the
eRouter1.0 client class are allowed to use that pool. Such a
configuration can be achieved in the following way:
<screen>
&gt; <userinput>config add Dhcp6/subnet6</userinput>
&gt; <userinput>config set Dhcp6/subnet6[0]/subnet "2001:db8:1::/64"</userinput>
&gt; <userinput>config set Dhcp6/subnet6[0]/pool [ "2001:db8:1::0 - 2001:db8:1::ffff" ]</userinput>
&gt; <userinput>config set Dhcp6/subnet6[0]/client-class "eRouter1.0"</userinput>
&gt; <userinput>config commit</userinput></screen>
</para>
<para>
Care should be taken with client classification as it is easy to prevent
clients that do not meet class criteria to be denied any service altogether.
</para>
</section>
</section>
<section id="dhcp6-serverid">
......
......@@ -22,6 +22,7 @@
#include <dns/message.h>
#include <dns/master_loader.h>
#include <dns/name.h>
#include <dns/labelsequence.h>
#include <dns/nsec3hash.h>
#include <dns/opcode.h>
#include <dns/rcode.h>
......@@ -245,6 +246,13 @@ public:
isc_throw(isc::Unexpected, "unexpected name for NSEC3 test: "
<< name);
}
virtual string calculate(const LabelSequence& ls) const {
assert(ls.isAbsolute());
// This is not very optimal, but it's only going to be used in
// tests.
const Name name(ls.toText());
return (calculate(name));
}
virtual bool match(const rdata::generic::NSEC3PARAM&) const {
return (true);
}
......
// Copyright (C) 2013 Internet Systems Consortium, Inc. ("ISC")
// 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
......@@ -588,10 +588,13 @@ NameAddTransaction::buildAddFwdAddressRequest() {
// Next build the Update Section.
// Create the TTL based on lease length.
dns::RRTTL lease_ttl(getNcr()->getLeaseLength());
// Create the FQDN/IP 'add' RR and add it to the to update section.
// Based on RFC 2136, section 2.5.1
dns::RRsetPtr update(new dns::RRset(fqdn, dns::RRClass::IN(),
getAddressRRType(), dns::RRTTL(0)));
getAddressRRType(), lease_ttl));
addLeaseAddressRdata(update);
request->addRRset(D2UpdateMessage::SECTION_UPDATE, update);
......@@ -599,7 +602,7 @@ NameAddTransaction::buildAddFwdAddressRequest() {
// Now create the FQDN/DHCID 'add' RR and add it to update section.
// Based on RFC 2136, section 2.5.1
update.reset(new dns::RRset(fqdn, dns::RRClass::IN(),
dns::RRType::DHCID(), dns::RRTTL(0)));
dns::RRType::DHCID(), lease_ttl));
addDhcidRdata(update);
request->addRRset(D2UpdateMessage::SECTION_UPDATE, update);
......@@ -635,6 +638,9 @@ NameAddTransaction::buildReplaceFwdAddressRequest() {
// Next build the Update Section.
// Create the TTL based on lease length.
dns::RRTTL lease_ttl(getNcr()->getLeaseLength());
// Create the FQDN/IP 'delete' RR and add it to the update section.
// Based on RFC 2136, section 2.5.2
dns::RRsetPtr update(new dns::RRset(fqdn, dns::RRClass::ANY(),
......@@ -644,7 +650,7 @@ NameAddTransaction::buildReplaceFwdAddressRequest() {
// Create the FQDN/IP 'add' RR and add it to the update section.
// Based on RFC 2136, section 2.5.1
update.reset(new dns::RRset(fqdn, dns::RRClass::IN(),
getAddressRRType(), dns::RRTTL(0)));
getAddressRRType(), lease_ttl));
addLeaseAddressRdata(update);
request->addRRset(D2UpdateMessage::SECTION_UPDATE, update);
......@@ -661,6 +667,9 @@ NameAddTransaction::buildReplaceRevPtrsRequest() {
std::string rev_addr = D2CfgMgr::reverseIpAddress(getNcr()->getIpAddress());
dns::Name rev_ip(rev_addr);
// Create the TTL based on lease length.
dns::RRTTL lease_ttl(getNcr()->getLeaseLength());
// Content on this request is based on RFC 4703, section 5.4
// Reverse replacement has no prerequisites so straight on to
// building the Update section.
......@@ -678,14 +687,14 @@ NameAddTransaction::buildReplaceRevPtrsRequest() {
// Create the FQDN/IP PTR 'add' RR, add the FQDN as the PTR Rdata
// then add it to update section.
update.reset(new dns::RRset(rev_ip, dns::RRClass::IN(),
dns::RRType::PTR(), dns::RRTTL(0)));
dns::RRType::PTR(), lease_ttl));
addPtrRdata(update);
request->addRRset(D2UpdateMessage::SECTION_UPDATE, update);
// Create the FQDN/IP PTR 'add' RR, add the DHCID Rdata
// then add it to update section.
update.reset(new dns::RRset(rev_ip, dns::RRClass::IN(),
dns::RRType::DHCID(), dns::RRTTL(0)));
dns::RRType::DHCID(), lease_ttl));
addDhcidRdata(update);
request->addRRset(D2UpdateMessage::SECTION_UPDATE, update);
......
......@@ -427,15 +427,19 @@ void checkAddFwdAddressRequest(NameChangeTransaction& tran) {
// Should be 2 RRs: 1 to add the FQDN/IP and one to add the DHCID RR
checkRRCount(request, D2UpdateMessage::SECTION_UPDATE, 2);
// Fetch ttl.
uint32_t ttl = ncr->getLeaseLength();
// First, Verify the FQDN/IP add RR.
ASSERT_TRUE(rrset = getRRFromSection(request, D2UpdateMessage::
SECTION_UPDATE, 0));
checkRR(rrset, exp_fqdn, dns::RRClass::IN(), exp_ip_rr_type, 0, ncr);
checkRR(rrset, exp_fqdn, dns::RRClass::IN(), exp_ip_rr_type, ttl, ncr);
// Now, verify the DHCID add RR.
ASSERT_TRUE(rrset = getRRFromSection(request, D2UpdateMessage::
SECTION_UPDATE, 1));
checkRR(rrset, exp_fqdn, dns::RRClass::IN(), dns::RRType::DHCID(), 0, ncr);
checkRR(rrset, exp_fqdn, dns::RRClass::IN(), dns::RRType::DHCID(),
ttl, ncr);
// Verify there are no RRs in the ADDITIONAL Section.
checkRRCount(request, D2UpdateMessage::SECTION_ADDITIONAL, 0);
......@@ -483,6 +487,9 @@ void checkReplaceFwdAddressRequest(NameChangeTransaction& tran) {
// adds the new one.
checkRRCount(request, D2UpdateMessage::SECTION_UPDATE, 2);
// Fetch ttl.
uint32_t ttl = ncr->getLeaseLength();
// Verify the FQDN delete RR.
ASSERT_TRUE(rrset = getRRFromSection(request, D2UpdateMessage::
SECTION_UPDATE, 0));
......@@ -491,7 +498,7 @@ void checkReplaceFwdAddressRequest(NameChangeTransaction& tran) {
// Verify the FQDN/IP add RR.
ASSERT_TRUE(rrset = getRRFromSection(request, D2UpdateMessage::
SECTION_UPDATE, 1));
checkRR(rrset, exp_fqdn, dns::RRClass::IN(), exp_ip_rr_type, 0, ncr);
checkRR(rrset, exp_fqdn, dns::RRClass::IN(), exp_ip_rr_type, ttl, ncr);
// Verify there are no RRs in the ADDITIONAL Section.
checkRRCount(request, D2UpdateMessage::SECTION_ADDITIONAL, 0);
......@@ -520,6 +527,9 @@ void checkReplaceRevPtrsRequest(NameChangeTransaction& tran) {
// Verify there are no RRs in the PREREQUISITE Section.
checkRRCount(request, D2UpdateMessage::SECTION_PREREQUISITE, 0);
// Fetch ttl.
uint32_t ttl = ncr->getLeaseLength();
// Verify the UPDATE Section.
// It should contain 4 RRs:
// 1. A delete all PTR RRs for the given IP
......@@ -545,13 +555,13 @@ void checkReplaceRevPtrsRequest(NameChangeTransaction& tran) {
ASSERT_TRUE(rrset = getRRFromSection(request, D2UpdateMessage::
SECTION_UPDATE, 2));
checkRR(rrset, exp_rev_addr, dns::RRClass::IN(), dns::RRType::PTR(),
0, ncr);
ttl, ncr);
// Verify the DHCID add RR.
ASSERT_TRUE(rrset = getRRFromSection(request, D2UpdateMessage::
SECTION_UPDATE, 3));
checkRR(rrset, exp_rev_addr, dns::RRClass::IN(), dns::RRType::DHCID(),
0, ncr);
ttl, ncr);
// Verify there are no RRs in the ADDITIONAL Section.
checkRRCount(request, D2UpdateMessage::SECTION_ADDITIONAL, 0);
......
// Copyright (C) 2012-2013 Internet Systems Consortium, Inc. ("ISC")
// Copyright (C) 2012-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
......@@ -164,7 +164,7 @@ public:
/// @param ignored first parameter
/// stores global scope parameters, options, option defintions.
Subnet4ConfigParser(const std::string&)
:SubnetConfigParser("", globalContext()) {
:SubnetConfigParser("", globalContext(), IOAddress("0.0.0.0")) {
}
/// @brief Adds the created subnet to a server's configuration.
......@@ -178,6 +178,11 @@ public:
"Invalid cast in Subnet4ConfigParser::commit");
}
// Set relay information if it was parsed
if (relay_info_) {
sub4ptr->setRelayInfo(*relay_info_);
}
isc::dhcp::CfgMgr::instance().addSubnet4(sub4ptr);
}
}
......@@ -200,10 +205,13 @@ protected:
parser = new Uint32Parser(config_id, uint32_values_);
} else if ((config_id.compare("subnet") == 0) ||
(config_id.compare("interface") == 0) ||
(config_id.compare("client-class") == 0) ||
(config_id.compare("next-server") == 0)) {
parser = new StringParser(config_id, string_values_);
} else if (config_id.compare("pool") == 0) {
parser = new Pool4Parser(config_id, pools_);
} else if (config_id.compare("relay") == 0) {
parser = new RelayInfoParser(config_id, relay_info_, Option::V4);
} else if (config_id.compare("option-data") == 0) {
parser = new OptionDataListParser(config_id, options_,
global_context_,
......@@ -292,6 +300,14 @@ protected:
} catch (const DhcpConfigError&) {
// Don't care. next_server is optional. We can live without it
}
// Try setting up client class (if specified)
try {
string client_class = string_values_->getParam("client-class");
subnet4->allowClientClass(client_class);
} catch (const DhcpConfigError&) {
// That's ok if it fails. client-class is optional.
}
}
};
......
// Copyright (C) 2012-2013 Internet Systems Consortium, Inc. ("ISC")
// Copyright (C) 2012-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
......@@ -185,6 +185,12 @@ library. See ticket #3275. The class specific behavior is:
Aforementioned modifications are conducted in @ref isc::dhcp::Dhcpv4Srv::classSpecificProcessing.
It is possible to define class restrictions in subnet, so a given subnet is only
accessible to clients that belong to a given class. That is implemented as isc::dhcp::Pkt4::classes_
being passed in isc::dhcp::Dhcpv4Srv::selectSubnet() to isc::dhcp::CfgMgr::getSubnet4().
Currently this capability is usable, but the number of scenarios it supports is
limited.
@section dhcpv4Other Other DHCPv4 topics
For hooks API support in DHCPv4, see @ref dhcpv4Hooks.
......
......@@ -250,6 +250,28 @@
}
},
{ "item_name": "client-class",
"item_type": "string",
"item_optional": false,
"item_default": "",
"item_description" : "Restricts access to this subnet to specified client class (i