[Kea-users] Converting an ISC IPv6 class definition to Kea syntax

Sun Apr 21 14:00:16 UTC 2024

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