PD design support in Kea

Tomek Mrugalski tomasz at isc.org
Mon Sep 16 13:58:22 UTC 2013


One of the planned tasks were to write up a PD design support. Since we
are in no position to spend lots of time on designs, here's a short
summary of how we plan to implement PD support.

CfgMgr is being updated, so it can handle multiple Pool types. For
Subnet4/Pool4 only one type (TYPE_V4) is allowed. For Subnet6/Pool6
three types are allowed (TYPE_IA, TYPE_TA and TYPE_PD). Each getPool()
method was extended, so it takes extra parameter that specifies pool
type. This is marginally more inconvenient for v4 (type has to be
specified, but there's only one valid type), but it lets us keep unified
interface for both v4 and v6 code. This is essential to keep one
AllocationEngine implementation that can handle both v4 and v6.

Allocation Engine will be extended. v4 part of it will remain as it is
now. If AllocEngine is initialized with v6, there will be 3 allocators
created: one for non-temporary addresses (IA), one for temporary (TA)
and one for delegated prefixes (PD).

Although we have plans to have 3 allocators for regular addresses:
iterative, hashed and random, we currently have only iterative. The plan
is to expand it to cover prefixes as well. Currently the allocator picks
the last tried address, increases it by one and tries if that new
address is available. Once the end of pool is reached, it loops over and
tries from the beginning.

Similar approach will be used for prefixes. The major difference is that
it will not increase by one in each iteration, but by a delegated prefix
length. So for example for a pool 2001:db8::/56 and delegated length of
64, it will go in /64 steps and will cover the whole delegated pool in
256 steps.

I plan to rename a bunch of methods in AllocEngine. allocateAddress6
will become allocateResource6 or allocateLease6 as it will cover both
addresses and prefixes, rather than addresses only.

Ultimately, we will also have hashed allocator (will calculate DUID hash
to pick an address or prefix, and hash of a previous hash if the first
pick is used, rather than iterating one by one) and random allocator
(will randomly pick and address or prefix) as well. It will be possible
to choose a different allocator for each resource type. But that is not
planned in the near future.

Any comments? Suggestions?

I have sent out the configuration proposal in a separate thread. Unless
I hear counter-proposals, this will be the plan for PD implementation.
Once the code is written, I plan to expand Developer's Guide to explain
PD support in more detail.

Tomek


More information about the bind10-dhcp mailing list