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: Plans for a KEA extensible DHCP client? (Francis Dupont)
2. Re: Plans for a KEA extensible DHCP client? (Tomek Mrugalski)
3. Re: Plans for a KEA extensible DHCP client? (Mike)
4. Collaboration question (Sallee, Jake)
----------------------------------------------------------------------
Message: 1
Date: Wed, 16 Dec 2015 12:14:32 +0000
From: Francis Dupont <[email protected]>
To: "Ray Hunter (v6ops)" <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Plans for a KEA extensible DHCP client?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Doing the same thing for ISC DHCP (which has client, server and relay)
I can say it is not so simple: a client has very different constraints
so the code sharing vs the increased complexity trade off is not clearly
on one side...
For plans I don't know but Tomek should.
Thanks
Francis Dupont <[email protected]>
PS: there is an embryonic client in the unit test code.
------------------------------
Message: 2
Date: Wed, 16 Dec 2015 14:59:49 +0100
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Plans for a KEA extensible DHCP client?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 16.12.2015 12:52, Ray Hunter (v6ops) wrote:
> Are there any plans to (re-)use the KEA libraries to produce an
> extensible client?
There are, but nothing concrete in the near future. We do organize the
code in a way that implementing client will become possible. In
particular, we don't include anything server-specific in libdhcp++,
which will be the core of the client code. When we said that libdhcp++
is general purpose DHCP lib, we really meant that. It can be used to
implement any DHCP-related functionality, including client.
Our highest level roadmap (if you can call it that) assumes that we're
focusing on the server now. Kea 1.0 is around the corner, but there's
still a lot of features that can be added: better host reservations,
leasequery, better command channel support, more flexible and resilient
reconfiguration, multi-core support, maybe failover one day. These are
all features that many deployments could benefit from.
We're receiving lots of requests for new features in Kea server, so
there's a verifiable demand for it. On the other hand, you're the first
one I remember that asked about a client. Yes, it's on our roadmap, but
there's much less demand for it. I can only speculate why. Maybe because
there are many client implementations out there? Maybe because the
client is usually bundled with the OS of your device? Maybe because
existing open source clients are good enough?
Francis mentioned an "embryonic" client code in unit-tests. This is not
something that could evolve into usable client. It's intrinsically
unsafe (it was designed that way to allow negative testing). This is a
very specialized client-like implementation that is useful for testing
and doing weird things for testing purposes.
Some time ago there was one student working on a minimialistic dhcpv6
client implementation using Kea infrastructure. Dominik published his
code here:
https://bitbucket.org/dzeromsk/kea-dhcp6-client/branch/dhcp6-client.
Depending on what you need your client to do, you could possibly look at
this. Please keep in mind couple essential things in mind. This is a
student's project and was never reviewed by anyone. It is based on Kea
codebase that is two years old (Kea's pace of development is quite fast,
so it's a huge, huge difference. We also moved away from bind10 python3
framework in the last 2 years, which further impacted the codebase a
lot). IIRC the code was able to request for an address and had the state
machine implemented, but was seriously lacking in almost everything else.
Disclaimer: this is strictly for informational purposes. I or ISC do not
recommend anyone to actually run the code, I'm merely pointing out that
there was a student project of that nature.
> It would save me an awful lot of work if I could write and test my
> libraries once for server and client simultaneously, rather than
> learning a whole new development tree for the client side and also
> re-writing everything that is client specific.
If you're really inclined to have a client in Kea framework, well...
we do accept patches :) Seriously speaking, it is somewhat imaginable
that the client implementation could be developed outside of ISC and
then contributed. But that's an enormous task that would require a lot
of design work, extensive public discussions (it's easy to skew the
design to adhere to only a limited requirements of a single deployment)
and an awful lot of implementation and testing work. If there are people
to work on this (it's not a small feat, think more like year long
commitment with many rounds of designs, reviews, tickets, etc.), please
do speak up. This is not a task for the faint of heart.
I'm sorry if that's not exactly what you'd like to hear.
Tomek
------------------------------
Message: 3
Date: Wed, 16 Dec 2015 10:00:37 -0500
From: Mike <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] Plans for a KEA extensible DHCP client?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 12/16/2015 8:59 AM, Tomek Mrugalski wrote:
> On the other hand, you're the first
> one I remember that asked about a client.
I certainly would like to see a client that has proper prefix delegation
hint support. :)
------------------------------
Message: 4
Date: Wed, 16 Dec 2015 16:20:27 +0000
From: "Sallee, Jake" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] Collaboration question
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Kea Devs:
Is the Kea project still looking for collaborators to develop applications
using the Kea API? If so I would like to throw my hat into the proverbial ring.
I have been looking for a while for a good open source DDI (DHCP, DNS, IPAM)
solution and I haven't been able to find one.
I have been watching the development of Kea for a while now with much
anticipation; I think it would make an excellent DHCP server for a true FOSS
DDI solution.
As I have been unable to find an open source DDI solution I have decided to
engineer one and make if freely available. I intend to use this project as a
means to fill a need in my production network as well as improve my skills.
Jake Sallee
Godfather of Bandwidth
System Engineer
University of Mary Hardin-Baylor
WWW.UMHB.EDU
900 College St.
Belton, Texas
76513
Fone: 254-295-4658
Phax: 254-295-4221
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 21, Issue 12
***************************************
