|
|
This page documents status of client classification as of 1.5.0 (January 2019), lists open issues and discusses possible ways forward.
|
|
|
|
|
|
# Issues
|
|
|
|
|
|
1. Different options order between ISC DHCP and Kea. Kea uses host, pool, subnet, shared network, class, global precedence, while ISC DHCP uses host, class, pool, subnet, shared network, global.
|
|
|
|
|
|
1. Address the long lasting #39. This affects the last two failing DHCPv6 tests*
|
|
|
|
|
|
1. We have require-client-classes and only-if-required. Those features are working, but it seems users are not taking advantage of it, because they're either too complex or not explained clearly. One problem here is that the choice of words is unfortunate. The "required" refers to "required to be evaluated" and not "required to access this subnet/pool".
|
|
|
|
|
|
1. it's tricky to select a subnet based on client classes. You can specify that only clients that belong to a certain client class can use the subnet. This was developed around 2014, years before we had shared networks and we had to support cable modems (and separate cable modems and the devices behind them to different subnets).
|
|
|
|
|
|
1. With the increasing number of classes defined, kea performance drops. This can be mitigated with only-if-required flags. This, however, complicates the setup, because you need to specify in which subnets each class is required.
|
|
|
|
|
|
1. isc dhcp has a spawn client classes mechanism.
|
|
|
|
|
|
1. Whatever we choose to, it has to be documented and explained clearly. @sgoldlust reported several doc sections that are unclear and confusing.
|
|
|
|
|
|
# Goals
|
|
|
|
|
|
1. We need to make the subnet selection based on client classification easier to do. This must take into account client classes added with host reservations. Perhaps global host reservations could do that with some reasonably small tweaking?
|
|
|
|
|
|
1. Need to weigh pros and cons of keeping the options precedence or changing it. In any case, we need to explain our decision and clearly say that it's gonna stay that way.
|
|
|
|
|
|
# Possible actions
|
|
|
|
|
|
**Action A1**: We could change the order to match ISC DHCP
|
|
|
|
|
|
There are arguments in favor of going the way ISC DHCP with options precedence:
|
|
|
1. PRO: some people perceive client classes as more generic host reservations, almost like reservations with wildcards. ("I don't mean this Arris AG561 modem with MAC 01:02:03:04:05:06, I mean all all Arris AG561 modems").
|
|
|
|
|
|
1. PRO: Fewer surprises when migrating from ISC DHCP
|
|
|
|
|
|
1. CON: The obvious drawback is a change for Kea users. Although we warned them in 1.4 release notes that the precedence may change.
|
|
|
|
|
|
**Action A2**: We could keep the order as is.
|
|
|
|
|
|
1. PRO: No surprises when upgrading from existing Kea deployment.
|
|
|
|
|
|
2. CON: Unsolved problem of client classes options not being able to override shared network/subnet options.
|
|
|
|
|
|
**Action A3**: We could make the order configurable.
|
|
|
|
|
|
1. PRO: This would allow us to solve all the "but I want the class/pool/subnet options to be sent" requests.
|
|
|
|
|
|
1. CON: If misconfigured, there's a huge potential to shoot your own foot.
|
|
|
|
|
|
|
|
|
**Action C**: Develop a new hook with classes templates or dynamic classes. Kea doesn't have the ability to create classes on the fly. The idea is that user would define one or more templates, similar to flex-id expressions. It would be for classes what flex-id is for host identifiers. You take a fixed prefix and add a value of some option, e.g. you configure a DEVICE_VENDOR_ prefix and value of first 3 bytes of MAC address. A client sends a packet with MAC address 01:02:03:04:05:06, so the packet is assigned to class DEVICE_VENDOR_01_02_03. There would be one such definition and it would work for all 16 millions of possible values. This would be a rough equivalent to spawn client classes in isc dhcp, except we wouldn't create any long lasting objects in memory. This would be a great subscriber hook material.
|
|
|
|
|
|
**Action D**: change the require-client-classes and only-if-required features into simpler but almost as powerful new features:
|
|
|
- a new flag replacing only-if-required asking for "late evaluation". The name itself is not fully defined but the meaning is clear: all classes with a test member are evaluated (once).
|
|
|
- change host reservation host-classes into add-host-classes (keeping the old name for backward compatibility for next releases) and extend it to all scopes where require-client-classes was allowed. When a scope is matched all classes from the add-host-classes are added to the query. Of course this is performed before the "late evaluation". The order scopes are matched is still to be defined but IMHO we should use the same than for using classes for options to keep consistency.
|
|
|
|
|
|
**Action E**: _add your proposal here_
|
|
|
|
|
|
# References
|
|
|
- https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#client-classification-in-dhcpv4
|
|
|
- https://kea.readthedocs.io/en/latest/arm/dhcp6-srv.html#client-classification-in-dhcpv6
|
|
|
- #39
|
|
|
- [tickers related to classification](https://gitlab.isc.org/isc-projects/kea/issues?scope=all&utf8=%E2%9C%93&state=opened&search=classif)
|
|
|
|
|
|
# Comments
|
|
|
|
|
|
**6**: ISC DHCP uses spawn classes because it has a hard (and small) limit on the number of classes a query can long to.
|
|
|
|
|
|
**4**: subnet or shared network selection is an essential part of the localization which should be done as early as possible and is a critical security feature. Note this notion is common to all DHCP server implementations so Kea and ISC DHCP but in Kea it is mixed with classification (subnet guards) and host reservations (designed to be dependent on the selected subnet) so a part of the topological point of view was lost. The subnet select hook allows to get back control on it but not in a built-in way. |