DHCP Hackaton summary

Tomek Mrugalski tomasz at isc.org
Wed Sep 24 12:16:08 UTC 2014


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?

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 10.0.0.0/8 subnet).
Leases would need to not be unique. What would be unique is (address,
subnet_id) tuple.

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.

Tomek





More information about the kea-dev mailing list