Hi Kraishak,

You can put option-def in classes and in the global area.  Perhaps not
in the subnet block.  I think you can place them in reservations also.
You would have to decide what is best for your environment.

Thank you,

Darren Ankney

On Thu, Jun 22, 2023 at 11:42 AM Kraishak Mahtha <kraishak....@gmail.com> wrote:
>
> Hi Michael,
>
> Thanks for sharing the reference.
> So basically to use vendor option 43 we must implement it using the option 
> space(sub-option) concept like this right?
>
> "option-data": [ { "name": "vendor-encapsulated-options", "always-send": true 
> }, { "name": "pnpserver", "space": "vendor-encapsulated-options-space", 
> "data": "5A1D;K4;B2;I192.0.2.16" }
>
>
> I am a bit confused as no one confirms the statement as valid.
>
> My ISC config has the format below where I don't have any option spaces using 
> while this option 43
>  subnet 3.4.0.0 netmask 255.255.0.0 {
>         pool {
>                 range 3.4.0.2 3.4.0.5;
>                 range 3.4.0.12 3.4.0.16;
>                 range 3.4.0.41 3.4.0.56;
>         }
>                 default-lease-time 86400;
>                 max-lease-time 86400;
>                 option domain-name "test.com";
>                 option domain-name-servers 6.6.6.6,7.7.7.7,8.8.8.4;
>                 option routers 3.4.0.1;
>                 option subnet-mask 255.255.0.0;
>                 option vendor-encapsulated-options "test";
> }
>
> It is exactly the same except for the value test for 
> vendor-encapsulated-options hence I am getting doubts. even I tried using the 
> keama tool but that just converted to option 43 without any new sub-options 
> defined
>
> On Thu, Jun 22, 2023 at 4:09 PM Michael Schwartzkopff via Kea-users 
> <kea-users@lists.isc.org> wrote:
>>
>> hi,
>>
>>
>> wrote an article about the use of option 43 in KEA for Cisco PnP. Perhaps 
>> you can get inspiration from there.
>>
>> https://blog.sys4.de/blog/kea-veos/
>>
>>
>> Michael.
>>
>>
>> On 22.06.23 12:27, Kraishak Mahtha wrote:
>>
>>  kea-dhcp4 -t kea-dhcp4.conf.option43
>> Syntax check failed with: kea-dhcp4.conf.option43:67.14-25: got unexpected 
>> keyword "option-def" in subnet4 map
>>
>> It is saying we cannot use the option-def inside the subnet4 section, It 
>> should be within class-def or in the global section I guess
>>
>> On Tue, Jun 20, 2023 at 3:08 PM Darren Ankney <darren.ank...@gmail.com> 
>> wrote:
>>>
>>> Hi Kraishak,
>>>
>>> Please provide the error message that you received.
>>>
>>> Thank you,
>>>
>>> Darren Ankney
>>>
>>> On Sun, Jun 18, 2023 at 1:34 AM Kraishak Mahtha <kraishak....@gmail.com> 
>>> wrote:
>>> >
>>> > Hi Darren,
>>> >  This might be best kept out of the global area (use in subnet, classes 
>>> > etc..),
>>> > ------>do you mean the following?
>>> >
>>> > "subnet4": [
>>> >         {
>>> >             "subnet": "4.0.0.0/16",
>>> >             "valid-lifetime": 86400,
>>> >             "option-def": [{
>>> >                  "code": 43,
>>> >                  "name": "vendor-encapsulated-options",
>>> >                   "type": "string",
>>> >                   "space": "dhcp4"
>>> >             }],
>>> >             "option-data": [
>>> >                 {
>>> >                   "name": "vendor-encapsulated-options",
>>> >                   "data": "any old string"
>>> >                 },
>>> >                 {
>>> >                     "data": "6.6.6.6, 7.7.7.7, 8.8.8.4",
>>> >                     "name": "domain-name-servers"
>>> >                 },
>>> >                 {
>>> >                     "data": "86400",
>>> >                     "name": "dhcp-lease-time"
>>> >                 },
>>> >                 {
>>> >                     "data": "255.255.0.0",
>>> >                     "name": "subnet-mask"
>>> >                 },
>>> >                 {
>>> >                     "data": "4.0.0.1",
>>> >                     "name": "routers"
>>> >                 }],
>>> >             "pools": [
>>> >                 {
>>> >                     "pool": "4.0.0.2-4.0.6.125"
>>> >                 }
>>> >             ],
>>> >             "id": 786173
>>> >         },
>>> > but it gives a syntax error for me and I don't see any reference in any 
>>> > forums too that declares the option definition within the subnet.
>>> >
>>> >
>>> > On Thu, Jun 15, 2023 at 9:21 PM Darren Ankney <darren.ank...@gmail.com> 
>>> > wrote:
>>> >>
>>> >> Hi Kraishak,
>>> >>
>>> >> I am informed by a colleague that you can redefine the expected
>>> >> contents of option 43 as shown:
>>> >> "option-def": [
>>> >>    {
>>> >>       "name": "vendor-encapsulated-options",
>>> >>       "code": 43,
>>> >>       "type": "string"
>>> >>    }
>>> >> "option-data": [
>>> >>    {
>>> >>       "name": "vendor-encapsulated-options",
>>> >>       "data": "any old string"
>>> >>    },
>>> >> ]
>>> >> which will allow you to store strings directly in the option.  This
>>> >> might be best kept out of the global area (use in subnet, classes
>>> >> etc..), however, in case you need to use option 43 in the default way
>>> >> with sub-options.
>>> >>
>>> >> Thank you,
>>> >>
>>> >> Darren Ankney
>>> >>
>>> >> On Wed, Jun 14, 2023 at 10:03 AM Kraishak Mahtha 
>>> >> <kraishak....@gmail.com> wrote:
>>> >> >
>>> >> > Yes, for a few of my lab centers that run using the ISC, I have 
>>> >> > checked the config and they only have option 43 in their subnet 
>>> >> > without any option spaces so I thought it would be the same for kea.
>>> >> > I don't have much familiarity with this option 43 but the current 
>>> >> > clients in the subnet do use option 43, My existing production has the 
>>> >> > same options with different values (a domain, number, and text) . I 
>>> >> > just replaced them with some random text and I am checking the tcpdump 
>>> >> > of both ISC and Kea server output to make sure I see the same results.
>>> >> >
>>> >> > In ISC tcpdump I can see the option value for option 43 and for kea, 
>>> >> > it is missing completely
>>> >> >
>>> >> >  TIME: 13:59:13.451640
>>> >> >     IP: > (00:50:56:99:38:1c) >  (00:50:56:99:5c:f3)
>>> >> >     OP: 2 (BOOTPREPLY)
>>> >> >  HTYPE: 1 (Ethernet)
>>> >> >   HLEN: 6
>>> >> >   HOPS: 0
>>> >> >    XID: 36835441
>>> >> >   SECS: 0
>>> >> >  FLAGS: 7f80
>>> >> > CIADDR: 0.0.0.0
>>> >> > YIADDR: 3.4.0.2
>>> >> > SIADDR: 0.0.0.0
>>> >> > GIADDR: 3.4.0.1
>>> >> > CHADDR: a1:21:2f:00:00:01:00:00:00:00:00:00:00:00:00:00
>>> >> >  SNAME: .
>>> >> >  FNAME: .
>>> >> > OPTION:  53 (  1) DHCP message type         5 (DHCPACK)
>>> >> > OPTION:  54 (  4) Server identifier         192.168.0.81
>>> >> > OPTION:  51 (  4) IP address leasetime      86400 (24h)
>>> >> > OPTION:   1 (  4) Subnet mask               255.255.0.0
>>> >> > OPTION:   3 (  4) Routers                   3.4.0.1
>>> >> > OPTION:   6 ( 12) DNS server                6.6.6.6,7.7.7.7,8.8.8.4
>>> >> > OPTION:  15 ( 11) Domainname                test.com
>>> >> > OPTION:  43 ( 11) Vendor specific info      74657374 test
>>> >> >
>>> >> >
>>> >> >  >>It sounds like you should be able to send data that isn't a 
>>> >> > suboption, but I cannot find anywhere in the ARM that indicates that 
>>> >> > Kea supports this.
>>> >> > ---> This is the major thing if we have different behavior change for 
>>> >> > option 43 in kea compared to ISC
>>> >> >
>>> >> > On Wed, Jun 14, 2023 at 6:48 PM Darren Ankney 
>>> >> > <darren.ank...@gmail.com> wrote:
>>> >> >>
>>> >> >> Hi Kraishak,
>>> >> >>
>>> >> >> I don't know if I can provide more specific information than is
>>> >> >> contained in the RFC 2132 section about option 43:
>>> >> >> https://www.rfc-editor.org/rfc/rfc2132#section-8.4
>>> >> >>
>>> >> >> According to the RFC, the data in option 43 is "opaque" as it is meant
>>> >> >> to be vendor specific.  It sounds like you should be able to send data
>>> >> >> that isn't a suboption, but I cannot find anywhere in the ARM that
>>> >> >> indicates that Kea supports this. It definitely supports sending
>>> >> >> sub-options of option 43 which is the usual case encountered in
>>> >> >> practice.
>>> >> >>
>>> >> >> Thank you,
>>> >> >>
>>> >> >> Darren Ankney
>>> >> >>
>>> >> >> On Wed, Jun 14, 2023 at 8:46 AM Kraishak Mahtha 
>>> >> >> <kraishak....@gmail.com> wrote:
>>> >> >> >
>>> >> >> > Hi Darren,
>>> >> >> >
>>> >> >> > I am testing for each option and its corresponding behavior in kea 
>>> >> >> > by checking the tcpdump and packet4.log mainly
>>> >> >> >
>>> >> >> > Can you please confirm one thing, so basically to use option 43 do 
>>> >> >> > we must need to define the vendor-encapsulated-options-space in 
>>> >> >> > both ISC and Kea-DHCP?
>>> >> >> >
>>> >> >> > I am a bit confused here, maybe it would be basic but can you 
>>> >> >> > please give me more info on it or any reference link so that I can 
>>> >> >> > understand the scope of option 43
>>> >> >> >
>>> >> >> > Thanks In Advance
>>> >> >> > Kraishak
>>> >> >> >
>>> >> >> > On Tue, Jun 13, 2023 at 6:08 PM Darren Ankney 
>>> >> >> > <darren.ank...@gmail.com> wrote:
>>> >> >> >>
>>> >> >> >> Hi Kraishak,
>>> >> >> >>
>>> >> >> >> Does this do something for some device you are trying to support?
>>> >> >> >>
>>> >> >> >> option vendor-encapsulated-options "test";
>>> >> >> >>
>>> >> >> >> Typically, option 43 is defined on the basis of something that a
>>> >> >> >> vendor device needs to receive.  That gives some constraints 
>>> >> >> >> regarding
>>> >> >> >> how it is configured.  Most of the time, it will be a collection of
>>> >> >> >> one or more sub-options.  For example, here is one vendor's 
>>> >> >> >> passing of
>>> >> >> >> a URL for tr69 in ISC DHCP:
>>> >> >> >>
>>> >> >> >> option space CALIXGC;
>>> >> >> >> option CALIXGC.acs-url code 1 = text;
>>> >> >> >> vendor-option-space CALIXGC;
>>> >> >> >> option CALIXGC.acs-url "http://someurl";;
>>> >> >> >>
>>> >> >> >> which, translated to Kea, would look like this:
>>> >> >> >>
>>> >> >> >>     "option-def": [
>>> >> >> >>       {
>>> >> >> >>         "space": "CALIXGC",
>>> >> >> >>         "name": "acs-url",
>>> >> >> >>         "code": 1,
>>> >> >> >>         "type": "string"
>>> >> >> >>       },
>>> >> >> >>       {
>>> >> >> >>         "name": "vendor-encapsulated-options",
>>> >> >> >>         "code": 43,
>>> >> >> >>         "type": "empty",
>>> >> >> >>         "encapsulate": "CALIXGC"
>>> >> >> >>       }
>>> >> >> >>     ],
>>> >> >> >>     "option-data": [
>>> >> >> >>       {
>>> >> >> >>         "name": "vendor-encapsulated-options",
>>> >> >> >>         "code": 43
>>> >> >> >>       },
>>> >> >> >>       {
>>> >> >> >>         "space": "CALIXGC",
>>> >> >> >>         "name": "acs-url",
>>> >> >> >>         "code": 1,
>>> >> >> >>         "data": "http://someurl";
>>> >> >> >>       }
>>> >> >> >>     ]
>>> >> >> >>
>>> >> >> >> See if you can send that to your device or discover what actual 
>>> >> >> >> data
>>> >> >> >> your device needs and we can see how that might be configured?
>>> >> >> >>
>>> >> >> >> Thank you,
>>> >> >> >>
>>> >> >> >> Darren Ankney
>>> >> >> >>
>>> >> >> >> On Tue, Jun 13, 2023 at 7:42 AM Kraishak Mahtha 
>>> >> >> >> <kraishak....@gmail.com> wrote:
>>> >> >> >> >
>>> >> >> >> > Hi Darren,
>>> >> >> >> >
>>> >> >> >> > Thank you for the suggestion but I am still facing the same 
>>> >> >> >> > problem.
>>> >> >> >> >
>>> >> >> >> >         {
>>> >> >> >> >                      "code": "43",
>>> >> >> >> >                     "csv-format": true,
>>> >> >> >> >                     "data": "74657374",
>>> >> >> >> >                },
>>> >> >> >> >
>>> >> >> >> > ---> With the above format I am getting a few issues because of 
>>> >> >> >> > double quotes for the code, and for CSV format, If I set that to 
>>> >> >> >> > true I am getting an error as
>>> >> >> >> > 2023-06-13 06:23:40.309 ERROR 
>>> >> >> >> > [kea-dhcp4.dhcp4/6561.139810011805888] DHCP4_PARSER_FAIL failed 
>>> >> >> >> > to create or run parser for configuration element subnet4: 
>>> >> >> >> > option data does not match option definition (space: dhcp4, 
>>> >> >> >> > code: 43): attempt to write invalid option data field type into 
>>> >> >> >> > the option buffer: 0 (kea-dhcp4.conf:60:27)
>>> >> >> >> > Error encountered: option data does not match option definition 
>>> >> >> >> > (space: dhcp4, code: 43): attempt to write invalid option data 
>>> >> >> >> > field type into the option buffer: 0 (kea-dhcp4.conf:60:27)
>>> >> >> >> >
>>> >> >> >> > The final trial is as follows:
>>> >> >> >> >         {
>>> >> >> >> >                      "code": "43",
>>> >> >> >> >                     "csv-format": false,
>>> >> >> >> >                     "data": "74657374",
>>> >> >> >> >                },
>>> >> >> >> >
>>> >> >> >> > This also gave me an empty for option 43  in the ACK packet.
>>> >> >> >> >
>>> >> >> >> > This is the subnet of the ISC config that I using for testing
>>> >> >> >> >  subnet 3.4.0.0 netmask 255.255.0.0 {
>>> >> >> >> >         pool {
>>> >> >> >> >                 range 3.4.0.2 3.4.0.5;
>>> >> >> >> >                 range 3.4.0.12 3.4.0.16;
>>> >> >> >> >                 range 3.4.0.41 3.4.0.56;
>>> >> >> >> >         }
>>> >> >> >> >                 default-lease-time 86400;
>>> >> >> >> >                 max-lease-time 86400;
>>> >> >> >> >                 option domain-name "test.com";
>>> >> >> >> >                 option domain-name-servers 
>>> >> >> >> > 6.6.6.6,7.7.7.7,8.8.8.4;
>>> >> >> >> >                 option routers 3.4.0.1;
>>> >> >> >> >                 option subnet-mask 255.255.0.0;
>>> >> >> >> >                 option vendor-encapsulated-options "test";
>>> >> >> >> > }
>>> >> >> >> >
>>> >> >> >> > Thanks
>>> >> >> >> > Kraishak
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > On Tue, Jun 13, 2023 at 12:35 AM Darren Ankney 
>>> >> >> >> > <darren.ank...@gmail.com> wrote:
>>> >> >> >> >>
>>> >> >> >> >> Hi Kraishak,
>>> >> >> >> >>
>>> >> >> >> >> Have a look here:
>>> >> >> >> >> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html?highlight=%22vendor-encapsulated-options%22#dhcpv4-vendor-specific-options
>>> >> >> >> >>
>>> >> >> >> >> You might need to setup encapsulated sub-options and tell Kea to
>>> >> >> >> >> include the "vendor-encapsulated-options-space" content in the 
>>> >> >> >> >> options
>>> >> >> >> >> as a sub-option:
>>> >> >> >> >>
>>> >> >> >> >>  "option-data": [
>>> >> >> >> >>    {
>>> >> >> >> >>      "name": "REPLACE_ME",
>>> >> >> >> >>      "space": "vendor-encapsulated-options",
>>> >> >> >> >>      "code": 1,
>>> >> >> >> >>      "csv-format": false,
>>> >> >> >> >>      "data": "74657374"
>>> >> >> >> >>    },
>>> >> >> >> >>     {
>>> >> >> >> >>        "name": "vendor-encapsulated-options"
>>> >> >> >> >>       }
>>> >> >> >> >>   ]
>>> >> >> >> >>
>>> >> >> >> >> So, above, first the data is added as a sub-option of option 43
>>> >> >> >> >> (option 43 typically consists of one or more sub-options).  
>>> >> >> >> >> Replace
>>> >> >> >> >> "REPLACE_ME" with the name of the sub-option you are trying to 
>>> >> >> >> >> send (I
>>> >> >> >> >> think you can omit name entirely if there is none as that part 
>>> >> >> >> >> isn't
>>> >> >> >> >> sent).  Set the code to the correct sub-option number.  If this
>>> >> >> >> >> particular data should not be a sub-option, then you might have 
>>> >> >> >> >> to do
>>> >> >> >> >> something like this:
>>> >> >> >> >>
>>> >> >> >> >>         {
>>> >> >> >> >>                      "code": "43",
>>> >> >> >> >>                     "csv-format": true,
>>> >> >> >> >>                     "data": "74657374",
>>> >> >> >> >>                },
>>> >> >> >> >>
>>> >> >> >> >> please note that if "csv-format" is set to false, then Kea will 
>>> >> >> >> >> be
>>> >> >> >> >> expecting "a hexadecimal string." see:
>>> >> >> >> >> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html?highlight=%22csv-format%22#standard-dhcpv4-options
>>> >> >> >> >>
>>> >> >> >> >> Can you share the option 43 portion of the ISC DHCP 
>>> >> >> >> >> configuration you
>>> >> >> >> >> are trying to convert if you still have trouble?
>>> >> >> >> >>
>>> >> >> >> >> Thank you,
>>> >> >> >> >>
>>> >> >> >> >> Darren Ankney
>>> >> >> >> >>
>>> >> >> >> >> On Mon, Jun 12, 2023 at 1:59 PM Kraishak Mahtha 
>>> >> >> >> >> <kraishak....@gmail.com> wrote:
>>> >> >> >> >> >
>>> >> >> >> >> > Hi,
>>> >> >> >> >> > I am trying to convert my ISC config to kea-equivalent and 
>>> >> >> >> >> > testing the changes as part of the testing, I am stuck at 
>>> >> >> >> >> > testing option 43 ,
>>> >> >> >> >> > Using the keama tool I convert my ISC config to Kea 
>>> >> >> >> >> > equivalent config and tested the leases but in the DHCP ACK 
>>> >> >> >> >> > packet I cannot see option 43 coming when I operate with Kea
>>> >> >> >> >> >
>>> >> >> >> >> > sample code config for option 43 that I used in my testing 
>>> >> >> >> >> > subnet
>>> >> >> >> >> >            {
>>> >> >> >> >> >                     "data": "74657374",
>>> >> >> >> >> >                     "name": "vendor-encapsulated-options",
>>> >> >> >> >> >                     "csv-format": false
>>> >> >> >> >> >                 },
>>> >> >> >> >> >
>>> >> >> >> >> > But in log and tcpdump I see the empty value for option 43
>>> >> >> >> >> >
>>> >> >> >> >> > Log:
>>> >> >> >> >> > ===
>>> >> >> >> >> > 2023-06-12 15:10:26.284 DEBUG 
>>> >> >> >> >> > [kea-dhcp4.packets/30590.140464453838592] DHCP4_RESPONSE_DATA 
>>> >> >> >> >> > [hwtype=1 21:21:2f:00:00:01], 
>>> >> >> >> >> > cid=[01:21:21:2f:00:00:01]x8259145: responding with packet 
>>> >> >> >> >> > DHCPACK (type 5), packet details: 
>>> >> >> >> >> > local_address=192.168.0.125:67, remote_address=4.0.0.1:67, 
>>> >> >> >> >> > msg_type=DHCPACK (5), =0x8259145,
>>> >> >> >> >> > options:
>>> >> >> >> >> >   type=001, len=004: 4294901760 (uint32)
>>> >> >> >> >> >   type=003, len=004: 4.0.0.1
>>> >> >> >> >> >   type=006, len=012: 6.6.6.6 7.7.7.7 8.8.8.4
>>> >> >> >> >> >   type=012, len=018: "dhcp-client-000001" (string)
>>> >> >> >> >> >   type=015, len=011: "test.com" (string)
>>> >> >> >> >> >   type=043, len=000:  ----->Empty Value, and I cross-verified 
>>> >> >> >> >> > the tcpdump too.
>>> >> >> >> >> >   type=051, len=004: 86400 (uint32)
>>> >> >> >> >> >   type=053, len=001: 5 (uint8)
>>> >> >> >> >> >   type=054, len=004: 192.168.0.125
>>> >> >> >> >> >   type=061, len=007: 01:21:21:2f:00:00:01
>>> >> >> >> >> >
>>> >> >> >> >> > I have checked the discover packet option 55 just to make 
>>> >> >> >> >> > sure if my packet is asking for option 43 or not, and yes I 
>>> >> >> >> >> > can see option 43 in the option 55 parameter value.
>>> >> >> >> >> >
>>> >> >> >> >> > I am not sure what is wrong I am doing, Can someone who has 
>>> >> >> >> >> > familiar can guide me
>>> >> >> >> >> >
>>> >> >> >> >> > Thanks in Advance
>>> >> >> >> >> > Kraishak
>>> >> >> >> >> > --
>>> >> >> >> >> > 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@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@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@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@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@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@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@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@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@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Reply via email to