I did a little experiment. With a bit of code tweaking, I managed to
force Kea to load two identical subnets that only differed in relay IP
address. It started all fine and I was able to get leases in each subnet.
There's one major caveat, though. Allocation engine, the core part of
the code that picks leases for new clients, can't tell a difference
between them and thinks the address is used, despite it being used in
the other subnet.
My subnets defined were 192.0.2.1 - 192.0.2.200. First client in the
first subnet got 192.0.2.1 (as expected), but the second client in the
second subnet got 192.0.2.2, not 192.0.2.1.
If your subnets are large (e.g. 10.0.0.0/8) you may not care. If they're
smaller, you'll use up all addresses real quick.
To implement it properly, we would have to remove getLeases4(addr) call
and implement getLeases4(addr, subnet-id) instead. There's tons of uses
of getLease4(addr) throughout the whole code (around 200 instances).
This would require a MAJOR rework of Kea code and the reworked code
would probably we worse than it is now. So am afraid it's unlikely to
happen. At least in official master. I can imagine you hacking Kea code
similar way you did dhcpd would be somewhat realistic, if you accept
that certain things will be broken.
Keep in mind that tweaking the code to allocate the leases is only the
first step on this dark and twisted path. The next step that will
probably not work is lease renewal. Then release release. After that
you'll face probably broken lease expiration. Commands related to leases
won't work etc. You can end up with all sorts of messed up situations,
like client from one network renewing a lease from another subnet, then
his lease expiring because not being renewed.
If you really want to go that path, here's a page that described my
Kea-users mailing list