Hello Franco
Sorry to direct this to you, I know you're busy.
- Could you please tell me what the plan is for DHCP ISC?
- I know it will be retired and become a plugin, but when will this happen?
- Will we need to change any configurations to keep it running or will it continue as already implmented?
I know I should be moving off it, but after spending too many days implementing, configuring and troubleshooting it due to encountering problems with DHCPv6, I've given up.
Unless there are serious security risks, I'm going to keep using ISC, but I would like to know the plan moving forward with it.
thanks
Hey :)
> Could you please tell me what the plan is for DHCP ISC?
Sure.
> I know it will be retired and become a plugin, but when will this happen?
26.1 will make ISC DHCP a plugin. As customary, if ISC DHCP is enabled the plugin will be auto-installed on the major upgrade so that the upgrade is seamless.
I don't know when the plugin will be sunset -- definitely not in 2026. Availability in FreeBSD ports is subject to fluid policies over there so I cannot make an predictions.
Plugins usually continue past their removal point as long as they are installed, but code may slowly break as it depends on functions that are going to be removed or rewritten in core beyond that point.
The software package itself will continue to work as long as FreeBSD doesn't introduce breaking changes in later releases, too.
TLDR; safe to assume 26.x will have the ISC DHCP plugin. Beyond that point is very difficult to assess today.
> Will we need to change any configurations to keep it running or will it continue as already implmented?
No.
Hope that helps.
Cheers,
Franco
How realistic is it that Kea can fully replace ISC by the time it becomes a plugin?
Personally, I've successfully migrated to Kea for DHCPv4, but am stuck with ISC for DHCPv6. Mostly because of dynamic prefixes and downstream prefix delegation.
Cheers
Maurice
I abandoned dynamic prefix delegation (in my personal multi router ipv6 home setup/test env) and just chain my ndp proxy now xD. Its just so convenient xD
> How realistic is it that Kea can fully replace ISC by the time it becomes a plugin?
Good question. Honest answer:
Quite unrealistic due to a number of other priorities for 26.1. We're trying to adequately replace stock ISC DHCPv6 with Dnsmasq DHCPv6, but that will undo the ability to do PD delegation in new/wizard setups since that feature is not supported by Dnsmasq.
26.7 is more realistic, but that's easy to say now. Simply trying not to change all of the world at once and we can still rely on DHCP ISC for the time being. Extra help could change that, but it also needs a good plan and coordination to pull this off properly.
Cheers,
Franco
Thanks for the reply and info Franco
I'd consider Dnsmasq more as a minimal all-in-one service for home routers. It's nice for basic networks, but can't (and doesn't want to) replace Unbound / Kea / radvd.
PD is becoming more and more important. RFC 9663 is an interesting read in this context.
The new NDP proxy is a life saver if you're stuck with Internet access without a properly delegated, decently sized prefix. But I wouldn't consider it as a replacement for PD.
I'll prepare to use the ISC plugin then. And maybe I'll be able to help with Kea, we'll see.
Cheers
Maurice
@OzziGoblin
gladly :)
@Maurice
I completely agree. The wizard will change scope a bit in 26.1 adding the concept of "use cases" which could eventually make Dnsmasq or Kea selectable in another major iteration. For now Dnsmasq in the wizard is tailored for the bulk users with simple setups.
You know where to find me. ;)
Cheers,
Franco
If PD is so important, and also its dynamic variant, I would expect KEA to support that natively (eg via a Constructor or Base6Interface to quote dnsmasq and radvd)
I don't want to script around KEA to force it to do that.
Also its pretty fragile even with static prefix...
It pretty much /desires/ to crash at any possible moment xD
https://github.com/opnsense/core/issues/9343
The NDP Proxy is no replacement for PD at all, but at least it handles the full dynamic nature of less optimal ISP setup gracefully. I'm not even sure why ISPs do not give static prefixes, This is all rooted under multiple layers of issues we now must messily script around? Kinda sad.
TLDR: It should be KEAs battle to support dynamic prefix delegation natively.
Quote from: Monviech (Cedrik) on Today at 06:25:44 AMI'm not even sure why ISPs do not give static prefixes
Money. Most ISPs will give you a static prefix - for extra €£$. They're happy to sell you the same service (+ static addresses) for twice the price and call it a "business product".
Quote from: Monviech (Cedrik) on Today at 06:25:44 AMIt should be KEAs battle to support dynamic prefix delegation natively.
That would be ideal. But if this hasn't happened by the time we sunset ISC, there's not really a choice but script around it.
The issue with scripting around it is that its fragile and the people who need it are not businesses who have static prefixes in the first place.
Users with residential ISPs do not seem to be in the scope of ISC (the organization) in general it seems.
It's almost like the client end of dynamic prefixes are not a business driver for Kea. ;)
Cheers,
Franco