Resumen

  • RFC 9928 permite que un 4o6RA encapsule DHCPv4 en DHCPv6 por un cliente IPv4 heredado que desconoce el mecanismo.
  • Cuando esa función se instala en un nodo intermedio, el servidor DHCPv6 puede perder la vista del segmento de capa 2. La combinación 4o6RA–LDRA vuelve a insertar un Interface-ID, pero la transferencia interna entre ambas funciones queda fuera del alcance del RFC.
  • Una concesión válida demuestra una asignación y una entrega; no demuestra por sí sola el puerto observado, el significado local del valor opaco, la regla de pool aplicada ni la ausencia de un servidor DHCPv4 directo.
  • La prueba útil debe conservar la cadena desde la recepción física hasta la expiración o corrección, sin fingir que el cliente legado autorizó una topología que no conoce.

Dos luces verdes, una diferencia invisible

Imaginemos un switch de fronthaul con varias unidades de radio IPv4. El servidor devuelve una dirección a una unidad conectada al puerto previsto. Tras una mudanza de cableado, otra solicitud también termina con DHCPACK y conectividad básica. En ambos casos el panel de concesiones muestra éxito. Sin embargo, el segundo resultado puede haber pasado por una política genérica porque la ubicación física no llegó al servidor.

RFC 7341 definió el transporte DHCPv4 sobre DHCPv6 para clientes capaces de formar el mensaje DHCPv6. La limitación aparece precisamente con equipos que no se pueden actualizar. RFC 9928 desplaza la tarea a un agente relay.

El 4o6RA recibe el mensaje DHCPv4, construye DHCPV4-QUERY, lo encapsula y lo lleva hacia un servidor compatible. En el regreso valida la forma de DHCPV4-RESPONSE, extrae el mensaje DHCPv4 y lo entrega al solicitante. El cliente sigue viendo el protocolo de siempre y no sabe que el 4o6RA actuó como cliente DHCP 4o6 en su nombre.

La ignorancia es intencional y útil: evita sustituir miles de dispositivos. También pone un límite probatorio. La máquina puede confirmar que obtuvo parámetros; no puede confirmar qué interfaz ascendente eligió el relay, qué envolturas DHCPv6 existieron o qué dato de topología acompañó a su solicitud.

La asignación puede depender de dónde entró la solicitud

RFC 7969 explica que los servidores DHCP pueden elegir direcciones y parámetros basándose en información aportada por la infraestructura de relay. Un mismo tipo de dispositivo puede necesitar pools o configuraciones distintas según su punto de conexión.

En DHCPv4, giaddr describe normalmente el primer salto de relay. DHCPv6 puede transportar una secuencia más rica mediante mensajes Relay-forward anidados, link-address e Interface-ID. El orden de las envolturas importa: muestra cómo se fue formando el contexto que ve el servidor.

RFC 9928 identifica el problema específico del traslado. Si DHCP 4o6 se ejecuta en un nodo intermedio, el borde IPv6 puede quedar después del acceso de capa 2. Una solución que use solo 4o6RA no aporta información de interfaz al mensaje encapsulado y rompe la propagación de topología. El servidor puede seguir respondiendo de forma correcta a la entrada que recibió, pero esa entrada ya no contiene todo lo que la política suponía.

Por eso no basta con preguntar si el lease existe. Hay que preguntar qué regla lo produjo. Un pool por defecto puede mantener el servicio y a la vez borrar la distinción entre dos puertos que tienen obligaciones diferentes.

El LDRA conserva una relación local

El RFC recomienda situar un Lightweight DHCPv6 Relay Agent junto al 4o6RA. El LDRA obtiene información de la interfaz y agrega Interface-ID a la consulta. RFC 6221 exige esa opción en los Relay-forward creados por el LDRA y pide que el valor sea estable para la interfaz.

La estabilidad permite políticas por coincidencia exacta. No convierte el valor en una etiqueta universal. El servidor debe tratar el contenido como opaco. No puede deducir que ciertos bytes significan un chasis, una ranura o un abonado salvo que el despliegue mantenga una tabla externa y controlada.

RFC 9915 completa el trayecto: el servidor copia la opción en Relay-reply y el relay la usa para seleccionar la interfaz de salida. La misma pieza participa así en la política de ida y en la entrega de vuelta, pero su verdad física depende de una correspondencia local que el wire format no explica.

El registro verificable debe unir ambas vistas. Del lado del acceso, puerto, instante y versión de mapeo. Del lado del protocolo, valor opaco y posición en el anidamiento. Del lado del servidor, regla exacta, pool y parámetros. Ninguna vista sustituye a las otras.

Un estándar abierto en la costura correcta

RFC 9928 no fija cómo entrega el 4o6RA la información de interfaz al LDRA, ni el formato interno, ni si el dato señala que intervino un 4o6RA. Esa libertad facilita arquitecturas integradas y distribuidas. También impide suponer que una implementación conforme conserva automáticamente la procedencia de esa transferencia.

La reparación no consiste en inventar un campo de red. Consiste en nombrar la frontera local: componente que observó, componente que transformó, versión de software o hardware, generación del mapeo y respuesta ante ausencia o caducidad.

Tampoco todos los diseños necesitan dos funciones separadas. Si el 4o6RA y el servidor DHCP 4o6 residen en el mismo nodo, RFC 9928 contempla que el primero sea suficiente. La pregunta de control es si la política recibe el dato que necesita y si el operador puede probar su procedencia.

El camino directo compite con el previsto

Como el cliente no sabe que existe 4o6, la red debe encaminar por el 4o6RA tanto broadcast como unicast DHCPv4. Un servidor DHCPv4 alcanzable en la misma capa 2 puede responder sin pasar por el mecanismo. RFC 9928 describe el caso como error de despliegue capaz de crear estados erróneos o afectar la alcanzabilidad.

Para un sistema de observación, ese camino no debe desaparecer bajo el total de concesiones. El flujo directo y el flujo 4o6 pueden producir estados plausibles, con servidores y temporizadores distintos. Una comprobación de bypass debe formar parte del recibo: interceptación del broadcast, tratamiento del unicast de renovación y ausencia —o bloqueo demostrado— del servidor alternativo.

Diez hechos, no un veredicto compuesto

El recibo de custodia propuesto es una recomendación editorial, no una opción DHCP.

Debe conservar la solicitud observada y su transacción; el nodo, puerto y generación de mapeo; el 4o6RA y la encapsulación; la transferencia interna al LDRA; el Interface-ID opaco y su capa de anidamiento; los siguientes link-address e Interface-ID; el servidor y la regla de pool; la respuesta, desencapsulación y puerto de entrega; la prueba de bypass; y el cierre por renovación, cambio de puerto, corrección, expiración o rollback.

La utilidad está en evitar herencias falsas. Un DHCPACK no hereda la certeza del puerto. Un Interface-ID no hereda significado semántico. Una respuesta devuelta por el relay no hereda la justificación de la regla. La cadena permite revisar cada transición con el equipo que la controla.

IETF mantiene la interoperabilidad del mecanismo. El operador de acceso controla la observación física; el propietario del relay controla el steering y la conversión; el servicio DHCP controla la asignación. El equipo heredado recibe el resultado, pero no debe figurar como principal informado de decisiones invisibles para él.

Fuentes