[kea-dev] DHCP Hackaton summary

Marcin Siodelski marcin at isc.org
Wed Sep 24 12:48:22 UTC 2014

On 24/09/14 14:16, Tomek Mrugalski wrote:
> On 24.09.2014 13:35, Marcin Siodelski wrote:
>> So, I'd really like to see the host reservations in a separate table
>> (see attachment for the proposed database layout). The only reservation
>> that may remain in the Hosts table is an IPv4 reservation (or NULL).
>> Technically, it could also be moved to the reservations table but since
>> IPv4 address is only 4 bytes long it should be rather stored in a column
>> of a different type than the IPv6 address or prefix. So, for performance
>> reasons it doesn't make much sense to store IPV4 address as a text in
>> the same column as IPv6 address.
>> I also point out that the entry in the table with reservations doesn't
>> make sense on its own (Identifying Relationship) so there should
>> probably be triggers on the table with hosts, which removes the
>> reservations from the reservations table before the DELETE operation on
>> the Hosts table. This way, removal of the host entry would trigger
>> removal of all reservations.
>> In addition to the fields that Tomek listed for the options table, I
>> added one called "persistent" which carries a boolean value and
>> identifies an option as a one that should always be returned to the
>> client or the one that is returned only if requested (using ORO or PRL).
> Yup, persistent options are useful.
>> I am working on documenting the design for host reservation and I am
>> planning to use the attached (or similar) database layout for this
>> design, unless I hear objections.
> You asked, so here it is :)

So rapid response indicates that requests for design review should
always end with the clause "... unless I hear objections".  :-)

> I think I heard only once that someone asked for reserving more than one
> address or prefix. Even though the protocol allows that, great majority
> of users are reserving just one address and/or prefix. So I think that
> particular use case should be as simple to use as possible. So how about
> tweaking your proposal with a little twist: keep the single address
> field in the Hosts table and allow additional ones to be stored in
> ipv6_reservations if needed. I *think*, but I'm not sure, that with that
> approach we still can enforce address uniqueness. Maybe we can do a view
> from two columns from two tables (options.ip6_address and
> ipv6_reservations.address) and check/enforce uniqueness there?

I don't think that this tweak makes it any easier. First, you need to
duplicate the fields in two tables: IPv6 address and IPv6 prefix in one
table and another table for additional addresses/prefixes. So, the
database becomes more complex. It makes it more complicated to perform
statistical/aggregated queries because you'll need to look at two
columns in two tables. If you just had one place where you keep the V6
reservation the query to retrieve all reservations for a host is as
simple as:

SELECT h.ipv4_address, r.address
FROM hosts AS h LEFT JOIN ipv6_reservations AS r
ON h.host_id = r.host_id
WHERE h.dhcp_identifier = "0x0102030405";

Each returned entry represents one address that you stuff into the
IA_NA/IA_PD sent to a client so you just have to iterate over the
returned rows.

Whereas if you had two fields where you keep addresses and prefixes your
application layer would need to combine the results and take one address
from one table and the rest from another.

Moreover, if you put addresses into secondary table only if you have
them, it doesn't mean that you don't have to query for them the way I
showed above. The only difference is that the NULL result indicates that
there is only one address in the Host table.

So, I am not sure that this tweak really makes things easier but I am
sure it puts additional constraints and creates redundancy.

Also, how do you actually know that admins don't configure their
networks to provide more than one address to a single client? Even if
this is the case most of the time, RFC accounts for this case, and
implementation should not put constraints on this.

The stateful issues draft in DHCWG is all about providing means to
obtain multiple bindings in a single transaction not only for single
address + prefix but in general. I don't think that we should go against
this with Kea.

> On a related note, depending on the address uniqueness is perhaps not
> the best strategy. More than one user talked to us and said about the
> need to store multiple instances of the same subnet (e.g. you have 10
> hotspots and each of them is handling the same subnet).
> Leases would need to not be unique. What would be unique is (address,
> subnet_id) tuple.

I heard about this case earlier. But, it is an example from the IPv4
world which doesn't really count for IPv6. Does it?

But anyway, it indicates that the Hosts table needs to store the
information about the subnet_id that the V4 client belongs to.

> This is not a requirement we thought about when we were creating MySQL
> or Postgres database layouts. But it is something we will have to
> support one day. My only point wrt host reservation is to not make
> matters worse here.

I agree with this, so maybe the database design should account for
unique tuples of addresses/subnet id (assuming that a single client
belongs to a single subnet id).


More information about the kea-dev mailing list