[Kea-users] Option 43 - Different formats for different client classes and host reservations

[Andreas]

Thank you Darren and Francis!

My issue is, the Option 43 (without suboption) is device-specific as 
this one is used to provision VoIP Accounts on CPEs, so unfortunately no 
way to set the option data in the client class too.
The option 43 with suboption is not, this is used to push the same 
information to all clients in that class.

I'll give it a try to set the class definition in a special clients 
class, the class data in the reservation and also assign the client 
class in the reservation.


BR
Andreas

Am 29.09.2026 um 10:36 schrieb Darren Ankney:
> Hi Andreas,
>
> To expand on what Francis has said. I think you'll find if you only
> ever set the option 43 definition and/or data inside a client class
> you should be OK.  You can add clients to classes in a reservation:
> https://kea.readthedocs.io/en/stable/arm/dhcp4-srv.html#reserving-client-classes-in-dhcpv4
>
> So, perhaps one class contains these "Special" clients and another
> class contains the not-so-special clients.
>
> Thank you,
> Darren Ankney
>
> On Mon, Sep 28, 2026 at 3:39 PM Andreas <ml+dhcp at tibdefender.com> wrote:
>> Hi Francis,
>>
>> What do you mean by
>>> before the option is decoded.
>> Define the class as the first one in the config? I already tried to do this:
>>
>>    {
>>       // DRG546 Voice
>>       "name": "drg546-voice",
>>       "test": "substring(option[60].text, 0, 11) == 'drg-DRG546s'",
>>           "option-def": [
>>               {
>>                   "name": "vendor-encapsulated-options",
>>                   "code": 43,
>>                   "type": "binary",
>>                   "space": "dhcp4",
>>                   "array": false,
>>                   "encapsulate": ""
>>               }
>>           ],
>>    },
>>
>> and then set the option in the subnet reservation:
>>    {
>>        "ip-address": "10.123.123.2",
>>        "option-data": [
>>            {
>>                "code": 43,
>>                "data": "5446545...",
>>                "name": "vendor-encapsulated-options",
>>                "space": "dhcp4",
>>                "csv-format": false
>>            }
>>        ],
>>        "hw-address": "00:AA:BB:CC:60:ED",
>>    },
>>
>> Obviously this is not working.
>>
>> You mean to define these legacy devices via global reservation? Would
>> that change the behaviour that kea treats the "data"-part as different
>> suboptions like it does in the above example?
>>
>>
>> BR
>> Andreas
>>
>> Am 28.09.2026 um 19:09 schrieb Francis Dupont:
>>> Option 43 is a mess because it is underf specified so you can need
>>> different incompatible ways to decode it. Kea tries to solve this issue
>>> with per class option definition so you only need to put the incoming
>>> query in the right class before the option is decoded. Now it can be
>>> hairy, early global reservation lookup should help...
>>>
>>> Regards
>>>
>>> Francis Dupont <fdupont at isc.org>
>> --
>> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>>
>> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>> Kea-users at lists.isc.org