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. Searching in nested options (Leonardo Jelenkovic)
2. Re: Searching in nested options (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Sat, 21 Nov 2015 16:36:34 +0100
From: Leonardo Jelenkovic <[email protected]>
To: [email protected]
Subject: [kea-dev] Searching in nested options
Message-ID:
<canjynktfpw_v3whofa8xp4szfp9-50btllqf6xd8eq_wotd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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-0001.html>
------------------------------
Message: 2
Date: Sun, 22 Nov 2015 02:21:38 +0000
From: Francis Dupont <[email protected]>
To: Leonardo Jelenkovic <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Searching in nested options
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Leonardo Jelenkovic writes:
> 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.
=> I remember to have updated the corresponding text, can you check
with last version of the guide?
> 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?
=> I don't understand how there can be standard options in a new space.
> 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?
=> I believe what you want is to be able to import definitions for
an option from another space, so if the same option is used in two
different spaces you have to define it once. Is it your idea?
> 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 :)
=> a hook (i.e., C++ code in a DSO).
> 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:
=> you need some syntax but fortunately a way to provide arguments
to a hook is being added.
> 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.
=> you already have vendor options (part of the standards), the hook
mechanism for any kind of extensions and with Kea >= 1.0 extended
classification. So you can implement what you'd like but of course
you prefer an easy/simple way...
Regards
Francis Dupont <[email protected]>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 20, Issue 11
***************************************
