Static leases, host reservation proposal

Thu Jun 26 10:13:28 UTC 2014

Hey, so with option #2 you want to extend the lease database with
additional column? But if I use memfile, does it mean I should edit the
lease file to make the reservation?

I would very much prefer to make the host reservation data source
distinct from the lease database because as you pointed out various
users/administrators may have different sources of the information about
the clients (including their name, credentials and bank account number)
and providing a consistent API which the server is using to query a
necessary information (from whatever source) may be everything that is
really needed.

Should we add additional switches controlling the host reservation, I
would hate updating lease tables to support these new switches. And
obviously still there is a question how much portable this approach is
for memfile backend.

I vote for option #3 with some minimalistic version first. If we can't
do minimalistic version, perhaps option #1 is enough for the kea 1.0.

Marcin

On 23/06/14 19:56, Tomek Mrugalski wrote:
> This is the second thread regarding planned features post 0.9.0 release.
> Once we have MAC addresses available in DHCPv6 (see previous thread),
> we'll be able to offer DHCPv4-DHCPv6 parity. The following discussion
> focuses on DHCPv6, because there's a bit more complexity there, but
> almost everything applies to DHCPv4 as well.
> 
> THE PROBLEM
> a) Administrators want to specify that a given device gets the same
> address every time and that a given address is used exclusively by a
> given device.
> 
> b) Some hosts require special treatment, for example specific hostname
> that should be assigned by the server, special options (e.g. a printer
> that needs some extra options), boss' laptop that gets different
> parameters than the rest etc.
> 
> Depending on the size of the deployment, solution to a) gravitates
> towards one of the opposing approaches. For small deployments, admins
> typically prefer to add extra clauses to the config file. That is more
> convenient if you're talking about tens, maybe up to 100 hosts.
> 
> On the other hand, larger deployments that count their clients in
> thousands or more, typically would prefer to keep that information in a
> database. They also typically do not store anything besides some sort of
> client identifying information (usually MAC) and a reserved IP address.
> 
> POSSIBLE SOLUTIONS
> Option 1. We could extend the configuration file to have host
> definitions. ISC DHCP had a single global list of hosts, but that is not
> an optimal solution any more due to popularity of mobile hosts.
> Nowadays, it is valid and quite common case that a mobile host acquires
> and keeps leases in several subnets at the same time. ISC DHCP tried to
> solve that issue by allowing multiple addresses be reserved for each
> host and then tries to dynamically select the best reserved address
> depending on the location where the client is currently connected. That
> does not scale well as every time there's a request, a structure of ALL
> reserved hosts is checked. Whether it is a list, a tree or some other
> structure is beside the point. It would be faster, if there was a
> shorter list, specific to the current subnet.
> 
> Having host reservation structure would have the benefit of being easily
> extensible and could cover at least the following cases:
> - reserve an address for a given host
> - reserve a prefix for a given host
> - specify a hostname for a given host
> - define additional options specific for a given host
> 
> If we decide to go that way, it would look somewhat like this:
> 
> "Dhcp6": {
>     "subnet6": [
>         {
>             "subnet": "2001:db8::/48",
>             "pool": [ "2001:db8::1 - 2001:db8::ff" ],
>             "reserved-hosts": [
>                 {
>                     mac-address "01:02:03:04:05",
>                     ip-address "2001:db8::1001"
>                 },
> 
>                 {
>                     mac-address "01:0a:0b:0c:0d",
>                     ip-address "2001:db8::1002",
>                     hostname "foo.example.com",
>                     "options": [
>                         {
>                             "name": "domain-name-servers",
>                             "data": "2001:db8::d09:f00d:cafe"
>                         }
>                     ]
>                 },
> 
>                 {
>                     mac-address "01:0a:0b:0c:0d",
>                     hostname "foo.example.com",
>                 }, ...
>             ]
>         }
>     ],
>     ...
> }
> 
> As you can see the first host would be a simple MAC-IP pair. The second
> one has more parameters specified: exact name and also different value
> of DNS servers option. Finally, the third example is something I don't
> have strong opinion on: not sure if it's needed or not. It's just a
> binding between MAC address and the hostname. As there is no reserved
> address specified, it will have its address dynamically assigned. Note
> that strictly speaking that is not a static lease any more.
> 
> The biggest benefit of this approach is flexibility. You can do a lot
> with this. It is easier to maintain if your deployment is small. The
> disadvantage is that it's getting more and more awkward to maintain once
> your user-base grows. Also, you need to change your configuration every
> time there is a change. For larger deployments that's quite frequently
> (new subscribers added, resigning ones removed, also those who forgot to
> pay their bills or finally paid due bills are restored, datacenters that
> spin up/shutdown virtual machines all the time etc.). Although Kea
> offers on-line reconfiguration without shutting down, the
> reconfiguration process is not instantaneous and takes time. With the
> complexity of the config file growing, the time needed to parse it,
> sanity check and create all necessary structures will will grow as well.
> From that perspective it makes sense to try to keep the config file as
> small as possible. So this solution can be perceived as less performant
> in larger deployments where frequent updates are needed.
> 
> DHCPv6-specific comment: we would also need host reservations by DUID.
> Also, since a single host can request multiple addresses and/or
> prefixes, we will need to somehow optionally store iaid information. We
> will need to cover the following use cases:
> - for this DUID reserve this address, no matter what IAID is used
> - for this DUID reserve this prefix, no matter what IAID is used
> - for this DUID+IAID pair, reserve this address
> - for this DUID+IAID pair, reserve this prefix
> 
> Option 2. Another possible approach is that we can keep the host
> reservations in the database. The change isn't that difficult. We could
> extend current definition with an additional column (bool fixed_lease),
> tweak the code to honour it (e.g. don't remove the lease when it expires
> or is released by the client) and it would be ready to be used. That
> would have the same characteristic as other data we keep in the
> databases: ability to update it using third party tools, no need for
> restart, instant application, not possible to cause inconsistency (i.e.
> the DB itself enforces addresses to be unique). On the downside, this
> offers less flexibility, because you wouldn't be able to specify extra
> options or have just MAC-hostname reservations. Also, it would be
> somewhat confusing as you'd keep current active leases (devices that are
> currently active in your network) and info about reserved devices (all
> networks known in your network) in the same table. They would just
> differ by a single column. On the other hand, it would be trivially easy
> to say that the address that was assigned should now be reserved for
> specific client. Just flip a bit in the database and you're done. Don't
> want it to be reserved anymore? No problem, just flip the big again and
> the server will recycle the lease.
> 
> None of those options is vastly superior to the other and I think we
> will eventually need to implement both. The question here are: which one
> to implement first and whether we want to implement the second one in
> the 0.9.1 timeframe (or before 1.0).
> 
> Option 3. Finally, I'd like to also mention a follow up to those two
> options. I'm not sure if Option 3 is the proper designation. "Optional
> follow up to options 1+2 combined" would be probably a better name.
> This is something that Marcin and I discussed during London IETF,
> shortly before the news about python3 removal was announced. Right now
> the config file allows choosing lease storage. We could potentially have
> a similar concept applied to the host reservations. The choices would be
> similar to what we have with the lease database, but would also cover
> "config" option. That would be the most flexible approach. You could
> keep the leases in CSV file and hosts in the config, keep leases and
> hosts in MySQL, keep leases in PostgreSQL and hosts in MySQL etc. Sadly,
> such approach would also be the most labour intensive to implement. If
> we decide to implement this approach, we'll also need to answer how to
> organize keeping host and leases in the same database backend: should
> they share a single table or use separate tables. Sharing a single table
> has the obvious benefit of being consistent. Using separate tables would
> be somewhat more natural, but would allow inconsistency.
> 
> There's also one other fundamental difference between option 1 and
> option 2. Option 1 would feature something what can be called
> out-of-pool reservations, i.e. the reserved addresses must not belong to
> the pool. The reason for this restriction is that it would otherwise
> break down too much logic: counting how many addresses/prefixes are left
> unused, checking whether a given address/prefix is available or not,
> etc. Option 2 would allow both in-pool and out-of-pool reservations, but
> only if leases and host reservations share the same table. Otherwise it
> would also also be restricted to out-of-pool reservations.
> 
> That's more or less it. There are additional smaller issues like
> defining classes for specific hosts, but I think they are out of scope
> for now.
> 
> Thoughts? Comments? Tomatoes?
> 
> Tomek
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
> 