... | ... | @@ -112,7 +112,7 @@ Handling of inbound LeaseQuery packets, would be provided by a new hook library, |
|
|
1. LeaseQuery::buffer<4/6>_receive() callout will unpack the query and pass it into a LeaseQuery handler which will:
|
|
|
1. Vet the LeaseQuery query against Access Control (discussed later on). Unauthorized requests will logged and dropped.
|
|
|
1. Search for matching leases
|
|
|
1. Construct the appropriate LeaseQueryResponse - When active leases are found this includes: extracting the needed information from the lease's user-context and based on the client's requested option list. Should we decide to support additional options, we would need to calculate them at this point, potentially using
|
|
|
1. Construct the appropriate LeaseQueryResponse - When active leases are found this includes: extracting the needed information from the lease's user-context and based on the client's requested option list. Should we decide to support additional options, we would need to calculate them at this point.
|
|
|
1. Send the LeaseQuery response
|
|
|
1. LeaseQuery::buffer<4/6>_receive() callout will set status to DROP, causing the
|
|
|
server to go on to the next DHCPX client packet.
|
... | ... | @@ -154,6 +154,14 @@ 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.
|
|
|
|
|
|
### Providing Additional Options
|
|
|
|
|
|
Queries provide a list of requested options which servers "should" provide, when possible. There is also mention
|
|
|
of a "sensitive options list" which servers could be configured with to not supply values deemed sensitive. As discussed earlier, storing options for each lease could have enormous impact on Lease IO. It is suggested here, that we recalculate the desired option values for each the lease(es) being returned in the LeaseQuery response. If we include vendor IDs and possibly client-class lists in the data stored for each lease, we should be able to provide the bulk of options that would be requested.
|
|
|
|
|
|
Whether we implement this initially, or ever is another matter. It is suggested that we wait until we have user feedback as to whether the additional options are important.
|
|
|
|
|
|
|
|
|
## 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.
|
... | ... | |