[kea-dev] Thoughts on reading the ARM documents

Thomas Markwalder tmark at isc.org
Fri Oct 24 12:44:15 UTC 2014

On 10/24/14, 7:09 AM, Marcin Siodelski wrote:
> Shawn,
> Thanks for sharing this. Please find my responses below. I am sure,
> others will also be able to clarify more on specific topics.
> Marcin
> On 10/24/14 05:14, Shawn Routhier wrote:
>> While reading through the ARM document I
>> cleaned up some minor typos (trac ticket 3620)
>> and had some questions and comments.
>> For those of you on this list that don't know me I'm the lead
>> engineer on the current ISC DHCP code.  When I talk about
>> what the current code does this should not be viewed as
>> a requirement or even a strong suggestion that Kea should
>> follow along.  I'm trying to describe what the current code
>> does and what users may be using - we may decide that Kea
>> should do the same thing, or have a similar feature but done
>> in a different way or that it isn't necessary for Kea for some reason.
>> There were three sections in the original document but I've
>> removed one section - that one was for changes I had made to
>> the ARM document that seemed like issues but for which I wasn't
>> completely sure.  They are on the trac ticket.
>> For the other two the first is for the general thoughts I had while 
>> reading the docs.  This covers things that the current code does 
>> that Kea may want to do, areas where Kea may distinguish itself from
>> the current code, ideas for futures etc.
>> The second is for more changes to the docs and some questions about 
>> the code that may require changes to the docs.  In some cases this is 
>> simply a step farther than 2 - there seems to be something a bit iffy and 
>> I think I understand it, but I'm not sure enough to make changes.
>> In other cases we may want to add more text to either be more clear or to be different than
>> ISC DHCP.  And there are some that may be feature requests in disguise.
>> I imagine that after some discussion a number of these may turn into tickets
>> for future work.  The priority will need to be evaluated over time.
>> I currently plan to do some more work on the ARM document and so as I understand
>> things better or get somebody to explain some of the items in the second section
>> to me I can open another ticket and do more work on the document.
>> I haven't tried to polish the text of these so some of the descriptions
>> may need some re-working but they should be sufficient to start the discussion.
>> ************
>> General thoughts about the documentation and the code
>> 1) Many users use something like nagios to watch over their dhcp servers
>> it would be useful to either work well with those tools or provide our own
>> that does similar nannying.
>> 2) Can there be more than one configuration file for the keactrl?  It appears as if there
>> can be only one for both v4 and v6 - if I want two files (say two diffeernt groups run the
>> v4 and v6 stuff) can I do so?
> To clarify this, there are two configuration files: keactrl.conf and
> kea.conf. The former controls the behavior of the keactrl script. It in
> fact also specifies whether kea.conf is called kea.conf or has a
> different name. The latter is a configuration file for the servers:
> DHCPv4, DHCPv6 and DHCP-DDNS and can be used to run any of them without
> keactrl.
> There is a command line switch for keactrl that allows for specifying an
> alternate configuration file for keactrl. However, if you want to use
> two different files simultaneously you need to be careful because some
> keactrl commands (e.g. keactrl stop) will by default shut-off all the
> running servers (at this point they don't use any pid files). So if you
> run v4 with one call to keactrl, and v6 with another call to keactrl.
> Then, you run keactrl stop with any of these configuration files, it
> will stop both v4 and v6 servers, unless you specify with a command line
> which one you want to shut-off.
> So, I think you can do what you want but you need to be careful with the
> command line options you use.
> There is also a point about the DHCP-DDNS module which will not start if
> there is another instance already running. So, you can't run DHCPv4 with
> DDNS and DHCPv6 with DDNS using two keactrl configuration files.
>> 3) I have some concerns about the reload option.  In general what people have been asking
>> for in ISC DHCP is the ability to change a running system (via OMAPI mostly).  I think those
>> that have asked for a reload capability want to change the config but not go through the full
>> startup sequence.  If Kea is quicker to start (quite likely as it doesn't have the same
>> issues in building the database) this may not be an issue.  But the example is that an
>> admin wants to add a new pool to a server without having to stop and restart the server.
> The "reload" command will not restart the process but will rather send a
> SIGHUP to the process and the process will reload configuration from the
> file. However, it is true that the server will reload (including
> parsing) whole the configuration from the scratch which may be an
> expensive operation. I think that one of the options (for the future) is
> to load the configuration in background while still serving clients with
> an old configuration. But, this is not how it works now and it would
> require some multi-threaded features.
> Please note that keactrl was meant to be a *simple* tool for managing
> the startup and reconfiguration of the servers. And, it was a quick
> replacement for the bindctl tool from BIND10. We know that we need some
> more sophisticated management tools and actually a simple management
> tool is in scope for 0.9.1 (IIRC), but for now keactrl should be good
> enough as a first step.
>> In the current code we have the options to test the lease and config files, is the
>> reload command part of the replacment for that feature?  If not will we get such a feature
>> in the future?
> keactrl will try to use the configuration file when reload is issued,
> and if it fails the server will continue to use an old configuration.
> Also, we are working on some refactoring of the code in this area to
> avoid using dead or partial configurations. There is no standalone tool
> to verify that the semantics of the config or lease file is correct.
>> 4) Is there a background option for starting a server directly?
> No, if you want to run in background you'd use keactrl.
Are you asking if servers can be started via command line?  If so,
yes.   You do not have to use keactrl, you can start servers
independently of each other.   Or are you asking if the servers will run
in the background, as isc_dhcpd does without the "-d" option?
>> 5) Note for failover support - the state of the lease will need to be stored in the
>> lease database. (Free, backup and active at least, possibly others for transition states).
> There are more features, e.g. MAC address extraction for v6, where we
> need to add new fields to the lease database. Extending the lease
> database with new fields is not a big deal, but we will need tools to
> upgrade existing instalations (e.g. upgrade database and preserve the
> data). There are some tickets for this in 0.9.1.
>> 6) 6.2.3 Inteface selection - can the wildcard be used as part of a string such as
>> "eth*" or "eth1.*"?  can the interface code deal with "funny" intefaces (vlans, bonded,
>> fractionals etc).  Doing a better job than the current code would be a selling point
>> so if it does so making that clear is probably worthwhile.
> No, it doesn't deal with wildcard names like "eth*". But, not that it
> couldn't. It is just a matter of, how important would it be?
> We already have some requests to improve the handling of multiple IPv4
> addresses on the same interfaces. We will start there. But, I think
> there will be more cases to cover, as we haven't really tested all the
> "funny interfaces".
>> 7) Table 6.3 - is there an option for a FQDN that will be looked up via DNS and then
>> the ip address sent out in the option?
> I don't understand this question.
>> 8) 6.2.8 - for the vendor encapsulated space, can we pick and choose which one to send based
>> on something in the request?
> I don't have we have any means to define "something" in the
> configuration file. We are planning to implement client classification
> and for specific client classes you'd be able to define specific options.
> So, are you asking if you can pick sub-options based on "something" in
> the configuration file? What that would be?
>> 9) 6.3 - note that we don't implement server id checks in the ISC DHCP server by default.
>> I don't know if this is an issue for many clients.
>> 9) 7.1 (and maybe for v4 as well) do we plan to allow a default config file at some time?
>> We do so now for ISC DHCP, I'm not sure if people like that.  I think the distros kind of like
>> having very little on the command line.  But maybe they will mostly use the keactrl?
> Yes, there are default configuration files installed with kea: kea.conf
> and keactrl.conf as I mentioned above.
>> 10) In ISC DHCP we currently do different things for hosts vs pools.  In v4 we don't check
>> to see if an address is in both and can hand it out twice if the configuration is incorrect.
>> In v6 we claim to check and won't hand out addresses from a pool that are also static.
>> (Just an FYI for when static entries are handled)
> Please read this: http://kea.isc.org/wiki/HostReservationDesign. There
> is a discussion in the "In-pool vs Out-of-pool Reservations" section
> about it.
>> 11) 7.2.7 in the current code we can have issues with prefix lengths.  If we can allocate
>> a /56 but somebody asks for a /60 we won't give them anything.
>> 12) I'm looking at the option-defs - can we format something that is a value followed
>> by an array of items?  
> No. But, if you really want to do it, you can create a record with
> multiple fields of the same type. But, we should actually consider some
> generic support for this.
>> 13) Are we using the same "vendor-encapsulated-options-space" for both v4 and v6?  Or
>> maybe it is "vendor-opts-space" in v6 as the text says in 7.2.10?
> I think this text needs to be revised. I think we also use "vendor-1234"
> for vendor id 1234 etc.
>> 14) In using client classification if a client has a class but the config doesn't include
>> a subnet for that class but does include an unclassified subnet will the client get an
>> address from the unclassified subnet?  Or if it has a class does there have to be a matching
>> subnet?
> I think, I'll leave it for Tomek.
>> 15) 8.2.1 - is there a default value for the dns_server_timeout?  The example shows 100
>> (milliseconds) which seems a bit low but I haven't checked to see if the specs provide any guidance.
>> For comparison 4.1 allows for 1 second while 4.2 & 4.3 are up to the Bind9 code but I
>> believe are in the multiple second range.
> There is. It is 100 ms. But it probably should have been documented.
>> 16) 8.2.2 - We may wish to provide or ask the Bind9 folks to provide a mechanism to
>> produce the proper tsig_key structure such that an admin can cut and paste from the
>> output into the config file.
>> 17) 8.2.4.x - We allow the admin to set the suffix for the reverse zone name for v4
>> and have a request to do the same for v6.
>> ****************
>> Items that I have questions about but didn't change.
>> 1) I note that the copyright years in share/kea/dhcpdb_create.* are 2013
>> should these be updated to 2014?  (In Bind they update all of the copyrights
>> every year in ISC DHCP we only do so when we touch a file.  If Kea wants to
>> do it every year (I think it should) we should probably have a script to do so).
> We update copyright year when we touch the file. But it is annoying
> because we tend to forget. I am not sure what would be a right way to go.
>> 2) 3.4.4 - mentions "prepare the Python scripts", we don't use python anymore do we?
> IIRC, there was one tool for which we still used python? But, I forgot
> the details.
Marcin, you might be thinking of the code generation in lib/dns/rdata
but hasn't that been disabled/removed?

