Resumen

  • El borrador activo del grupo INTAREA, obra de Remco van Mook, propone 192.0.0.11/32 como puerta centinela: un host compatible no pregunta por ARP, sino que emplea el MAC del router IPv6 elegido.
  • El paquete no se traduce ni se encapsula. Sigue siendo IPv4, pero su retorno depende de una ruta de host /32 con un siguiente salto IPv6 enrutable.
  • La aparente eliminación de estado es, en realidad, una reutilización. DHCP, RA, NUD, reenvío IPv4, ruta inversa y compatibilidad para equipos antiguos conservan estados y fallos propios.

El vecino prestado

La intuición habitual dice que una puerta de enlace IPv4 es un equipo con una dirección IPv4 localizable mediante ARP. El borrador cambia esa relación. La dirección centinela no identifica a un equipo. Le indica a la pila: consulta la lista de routers predeterminados IPv6 de la misma interfaz, elige uno y toma de su caché de vecinos la dirección de capa 2.

Todo lo demás puede seguir siendo nativo. La aplicación abre un socket IPv4; el host construye un paquete IPv4; la red lo reenvía como IPv4. No aparece una cabecera exterior IPv6 ni una traducción NAT64. Lo único prestado es la resolución del primer salto.

En agosto de 2026 el texto pasó a ser un documento del grupo de trabajo INTAREA. Informa de pruebas sin cambios de aplicaciones ni DHCPv4 en Windows 11, macOS, Android, iOS, Linux, FreeBSD y ChromeOS. Conviene conservar el sujeto de esa afirmación: es el informe del borrador, no una certificación externa. Como Internet-Draft, puede cambiar y su dirección propuesta todavía no debe presentarse como norma definitiva.

El control está en las uniones

Recibir 192.0.0.11/32 por DHCP solo demuestra que llegó la configuración. Para enviar, el host necesita una Router Advertisement válida. Antes de la primera RA no hay router que pueda aportar un vecino; cualquier cola debe tener límite. Después, la preferencia del RFC 4191, el estado de alcance y las reglas internas de cada sistema deciden entre candidatos.

Neighbor Discovery aporta el MAC, pero tampoco garantiza el servicio. Los estados reachable, stale, delay y probe del RFC 4861 permiten utilizar un vecino en distintos momentos de comprobación. La entrada puede sobrevivir unos instantes a un fallo de reenvío. También puede desaparecer aunque el equipo físico siga sano. Conviene medir ambos hechos, no inferir uno del otro.

El retorno abre otra frontera. Para salir del host basta la dirección link-local IPv6 del router. Para que otros routers devuelvan tráfico, un siguiente salto link-local no alcanza. La red necesita anunciar la IPv4 /32 del host con un siguiente salto IPv6 GUA o ULA enrutable. El RFC 8950 define esa combinación en BGP; el trabajo v4-via-v6 extiende el modelo de forwarding entre routers.

Por eso una sonda saliente satisfactoria puede coexistir con una sesión rota. La operación completa requiere recibos distintos para la concesión, la RA elegida, el vecino y su MAC, el forwarding IPv4 del router y la ruta de host que devuelve el paquete.

La máscara también es una regla de seguridad

Con un prefijo IPv4 más ancho, el host clasificaría otros destinos como locales e intentaría resolverlos con ARP. El /32 impide que reaparezca una red IPv4 implícita. La centinela tampoco debe anunciarse por el sistema de routing ni aparecer como origen o destino de tráfico reenviado. Es una orden local, no una identidad.

El borrador menciona prácticas de alojamiento en Hetzner, OVH y Scaleway: una IPv4 por cliente y una puerta fuera del enlace, hoy acompañadas por ajustes específicos del sistema operativo. Esa experiencia explica por qué interesa una señal común, pero no equivale a una auditoría ni a un despliegue del nuevo método por esas empresas.

El RFC 8925 ofrece a los equipos capaces una preferencia por operación solo IPv6. La centinela atiende otro caso: hosts dual-stack que todavía precisan IPv4 nativo en un segmento diseñado alrededor de IPv6. Una red puede utilizar ambos enfoques, siempre que no convierta la presencia de uno en prueba del otro.

La compatibilidad tiene su propio recibo

Un host sin soporte verá una puerta IPv4 ordinaria y enviará ARP. El proyecto recomienda que el router responda con su MAC. Así se puede implantar una capa moderna sin expulsar de inmediato al parque antiguo.

Pero los dos caminos pueden ocultarse entre sí. Si solo se prueba un equipo antiguo, quizá funcione exclusivamente gracias a la respuesta ARP. Si solo se prueba uno nuevo, quizá nadie detecte que el nivel heredado está roto. Hacen falta clientes sintéticos y telemetría separados para el tráfico sin ARP y para la compatibilidad.

El debate de IETF 126 anticipó ese problema. Lorenzo Colitti preguntó si los cambios del routing IPv6 debían arrastrar al IPv4 y advirtió que una implementación defectuosa podía romperlo. Van Mook confirmó que el seguimiento forma parte del diseño. Tobias Fiebig destacó la elegancia frente a DHCPv4-over-DHCPv6. Menos señalización no significa menor necesidad de observar el estado.

Un prototipo que declara sus límites

El repositorio v4-with-v6-nh aporta código y pruebas. En Linux, un daemon identifica la centinela, selecciona el router de acuerdo con RFC 4191, instala una ruta IPv4 cuyo siguiente salto es IPv6, reacciona a cambios y retira la ruta cuando se pierde el requisito. El kernel representa estas rutas desde Linux 5.2.

La honestidad del repositorio evita exagerar. El daemon no puede retener paquete por paquete mientras espera la primera RA. La integración con systemd-networkd existe como parche. La sintaxis de FreeBSD fue validada pero no ejecutada, las configuraciones comerciales no se probaron en equipos y no hay una versión etiquetada. Esto demuestra viabilidad, no madurez homogénea.

Las pruebas decisivas son transiciones: caducidad de DHCP, demora de la primera RA, retirada del router preferido, estado NUD envejecido, desaparición de la ruta inversa, empate entre routers y mezcla de hosts capaces e incapaces.

ARP sale; la confianza no

La reducción de ARP puede eliminar ruido y una superficie de suplantación. A cambio, la disponibilidad IPv4 queda ligada a RA y ND. Una RA falsa o equivocada puede escoger el MAC utilizado para IPv4; un fallo de ND afecta ahora a dos familias.

RA Guard, puertos confiables, inspección del vecino y preferencias explícitas pasan a ser controles de IPv4. La avería más peligrosa es silenciosa: DHCP entrega la centinela donde solo existe media implementación. Algunos validadores DHCP pueden rechazar antes esa puerta fuera del enlace. Ambas situaciones prueban que “configurado” y “capaz de reenviar” nunca deben compartir un único indicador.

Fuentes