|
|
|
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.
|
|
|
|
1. @sgoldlust reported several doc sections that are unclear and confusing.
|
|
|
|
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.
|
|
|
|
1. Kea doesn't have the ability to create classes on the fly. The idea is that 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.
|
|
|
|
|
|
|
|
# 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 directions
|
|
|
|
|
|
|
|
Direction A: We could change the order to match ISC DHCP
|
|
|
|
|
|
|
|
There are arguments in favor of going the way ISC DHCP with options precedence:
|
|
|
|
1. 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").
|
|
|
|
2. fewer surprises when migrating from ISC DHCP
|
|
|
|
|
|
|
|
Direction B: We could make the order configurable.
|
|
|
|
|
|
|
|
1. + This would allow us to solve all the "but I want the class/pool/subnet options to be sent" requests.
|
|
|
|
1. - If misconfigured, there's a huge potential to shoot your own foot.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#dhcp4-client-classifier |
|
|
|
\ No newline at end of file |