>> 3) 3.4.5 - when would ldconfig be required
>> 4) 6.2 and 7.2 the description of the lease database in the v4 and v6 sections doesn't match the example.
>> The example has multiple paramaters (type, persist and name) while the description claims
>> only one paramater.  Or perhaps there is a missing example block right next to the lease
>> database description?
> Good catch. I think it may be because initially it was only a type and
> other were left at defaults, but they were added later.
>> 5) 6.2.4 it sounds as if auto-generated ids always start from 1 and increase.  They won't
>> start from the id of a defined subnet?  And if they overlap what happens?  I have 5 subents
>> 1-4 and number five specifies
>>  "id": 2,
>> Does the answer change if the first one is specified as 2?
> If they happen to overlap the configuration of the server will fail.
>> 6) 6.2.6 when using hex strings which formats do we allow "xx yy", "xx:yy" "xxyy".  It would
>> probably be good to allow all of them if possible (eventually).
> For DUIDs and MACs I think we allow all of them. For the options, we
> probably would need to allow "xx:yy" as I think we don't allow this at
> this point.
>> 7) I see we use both option-data and option-def - it might be useful to mention that explicitly
>> people glancing through the examples may miss that difference.
> Agree.
>> 8), the text says we will alwayss do a remove and add in case 2 and remove in case 3
>> are those also gated by the FQDN flag bits?  Do we attempt a removal if we haven't attempted
>> an addition?
> We keep an information about the attempted updates in the lease
> database. So, if we get the new message from the client and something
> changes (e.g. FQDN) we perform an update. Otherwise, we do not.
The numbered statement list the general case impetus for when DDNS
updates might be performed.  That decision is then subject to the FQDN
flag bits (assuming the client sent the FQDN option) and the
configuration values for overrid-client-update and override-no-update.  
Requests that do contain host-name rather than FQDN are treated the same
as Client FQDN flag values N=0,S=1

