[kea-dev] Searching in nested options

[Leonardo Jelenkovic]

Hello

We have a project and plan to use kea for dhcp part (part of it is being
formulated in
https://tools.ietf.org/html/draft-ietf-mif-mpvd-dhcp-support-02).
However, I have some design/implementation questions.


First, there is an error in:
http://kea.isc.org/docs/kea-guide.html#dhcp4-option-spaces example.
Adding "csv-format": false to container in "option-data":
{
    "name": "container",
    "code": 222,
    "space": "dhcp4",
    "csv-format": false
}
prevents error:
kea-dhcp4.dhcp4/8616] DHCP4_PARSER_FAIL failed to create or run parser for
configuration element option-data: option data does not match option
definition (space: dhcp4, code: 222): no option value specified
Same for #dhcp6-option-spaces.


Second, question/suggestion about nested DHCPcX options:
Since "option-data" items have "space" element, why is it required to
define each item for container, even if its standard option?
Wouldn't standard options (with standard code/name) that we want in
container be added just in "option-data" with "space" set to one in
container definition? Of course, "option-def" needs first to be searched if
such option is defined there, and if it isn't, search relevant dhcpX option
space.

For example, if I want dns-servers in container, I need to redefine it
within "option-def":
{
"name": "dns-servers",
"code": 23,
"space": "option-pvd",
"type": "ipv6-address",
"record-types": "",
"array": true,
"encapsulate": ""
}
I would like to avoid that. But this is just an small inconvenience for me.


And finally, the real problem I have.
Problem we have to solve can be described with a use-case:
1. Client sends option OPTION_PVD which is a container with suboption
OPTION_PVD_ID.
2. Server could have several OPTION_PVD options (containers) with different
suboption OPTION_PVD_ID. The OPTION_PVD option MAY be used to encapsulate
any allocated DHCPv6 options (but only single OPTION_PVD_ID).
3. Server must search its OPTION_PVD options (in client's allowed space)
and find one that matches one in client request (if found) and return that
option.

What is the simplest way to do it? With little coding as possible :)

I thought that a new element needs to be introduced, e.g. "pvds", which can
be defined globally (in dhcp6/dhcp4 space) and locally inside some subnet,
with example format:

"pvds": [
{
"pvd-id": "0265451e-905e-11e5-8994-feff819cdc9f",
"option-data": [
...
{
"name": "OPTION_PVD_ID",
"code": 1, #test code
"space": "option-pvd",
"csv-format": true,
"data": "0265451e-905e-11e5-8994-feff819cdc9f"
},
...
{ #container option, defined with "encapsulate": "option-pvd"
"name": "OPTION_PVD",
"code": 104, #test code
"space": "dhcp6",
"csv-format": false
},
...
],
},
...
]

I didn't yet examined kea source code, and can't predict how simple/complex
this is. I would appreciate any pointers (similar mechanisms already
implemented), and possible ways of implementing this feature.

Best regards,
Leonardo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-dev/attachments/20151121/c11425ce/attachment.html>