From: Tomek Mrugalski Date: Tue, 4 Feb 2014 12:54:01 +0000 (+0100) Subject: [3274] DHCPv4 section of User's Guide written X-Git-Tag: bind10-1.2.0beta1-release~57^2~1^2~9 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=d52f14789d9dc775b3a7f8da71dcd923affb2168;p=thirdparty%2Fkea.git [3274] DHCPv4 section of User's Guide written --- diff --git a/doc/guide/bind10-guide.xml b/doc/guide/bind10-guide.xml index 88425e2dfd..0eee9f80fa 100644 --- a/doc/guide/bind10-guide.xml +++ b/doc/guide/bind10-guide.xml @@ -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). This is the reference guide for BIND 10 version &__VERSION__;. @@ -3523,7 +3523,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. + 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 is called Kea6. This chapter covers those parts of BIND 10 that are common to both servers. DHCPv4-specific details are covered in , while those details specific to DHCPv6 are described in @@ -4383,7 +4385,86 @@ Dhcp4/subnet4 [] list (default) e.g. "123" - would then be assigned to the uint16 field in the "container" option. - + +
+ Client Classification in DHCPv4 + + + 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. + + + 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 "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 are only two mechanisms that are taking + advantage of client classification: specific processing for cable modems and + subnet selection. + + + 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. + + + + 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 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 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: + +> config add Dhcp4/subnet4 +> config set Dhcp4/subnet4[0]/subnet "192.0.2.0/24" +> config set Dhcp4/subnet4[0]/pool [ "192.0.2.10 - 192.0.2.20" ] +> config set Dhcp4/subnet4[0]/client-class "docsis3.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. + +
+ + +
Server Identifier in DHCPv4 @@ -4401,6 +4482,7 @@ Dhcp4/subnet4 [] list (default)
+
Next server (siaddr) In some cases, clients want to obtain configuration from the TFTP server. @@ -4467,6 +4549,8 @@ Dhcp4/subnet4 [] list (default) RFC 3046: Relay Agent Information option is supported. + + RFC 6842: Server by default sends back client-id option. That capability may be disabled. See for details. diff --git a/src/bin/dhcp4/dhcp4.dox b/src/bin/dhcp4/dhcp4.dox index aa43ee3267..5182f73794 100644 --- a/src/bin/dhcp4/dhcp4.dox +++ b/src/bin/dhcp4/dhcp4.dox @@ -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.