Resumen

  • ISC documenta keama como una utilidad de conversión de configuración, con modalidades para DHCPv4 y DHCPv6. El alcance depende de las construcciones reconocidas y de la versión; el resultado necesita revisión.
  • Kea tiene modelos propios para el servicio DHCP, la alta disponibilidad, las actualizaciones DNS y las extensiones. Convertir parámetros no demuestra que esas piezas estén desplegadas ni que mantengan el comportamiento necesario.
  • La documentación permite identificar qué debe comprobar un operador, pero no medir la duración, el coste o la tasa de éxito de una migración concreta. El criterio de cierre debe ser un servicio validado y recuperable.

La diferencia entre describir un servicio y hacerse cargo de él

Una subred puede estar presente en un archivo nuevo y, aun así, quedar trabajo por hacer antes de que el servicio atienda correctamente a sus clientes. Esa separación es el punto de partida para evaluar el paso de ISC DHCP a Kea. La pregunta no es solamente si se ha expresado la configuración antigua en otro formato. Es si el sistema de destino reproduce los comportamientos que la organización necesita, conserva o trata adecuadamente su estado y puede recuperarse de un fallo.

El caso concierne a Internet Systems Consortium, Inc., vinculada a la entrada ISC-AGP1 del directorio, pero no justifica atribuirle el control de cada instalación que utiliza su software. Aquí se examina lo que ISC documenta sobre sus componentes y lo que esa documentación deja por demostrar en el entorno del operador. Son responsabilidades relacionadas, no intercambiables.

La distinción tiene consecuencias para la manera de presupuestar y aceptar una migración. Si el entregable contratado es una configuración convertida, el resultado puede ser útil sin constituir un servicio listo para producción. Si el entregable es continuidad operativa, la aceptación necesita abarcar clientes, estado, dependencias y recuperación. Confundir ambas cosas no amplía lo que automatiza keama: reduce la visibilidad del trabajo pendiente.

Esta es una lectura técnica de documentación, no el informe de una migración observada. No establece que Kea falle al sustituir a ISC DHCP ni que todos los operadores encuentren las mismas dificultades. Identifica los límites de una inferencia frecuente: de un archivo generado correctamente no se deduce, por sí solo, una red correctamente migrada.

Qué convierte keama y qué queda fuera de esa prueba

El manual de keama describe una utilidad de línea de comandos que convierte configuración de ISC DHCP en configuración JSON de Kea, con modalidades diferenciadas para DHCPv4 y DHCPv6. La unidad de trabajo es la configuración reconocida. La documentación también contempla construcciones que no se convierten y la necesidad de revisar y editar el resultado.

Eso permite una conclusión favorable, aunque acotada: la utilidad puede reducir la transcripción mecánica de las partes que sabe representar. No permite concluir que reproduzca cualquier configuración histórica, que cubra todos los comportamientos ejecutables ni que traslade el conjunto de una instalación en funcionamiento. El alcance concreto debe contrastarse con la versión de Kea elegida y con los elementos que realmente utiliza esa instalación.

Conviene distinguir tres preguntas. La primera es si existe una representación del parámetro en el destino. La segunda es si esa representación conserva la intención operativa. La tercera es si el servicio desplegado produce el resultado esperado con clientes y dependencias reales. Una respuesta afirmativa a la primera no contesta automáticamente a las otras dos.

La misma cautela se aplica a las omisiones. Encontrar una construcción sin conversión directa no significa necesariamente que Kea sea incapaz de satisfacer la necesidad que había detrás. Puede exigir otra configuración, una extensión o una decisión de rediseño. Tampoco sería correcto prometer que siempre existe una sustitución equivalente. Esa equivalencia se tiene que demostrar para la función y la versión concretas.

Por tanto, el documento de trabajo más valioso después de la conversión no es solo el archivo JSON. Es una relación entre cada comportamiento necesario, su representación propuesta y la evidencia que permitirá aceptarlo. Esa relación es una recomendación de evaluación, no una función adicional atribuida a keama. Hace visibles tanto las partes automatizadas como las excepciones que requieren criterio humano.

