Commit ab8c4956 authored by Tomek Mrugalski's avatar Tomek Mrugalski 🛰
Browse files

[3203] Developer's guide update

parent daa4b00d
......@@ -59,6 +59,7 @@
* - @subpage dhcpv4ConfigInherit
* - @subpage dhcpv4OptionsParse
* - @subpage dhcpv4DDNSIntegration
* - @subpage dhcpv4Classifier
* - @subpage dhcpv4Other
* - @subpage dhcp6
* - @subpage dhcpv6Session
......@@ -66,6 +67,7 @@
* - @subpage dhcpv6ConfigInherit
* - @subpage dhcpv6DDNSIntegration
* - @subpage dhcpv6OptionsParse
* - @subpage dhcpv6Classifier
* - @subpage dhcpv6Other
* - @subpage libdhcp
* - @subpage libdhcpIntro
......
......@@ -155,6 +155,36 @@ The default behaviour is constituted by the set of constants defined in the
(upper part of) dhcp4_srv.cc file. Once the configuration is implemented,
these constants will be removed.
@section dhcpv4Classifier DHCPv4 Client Classification
Kea DHCPv4 server currently supports simplified client classification. It is called
"simplified", because the incoming packets are classified based on the content
of the vendor class (60) option. More flexible classification is planned, but there
are no specific development dates agreed.
For each incoming packet, @ref isc::dhcp::Dhcpv4Srv::classifyPacket() method is called.
It attempts to extract content of the vendor class option and interpret as a name
of the class. For now, the code has been tested with two classes used in cable modem
networks: eRouter1.0 and docsis3.0, but any other content of the vendor class option will
be interpreted as a class name.
In principle any given packet can belong to zero or more classes. As the current
classifier is very modest, there's only one way to assign a class (based on vendor class
option), the ability to assign more than one class to a packet is not yet exercised.
Neverthless, there is such a possibility and it will be used in a near future. To
check whether a packet belongs to given class, isc::dhcp::Pkt4::inClass method should
be used.
Currently there is a short code section that alternates packet processing depending on
which class it belongs to. It is planned to move that capability to an external hook
library. See ticket #3275. The class specific behavior is:
- docsis3.0 packets have siaddr (next server) field set
- docsis3.0 packets have file field set to the content of the boot-file-name option
- eRouter1.0 packets have siaddr (next server) field cleared
Aforementioned modifications are conducted in @ref isc::dhcp::Dhcpv4Srv::classSpecificProcessing.
@section dhcpv4Other Other DHCPv4 topics
For hooks API support in DHCPv4, see @ref dhcpv4Hooks.
......
......@@ -190,6 +190,33 @@ implemented within the context of the server and it has access to all objects
which define its configuration (including dynamically created option
definitions).
@section dhcpv6Classifier DHCPv6 Client Classification
Kea DHCPv6 server currently supports simplified client classification. It is called
"simplified", because the incoming packets are classified based on the content
of the vendor class (16) option. More flexible classification is planned, but there
are no specific development dates agreed.
For each incoming packet, @ref isc::dhcp::Dhcpv6Srv::classifyPacket() method is
called. It attempts to extract content of the vendor class option and interprets
as a name of the class. Although the RFC3315 says that the vendor class may
contain more than one chunk of data, the existing code handles only one data
block, because that is what actual devices use. For now, the code has been
tested with two classes used in cable modem networks: eRouter1.0 and docsis3.0,
but any other content of the vendor class option will be interpreted as a class
name.
In principle any given packet can belong to zero or more classes. As the current
classifier is very modest, there's only one way to assign a class (based on vendor class
option), the ability to assign more than one class to a packet is not yet exercised.
Neverthless, there is such a possibility and it will be used in a near future. To
check whether a packet belongs to given class, isc::dhcp::Pkt6::inClass method should
be used.
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.
@section dhcpv6Other Other DHCPv6 topics
For hooks API support in DHCPv6, see @ref dhcpv6Hooks.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment