summaryrefslogtreecommitdiff
path: root/interface-definitions/dhcpv6-server.xml.in
AgeCommit message (Collapse)Author
2021-05-01dhcpv6-server: T3379: Add option global-parameters name-serversever-sever
(cherry picked from commit 117533482d29ce0bd1bc7f3a3f2536921c16565c)
2021-01-07xml: include: provide generic include for disable nodeChristian Poessinger
2020-10-19dhcpv6-server: T3000: fix prefix-degeation prefix-length help stringsChristian Poessinger
Error while copying statement from preference node.
2020-10-05dhcp(v6)-server: T2961: use fqdn validator wnd move to include snippedChristian Poessinger
Migrate the domain-search node (which occurs three times) to an includable snippet. Also re-use the fqdn validator to keep the regex patterns to as few locations as possible.
2020-10-04dhcpv6: T2961: support stateless dhcpv6 clientsLucas Christian
This commit adds support for configuring the DHCPv6 server to serve "stateless" DHCPv6 clients (those that send an information-request message and do not request an address). The change introduces a `common-options` node at the `shared-network-name` level, which allows specifying options applicable to clients regardless of subnet assigned (or in the case of stateless clients, when no subnet is assigned). Parameters specified at the subnet level take precedence over those set at the shared-network level. Presently, only parameters that are meaningful to stateless clients have been exposed under `common-options`, as there is no precedent of exposing parameters at multiple levels under the current DHCPv4 or DHCPv6 configuration syntax. If desired, additional parameters could certainly be added with relative ease.
2020-04-30dhcpv6-server: T2406: add lease-time validator to XMLChristian Poessinger
2020-04-30dhcpv6-server: T2406: merge sip-server-{address,name} to sip-server nodeChristian Poessinger
The subnet specific nodes sip-server-address & sip-server-name do the same for the user - specify a SIP server. Only the backend is rendered in a different way, as ISC DHCPv6 expects different options. There is absolutely no need for the user to distinguish between both two nodes.
2019-12-06T1843: run interface-definitions though GCC preprocessorChristian Poessinger
A lot of XML code is duplicated (VLAN, interface address) for instance. Such XML definitions should be moved to feature.xml.i files and then just pulled in via GCC preprocessor #include definition in e.g. bond or ethernet definitions. This will give us the ability to single-source repeating node definitions as: * Interface Address * Interface Description * Interface Disable * VLAN (both vif-s and vif-c) The .in suffix of the interface-definitions is a marker that those files are input files to the GCC preprocessor. They will be rendered into proper XML files in the build directory. Some node definitions have been reworder to remove escaped double quote occurances which would have been warned about by the GCC preprocessor.