Services: Kea DHCP: Kea DHCPv6 - add new option based on v4 #8571
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
AdSchellevis
added a commit
that referenced
this pull request
May 1, 2025
…add required interface to subnet. Although a bit unexpected, based on the documentation https://kea.readthedocs.io/en/stable/arm/dhcp6-srv.html#introduction, apparently clients won't receive an address when not strictly connected to the subnet. ref: https://lists.isc.org/pipermail/kea-users/2018-January/001581.html
AdSchellevis
added a commit
that referenced
this pull request
May 1, 2025
…add required interface to subnet. Although a bit unexpected, based on the documentation https://kea.readthedocs.io/en/stable/arm/dhcp6-srv.html#introduction, apparently clients won't receive an address when not strictly connected to the subnet. ref: https://lists.isc.org/pipermail/kea-users/2018-January/001581.html
AdSchellevis
added a commit
that referenced
this pull request
May 4, 2025
…de easily for v4 and v6 and add the v6 view (#8571)
AdSchellevis
added a commit
that referenced
this pull request
May 4, 2025
…idate control agent instead of separate services (#8571) As the kea rc script controls the agent and enabled services, we can't split them easily without refactoring the rc scripts as well. The second best option seems to be to pin service control to the agent as that part is always active when a service is used.
fichtner
pushed a commit
that referenced
this pull request
May 6, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.