Las páginas examinadas pertenecen a la documentación pública consultada el 19 de septiembre de 2026. Sus enlaces a la edición «latest» no fijan una matriz permanente de compatibilidad. El análisis no enumera directivas universalmente admitidas o rechazadas porque las fuentes no sostienen una lista válida para cualquier versión y cualquier instalación.

IPv4 e IPv6: comprobar la intención, no solo la sintaxis

El manual del servidor DHCPv4 de Kea presenta un modelo propio de configuración JSON que abarca, entre otros elementos, interfaces, bases de datos de concesiones, registros, subredes, conjuntos de direcciones, reservas, opciones, clases de clientes y bibliotecas de extensión. La presencia de esas piezas en un documento no demuestra que estén relacionadas de la forma que necesita una red determinada.

Para valorar la equivalencia conviene empezar por resultados observables: qué cliente debe recibir qué tratamiento, dentro de qué subred y con qué opciones. Después se comprueba qué configuración produce ese resultado. Ese orden evita convertir el parecido entre archivos en criterio de aceptación. Dos configuraciones pueden diferir mucho en su forma y satisfacer el mismo requisito; un parecido superficial puede esconder una diferencia importante.

Piénsese en un caso de ensayo, no en un incidente documentado: una instalación necesita distinguir un grupo de clientes y entregarles opciones específicas. Ver la clase y las opciones en el archivo de destino no bastaría para dar esa función por concluida. La prueba tendría que mostrar que los clientes previstos reciben el tratamiento correcto y que otros clientes no lo reciben por error. El objeto evaluado sería la política efectiva, no el número de líneas trasladadas.

IPv6 requiere su propia comprobación. El manual DHCPv6 documenta subredes y conjuntos IPv6, prefijos delegados, opciones, reservas, almacenamiento de concesiones y aspectos de operación con relés. Un resultado satisfactorio en IPv4 no proporciona evidencia sobre esas funciones. Cuando la delegación de prefijos forma parte del servicio, debe aparecer como requisito y como resultado comprobable, no como una casilla implícita dentro de «DHCP funciona».

La separación no obliga a duplicar todos los trabajos. Obliga a reconocer dónde una prueba representa una función y dónde deja otra sin examinar. Una organización que no utiliza determinada capacidad no necesita inventar un escenario para justificarla. Una que sí depende de ella no debería esconderla dentro de una prueba genérica de arranque.

También hay que distinguir un cambio deliberado de una pérdida accidental. La migración puede ser una ocasión para retirar reglas antiguas, simplificar opciones o modificar reservas. Si se decide hacerlo, el comportamiento esperado ya no será una copia íntegra del sistema anterior. La aceptación debe registrar esa decisión: preservar lo necesario y cambiar lo aprobado son objetivos compatibles, siempre que no se confundan con una omisión inadvertida.

Las concesiones convierten el retorno en un problema de estado

La configuración de almacenamiento de concesiones figura en el modelo nativo de Kea, pero configurar dónde se guarda información no equivale a demostrar qué información existe allí ni cómo se tratará durante el cambio. El capítulo DHCPv4 permite situar esa responsabilidad dentro de la operación del servidor; no convierte la salida de keama en prueba de transferencia del estado vivo.

Este límite importa porque una migración no parte necesariamente de un servicio vacío. La evaluación debe especificar qué estado se necesita conservar, qué tratamiento se ha elegido y cómo se comprobará que el resultado es coherente con los requisitos del servicio. No se prescribe aquí una técnica universal de traslado de concesiones: las fuentes examinadas no permiten hacerlo para todas las topologías.

También cambia la pregunta sobre la vuelta atrás. Guardar el archivo de configuración anterior demuestra que se conserva una descripción, no que se haya resuelto la reconciliación del estado después de operar con el sistema nuevo. Como deducción operativa, cualquier plan de retorno debe explicar qué información habrá cambiado, quién determinará cuál es válida y qué comprobaciones permitirán reanudar el servicio sin asumir una continuidad no demostrada.

