... | ... | @@ -40,15 +40,14 @@ response construction. The latter approach would offer a deal of flexibility |
|
|
with the least impact to normal DHCPx processing, though we might need to
|
|
|
store some additional information such as the vendor id and client class list.
|
|
|
|
|
|
The basic structure of the solution:
|
|
|
# Design
|
|
|
|
|
|
* Modifications to Kea core to store requisite data
|
|
|
* New LeaseQuery hook library to process inbound LeaseQuery queries
|
|
|
LeaseQuery will be a subscription feature. The proposed design will make modifications to Kea core as as well the creation of a new hook library, LeaseQuery.
|
|
|
|
|
|
# Kea Core Modifications
|
|
|
## Kea Core Modifications
|
|
|
The modifications to Kea core provide the storage of the additional data required, primarily relay-related options), to lease stores.
|
|
|
|
|
|
## Data Storage Content and Format
|
|
|
### Data Storage Content and Format
|
|
|
General consensus during informal discussions has been that the most likely place to store relay information (along with any other data that might be needed by LeaseQuery) would be in the lease's user-context. This would not require any modifications to any of lease back ends.
|
|
|
|
|
|
For DHCPv4 we need to store the relay-agent-info (option 82). Per the RFC 4388, the relay-agent-info should be taken from the most recent DHCPREQUEST that provided it. Recall that DHCPREQUESTs sent as renews or rebinds will not have it.
|
... | ... | @@ -89,7 +88,7 @@ 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
|
|
|
### 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:
|
|
|
|
|
|
```
|
... | ... | @@ -105,7 +104,7 @@ For DHCPv4 we would add a function, **AllocEngine::updateLease4ExtendedInfo()**. |
|
|
|
|
|
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()**.
|
|
|
|
|
|
# LeaseQuery Hook Library
|
|
|
## 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:
|
|
|
|
... | ... | @@ -118,7 +117,7 @@ Handling of inbound LeaseQuery packets, would be provided by a new hook library, |
|
|
1. LeaseQuery::buffer<4/6>_receive() callout will set status to DROP, causing the
|
|
|
server to go on to the next DHCPX client packet.
|
|
|
|
|
|
## Access Control
|
|
|
### Access Control
|
|
|
Two points of access control have been suggested:
|
|
|
|
|
|
* Enabling LeaseQuery only for specific interfaces
|
... | ... | @@ -139,7 +138,7 @@ This is aspect on access control is straight forward. We will limit LeaseQuery q |
|
|
}
|
|
|
```
|
|
|
|
|
|
## Searching for Matching Leases: Use of LeaseMgr
|
|
|
### Searching for Matching Leases: Use of LeaseMgr
|
|
|
LeaseMgr already provides the requisite queries. For DHCPv4 the lease matching process is a straight forward use of the appropriate LeaseMgr functions. There is a case for DHCPv6 though, where additional logic will be needed to narrow the parameters that LeaseMgr queries can be used. These are described in [RFC 5007, Section 4.1.2.1](https://tools.ietf.org/html/rfc5007#section-4.1.2.1):
|
|
|
|
|
|
```
|
... | ... | @@ -155,7 +154,7 @@ LeaseMgr already provides the requisite queries. For DHCPv4 the lease matching |
|
|
If the OPTION_IAADDR address is not explicitly leased, but falls within a pool of prefixes, the server will need infer what the delegated prefix would be and look for
|
|
|
an active lease for that prefix.
|
|
|
|
|
|
# Looking Forward
|
|
|
## Looking Forward
|
|
|
|
|
|
While the scope of this design does not include Bulk LeaseQuery, there is at least one point worth discussing. Bulk LeaseQuery, for both DHCPv4 and DHCPv6, provides for the ability to search for leases by relay attributes such as relay-id, remote-id, link address. In other words, by values within the same information that this design proposes be stored as part of a lease's user-context. The proposed format in this design is store these values opaquely rather than as individual sub-option values. While more efficient for lease storage IO during normal DHCP operations, it may not be the best arrangement for Bulk LeaseQuery performance and may well require walking lists of leases, as opposed to querying against indexes of explicit values.
|
|
|
|
... | ... | |