<div dir="ltr"><div>Hello</div><div><br></div><div>We have a project and plan to use kea for dhcp part (part of it is being formulated in <a href="https://tools.ietf.org/html/draft-ietf-mif-mpvd-dhcp-support-02">https://tools.ietf.org/html/draft-ietf-mif-mpvd-dhcp-support-02</a>).</div><div>However, I have some design/implementation questions.</div><div><br></div><div><br></div><div>First, there is an error in: <a href="http://kea.isc.org/docs/kea-guide.html#dhcp4-option-spaces">http://kea.isc.org/docs/kea-guide.html#dhcp4-option-spaces</a> example.</div><div>Adding "csv-format": false to container in "option-data":</div><div>{</div><div>    "name": "container",</div><div>    "code": 222,</div><div>    "space": "dhcp4",</div><div>    "csv-format": false</div><div>}</div><div>prevents error:</div><div>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</div><div>Same for #dhcp6-option-spaces.</div><div><br></div><div><br></div><div>Second, question/suggestion about nested DHCPcX options:</div><div>Since "option-data" items have "space" element, why is it required to define each item for container, even if its standard option? </div><div>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.</div><div><br></div><div>For example, if I want dns-servers in container, I need to redefine it within "option-def":</div><div>{</div><div><span class="" style="white-space:pre">        </span>"name": "dns-servers",</div><div><span class="" style="white-space:pre"> </span>"code": 23,</div><div><span class="" style="white-space:pre">      </span>"space": "option-pvd",</div><div><span class="" style="white-space:pre"> </span>"type": "ipv6-address",</div><div><span class="" style="white-space:pre">        </span>"record-types": "",</div><div><span class="" style="white-space:pre">    </span>"array": true,</div><div><span class="" style="white-space:pre">   </span>"encapsulate": ""</div><div>}</div><div>I would like to avoid that. But this is just an small inconvenience for me.</div><div><br></div><div><br></div><div>And finally, the real problem I have.</div><div>Problem we have to solve can be described with a use-case:</div><div>1. Client sends option OPTION_PVD which is a container with suboption OPTION_PVD_ID. </div><div>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).</div><div>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.</div><div><br></div><div>What is the simplest way to do it? With little coding as possible :)</div><div><br></div><div>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:</div><div><br></div><div>"pvds": [</div><div><span class="" style="white-space:pre">  </span>{</div><div><span class="" style="white-space:pre">          </span>"pvd-id": "0265451e-905e-11e5-8994-feff819cdc9f",</div><div><span class="" style="white-space:pre">              </span>"option-data": [</div><div><span class="" style="white-space:pre">                 </span>...</div><div><span class="" style="white-space:pre">                        </span>{</div><div><span class="" style="white-space:pre">                          </span>"name": "OPTION_PVD_ID",</div><div><span class="" style="white-space:pre">                               </span>"code": 1, #test code</div><div><span class="" style="white-space:pre">                            </span>"space": "option-pvd",</div><div><span class="" style="white-space:pre">                         </span>"csv-format": true,</div><div><span class="" style="white-space:pre">                              </span>"data": "0265451e-905e-11e5-8994-feff819cdc9f"</div><div><span class="" style="white-space:pre">                 </span>},</div><div><span class="" style="white-space:pre">                 </span>...</div><div><span class="" style="white-space:pre">                        </span>{ #container option, defined with "encapsulate": "option-pvd"</div><div><span class="" style="white-space:pre">                          </span>"name": "OPTION_PVD",</div><div><span class="" style="white-space:pre">                          </span>"code": 104, #test code</div><div><span class="" style="white-space:pre">                          </span>"space": "dhcp6",</div><div><span class="" style="white-space:pre">                              </span>"csv-format": false</div><div><span class="" style="white-space:pre">                      </span>},</div><div><span class="" style="white-space:pre">                 </span>...</div><div><span class="" style="white-space:pre">                </span>],</div><div><span class="" style="white-space:pre"> </span>},</div><div><span class="" style="white-space:pre"> </span>...</div><div>]</div><div><br></div><div>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.</div><div><br></div><div>Best regards,</div><div>Leonardo</div><div><br></div><div><br></div></div>