* Services: ISC DHCPv6 - show "tracking" interfaces when enabled an offer an explicit disable option for the service in question so someone could use dnsmasq or kea instead.
To avoid large changes, we opt for a minimal set here.
In services_dhcpv6.php, we add a separate form and handler in case tracking (without dhcpd6track6allowoverride) is set, which either flushes the unused isc-dhcpv6 server configuration when enabled (default) or writes a small section only including ['enabled' => -1].
For visibility, we show the calculated range as would be set by dhcpd_dhcp6_configure() when tracking is used.
The backend code then double checks the services which er explicitly disabled (-1) and skip processing for these (not enabled).
In order to make people aware of the fact that an isc-dhcpv6 server could be running, make sure the menu system also reflects reality.
Since router advertisements are stored within the same container and will need a toggle as well, keep the value of ramode so we have a way to intervene in a similar way as for dhcpv6.
One small side affect of this commit is that it will show "Services: Router Advertisements" for the tracking interface, which we need to implement later.
One of the building blocks for: https://github.com/opnsense/core/issues/8528
* Update src/www/services_dhcpv6.php
Co-authored-by: Franco Fichtner <franco@opnsense.org>
* Services: Router Advertisements: show "tracking" interfaces when enabled an offer an explicit disable option for the service in question so someone could use dnsmasq instead.
More or less the same construction as added for dhcpv6, using the ramode field to switch between types (disabled or assisted).
While here, also bugfix fieldname in services_dhcpv6.php
also for https://github.com/opnsense/core/issues/8528
---------
Co-authored-by: Franco Fichtner <franco@opnsense.org>
This contains roughly the same configuration items as our current isc-dhcp6 alternative, with the exception of not trying to implement dynamic ranges based on data received from dhclient6.
In terms of target audience, dynamic environments (receiving their "wan" type addressess via dhcp), should logically use dnsmasq for client configuration. Large (enterprise) setups usually are static by nature and may require prefix deligation to routers behind the primary one. In these cases Kea will be the tool of choice.
Both v4 and v6 share the same rc scripts underneath, which means reconfiguration happens per package (eventhough two services are registered).
Existing hooks for v4 have been extended with v6 data (firewall rules and staticmaps).
Advanced configurations can still opt out of config file generation and supply their own json config, same as implemented for v4.
The lease view still needs to be implemented, but that's likely a minor addition.
The level key words are easy to find in the source code, but knowing
which verbose description they belong to is difficult without pulling
up our source code as well. Make it explicit.
This prevents validation errors when interfaces are temporarily
disabled. Other device components received similar fixes in the
past due to this "glitch" of not offering valid devices and selectpickers
would lose their correct value on save too (the field is a bit different
here but the same principle applies).
When attaching a GIF tunnel to an IPv6 device it's more likely a LAN
device but that is being missed when WAN is reloaded here. Much of the
other code still accounts for this so this merely goes with the flow
and since we only operate in IPv6 scope that is ok.
