Summary

  • The keama documentation describes configuration conversion, with release-sensitive limits and a need to review and manually edit unsupported or unconverted constructs. Generated JSON is not proof of equivalent service behavior.
  • Kea’s native server configuration, lease storage, high-availability arrangement, separate DHCP-DDNS service and extensions create distinct validation responsibilities where those features are used. The documentation identifies these boundaries; it does not establish a universal migration cost, outage rate or recovery time.

A generated configuration answers a narrower question than a successful DHCP migration. It can show how recognized settings from one implementation are expressed in another. It cannot, by itself, show that clients receive the intended service, that live lease information remains coherent, or that a replacement deployment will behave correctly when a dependency fails. The distinction starts with the scope of ISC’s keama documentation: a command-line utility for converting ISC DHCP configuration into Kea JSON, with separate DHCPv4 and DHCPv6 conversion modes.

That is useful automation. It is also bounded automation. Treating the output as a completed migration collapses several different questions into the existence of one file: configuration meaning, operational state, coordination between servers, communication with other services and the behavior of local extensions. Each question needs evidence appropriate to what it claims to establish.

This report examines the DHCP software documentation associated with Internet Systems Consortium. It is a documentation-based analysis, not a report of a named operator’s migration or an independent performance test. Its central finding is consequently narrow: the documented conversion boundary is not the same as the deployment boundary. The remaining work depends on the installed release and the services an operator actually uses.

What keama carries across—and what its output cannot certify

The keama manual describes conversion of recognized configuration constructs, not reproduction of an entire running deployment. It identifies unsupported or unconverted constructs that require review and manual editing. The exact support boundary is release-sensitive. A statement that one setting converts in a particular release cannot safely become a statement that all settings, or all releases, behave the same way.

There are two mistakes to avoid here. The first is to assume that every source setting has a direct equivalent and that generated output therefore preserves every relevant behavior. The second is to read the existence of conversion limits as evidence that the utility provides no value. Neither conclusion follows. Automating a recognized mapping can remove mechanical work while leaving difficult exceptions and deployment decisions untouched.

The useful unit of assessment is therefore a required behavior, not merely a line of configuration. An operator can ask whether a setting was recognized, how it was represented, whether manual intervention was needed and what observation would establish that its intended effect survives. A list of converted settings answers only the first part of that sequence. It does not establish the last.

Consider a hypothetical conversion in which the familiar subnet and pool definitions are visible in the output. That is evidence worth retaining. It still does not settle whether the intended clients reach the right service, receive the expected options or follow the expected reservation policy. Those are questions about the deployed behavior, not the appearance of familiar names in JSON. This is an analytical distinction, not a claim that keama has failed in such a case.

The same discipline applies to exceptions. An unconverted construct deserves an explanation tied to the target release and the local requirement. It might require a different implementation, a deliberate change in behavior or a decision that the old behavior is no longer needed. The presence of an exception does not tell the operator which choice is correct. Nor does removing a warning establish that the original requirement has been met.

A credible conversion record would thus preserve what changed and why. The purpose is not to demand identical implementation details from different systems. It is to keep a change in service behavior from being mistaken for a change in syntax.

Configuration describes intent; leases and services require separate attention

Kea has its own configuration structure. The DHCPv4 server manual covers global settings, interfaces, lease databases, logging, subnets, pools, reservations, options, client classes and hooks. That breadth matters because a converted network definition sits inside a larger service arrangement. An operator still needs to establish which interfaces the service uses, where lease information is stored, how the service starts and what its logs and monitoring reveal.

Configuration and lease information answer different questions. Configuration describes intended allocation rules and operating choices. Lease information concerns allocations made under those rules. The fact that a pool exists in a converted file does not establish how the replacement deployment will account for existing leases. The relevant migration question is not just whether the address range has been carried across, but what evidence supports the treatment of the service’s existing state.

That observation does not prescribe one universal lease-transfer procedure. The documentation used here does not establish that every network can or should follow the same method. It supports a more limited requirement: configuration conversion alone must not be treated as proof that lease data and service state have been transferred appropriately. A locally chosen method needs its own validation.

