Kea should honor PD length hints if possible
The issue has been brought up in support#18537.
The RFC8415 has the following text:
Client MAY include the IA Prefix option encapsulated within the IA_PD option, with the "IPv6-prefix" field set to 0 and the "prefix-length" field set to the desired length of the prefix to be delegated. The server MAY use this value as a hint for the prefix length.
Kea does not support this mechanism yet.
Here's how the situation could be improved: When configured with a certain address space (e.g.
/48), Kea is told to split it into specific length (e.g.
/56) and delegate however many prefixes from it. This part is fixed and it's not going to change due to a problem with long term fragmentation reasons. To visualize this, imagine a case of
/48 pool intending to be split into 256
/56 prefixes and very liberal policy accepting all prefix hints. In the extreme case clients could request 256 of smallest prefixes available, i.e. each consisting of a single address
/128. Those prefixes could be distributed across the address space in a way that it would no longer be possible to allocate any
/56 prefixes, because there would always be some /128 in place. This extreme case is an exaggeration, but similar problems could happen on a smaller scale. Also, finding "holes" is allocated address space is a hard problem if the allocations are not of the same size.
Saving said that, here's what possibly could be done to improve the situation:
if there are
pd-poolsdefined with different lengths, e.g.
/64, Kea could pick the right pool and allocate from it. Within any given pd-pool there would be only allocations of the same length, but from the client's perspective, its request to get specific prefix length would be honored, as long as it's
In practice, delegating prefixes longer than
/64(65 or more) do not make any sense. The CPE requires PD to use SLAAC on its LAN facing segment. SLAAC to function requires exactly /64 prefix. If the device gets prefix longer (e.g.
/60), it can easily split it into more sub-prefixes and only use one or some of them. In practice, this translates to a common practice of using
/56and very sporadically
It is somewhat feasible to think about allocation policy that when configured with pd-pool with length X, to also accept requests for X-Y and then allocate 2^Y prefixes. This could possibly work for small Y values, e.g. when configured with pool of
/64s, a request for
/63could be accepted with 2 allocations. I'm not sure if such a mechanism would give us much. On the other hand, it could seriously complicate the allocation engine.
Point 1 above looks like the best choice for improving the situation here.