Esto no significa que el retorno sea imposible. Significa que su viabilidad debe diseñarse y ensayarse, en lugar de deducirse de la existencia de una copia del archivo antiguo. Un plan que solo dice «volver a la versión anterior» deja sin contestar precisamente la parte que puede haber evolucionado desde el cambio: el estado del servicio y sus dependencias.

La observación también debe seguir a los comportamientos. Que el proceso permanezca activo es una señal distinta de que las asignaciones, renovaciones y reservas necesarias se comporten como se esperaba. Una propuesta de aceptación razonable separaría ambas clases de evidencia. La primera ayuda a saber si el software está en ejecución; la segunda informa sobre la prestación que se quiere conservar.

No hay en las fuentes una duración de ensayo aplicable a todas las redes. Elegirla exige conocer qué comportamientos tienen que ocurrir para considerar la prueba representativa. La consecuencia para el proyecto es concreta: una ventana de observación debería justificarse por los eventos que permite comprobar, no simplemente por la comodidad del calendario.

Alta disponibilidad: otra coordinación, no un nombre nuevo

La diferencia arquitectónica resulta especialmente visible en la alta disponibilidad. El manual de HA de Kea describe una biblioteca específica y su propia configuración. No se trata de reutilizar directamente las declaraciones de pares de failover de ISC DHCP. La comunicación entre compañeros, los roles o modalidades y la sincronización pertenecen a un diseño que hay que configurar y validar.

Así, convertir correctamente las subredes y los conjuntos de direcciones no demuestra que exista un servicio Kea de alta disponibilidad operativo. La evidencia sobre la capacidad de asignar una dirección no es la misma que la evidencia sobre la coordinación entre servidores. Ambas pueden ser necesarias, pero responden a preguntas diferentes.

Para una instalación que dependa de HA, la evaluación debería incluir el funcionamiento normal y los cambios de condición que el operador considere relevantes. Entre los escenarios que conviene definir están la pérdida de un compañero, los problemas de comunicación y su reincorporación. Se proponen como categorías de prueba controlada; no se afirma que todas las versiones reaccionen de la misma manera ni se anticipa un resultado que no se haya medido.

El retorno del componente merece atención propia. Observar que el servicio continúa durante una ausencia no prueba por sí solo cómo se restablecerá la coordinación cuando el componente vuelva. El diseño de aceptación necesita incluir ese recorrido completo, con un resultado esperado y una forma de detectar discrepancias.

No toda migración necesita la misma arquitectura de disponibilidad. Adoptar dos servidores solo para reproducir la apariencia del esquema anterior sería una decisión distinta de justificar sus funciones y dependencias. La documentación de ISC ofrece el modelo de Kea; corresponde al operador explicar por qué el diseño elegido responde a su necesidad y aportar evidencia de que funciona en su entorno.

D2 abre una segunda cadena que debe llegar hasta DNS

El límite de la conversión también aparece cuando la asignación DHCP tiene consecuencias en DNS. ISC documenta DHCP-DDNS mediante el servicio separado D2, con configuración y punto de comunicación propios. La política de actualización, las credenciales, las zonas y la conectividad necesitan atención específica; una configuración DHCP convertida no acredita por sí sola una cadena de actualización DNS funcional.

La condición es importante: este trabajo corresponde a las instalaciones que utilizan esa integración. No debe presentarse D2 como obligación universal de cualquier despliegue de Kea. Pero donde la integración sí existe, probar únicamente la asignación DHCP deja parte del servicio fuera de la aceptación.

La comprobación debe alcanzar el resultado que interesa a la organización: que los eventos previstos produzcan las actualizaciones directas e inversas necesarias. Que un componente esté configurado para solicitar una actualización no constituye evidencia suficiente de que el resultado final sea correcto. El criterio debería seguir la cadena hasta el destino, no detenerse en el primer paso que parece funcionar.

