Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Possibility of disabling raw socket use in Kea ?
(Tomek Mrugalski)
2. DHCP Hackaton summary (Tomek Mrugalski)
3. Re: DHCP Hackaton summary (Francis Dupont)
4. RE: Possibility of disabling raw socket use in Kea ?
(Chaigneau, Nicolas)
5. IA_NA + IA_PD (Agust?n Bertamoni)
6. Re: IA_NA + IA_PD (Tomek Mrugalski)
----------------------------------------------------------------------
Message: 1
Date: Mon, 22 Sep 2014 14:42:50 +0200
From: Tomek Mrugalski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>, Marcin
Siodelski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: Possibility of disabling raw socket use in Kea ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 22/09/14 13:58, Chaigneau, Nicolas wrote:
> I don't need it right away. Knowing that it is planned is good enough :)
That's a slight over-interpretation. I said that it can be done, not
that it's planned ;)
But yeah, the change itself simple enough that we can probably do it. It
will impact how we run our conformance tests (with udp sockets some
tests will most likely fail), so we'll need to coordinate with our
testing team.
If you have time to test that quick hack, it would be great if you could
report that it's indeed working. Also, feel free to create a ticket for it.
Tomek
------------------------------
Message: 2
Date: Mon, 22 Sep 2014 15:50:58 +0200
From: Tomek Mrugalski <[email protected]>
To: "[email protected]" <[email protected]>
Subject: DHCP Hackaton summary
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Here's the DHCP Hackaton summary. These were the discussions that I
participated in. Couple times several things were happening in parallel,
so I'll let others to fill in the blanks.
We had a very interesting DHCP hackaton last week co-organized by ISC
and a Department of Computer Communications of ETI faculty of Gdansk
University of Technology. There were 14 participants with varied
background - undergrad students, lecturers, professors, network
administrators and software developers. Two participants had to drive
from almost the other end of the country to get to Gdansk. Thanks for
your dedication. We were even visited by a vice-dean of the faculty!
This was a two day event where DHCP developers, users, students and
other interested people had a chance to talk, discuss bugs, fix them,
write new code and design new features together.
Hackaton had started with slightly over 2 hours long participants
introduction, DHCP introduction (about the protocol, but also its
implementations Kea and Dibbler) and overview of ISC engineering
processes, including trac and github repository.
Several documentation issues were reported and fixed (thanks to Adam
Osuchowski and Piotr Strzyzewski for reports and fixes). Couple logging
issues were reported. Fortunately, ISC was aware of them and in two
cases we already had branches with proposed fixes that are currently
undergoing reviews. It's always useful to get a hands on confirmation if
a given solution is working. Especially when it doesn't :) Fortunately,
the code was promptly fixed.
We started using Kea repository on github and managed to merge our first
pull request! Yay!
We had a discussion about implementing minimalistic server and client
for embedded environments, based on libdhcp++ from Kea. Dominik Zeromski
and Tomek Kleinschmidt reported that they managed to trim down libdhcp++
to 400kb, but with additional steps it is possible to further trim it
down to 200kb. One issue was dependency on libutil library. That
dependency is rather minor - only OutputBuffer class is really needed.
We discussed various possible solutions - moving OutputBuffer to
libdhcp++, splitting OutputBuffer into its own small library etc.
Another roadblock on making libdhcp++ is exception handling code.
Exceptions cause compiler to generate non-trivial amount of additional
output binary code. We had a discussion about it and the most feasible
way forward would be to split isc_throw macro into isc_throw and
isc_throw_fatal. The latter would be replaced by calling assert and
terminating application. The former would be silently ignored. Those new
macros will be used when compiling for embedded environment. There will
be an additional target for that (libdhcp++-minimal?). Obviously, the
regular target will remain and exceptions will be used in normal
environments (both isc_throw and isc_throw_fatal will simply throw
exceptions).
Second day was focused on host reservation design. This is an upcoming
feature for 0.9.1. After a lengthy discussion, we came up with the
following design:
1. Host reservations will be defined in config file (the default mode),
but it will possible to also store them in a database.
2. Proposed table layout is as follows:
Hosts table
- identifier (varchar) - container for client identifier. For now, it
will be either MAC or DUID, but soon will be adding additional
identifiers, like subscriber-id, remote-id etc.
- identifier type - specifies type used in identifier (this will
essentially be an enum with values of TYPE_MAC, TYPE_DUID etc.)
- ip4 - an IPv4 address (this field may be null)
- ip6 - list of IPv6 addresses (may be null, one or several addresses)
- ip6prefix - list of IPv6 prefixes (null, one or several prefixes)
- hostname (optional)
- clientclass (this field will be added at a later stage)
- host-id (a primary key)
We need an unified way to reserve hosts by MAC, DUID, subscriber-id,
remote-id, docsis options etc. The design above allows that. It is also
easily extensible. If we decide to add a support for a new identifier,
it's only a matter of adding one more enum (database wise, it will be
more involved DHCP engine wise, but that complexity is an independent
problem).
ip4 address is optional as it may be IPv6 only reservation or maybe
mac+hostname reservation.
ip6 and ip6prefix fields may have zero (IPv4 only reservation or maybe
mac+hostname only), one (typical reservation) or more than one address
or prefix. DHCPv6 spec allows for a single client to handle more than
one address and more than one prefix (client sends several instances of
IA_NA and/or IA_PD options)
The hostname is obviously optional.
Clientclass is an optional field. It allows to specify that a given host
belongs to a client class. That is important for at least two reasons.
First, we may get per host client classification granularity. Second, if
there is 100 hosts that require an option, we may want to add one option
and say that it's for class X, rather than adding 100 instances of
exactly the same option. It seems that client class will be implemented
at a later stage (or perhaps implemented along the rest of the fields,
but will be ignored for now).
host-id will be required to be able to refer for specific host instance.
It is not clear yet if we will need it for memfile backend.
3. Multiple host reservations
Since we'll be able to reserve host based on mac, DUID and others
parameters, we can't enforce them to be unique. Therefore it may be
possible that due to misconfiguration there will be several reservations
that will match. It would be bad if the server randomly used one or the
other. We need to analyze 3 cases here: 0 hosts (carry on as usual), 1
host (use that reservation), more than one (log error).
The easiest way would be to do SELECT with LIMIT 2. We're not really
interested in how many are there, just if there is anything more than
one. We will then log warning and probably use whatever MySQL or
Postgres returned as first host.
4. Options in DB
We will also need a table for storing options in database. The immediate
need is to allow storing options for a specific host, but soon after
that we'll need options associated with a given class or with a given
subnet (once we get the capability to store subnets in a DB).
The proposed table looks as follows:
Options table
- option code (uint16, option code in DHCPv4 or DHCPv6 sense)
- value string (options have diverse formats. using string will allow
values to be stored in an uniform way, e.g. for format uint32, bool,
string we'll store something like 1234,true,"hello world".
- option space (see explanation below)
- host-id - foreign key (a reference to hosts table)
- client-class string (explanation below)
- subnet-id uint32_t
option space will be the same as we have in Kea now. There are 2 defined
out of box: "dhcp4" and "dhcp6", but we can easily define vendor option
namespaces. Also, for custom options it is now possible to define that
option A belongs to "dhcp4" and contains option space "foo" and options
B and C belong to option space "foo".
It is understood and agreed that for any custom or vendor options, there
will be definitions needed. Those will be kept in the config file.
Client-class will be an optional field that will specify that a given
option is for hosts that belong to that class.
Subnet-id performs similar selective role for subnets.
Host-id, client-cass and subnet-id can be considered selectors, i.e.
properties that will be used to find appropriate options. There was a
discussion on how the query should look like:
host-id=X AND client-class=Y AND subnet-id=X
host-id=X OR client-class=Y OR subnet-id=X
There was also a brief discussion how MySQL treats NULLs, as not all
values will be specified at all times. This particular topic will need
further thoughts.
5. Hosts cached or not
In theory, hosts can be kept either in memory or in database only. In
memory approach, hosts information is read from the DB and kept in
memory. This is good from performance perspective, but requires
administrative action (admin needs to tell the server that hosts
reservations changed) every time hosts information has changed in the
DB. On the other hand, it is possible to not keep anything in memory and
check with the DB every time. This will be less performant (extra query
for each packet processing), but will have the benefit of being always
up to date (any changes to the DB will be immediately picked up).
Adam proposed a mixed mode, where the server has a cache that is
gradually filled with data that is read from the DB. This is an
interesting proposal as it gives fast startup and ultimately high
performance. We will likely implement it one day, but it is probably not
feasible in 0.9.1 timeframe. Nevertheless, we need to make the design
extensible to allow adding it at some later time.
6. Required and proposed commands
If we implement hosts kept in the memory strategy, then we'll need at
least the following commands:
- delete-host - deletes one host. It would be useful to use
identifier/identifier type as parameters for consistency
- flush-case - drops existing list of hosts from the in-memory cache
- reload-hosts - drop all hosts from memory and reload from DB
We also talked about reloading hosts from DB. In typical case, there
will be thousands of mostly static host reservations, with a handful new
ones being added or deleted. Naive approach of dropping all from memory
and reloading will cause the server to reload mostly the same with
minimal delta, which will be a performance problem. It may be useful to
has one extra command: add-host. Full implications are not yet fully
understood, though. The behavior must be well defined: is add-host only
adds a host to in-memory cache and will be lost after restart? Or will
it also insert the host into DB?
7. Feature request
One missing feature is config file inclusion. Adam requested this
capability as it is very commonly used. Kea doesn't have such capability
yet. It is supported by ISC DHCP, though.
8. DHCPv6 Bulk leasequery in Dibbler
Damian Manelski is working on bulk leasequery support in Dibbler.
Dibbler server was extended with TCP sockets and bulk leasequery
processing. There are bits and pieces still missing, though. Several
bulk leasequery scenarios rely on options inserted by relay agants. In
particular, on remote-id and relay-id options. ISC DHCP does not insert
those options. Dibbler inserts only remote-id, but not relay-id. We
managed to implement support for relay-id. Even though this is not
directly related to Kea, it may still be useful as a testing tool, even
before we start implementing bulk leasequery in Kea. Even as of today,
we do have code for extracting options inserted by relays. Using
remote-id or relay-id for testing its correctness may be useful.
9. MAC addresses support in DHCPv6
Adam Kalmus started work on extracting MAC addresses from DUID. This is
one of the tickets we planned for 0.9.1. This work is in its early
stages, but the environment was set up and first lines of code were
written. That's a good start. We're keeping our fingers crossed.
No slides were shown during the event.
Thanks to doc. Krzysztof Nowicki and Department of Computer
Communications from Gdansk University of Technology for hosting us!
Tomek Mrugalski
ISC
------------------------------
Message: 3
Date: Mon, 22 Sep 2014 14:41:25 +0000
From: Francis Dupont <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: DHCP Hackaton summary
Message-ID: <[email protected]>
> 7. Feature request
> One missing feature is config file inclusion. Adam requested this
> capability as it is very commonly used. Kea doesn't have such capability
> yet. It is supported by ISC DHCP, though.
=> it is a pretty standard feature, easy to implement by stacking the
config file parser. BTW the only hairy point is to prevent recursive
inclusion (i.e., one must check (e.g., by calling fstat()) that a file
is not already in the stack).
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 4
Date: Mon, 22 Sep 2014 16:16:24 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Tomek Mrugalski <[email protected]>, Marcin Siodelski
<[email protected]>, "[email protected]" <[email protected]>
Subject: RE: Possibility of disabling raw socket use in Kea ?
Message-ID:
<ab94b0b675bdf14189cd5a861db36c8414197...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Fair enough, sorry for wrongly assuming something you didn't say :)
I'll build and test the hack you proposed, I hope this week.
I'll keep you informed of the results.
Nicolas.
> On 22/09/14 13:58, Chaigneau, Nicolas wrote:
> > I don't need it right away. Knowing that it is planned is good enough
> > :)
> That's a slight over-interpretation. I said that it can be done, not that
> it's planned ;)
>
> But yeah, the change itself simple enough that we can probably do it. It will
> impact how we run our conformance tests (with udp sockets some tests will
> most likely fail), so we'll need to coordinate with our testing team.
>
> If you have time to test that quick hack, it would be great if you could
> report that it's indeed working. Also, feel free to create a ticket for it.
>
> Tomek
>
>
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
------------------------------
Message: 5
Date: Mon, 22 Sep 2014 20:24:44 -0300
From: Agust?n Bertamoni <[email protected]>
To: [email protected]
Subject: IA_NA + IA_PD
Message-ID:
<CAJtDY1Bwv07=usddp6z0jncusc10vrhha29baztpwkrw06o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
According to docsis scenario, we need to assign IA_NA and IA_PD to
erouters at the same time, but the NA (non-temporary addresses) candidate
and the IAPREFIX not necessary must be in the same prefix, so the ?pool?
and ?pd-pool? are not in the same subnet.
As a result of the tests, this seems not to be supported and we see that
first selects a class-based available subnet and PD that is within it. Is
this analysis correct ?
Thanks in advance for your time!
Regards
AgustinI
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20140922/71a64c5d/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 23 Sep 2014 13:39:38 +0200
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: IA_NA + IA_PD
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 23.09.2014 01:24, Agust?n Bertamoni wrote:
> According to docsis scenario, we need to assign IA_NA and IA_PD to
> erouters at the same time, but the NA (non-temporary addresses)
> candidate and the IAPREFIX not necessary must be in the same prefix, so
> the ?pool? and ?pd-pool? are not in the same subnet.
> As a result of the tests, this seems not to be supported and we see that
> first selects a class-based available subnet and PD that is within it.
> Is this analysis correct ?
Yes. The assignment process more or less looks like following:
1. parse incoming packet
2. assign packet to a class if appropriate. Right now it simply takes
content of the vendor-class identifier (DHCPv4) or vendor class
(DHCPv6). The class is specified on a per packet basis.
3. a subnet is selected for incoming packet. Normally it is done based
on relay IP address and/or interface-id inserted by relay, but you can
also allow/forbid specific client class from a given subnet.
4. Leases are assigned from the selected subnet. Each lease type (IA_NA
or IA_PD) is processed separately, but to assign both of them, you need
to have both pool and pd-pool defined.
So if you want to have both IA_NA and IA_PD assigned in the same
transaction, it is currently not supported. But are you completely sure
that's what you really want? One of those resources assigned (either
address or prefix) will be topologically incorrect.
Tomek
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 6, Issue 16
**************************************
