... | ... | @@ -91,21 +91,32 @@ For DHCPv6, we actually need to store the all of the relay message up to but exc |
|
|
Note, that in addition to supporting LeaseQuery, storing relay information for v6 is necessary to support DHCPv6 Reconfigure.
|
|
|
|
|
|
### Data Storage Mechanics
|
|
|
Rather than create a dependency between LeaseQuery and DHCPv6 Reconfigure, or implementing some other mechanism by which the steps to store relay information is not duplicated between them, it is proposed that we implement the ability to store the relay information as feature within Kea core, that is enabled if either of two new Kea core parameters are enabled:
|
|
|
Rather than create a dependency between LeaseQuery and DHCPv6 Reconfigure, or implementing some other mechanism by which the steps to store relay information is not duplicated between them, it is proposed that we implement the ability to store the relay information as feature within Kea core, that is enabled if a the following
|
|
|
new Kea core parameter is enabled:
|
|
|
|
|
|
```
|
|
|
"enable-lease-query" : true/false
|
|
|
"enable-dhcp6-reconfig" : true/false (add during v6 Reconfigure work)
|
|
|
"store-extended-info" : true/false
|
|
|
```
|
|
|
|
|
|
Both would globally default to false and be scoped down to the subnet (possibly pool) level. Any scope for which either is true, would store the additional data on the lease as well as permit that feature for that scope.
|
|
|
|
|
|
This would make it easy to control when the information is added to the lease without introducing additional lease commits or hook points. Users would be able to fine-tune the storage and enable the specific to the network-scopes that suit them.
|
|
|
It would globally default to false and be scoped down to at least the subnet, if not pool level. This will make it easy to control when the information is added to the lease without introducing additional lease commits or hook points. Users would be able to fine-tune the storage and enable the specific to the network-scopes that suit them.
|
|
|
|
|
|
For DHCPv4 we would add a function, **AllocEngine::updateLease4ExtendedInfo()**. When storage is enabled, it would gather the necessary information and update the lease's user-context with it. The function would be invoked from **AllocEngine::createLease4()** and **AllocEngine::updateLease4Information()**. This ensures the data is updated on the lease before the lease is committed to lease storage.
|
|
|
|
|
|
We would take a similarly tact for v6 by adding a function, **AllocEngine::updateLease6ExtendedInfo()** which would update the lease's user-context, when enabled. This would be invoked from **AllocEngine::createLease6()** and **AllocEngine::reuseExpiredLease()**.
|
|
|
|
|
|
### Enabling LeaseQuery (and Dhcpv6 Reconfigure)
|
|
|
|
|
|
The initial implementation will consider either feature globally enabled if their hook library component is enabled.
|
|
|
|
|
|
The original design called for Kea two core parameters as follows:
|
|
|
|
|
|
```
|
|
|
"enable-lease-query" : true/false
|
|
|
"enable-dhcp6-reconfig" : true/false (add during v6 Reconfigure work)
|
|
|
```
|
|
|
|
|
|
Both would globally default to false and be scoped down to the subnet (possibly pool) level. In addition to permitting either feature for that scope, the presence of either would also enable storing the extended data. If we find users want finer grained control we can always add these parameters.
|
|
|
|
|
|
## LeaseQuery Hook Library
|
|
|
|
|
|
Handling of inbound LeaseQuery packets, would be provided by a new hook library, LeaseQuery. The process flow is fairly straight forward and breaks down as follows:
|
... | ... | |