[Kea-users] Converting an ISC IPv6 class definition to Kea syntax
Darren Ankney
darren.ankney at gmail.com
Tue Apr 30 19:50:16 UTC 2024
Hi Marek,
It looks to me like, in your last screenshot, that option 17 is part
of the solicit message proper rather than the relay portion. It's a
little hard to tell from screenshots.
You can split the classes up for testing (or permanently) so that you
can see exactly what is happening. For example:
{
"name": "ecm-test-1",
"test": "substring(option[17].option[2].hex,0,3) == 'ECM'"
},
{
"name": "md-test-1",
"test": "member('ecm-test-1') and
substring(relay6[2].option[18].hex,0,9) == 'Md1:0/0.0'"
},
This will cause the logs to tell you which classes the client became a
member of so that you can note which part of the test is failing.
I think I've corrected your test strings above to reflect the actual
position in the packet. If you wouldn't mind attaching the actual
packet capture, however, that would make things easier.
Thank you,
Darren Ankney
On Mon, Apr 29, 2024 at 2:19 PM Marek Hajduczenia
<mxhajduczenia at gmail.com> wrote:
>
> Thank you, Darren,
>
>
>
> That seems to work as well.
>
>
>
> I did run into another corner case, I think, though. The same table shows relay6[nest].option[code].hex as the only available options for classifying on options within the Relay6 messages. I assume this applies to option 17/18/37, which are part of the relay message and can be accessed at the level of Relay6[1] in this example below. However, there are additional suboptions within these options, for example, sub-option 14 within option 17, so relay6[1].option[17].option[14].hex would be the only way to extract and match on this sub-option but this does not seem to be supported today. Is there any specific reason as to why?
>
>
>
>
>
> The issue that I am running into is related, i.e., the Solicit message I receive traverses two relays as shown below
>
>
>
>
>
> and I want to classify based on option 17, sub-option 2 and also option 18 in relay6[1], as shown below
>
>
>
> {
>
> "name": "ecm-1",
>
> "test": "substring(option[17].option[2].hex,0,3) == 'ECM' and substring(relay6[1].option[18].hex,0,9) == 'Md1:0/0.0'"
>
> },
>
>
>
> but the valuation logs show the “EVAL_DEBUG_SUB_OPTION_NO_OPTION Requested option 17 sub-option 2, but the parent option is not present, pushing result 0x” error, which implies option 17, sub-option 2 is requested but not found. I suspect it is matching on option 17 in outer relay messages for some reason.
>
>
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_SUB_OPTION_NO_OPTION Requested option 17 sub-option 2, but the parent option is not present, pushing result 0x
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text string '0'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text string '3'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_SUBSTRING_EMPTY Popping length 3, start 0, string 0x pushing result 0x
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text string 'ECM'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_EQUAL Popping 0x45434D and 0x pushing result 'false'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_OPTION Pushing option 18 with value 0x4D64313A302F302E3000A8705DD0DD0D
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text string '0'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text string '9'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_SUBSTRING Popping length 9, start 0, string 0x4D64313A302F302E3000A8705DD0DD0D pushing result 0x4D64313A302F302E30
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_STRING Pushing text string 'Md1:0/0.0'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_EQUAL Popping 0x4D64313A302F302E30 and 0x4D64313A302F302E30 pushing result 'true'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.eval/8872.140202025109056] EVAL_DEBUG_AND Popping 'true' and 'false' pushing 'false'
>
> Apr 29 17:34:22 server-kea-node1 kea-dhcp6[8872]: 2024-04-29 17:34:22.960 DEBUG [kea-dhcp6.dhcpsrv/8872.140202025109056] EVAL_RESULT Expression ecm-1 evaluated to 0
>
>
>
> That option / sub-option is definitely present in the packet but some reason the parser does not seem to be able to find it.
>
>
>
>
>
> I attempted to narrow it down to relay6[2] but that does not pass parser, and I do not see that syntax covered in the respective table: https://kea.readthedocs.io/en/kea-2.4.1/arm/classify.html#using-expressions-in-classification
>
>
>
> {
>
> "name": "ecm-1",
>
> "test": "substring(relay6[2].option[17].option[2].hex,0,3) == 'ECM' and substring(relay6[1].option[18].hex,0,9) == 'Md1:0/0.0'"
>
> },
>
>
>
> If there any way to make sure that the match applies to inner relay6 message not the outer one?
>
>
>
> Regards
>
>
>
> Marek
>
>
>
>
>
> -----Original Message-----
> From: Kea-users <kea-users-bounces at lists.isc.org> On Behalf Of Darren Ankney
> Sent: Saturday, April 27, 2024 9:21 AM
> To: Kea user's list <kea-users at lists.isc.org>
> Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to Kea syntax
>
>
>
> Hi Marek,
>
>
>
> I recently found out that you can use syntax like: 'vendor[<some vendor number>].option[<some option number>].hex' in class test lines to match instead of 'option[17].option[2].hex' as noted in the table
>
> here: https://kea.readthedocs.io/en/kea-2.4.1/arm/classify.html#id3
>
> Though it isn't exalty what you were asking for, perhaps it helps in some way?
>
>
>
> Thank you,
>
> Darren Ankney
>
>
>
>
>
> On Wed, Apr 24, 2024 at 8:51 AM Marek Hajduczenia <mxhajduczenia at gmail.com> wrote:
>
> >
>
> > Thank you, Darren,
>
> >
>
> >
>
> >
>
> > If these custom-defined options are outbound only, it would be great if that was mentioned in the documentation somewhere. In all my reading I did not find a single reference to that – perhaps I just missed it. I was treating it as any internally defined variable name, and since it can be used to specify outbound options, I figured they should also work the same way in ingress parser. Clearly, a wrong assumption on my part.
>
> >
>
> >
>
> >
>
> > Regards
>
> >
>
> >
>
> >
>
> > Marek
>
> >
>
> >
>
> >
>
> > From: Darren Ankney <darren.ankney at gmail.com>
>
> > Sent: Wednesday, April 24, 2024 3:51 AM
>
> > To: mxhajduczenia at gmail.com; Kea user's list <kea-users at lists.isc.org>
>
> > Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to
>
> > Kea syntax
>
> >
>
> >
>
> >
>
> > Understood Marek,
>
> >
>
> >
>
> >
>
> > > I still dislike the fact that I cannot use option definitions that already exist in the very same configuration file. They are there, the parser should be able to reference them internally as part of the vendor-specific option space.
>
> >
>
> >
>
> >
>
> > I understand this statement too. However, I feel it necessary to point out that those option definitions are so that you can fill option data in the defined option for outbound packets not so that you can use names to classify inbound packets.
>
> >
>
> >
>
> >
>
> > Thank you,
>
> >
>
> > Darren Ankney
>
> >
>
> >
>
> >
>
> > On Tue, Apr 23, 2024 at 9:50 AM Marek Hajduczenia <mxhajduczenia at gmail.com> wrote:
>
> >
>
> > Hi Darren,
>
> >
>
> >
>
> >
>
> > Thanks for the feedback.
>
> >
>
> >
>
> >
>
> > I did run a packet capture from a lab device and it is attached. I
>
> > hope it comes through - this is a DHCPv6 traffic from a DOCSIS CM
>
> > running in IPv6 mode only, two relay level deep, i.e., inner relay is
>
> > a vCMTS and outer relay is the first hop router. I hope clarify some
>
> > of the questions I have been asking
>
> >
>
> >
>
> >
>
> > Packet 11 is a relayed Solicit with Option 17, containing CableLabs specific sub-option (4491) and then inside of it, there is sub-option 2 (Device Type), which is what I need access to classify packets correctly.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > The very same device, just EROUTER requesting address (packet 21) and
>
> > again I will need access to the very same sub-option 2 (Device Type)
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > I will build a configuration pool on a Kea test node next and attempt to use your syntax suggestion, i.e., "test": "substring(option[17].option[2].hex,-1,7) == 'EROUTER'" but even if that works, I still dislike the fact that I cannot use option definitions that already exist in the very same configuration file. They are there, the parser should be able to reference them internally as part of the vendor-specific option space.
>
> >
>
> >
>
> >
>
> > I will report back when I am done with a test
>
> >
>
> >
>
> >
>
> > Thank you !
>
> >
>
> >
>
> >
>
> > Marek
>
> >
>
> >
>
> >
>
> > -----Original Message-----
>
> > From: Kea-users <kea-users-bounces at lists.isc.org> On Behalf Of Darren
>
> > Ankney
>
> > Sent: Tuesday, April 23, 2024 3:32 AM
>
> > To: Kea user's list <kea-users at lists.isc.org>
>
> > Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to
>
> > Kea syntax
>
> >
>
> >
>
> >
>
> > Hi Marek,
>
> >
>
> >
>
> >
>
> > I failed to notice that this was DHCPv6. I was talking about option
>
> >
>
> > 125 which is DHCPv4 vendor options. Option 17 is covered in the
>
> > manual here:
>
> > https://kea.readthedocs.io/en/kea-2.4.1/arm/dhcp6-srv.html#dhcpv6-vend
>
> > or-specific-options
>
> >
>
> > I am not clear regarding the presence of option 17 in the inbound packet (Solicit / request). Is option 17 in the packet? If so, then you may be able to use a test line like this:
>
> >
>
> >
>
> >
>
> > "test": "substring(option[17].option[2].hex,-1,7) == 'EROUTER'"
>
> >
>
> >
>
> >
>
> > Though again, I've not tested it. But my understanding is that option
>
> >
>
> > 17 is something the server sets to send back to the client, not the reverse. So I'm not sure this option will be present in the inbound packets to be tested. You can easily find out what is there by taking a packet capture, however.
>
> >
>
> >
>
> >
>
> > Thank you,
>
> >
>
> > Darren Ankney
>
> >
>
> >
>
> >
>
> > On Sun, Apr 21, 2024 at 10:00 AM <mxhajduczenia at gmail.com> wrote:
>
> >
>
> > >
>
> >
>
> > > You did hit the nail on the head, Darren,
>
> >
>
> > >
>
> >
>
> > > I have three device "classes" to deal with her:
>
> >
>
> > >
>
> >
>
> > > - DOCSIS CM, which will have Option 17 with sub-option 2 equal to
>
> >
>
> > > "ECM",
>
> >
>
> > > - DOCSIS embedded router (eROUTER), which will have Option 17 with
>
> >
>
> > > sub-option 2 equal to "EROUTER", and
>
> >
>
> > > - all devices connected to the DOCSIS CM, which will not have Option 17 (likely) - I do not control these, and these are just a random bag of devices.
>
> >
>
> > >
>
> >
>
> > > My train of through in here is simple: classify incoming DHCP packets (Solicits, since I am dealing with IPv6 only for now), and (a) match on ECM and give them addresses from a specific target pool, (b) then match on EROUTER and give them addresses from a specific target pool, and (c) whatever does not match on either condition, get an address from the "client" pool.
>
> >
>
> > >
>
> >
>
> > > In ISC, I was able to do that with "match if" statements, which work fine for my purposes. In Kea, I am struggling with logic here, since the parser does not seem to support locally defined vendor-specific class space.
>
> >
>
> > >
>
> >
>
> > > I am not sure whether your example below would work for me, since
>
> >
>
> > > Option 17 (DHCPv6) will have to have Vendor 4491 (CableLabs) defined
>
> >
>
> > > wrapper, and only then option 2 inside of it. That is what the "
>
> > > match
>
> >
>
> > > if (option docsis.device-type) = > 'EROUTER'" in ISC syntax was
>
> >
>
> > > achieving as far as I know. In Kea, it would be similar to
>
> >
>
> > > "test": "substring(vendor-4491.option[2].hex,-1,7) == 'EROUTER'" but parser does not like it, obviously. It does seem like it is one of the missing Kea features?
>
> >
>
> > >
>
> >
>
> > > Marek
>
> >
>
> > >
>
> >
>
> > > -----Original Message-----
>
> >
>
> > > From: Darren Ankney <darren.ankney at gmail.com>
>
> >
>
> > > Sent: Sunday, April 21, 2024 4:39 AM
>
> >
>
> > > To: mxhajduczenia at gmail.com; Kea user's list
>
> > > <kea-users at lists.isc.org>
>
> >
>
> > > Subject: Re: [Kea-users] Converting an ISC IPv6 class definition to
>
> >
>
> > > Kea syntax
>
> >
>
> > >
>
> >
>
> > > Hi Marek,
>
> >
>
> > >
>
> >
>
> > > I don't think you can use vendor option space like that. This MIGHT work:
>
> >
>
> > >
>
> >
>
> > > "test": "substring(option[125].option[2].hex,-1,7) == 'EROUTER'"
>
> >
>
> > >
>
> >
>
> > > But would option 125 exist in the inbound packet? I don't think class testing occurs on the outbound packets... It might help to understand what you are trying to achieve there as there might be a better way.
>
> >
>
> > >
>
> >
>
> > > Thank you,
>
> >
>
> > > Darren Ankney
>
> >
>
> > >
>
> >
>
> > > On Fri, Apr 19, 2024 at 5:22 PM Marek Hajduczenia <mxhajduczenia at gmail.com> wrote:
>
> >
>
> > > >
>
> >
>
> > > > Thank you, Darren,
>
> >
>
> > > >
>
> >
>
> > > > That does indeed at least pass the parser stage (actual device testing will have to wait). It is a pity that a regex is not yet available. I saw it was planned for 2.6 release?
>
> >
>
> > > >
>
> >
>
> > > > If I can build on the previous request, this part is more
>
> >
>
> > > > challenging, since it relays on a custom vendor address space,
>
> >
>
> > > > specifically, DOCSIS-specific sub-options in Option 17. Assume I
>
> >
>
> > > > have a "device-type" sub-option defined as follows
>
> >
>
> > > >
>
> >
>
> > > > "option-def": [
>
> >
>
> > > > {
>
> >
>
> > > > "space": "vendor-4491",
>
> >
>
> > > > "name": "device-type",
>
> >
>
> > > > "code": 2,
>
> >
>
> > > > "type": "string"
>
> >
>
> > > > }]
>
> >
>
> > > >
>
> >
>
> > > > and then I would like to classify based on it to translate the ISC
>
> >
>
> > > > compare statement of " match if (option docsis.device-type) =
>
> >
>
> > > > 'EROUTER'". Following your example below
>
> >
>
> > > >
>
> >
>
> > > > "test": "substring(vendor-4491.option[2].hex,-1,7) == 'EROUTER'"
>
> >
>
> > > >
>
> >
>
> > > > Should be theoretically possible, but I do not think the parser
>
> >
>
> > > > likes it much: [substring(vendor-4491.option[2].hex,-1,7) ==
>
> >
>
> > > > 'EROUTER']
>
> >
>
> > > > error: <string>:1.17-21: syntax error, unexpected integer,
>
> > > > expecting
>
> >
>
> > > > [ or . at (/etc/kea/kea-dhcp6.conf:141:17)
>
> >
>
> > > >
>
> >
>
> > > > Regards
>
> >
>
> > > >
>
> >
>
> > > > Marek
>
> >
>
> > > >
>
> >
>
> > > > -----Original Message-----
>
> >
>
> > > > From: Kea-users <kea-users-bounces at lists.isc.org> On Behalf Of
>
> >
>
> > > > Darren Ankney
>
> >
>
> > > > Sent: Friday, April 19, 2024 3:08 PM
>
> >
>
> > > > To: Kea user's list <kea-users at lists.isc.org>
>
> >
>
> > > > Subject: Re: [Kea-users] Converting an ISC IPv6 class definition
>
> > > > to
>
> >
>
> > > > Kea syntax
>
> >
>
> > > >
>
> >
>
> > > > Hi Marek,
>
> >
>
> > > >
>
> >
>
> > > > That is pseudo code generated by KeaMA as Kea doesn't support regex statements like ISC DHCP did. There was probably an additional line output that linked to some GL issue explaining. Something like this might work (I've not tested it):
>
> >
>
> > > >
>
> >
>
> > > > "client-classes": [
>
> >
>
> > > > {
>
> >
>
> > > > "name": "rpd-1",
>
> >
>
> > > > "test": "substring(relay6[1].option[18].hex,-1,9) == 'Md1:0/0.0'"
>
> >
>
> > > > }
>
> >
>
> > > > ]
>
> >
>
> > > >
>
> >
>
> > > > Thank you,
>
> >
>
> > > > Darren Ankney
>
> >
>
> > > >
>
> >
>
> > > > On Fri, Apr 19, 2024 at 4:27 PM Marek Hajduczenia <mxhajduczenia at gmail.com> wrote:
>
> >
>
> > > > >
>
> >
>
> > > > > Dear colleagues,
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > > I ran into a bit of a challenge with the conversion of the config from ISC to Kea, namely this little class definition gem:
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > > class "rpd-1" { match if v6relay( 1, option dhcp6.interface-id )
>
> >
>
> > > > > ~= "Md1:0/0.0$"; }
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > > What it does, as you can tell, it matches on the inner relay interface-id field in the DHCPv6 messages. Nothing fancy, it does work as tested.
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > > I have been looking at the available options and nothing comes
>
> > > > > to
>
> >
>
> > > > > mind so I used keama for automatic conversion and it generated
>
> >
>
> > > > > something pretty complex, as follows. Additionally, it is
>
> >
>
> > > > > commented out, so I assume this is a non-working configuration
>
> >
>
> > > > > element (?)
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > > "client-classes": [
>
> >
>
> > > > >
>
> >
>
> > > > > {
>
> >
>
> > > > >
>
> >
>
> > > > > "name": "rpd-1"
>
> >
>
> > > > >
>
> >
>
> > > > > // /// match if (v6relay(1, option dhcp6.interface-id)) ~= 'Md1:0/0.0$'
>
> >
>
> > > > >
>
> >
>
> > > > > // "match-if": {
>
> >
>
> > > > >
>
> >
>
> > > > > // "regex-match": {
>
> >
>
> > > > >
>
> >
>
> > > > > // "left": {
>
> >
>
> > > > >
>
> >
>
> > > > > // "v6relay": {
>
> >
>
> > > > >
>
> >
>
> > > > > // "relay": 1,
>
> >
>
> > > > >
>
> >
>
> > > > > // "relay-option": {
>
> >
>
> > > > >
>
> >
>
> > > > > // "option": {
>
> >
>
> > > > >
>
> >
>
> > > > > // "universe": "dhcp6",
>
> >
>
> > > > >
>
> >
>
> > > > > // "name": "interface-id",
>
> >
>
> > > > >
>
> >
>
> > > > > // "code": 18
>
> >
>
> > > > >
>
> >
>
> > > > > // }
>
> >
>
> > > > >
>
> >
>
> > > > > // }
>
> >
>
> > > > >
>
> >
>
> > > > > // }
>
> >
>
> > > > >
>
> >
>
> > > > > // },
>
> >
>
> > > > >
>
> >
>
> > > > > // "right": "Md1:0/0.0$"
>
> >
>
> > > > >
>
> >
>
> > > > > // }
>
> >
>
> > > > >
>
> >
>
> > > > > // }
>
> >
>
> > > > >
>
> >
>
> > > > > }]
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > > If I try to remove the comment markup and apply it with Kea 2.4.1, the parser does not like the “match-if” statement for some reason. I cannot locate it in the list of Kea statements, so not sure why it would be generated by keama. However, the bigger question is on how to build a Kea-compatible match on such embedded message. Any help here would be really appreciated.
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > > Apr 19 18:54:20 server-kea-node1 systemd[1]: Started Kea DHCPv6 Service.
>
> >
>
> > > > >
>
> >
>
> > > > > Apr 19 18:54:20 server-kea-node1 kea-dhcp6[2099]: 2024-04-19
>
> >
>
> > > > > 18:54:20.202 ERROR [kea-dhcp6.dhcp6/2099.841038976]
>
> >
>
> > > > > DHCP6_INIT_FAIL failed to initialize Kea server: configuration
>
> >
>
> > > > > error using file
>
> >
>
> > > > > '/etc/kea/kea-dhcp6.conf': /etc/kea/kea-dhcp6.conf:118.9-18:
>
> >
>
> > > > > syntax error, unexpected constant string, expecting }
>
> >
>
> > > > >
>
> >
>
> > > > > Apr 19 18:54:20 server-kea-node1 systemd[1]:
>
> >
>
> > > > > isc-kea-dhcp6-server.service: Main process exited, code=exited,
>
> >
>
> > > > > status=1/FAILURE
>
> >
>
> > > > >
>
> >
>
> > > > > Apr 19 18:54:20 server-kea-node1 systemd[1]: isc-kea-dhcp6-server.service: Failed with result 'exit-code'.
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > > Regards
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > >
>
> >
>
> > > > > Marek
>
> >
>
> > > > >
>
> >
>
> > > > > --
>
> >
>
> > > > > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> >
>
> > > > >
>
> >
>
> > > > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> >
>
> > > > >
>
> >
>
> > > > > Kea-users mailing list
>
> >
>
> > > > > Kea-users at lists.isc.org
>
> >
>
> > > > > https://lists.isc.org/mailman/listinfo/kea-users
>
> >
>
> > > > --
>
> >
>
> > > > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> >
>
> > > >
>
> >
>
> > > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> >
>
> > > >
>
> >
>
> > > > Kea-users mailing list
>
> >
>
> > > > Kea-users at lists.isc.org
>
> >
>
> > > > https://lists.isc.org/mailman/listinfo/kea-users
>
> >
>
> > > >
>
> >
>
> > > > --
>
> >
>
> > > > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> >
>
> > > >
>
> >
>
> > > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> >
>
> > > >
>
> >
>
> > > > Kea-users mailing list
>
> >
>
> > > > Kea-users at lists.isc.org
>
> >
>
> > > > https://lists.isc.org/mailman/listinfo/kea-users
>
> >
>
> > >
>
> >
>
> > --
>
> >
>
> > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> >
>
> >
>
> >
>
> > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> >
>
> >
>
> >
>
> > Kea-users mailing list
>
> >
>
> > Kea-users at lists.isc.org
>
> >
>
> > https://lists.isc.org/mailman/listinfo/kea-users
>
> >
>
> > --
>
> > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> >
>
> > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> >
>
> > Kea-users mailing list
>
> > Kea-users at lists.isc.org
>
> > https://lists.isc.org/mailman/listinfo/kea-users
>
> --
>
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
>
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
>
>
> Kea-users mailing list
>
> Kea-users at lists.isc.org
>
> https://lists.isc.org/mailman/listinfo/kea-users
>
> --
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
More information about the Kea-users
mailing list