Static leases, host reservation proposal

Tomek Mrugalski tomasz at isc.org
Mon Jun 23 17:56:59 UTC 2014


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


More information about the kea-dev mailing list