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
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.
One of the building blocks for: https://github.com/opnsense/core/issues/8528
system: move get_country_codes() to only caller
Also cleans up the last raw use of $contribDir which neatly lands
in the file that was already modified.
Services: Kea DHCP: Kea DHCPv6 - add new option based on v4 (#8571)
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.
