Resumen

  • RFC 9928 hace que un 4o6RA encapsule y desencapsule DHCPv4 en DHCPv6 por un cliente IPv4 heredado que no puede implementar RFC 7341.
  • Al asumir ese papel, el relevo cambia el punto de observación y puede esconder la interfaz de capa 2; transportar una respuesta no acredita la política topológica correcta ni el resultado del cliente.

El informe de cambio mostraba una secuencia sin errores de formato. Había una petición DHCPv4, un DHCPV4-QUERY, una respuesta y un reenvío al extremo. No había, sin embargo, una prueba que vinculara la transacción con el puerto de acceso. El servidor había contestado; nadie podía demostrar que había decidido con la topología que el diseño suponía.

Ese vacío no invalida el protocolo. Delimita lo que puede afirmarse. El relevo puede probar qué recibió, qué encapsuló y qué devolvió. El servidor puede probar la configuración que eligió a partir de sus entradas. Ninguno de esos hechos sustituye la procedencia de la interfaz, la aceptación del cliente, la ausencia de un camino DHCP alternativo o una comprobación posterior de conectividad.

RFC 7341 definió DHCPv4-over-DHCPv6 para obtener configuración IPv4 a través de una red IPv6. Su cliente participa en DHCP 4o6. RFC 9928 atiende otro caso: equipos IPv4 antiguos, integrados y difíciles de actualizar. En lugar de exigirles una nueva pila, coloca la encapsulación en un nodo intermedio, el 4o6RA.

El extremo sigue creyendo que usa DHCPv4 ordinario. El 4o6RA, en cambio, representa al cliente dentro de RFC 7341. Elige una interfaz DHCPv6, localiza el servicio, obtiene configuración IPv6, solicita la opción con la dirección del servidor 4o6 y forma la consulta encapsulada. Cuando vuelve la respuesta, comprueba que contenga la opción DHCPv4, descarta los mensajes mal formados y extrae el contenido correcto si realmente puede reenviarlo.

La elección de diseño mantiene pequeños los compromisos comunes. No aparecen formatos nuevos ni requisitos adicionales para un servidor 4o6 ya compatible. Es posible probar cada condición del transporte. Pero una gramática compartida no decide qué dirección corresponde a qué lugar de la red.

La asignación DHCP puede utilizar topología. RFC 7969 muestra que DHCPv4 y DHCPv6 expresan la ruta de forma distinta. En IPv4, normalmente sólo el primer relevo escribe giaddr, por lo que una cadena revela una parte. En DHCPv6, cada relevo puede aportar link-address e Interface-ID y formar una descripción más completa del recorrido.

Si el propio cliente realiza 4o6, el relevo DHCPv6 conoce la interfaz por la que llegó el mensaje. Si el trabajo se desplaza a un 4o6RA situado en el borde, éste se convierte en el cliente visible y el segmento de capa 2 queda detrás. RFC 9928 advierte que una solución sólo con 4o6RA rompe la propagación de topología: el mensaje encapsulado no lleva información de la interfaz oculta.

La recomendación es combinarlo con un LDRA de RFC 6221, colocado inmediatamente junto al 4o6RA, para añadir Interface-ID. Aun así, el mecanismo interno que transmite la información de interfaz, su formato y la señal de que intervino 4o6RA quedan fuera del estándar. La red local debe diseñar, registrar y verificar ese empalme.

Aquí encaja la regla de especificación inicial mínima de Heng Lu. La capa común debe cubrir lo indispensable para interoperar y ser verificable por quienes ejecutan el código. No debe apropiarse de las decisiones ni de la evidencia que pertenecen a otra capa. La libertad local no es una excusa para la opacidad: exige un responsable local y una prueba reproducible.

También debe existir un solo recorrido autorizado para los mensajes DHCPv4 del cliente. RFC 9928 exige dirigir tanto difusión como unicast por el 4o6RA y menciona una posición central o NAT para conseguirlo. Si un servidor DHCPv4 convencional permanece directamente accesible en la misma capa 2, el cliente puede saltarse el mecanismo. El RFC reconoce que ello crea estados erróneos y configuraciones capaces de afectar la accesibilidad. Lo llama error de despliegue, no una nueva cuestión de seguridad; el efecto operativo sigue siendo real.

Por eso un expediente serio separa al menos diez piezas: identidad de transacción; interfaz, VLAN o clase de acceso; selección de interfaz del 4o6RA; descubrimiento del servicio; huellas de consulta y respuesta; secuencia de relés y valores link-address/Interface-ID; entradas de política del servidor; decisión de asignación; validación y reenvío al cliente; estado que éste instaló; prueba de conflicto; y observación independiente de ruta o servicio. Una marca temporal y un propietario acompañan a cada pieza.

La separación evita una confusión habitual de responsabilidad. El equipo de acceso conoce dónde apareció el extremo. El propietario del relevo conoce la transformación. El servicio DHCP conoce la regla. El responsable del dispositivo conoce el estado aceptado. Operaciones conoce el efecto observado. La palabra “éxito” no debería ocultar cuál de esas cinco afirmaciones está disponible.

La primacía del código en ejecución no concede infalibilidad al intermediario. Le concede autoridad sobre su resultado local y nada más. Describir la evidencia con precisión no debilita la automatización; hace posible reparar la capa correcta y conservar una salida cuando el mecanismo invisible deja de funcionar.

Fuentes