[bind10-dev] DHCP and BIND10

Thu Nov 12 23:10:26 UTC 2009

I want to take a brief moment to introduce Christof to the rest of
the bind10-dev team;

Christof is a long-time DHCP-users and patch submitter, and he's been
invaluable to us on what will later be called the "old" DHCP software.

On Wed, Nov 11, 2009 at 10:29:17PM +0100, Christof Chen wrote:
> reading through the wiki pages and through 6 months of ml-archives i
> miss the DHCP part of BIND10 a little.
> 
> Are there any targeted milestones regarding DHCP?

No milestones as yet.  I think we are basically going to start working
on putting our design ideas down on paper, and figure out our first
steps in implementation.

> Something like
> 1. A listener which consumes/logs DHCPv4 packets
> 2. a server which actually responds

Those would both be a good start.  :)  We need to write down how we
think the high level server architecture will work, but we also need
to test our conviction against some sample implementation like this
(BIND 10's DNS software team recently did the same thing).

> 3. asynchroneous DDNS

ISC DHCP 4.2 will have asynch DDNS - this is sort of a "trial run,"
even though it should be production quality when 4.2.0 is final.  We
may learn some tricks - what works, what doesn't, and how we'd like to
do it over again, so we decided to get it done in 4.2 rather than make
it a "BIND 10 future" feature.

Mainly it means using an asynch DNS library, which we expect will be a
component of BIND 10 (and is a new component in BIND 9.7 thanks to
Jinmei).

> 4. reliable failover

I am hoping that, with a "server cluster" server architecture framework
in BIND 10, DHCP in BIND 10 will solve fault tolerance in an "N+1" way,
instead of DHCP Failover (which we may retain as a means to tie two
independent clusters together, in the very late game) which only allows
two servers.

This to me conceptually distinguishes "High Availability"
configurations where the servers are in the same rack with a heartbeat
cable and "Fault Tolerance" configurations where the servers are in
different data centers (Failover is very much proposed for this
situation).

We would probably call the HA solution something different to be
distinct, like "DHCP-RAID" or "RAIDHCP" (Redundant Array of
Independent DHCP-servers?).

There are no current implementation notes on how that would work, it
should be an input to our high level server architecture.

> or design goals like
> - the ability to intercept and mangle DHCP messages at various points
> during the lease-lifecycle  (eg. at packet reception, after lease
> selection, before offering, just before sending,...)

One of the BIND 10 goals is to make it easy to plug in custom code,
and not necessarily C or C++ (but rather using an embedded scripting
language such as python).

One of DHCP's challenges is that it is maintaining its own programming
language config-file-syntax...so hopefully providing a "converter"
from current legal 'dhcpd.conf' syntax into 'embed this python' will
be something we can auto-generate the first time someone starts a BIND
10 DHCP server using their DHCP 4.2 'dhcpd.conf' file, and that gets
you a starting point where you can do your own thing editing the python
from there on out (it is hoped you may also be able to use this as a
"proof of concept" to then write the equivalent changes in C++, and
customize the server without compromising performance).

You've identified exactly the 3 points I think we'd like to have the
ability to manipulate DHCP with custom software;

At packet reception:  Mangle the client's PRL, strip bogus null
    termination from text options, select a unique client identity
    (play client-id/hardware games) stuff like that for example.

    Basically "change the inputs."

On or after lease selection:  Write your own routine that guides the
    server's selection of IP address.  I'm not sure if we'd allow to
    write your own "find_lease_for_client()", or allow to over-ride
    the results of that operation.  I lean towards allowing to write
    your own function, or to call our standard function if you wanted
    to do something special afterwards at this step of processing
    (this is before the database is written to).

    Basically "change the facts."

Before sending the answer:  This is after the database is written to,
    after it is committed.  Common operations here would be to log the
    information in a separate database, to update firewall rules, or
    to otherwise record the "active" state advertisement, but you
    might also want to "mangle" some options - inserting null
    termination for bogus clients for example.

    Basically "change (or use) the output."

We would also add to this a hook on the expiration, release, and reset
events (separately).

This closes the loop on being able to replicate any dhcpd.conf syntax
with custom python (or to throw up our hands if the dhcpd.conf syntax
is too hard and direct the migrating customer to a wiki on how to get
started with embedding code).

> - flexible DDNS options (multi-domain update, different update policies,...)

I always wanted to have several ddns-update-styles beyond interim.  I
think in BIND 10 we would want to have a number of "official" update
styles (starting with the standard style and expanding if we have time
or patch submissions), but here there is a slight distinction;

The sources that craft DDNS updates are in the "performance path" of
DHCP's back-office processing (slowdowns here affect how many asynch.
DDNS updates can be pending at once).  Also because DHCID generation
uses hash algorithms, and has some other CPU-intensive qualities to
it.  I expect these will largely be in C++.

The sources that describe the DDNS-update-policy might be able to be
done in a way where they aren't processed "in the packet processing
path", or even if they must be processed in the packet-path, they
may only be processed on initial lease assignments (and not on every
DHCP renew or DNS retransmit which are both more common and more of a
worry for server performance).  So these may not have a best-
performance criteria.

So this is a situation where the DDNS-update-policies might be
implemented in e.g. python while the DDNS worker-code itself is in
C++ for speed.

So you could pretty much use our python as a starting point and
customize your own update policy. :)

We're also going to want to solve the problem where DNS records are
not cleaned up when leases are taken out of configuration.  We may
either give DDNS its own database and expiration events to process
(with some poke from DHCP renews to advance the expiration timer),
or we may be able to get "cleanup" call-out hooks from the data
storage system when records are deleted.

But we'll want some way to ensure that the expiration event happens
even if the server doesn't process DDNS anymore.

> - continous service while reconfiguring

In the BIND 10 framework, everything will be manageable by a CLI
system, with persistence assured by a "configuration management"
daemon.

I have a question;

I know we often get abused by embedded systems users, as the DHCP
package has gained a lot of bloat.  We want to be able to provide a
solution here, but we may just write a separate "minimal" piece of
software rather than try and make one piece of software scale to
both ends of the spectrum.  But then we do double the maintenance,
and probably the smaller daemon will suffer from slow feature creep
as people want just "one more thing" from the big server's camp.

Anyway.

Is it still important on a regular system not to burden the software
with features you don't necessarily use?

I am thinking that most people (and especially those looking for
utmost performance) probably aren't using DHCP's "programming
language" config syntax, and yet we call execute_statements_in_scope()
multiple times on every DHCP packet...

In this case supplying an answer at both ends of the spectrum may not
actually require separate extremes in software, we can make a minimal
server that grows according to demands and its configuration,
reconfigure itself to put the demanded features in rather than always
having them in the way, but I worry that I'm inventing an interesting
problem to solve.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20091112/4b9e62e7/attachment.bin>