[kea-dev] DHCP Hackaton summary

Thomas Markwalder tmark at isc.org
Wed Sep 24 14:13:31 UTC 2014

On 9/24/14, 8:16 AM, 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 :)
> 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?

Sorry Tomek, but that's an ugly hack based on "premature optimization". 
It is cleaner and simpler to go with the second table.  It is a 1-to-M
relationship, you should build it that way from the start.  That way all
logic assumes more than one,  so having only 1 isn't an exceptional case.


More information about the kea-dev mailing list