There is a similar distinction between starting a process and proving service readiness. A successful startup would be useful evidence about that startup. It would not, on its own, establish correct allocation, reservation behavior, logging coverage or recovery. Tests should be matched to those separate claims rather than allowing one successful event to stand in for all of them.

IPv6 adds a further reason to avoid a single undifferentiated migration verdict. The DHCPv6 server manual describes Kea’s configuration for IPv6 subnets, pools, delegated prefixes, options, reservations, lease storage and relay-related operation. Where these functions matter, their behavior needs to be checked in its own right. A successful IPv4 exercise does not demonstrate IPv6 address allocation or prefix delegation.

This is especially important when deciding what counts as representative evidence. A test that covers only a straightforward allocation case says little about an untested reservation or delegated-prefix requirement. The remedy is not necessarily a larger configuration file or more testing indiscriminately. It is a clear account of which behaviors are required, which have been observed and which remain assumptions.

For technical leaders, the practical consequence is a change in the migration question. Instead of asking whether the configuration has been converted, ask which parts of the service have evidence of continuity. The first question remains useful, but it is no longer allowed to answer for the rest.

High availability is a new coordination arrangement, not a copied declaration

Kea’s high-availability documentation describes a dedicated High Availability hook and its own configuration. ISC DHCP failover-peer declarations are not simply reused as an operational Kea HA arrangement. Partner communication, roles or modes, synchronization and failure testing remain separate migration work.

This is a concrete architectural boundary. Carrying subnet and pool definitions into a replacement configuration does not establish how multiple servers will coordinate. Even if ordinary service behavior has been demonstrated, coordination under changed conditions is another claim. It needs evidence about the arrangement being deployed, not confidence inherited from the old one.

For an operator that requires HA, an isolated rehearsal could ask what happens when the expected partner communication is unavailable, whether the intended service behavior is observed and how the participating systems return to their intended relationship. These are proposed validation questions, not reported test results. The appropriate cases depend on the chosen mode, topology and release.

Recovery deserves particular attention because it is easy to stop a test at the first sign that a surviving component is serving clients. That observation would establish something important, but not everything. The return of a component and the restoration of coordination also need to be understood. A resilience claim is broader than a claim that a process stayed running during one exercise.

Not every Kea deployment needs the same HA design, and this report does not argue that all deployments must use HA. The point is conditional: when continuity depends on a coordinated arrangement, conversion of ordinary configuration is not evidence that this arrangement has been reconstructed. Its design and acceptance need to remain visible as separate work.

That separation also makes responsibility clearer. ISC documents a software mechanism. The deploying operator chooses an arrangement and must establish what that arrangement does in its own environment. Documentation can explain the mechanism without certifying the result of a local deployment.

DNS updates introduce another service boundary

The Kea DHCP-DDNS documentation describes D2 as a separate service with its own configuration and communication endpoint. DNS update policy, credentials, zones and connectivity therefore need attention beyond conversion of DHCP settings. The intended forward and reverse updates also need to be verified.

This creates a straightforward distinction between address service and name-update behavior. Evidence that a client receives an address does not establish that the associated DNS updates occurred as intended. Where those updates are part of the required service, treating allocation success as the sole acceptance result leaves a material question unanswered.

A hypothetical test illustrates the issue without implying an observed incident. Suppose a replacement DHCP service produces the expected allocation result. If the migration assessment records only that result, it has not yet demonstrated the DNS behavior expected from the deployment. It would need to follow the relevant lease event through to the intended update and examine the resulting forward and reverse records. The point is the scope of the observation, not an allegation that D2 is unreliable.

The separate service also makes ownership an operational question. A project should identify who can configure the DHCP-to-D2 relationship, who controls the relevant DNS update permissions and who can inspect failures across that boundary. Those may be different responsibilities in a particular organization; the documentation alone cannot establish how any named operator has assigned them.

It would be equally misleading to claim that every migration requires a complex DNS redesign. Some deployments may not use this function at all. The defensible statement is narrower: where dynamic DNS updates are required, their configuration and validation cannot be inferred merely from the presence of converted DHCP output.

The lesson extends beyond a checklist entry labelled “DNS.” The evidence should address the actual required outcome. A service being installed, an endpoint being configured and the expected name updates being observed are related but distinct milestones.

