Age | Commit message (Collapse) | Author |
|
Reinstate support for hostname in DHCP reservation. Having `hostname` in
allows for server-side assignment of hostname. This is useful for static
lookup of hostname.
Ensure that hostname is a valid FQDN (doesn't have underscore, etc.)
Additionally, support using either of DUID or MAC address for
reservation. While MAC address is typically used for IPv4, and DUID is
typically used for IPv6, either of them can be used in IPv4 and IPv6
reservations in Kea.
|
|
|
|
|
|
If a parameter is required is determined from the Python string on commit.
This "indicator" is not used consistently and sometimes missing, or added where
it is not required anymore due to Python script improvement/rewrite.
|
|
|
|
Add vendor specific options for DHCPv6-server for working with
cisco VoIP phone provisioning over IPv6
|
|
|
|
|
|
IPv4 DHCP uses "dns-server" to specify one or more name-servers for a given
pool. In order to use the same CLI syntax this should be renamed to name-server,
which is already the case for DHCPv6.
|
|
|
|
|
|
|
|
|
|
Error while copying statement from preference node.
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
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.
|