De esta arquitectura se deriva una cuestión de responsabilidad. Si personas o equipos diferentes administran DHCP y DNS, el proyecto debe acordar quién puede modificar cada parte y quién valida el resultado conjunto. Es una recomendación de gestión basada en la separación de componentes, no una afirmación sobre cómo se organiza un operador particular.

Un fallo de esa cadena tampoco debería diagnosticarse automáticamente como fallo de keama. Para atribuirlo haría falta conocer dónde se produce la discrepancia: en la configuración generada, en una decisión manual, en D2, en los permisos o en otra dependencia. La documentación permite formular esas preguntas. Sin observaciones de una instalación concreta, no permite escoger una causa.

Las extensiones obligan a inventariar comportamientos

El manual de bibliotecas de extensión de Kea describe los hooks como mecanismo para incorporar funcionalidades adicionales. Los manejadores de eventos, scripts u otros comportamientos ejecutables de ISC DHCP que no tengan correspondencia directa en keama pueden necesitar una implementación manual mediante una extensión adecuada o una integración externa, seguida de configuración y pruebas.

Hay dos exageraciones que conviene evitar. La primera sería suponer que todo comportamiento personalizado se traslada porque el resto del archivo se ha convertido. La segunda, afirmar que cualquier personalización de ISC DHCP debe reescribirse desde cero. El punto documentado es más preciso: hay que verificar la correspondencia concreta y no presumirla cuando no está establecida.

Por eso el inventario debería describir qué hace una personalización y por qué sigue siendo necesaria. El nombre de un script o su ubicación no bastan para evaluar una alternativa. Importan el evento que lo activa, el efecto esperado, la dependencia que necesita y la evidencia de que ese efecto se ha producido. Es una propuesta de análisis funcional, no una promesa de equivalencia entre mecanismos.

La migración también permite preguntar si una función debe conservarse. Una dependencia antigua puede responder a un requisito vigente o a uno que ya no existe. Suprimirla sin revisar ese vínculo podría perder una capacidad necesaria; reconstruirla sin cuestionarla podría perpetuar complejidad evitable. La decisión requiere una persona responsable del requisito, además de otra capaz de implementar la solución.

Finalmente, cargar una biblioteca y aceptar sus parámetros no prueba su comportamiento operativo. La validación debe observar la función que motivó su inclusión y las condiciones relevantes para ella. Las fuentes no ofrecen una estimación universal del esfuerzo de este trabajo. Por tanto, tampoco permiten calcular un ahorro total de migración a partir de cuántas líneas se hayan convertido automáticamente.

Qué conclusión permiten realmente los manuales

Leídos conjuntamente, los capítulos de ISC separan varias capas: conversión de configuración, modelo nativo del servidor, estado, coordinación, servicios auxiliares y extensiones. Esa separación explica por qué puede reducirse el esfuerzo mecánico sin que desaparezca la responsabilidad del despliegue. La utilidad de keama y la necesidad de validación no son argumentos opuestos.

La consecuencia práctica es sustituir un hito demasiado amplio —«conversión terminada»— por evidencias adecuadas a cada función. El archivo generado acredita una salida de conversión; una prueba funcional acredita un comportamiento bajo determinadas condiciones; un ensayo de recuperación aporta evidencia sobre un escenario de fallo. Ninguno debería presentarse como prueba ilimitada de los demás.

El alcance documentado de keama tampoco establece resultados comerciales u operativos de una instalación. Estas fuentes no miden indisponibilidad, costes laborales, plazos ni éxito de clientes. Son documentación primaria del software, no una comparación independiente de migraciones. Para responder a esas cuestiones harían falta versiones fijadas, configuraciones, registros de prueba y observaciones del entorno considerado.

La conclusión es, por tanto, limitada pero útil: pasar de ISC DHCP a Kea exige decidir qué debe seguir funcionando y demostrarlo en el sistema de destino. ISC proporciona modelos y documentación; el control sobre la puesta en servicio depende de quién configura, observa, autoriza y puede recuperar cada pieza. El proyecto termina cuando esa responsabilidad está respaldada por resultados, no cuando un archivo cambia de sintaxis.