Local extensions can contain requirements that a file comparison misses

Kea’s hook-library documentation describes an extension mechanism for functionality beyond the base server configuration. ISC DHCP event handlers, custom scripts or other executable behavior without a direct keama mapping may need manual reimplementation through an appropriate hook or external integration, followed by configuration and operational testing.

The qualification matters: this is not a blanket statement that every script or customization has the same migration path. The specific behavior, available mapping and installed release must be examined. It would exceed the evidence to invent a universal list of unsupported directives or promise that a particular extension design covers every case.

The operational risk is nevertheless understandable. A locally important action can be absent from a comparison focused only on address pools and reservations. If a migration team does not identify the requirement that an extension serves, it cannot decide whether a new implementation is equivalent, deliberately different or incomplete.

The right question is therefore what the local behavior achieves. Merely finding a similarly named extension would not prove equivalence. Enabling a library and supplying parameters would not establish that its interaction with the rest of the service meets the requirement. Those are implementation steps whose outcome still needs observation.

This is also where a migration can become a redesign rather than a mechanical conversion. That is not necessarily a defect. An operator may choose a different arrangement, provided the change is explicit and accepted by those responsible for the affected service. The problem is not difference itself; it is an unexamined difference hidden inside a claim of completed conversion.

A migration needs several kinds of evidence

The documented boundaries suggest a useful way to read a migration report. Each piece of evidence should support a specific claim, with untested claims left visible. The following is an assessment framework derived from those boundaries, not a report of tests conducted by ISC or BTW.

Evidence available What it can help establish What it does not establish by itself
Converted output and reviewed exceptions How recognized source configuration was represented and where manual decisions were made Equivalent service behavior or transfer of live state
Observed DHCPv4 and DHCPv6 behavior Whether the exercised allocation, reservation, option and delegation cases meet expectations Correct behavior in cases that were not exercised
Validated treatment of lease information How the chosen migration approach accounts for relevant lease state Recovery under every later change or failure
HA coordination and recovery observations, where applicable Behavior of the tested partner arrangement under the tested conditions Resilience across every topology or failure condition
Observed D2 outcomes, where applicable Whether the relevant events produced the expected DNS updates Correct operation of unrelated extensions or DHCP cases
Validated local extension behavior Whether the implemented customization meets the tested requirement Equivalence of other local customizations

The framework resists a common category error: letting evidence at one layer certify another. A syntactically acceptable file is not an allocation test. An allocation test is not an HA recovery exercise. A successful DNS update is not evidence that an unrelated extension has been preserved. None of those observations is worthless; each is simply narrower than a complete service claim.

The distinction also helps an operator avoid unnecessary work. A feature that is not used does not need to be presented as an unresolved migration failure. What matters is whether its absence is an informed scope decision. A feature that is used but untested is different from one that is deliberately out of scope.

What the public documentation leaves unresolved

The conversion documentation makes release-sensitive support a material qualification. The cited manuals use a moving “latest” documentation path. Operators should check their chosen release rather than treating a general description here as a fixed support matrix. This report does not resolve individual directive mappings for every release.

Nor do these sources establish the success rate, elapsed time or staffing requirement of real-world migrations. They contain no basis here for a universal outage forecast, a percentage saving in engineering work or a claim that Kea will outperform a particular existing deployment. Those conclusions would require execution evidence beyond documentation of the software’s configuration boundaries.

A stronger assessment of a named migration would include its starting requirements, chosen release and topology, handling of configuration exceptions, treatment of lease information and observed results. Where relevant, it would also include HA recovery, DNS updates and extensions. Without that material, it is possible to describe what needs to be established, but not to certify that it has been established.

The bounded conclusion is still useful. Keama can address mechanical configuration conversion without becoming a guarantee of operational continuity. Its limits do not negate its purpose. They locate the point at which the operator must supply deployment-specific decisions and evidence.

For ISC, that distinction separates a documented software capability from claims about services run by others. For operators, it changes the definition of completion. A migration is not demonstrated by the existence of a replacement file; it is demonstrated by evidence that the required service works, and that the chosen recovery arrangements do what the operator expects under the conditions examined.