... | ... | @@ -39,7 +39,7 @@ There are arguments in favor of going the way ISC DHCP with options precedence: |
|
|
|
|
|
1. CON: If misconfigured, there's a huge potential to shoot your own foot.
|
|
|
|
|
|
**Action C**: Develop a new hook with classes templates. Kea doesn't have the ability to create classes on the fly. The idea is that user would define templates, similar to flex-id expressions. In a way it would be flex-id for classes. 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 material.
|
|
|
**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 material.
|
|
|
|
|
|
**Action D**: _add your proposal here_
|
|
|
|
... | ... | |