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. Thoughts on reading the ARM documents (Shawn Routhier)
2. Re: Thoughts on reading the ARM documents (Angelo Failla)
3. Re: Thoughts on reading the ARM documents (Marcin Siodelski)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Oct 2014 20:14:45 -0700
From: Shawn Routhier <[email protected]>
To: [email protected]
Subject: [kea-dev] Thoughts on reading the ARM documents
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
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?
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.
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?
4) Is there a background option for starting a server directly?
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).
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.
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?
8) 6.2.8 - for the vendor encapsulated space, can we pick and choose which one
to send based
on something in the request?
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?
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)
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?
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?
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?
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.
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).
2) 3.4.4 - mentions "prepare the Python scripts", we don't use python anymore
do we?
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?
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?
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).
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.
8) 6.2.12.2, 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?
9) 6.2.12.2 - 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?
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?
11) 6.2.14 - is echo-client-id a global or can it be more specific?
12) 6.4.1 - can there be only one relay and ip address? or can there be
multiple of either?
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?
14) 7.2.8 the comment mentions numbers in the first column, but I don't see any?
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) 7.2.16.1 - 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 (127.0.0.1)
and the
example as a 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.
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.
20) 8.2.3.1.1 - 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.)
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?
------------------------------
Message: 2
Date: Fri, 24 Oct 2014 10:34:41 +0000
From: Angelo Failla <[email protected]>
To: Shawn Routhier <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Thoughts on reading the ARM documents
Message-ID: <d06fe633.1e8fb%[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
On 10/24/14, 4:14 AM, "Shawn Routhier" <[email protected]> wrote:
>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.
In Facebook we use a Python script that uses Scapy
<http://www.secdev.org/projects/scapy/>
for that.
It works for both DHCPv4 and v6.
Since we basically use host reservation via a customized hook we just have
to check that
the returned IP for a SOLICIT/DISCOVER is the expected one.
For DHCPv6 we have to pretend to be a DHCP relayer because kea dhcp6
discards messages
that has been sent to unicast.
If you are interested I can see if I can remove a few facebook-ism from
the script and make
a pull request so that you can put it in your tests/ contrib/ (or whatever
you guys use)
Directories.
Let me know!
>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).
For leases have you guys thought about using memcache or other key value
stores?
Some of them like Redis have disk persistency features:
http://redis.io/topics/persistence
I?m suggesting those systems because they might provide better latency as
everything is served from memory.
-
Angelo Failla
Cluster Operations
Facebook Ireland
------------------------------
Message: 3
Date: Fri, 24 Oct 2014 13:09:24 +0200
From: Marcin Siodelski <[email protected]>
To: Shawn Routhier <[email protected]>, [email protected]
Subject: Re: [kea-dev] Thoughts on reading the ARM documents
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
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.
> 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.
> 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) 6.2.12.2, 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.
> 9) 6.2.12.2 - 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.
> 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?
> 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) 7.2.16.1 - 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
> (127.0.0.1) and the
> example as a v6 address.
>
The description of server-ip in 7.2.16.1 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) 8.2.3.1.1 - 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.
> 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
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 7, Issue 10
**************************************