As to your second question, do you mean will we attempt to do a removal
on a release if an add was not done on the grant?  This might occur if
DDNS was turned off at the time the lease was granted and then enabled
prior to the release request.  In such a case, yes, I believe we will
still attempt it.  However, D2 will consider should consider the outcome
successful if the DNS outcome is "not found".

>> 9) - The text says that N=1, S=1 packets will be dropped.  Will they be completely
>> dropped (no address allocated) or will the DDNS step be dropped?
> It will be completely dropped.
Both bits on is not valid per RFC(s). Packet parsing will catch this and
discard the packet.
>> 10) 6.2.12 - generated names, it appears as if the leading hyphen always required
>> is that true?  or if one sets the generated prefix to "" will it be left out?
> Why do you think the hyphen is always required?
If the prefix is ""  you will end up with a leading hyphen.  This is an

>> 11) 6.2.14 - is echo-client-id a global or can it be more specific?
> It is global.
>> 12) 6.4.1 - can there be only one relay and ip address?  or can there be multiple of either?
> One at the time. But, this could be easily extended to a list.
>> 13) in 7.2.6 we mention there is no danger when using gigantic address pools.  
>> I assume the danger would be to allocating large amounts of memory which would
>> seem to be true for pre-allocation.  But as we aren't doing clean up yet don't we
>> have a potential for usng large amounts of resources over time?  should we mention
>> that?
> The lease information is stored in memory (for memfile backend) so if
> there are many addresses allocated, the memory usage will grow. I think,
> the text could mention this. Yes.
>> 14) 7.2.8 the comment mentions numbers in the first column, but I don't see any?
> Oops, this may have been an internal comment in the xml which should not
> pop-up in the text. Good catch.
>> 15) In general there seems to be some confusion over ". " or ".  " to end a sentence,
>> that is should a period at the end of a sentence be followed by 1 or 2 spaces.
>> I typically do the second and I think there were some uses of that before my edits
>> but I also see a lot of the first.  We should probably pick one and be consistent.
>> 16) - we may wish to make clear if the server-ip can be v4 or v6 for both dhcp4
>> and dhcp6.  In this text we describe the loop back as a v4 address ( and the
>> example as a v6 address.
> The description of server-ip in does mention it could be both
> v4 and v6 address.
>> 17) 7.2 - we should probably allow for two options in the name creation area.  I can
>> see people wanting either what is there or a fully spelled out address (no zero compression
>> on v6 addresses) to make sure the names are all the same length for other processing.
> I am not sure I understand this point in the context of 7.2. But, we
> generally do allow for fully spelled out addresses.
>> 18) D2 - we currently don't support finding the appropriate DNS server via queries.
>> We may want to make this explicit and to indicate our plans in this area.  I believe
>> that some customers may want this feature.
>> 19) 8.2 - the v4 and v6 configuration sections start by showing the appropriate block
>> within the entire config file (mostly this means and extra pair of braces outside of
>> the block).  I'm wondering if D2 should do the same.
> Yes. I think it should.
>> 20) - What happens if i include a hostname paramenter?  What is the planned
>> response in the future if an entry has both a hostname and ip_address?  (I'm curious
>> about what will happen if I try and prepare for when hostname is available.)
> I am not sure what Tom's plans were for this.
Currently, configuration validation enforces mutual exclusivity, and
will complain if you specify both a hostname and an ip-address.   As to
the future plans, my initial thought was to attempt resolution of the
host name and if that fails, that server is unavailable.   One could
contemplate allowing both and preferring a value found my host-name
resolution over the configured IP, but you would have essentially the
same behavior by supplying two server entries, one with host name and
one with an explicit IP.   There is nothing concrete designed at this point.

>> 21) 9.1 - perhaps expand a bit on the use of raw sockets?  Mostly that they are necessary
>> for (more or less) directly connected clients and not so much for relays that use IP?
> Yes. It should maybe also be mentioned that when you don't need to
> handle directly connected clients, it would be better to use IP/UDP
> sockets as you don't have to deal with the issues with bypassing IP
> firewalls. But, the switch to disable the use of raw sockets is not
> implemented yet.
> Marcin
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev

More information about the kea-dev mailing list