Bulk Leasequery (BLQ) needs to be able to match PDs associated with a link, even if the subnet of the PD is outside of the subnet of the link

I'm reporting this a bug, since this is missing functionality, but functionality that is clearly important operationally, and without this (or a viable workaround) means the use of BLQ by a rebooting router is useless for finding and quickly reprovisioning PDs as well as IAs.

Describe the bug

A router is using BLQ to learn of the existing leases associated with its link following a reboot. Particularly it's interested in the PDs since it's going to need to set up its routing appropriately to the client PDs.

BLQ using query-by-link-address is retrieving only the IAs associated with the link. This is sort of unsurprising since the PDs, although associated with the subnet that matches the link, aren't members of that subnet (this is also unsurprising).

However, in the leases memfile, both the IA and the PD have the same subnet id (the id of the subnet that matches to the link), and the IA, unsurprisingly is an address within that subnet.

• There is no PD pool associated with the subnet in the dhcp6 configuration
• All the PDs are assigned using HRs - but they are associated with the same subnet as the client IA
• I can see in the leases file, that the subnet ID is correct, if BLQ happened internally to be using subnet ID to 'find' leases associated with a link address.

I can't see any other way to get this information currently. The natural way to use BLQ here is to specify the link address (which also does match in the leases database, as well as the subnet ID associated with this link address's subnet). But the underlying lease search code doesn't seem to be using either of these.

How else is a router going to get the list of PDs it should be provisioning? Clearly after just rebooting, it's not going to know what ranges of prefixes have been delegated since PD subnets are independent of the subnet via which they're being delegated anyway.

See details in the customer case linked below.

I've also been discussing the semantics of the documentation and other information around BLQ with Kea Engineering, who have requested that I open this issue.

Environment:

• Kea version: 2.4.0
• OS: N/A
• Using memfile for leases, postgresql for HRs and mysql for config:

...
            "Dhcp6": {
                "allocator": "iterative",
                "calculate-tee-times": true,
                "config-control": {
                    "config-databases": [
                        {
                            "host": "127.0.0.1",
                            "max-reconnect-tries": 30,
                            "name": "kea",
                            "password": "<obscured>",
                            "port": 3306,
                            "reconnect-wait-time": 2000,
                            "type": "mysql",
                            "user": "kea"
                        }
                    ],
                    "config-fetch-wait-time": 60
                },

...
                "lease-database": {
                    "lfc-interval": 3600,
                    "type": "memfile"
                },
...
                "reservations-global": false,
                "reservations-in-subnet": true,
                "reservations-lookup-first": false,
                "reservations-out-of-pool": false,
...
"library": "\/usr\/lib\/x86_64-linux-gnu\/kea\/hooks\/libdhcp_lease_query.so",
                        "parameters": {
                            "advanced": {
                                "active-query-enabled": false,
                                "bulk-query-enabled": true,
                                "extended-info-tables-enabled": true,
                                "lease-query-ip": "<obscured>",
                                "lease-query-tcp-port": 547,
                                "max-bulk-query-threads": 0,
                                "max-concurrent-queries": 0,
                                "max-leases-per-fetch": 100,
                                "max-requester-connections": 10,
                                "max-requester-idle-time": 300
                            },
                            "requesters": [
                                "<obscured>"
                            ]
                        }
                    }
                ],
                "host-reservation-identifiers": [
                    "duid",
                    "flex-id"
                ],
                "hostname-char-replacement": "",
                "hostname-char-set": "[^A-Za-z0-9.-]",
                "hosts-databases": [
                    {
                        "host": "127.0.0.1",
                        "max-reconnect-tries": 30,
                        "name": "kea",
                        "password": "<obscured>",
                        "port": 3306,
                        "reconnect-wait-time": 2000,
                        "type": "mysql",
                        "user": "kea"
                    }
                ],

• Using hooks:

libdhcp_ha.so
libdhcp_mysql_cb.so
libdhcp_host_cmds.so
libdhcp_lease_cmds.so
libdhcp_subnet_cmds.so
libdhcp_cb_cmds.so
libdhcp_flex_id.so
libdhcp_legal_log.so
libdhcp_lease_query.so

Additional Information Here's the operational use case supporting this:

The DHCP BLQ needs to return the PDs including from any reservations. For our use case, PDs are the one thing we are actually looking to grab when using BLQ. Our routers will send a BLQ after they reload so that they can re-populate the PD routes and subscribers v6 networks can begin working again.

Contacting you See SF#1426