From: Tomek Mrugalski Date: Tue, 4 Feb 2014 13:03:30 +0000 (+0100) Subject: [3274] DHCPv6 sections about client classification in User's Guide added X-Git-Tag: bind10-1.2.0beta1-release~57^2~1^2~8 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=41328ae3ce0eddddc4bb7c3752ba22b476c1bbf2;p=thirdparty%2Fkea.git [3274] DHCPv6 sections about client classification in User's Guide added --- diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 0eee9f80fa..b2acd633fa 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -3805,7 +3805,7 @@ Dhcp4/subnet4 [] list (default)
- Configuration of Address Pools + Configuration of IPv4 Address Pools 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 @@ -4391,8 +4391,9 @@ Dhcp4/subnet4 [] list (default) DHCPv4 server has been extended to support limited client classification. - Although the current capability is limited, it is expected to be expanded - in the future. + 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. In certain cases it is useful to differentiate between different types @@ -4437,7 +4438,7 @@ Dhcp4/subnet4 [] list (default)
- Limiting access to subnet to certain classes + Limiting access to IPv4 subnet to certain classes In certain cases it beneficial to restrict access to certains subnets only to clients that belong to a given subnet. For details on client @@ -4857,7 +4858,7 @@ Dhcp6/subnet6/ list
-
+
Subnet and Address Pool The essential role of a DHCPv6 server is address assignment. For this, @@ -5361,7 +5362,7 @@ should include options from the isc option space:
- Subnet Selection + IPv6 Subnet Selection The DHCPv6 server may receive requests from local (connected to the same subnet as the server) and remote (connecting via relays) clients. @@ -5449,6 +5450,76 @@ should include options from the isc option space:
+
+ Client Classification in DHCPv6 + + + 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. + + + 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 "docsis3.0" and as a result the + packet will belong to class "docsis3.0". + + + 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. + + + 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 . + + +
+ +
+ Limiting access to IPv6 subnet to certain classes + + 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 . This is an + extension of a previous example from . + + 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: + + +> config add Dhcp6/subnet6 +> config set Dhcp6/subnet6[0]/subnet "2001:db8:1::/64" +> config set Dhcp6/subnet6[0]/pool [ "2001:db8:1::0 - 2001:db8:1::ffff" ] +> config set Dhcp6/subnet6[0]/client-class "eRouter1.0" +> config commit + + + + 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. + +
+
diff --git a/src/bin/dhcp6/dhcp6.dox b/src/bin/dhcp6/dhcp6.dox index c722472b27..3eb6994872 100644 --- a/src/bin/dhcp6/dhcp6.dox +++ b/src/bin/dhcp6/dhcp6.dox @@ -217,6 +217,12 @@ Currently there is no class behaviour coded in DHCPv6, hence no v6 equivalent of @ref isc::dhcp::Dhcpv4Srv::classSpecificProcessing. Should any need for such a code arise, it will be conducted in an external hooks library. +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 dhcpv6Other Other DHCPv6 topics For hooks API support in DHCPv6, see @ref dhcpv6Hooks.