La mayoría de los sitios ahora funcionan con doble pila. El mismo servidor, API o página de pago responde tanto sobre IPv4 como IPv6 al mismo tiempo. Esta configuración te mantiene accesible a medida que las direcciones IPv4 se vuelven escasas, pero también divide tu tráfico en dos redes que fallan de manera independiente.
Aquí está el problema que crea. Si tu monitoreo solo prueba sobre IPv4, reporta verde mientras que los usuarios nativos de IPv6 se encuentran con un gateway muerto, un registro DNS faltante o una regla de firewall que nunca se actualizó. El panel muestra un 100 % de tiempo activo. Una porción creciente de tu audiencia dice que el sitio está roto.
Este artículo explica cómo Dotcom-Monitor prueba la ruta IPv6 en sus propios términos: nodos nativos solo IPv6 sin túneles, scripts de navegador que cargan cada recurso de terceros sobre IPv6, y verificaciones de protocolo que aíslan una falla IPv6 mientras la ruta IPv4 permanece limpia.
¿Qué es el monitoreo IPv6?
El monitoreo IPv6 es la práctica de verificar si tu sitio web, API y servicios responden correctamente sobre IPv6, desde el punto de vista de un usuario real de IPv6. Ejecuta las mismas verificaciones de disponibilidad y rendimiento que ya usas sobre IPv4—resolución DNS, carga de páginas, transacciones y respuestas de protocolo—pero sobre la ruta IPv6, que tiene sus propios registros DNS, rutas y reglas de firewall.
En un sitio de doble pila que sirva ambos protocolos, el monitoreo IPv6 es la única forma de confirmar que la mitad IPv6 funciona. Una verificación IPv4 pasa sin importar si IPv6 esté saludable, por lo que sin una prueba de monitoreo dedicada a IPv6, una caída que afecte solo a usuarios IPv6 permanece invisible. Las secciones a continuación muestran cómo Dotcom-Monitor ejecuta esa prueba desde nodos nativos solo IPv6, cubriendo tiempo activo, transacciones, DNS y verificaciones de protocolo en ambos planos.
Por qué las redes de doble pila crean un punto ciego en el monitoreo
Un servicio de doble pila responde en dos protocolos, pero IPv4 e IPv6 no comparten una ruta. Son dos planos de enrutamiento. El tráfico se resuelve mediante diferentes registros DNS, cruza distintas reglas de firewall y viaja por proveedores de tránsito diferentes antes de alcanzar el mismo origen.
Por lo tanto, una solicitud puede tener éxito en un plano y fallar en el otro. El cliente IPv4 resuelve tu registro A, pasa un firewall IPv4 que tu equipo ha afinado por años, y carga la página. El cliente IPv6 resuelve tu registro AAAA, toca un gateway que nunca fue configurado completamente y expira. Ambos usuarios escribieron la misma URL. Uno de ellos piensa que tu sitio está caído.
Los dos planos también difieren internamente. IPv6 usa un encabezado base fijo de 40 bytes, un campo de clase de tráfico de 8 bits y una etiqueta de flujo de 20 bits, por lo que los routers de tránsito manejan paquetes IPv6 de manera diferente al modelo IPv4 de mejor esfuerzo que han usado durante décadas. Y una sola subred IPv6 contiene muchas más direcciones que toda la Internet IPv4 heredada, lo cual cambia cómo se propagan las rutas y cómo se aplican los filtros. El punto para el monitoreo es simple: un resultado IPv4 no te dice nada confiable sobre la ruta IPv6. Debes probar cada una donde reside.
Cómo Dotcom-Monitor ejecuta monitoreo nativo solo IPv6
Dotcom-Monitor ejecuta sus verificaciones desde una red global de monitoreo de nodos en redes troncales reales IPv4 e IPv6. Algunos de esos nodos son de doble pila y pueden alcanzar un objetivo sobre cualquiera de los dos protocolos. Otros son solo IPv6.
Las ubicaciones solo IPv6 son la parte que importa aquí, por lo que se niegan a hacer. Gran parte del equipo de red que habla IPv6 también puede traducir el tráfico de regreso a IPv4 mediante mecanismos de transición como túneles 6to4 o NAT64. Esa traducción es conveniente en producción y engañosa en una prueba. Un agente de doble pila puede reportar un resultado limpio mientras silenciosamente recurre a IPv4, lo cual oculta la falla exacta que estás tratando de encontrar.
Un nodo solo IPv6 no usa traducción. Envía y recibe solo IPv6. Cuando una verificación pasa desde ese nodo, el objetivo respondió genuinamente sobre IPv6 nativo. Cuando falla, has atrapado una falla real en IPv6 en lugar de una caída cubierta con un respaldo.
Ejecutar la misma verificación desde un nodo nativo IPv4 y uno nativo solo IPv6 te da una comparación clara para cada plano. Cualquier diferencia entre los dos resultados es un problema específico de IPv6, no ruido de medición.
Esa línea base dividida se ejecuta en todos los tipos de dispositivos de la plataforma. El monitoreo de Aplicaciones Web conduce un navegador real a través de una transacción con guion. El monitoreo de Páginas Web carga una sola página de la misma forma. El monitoreo de Infraestructura de Internet ejecuta verificaciones de protocolo contra tus servidores. Y el monitoreo de Servicios Web valida tus API. Cada uno puede asignarse a ubicaciones solo IPv6, y los dos dispositivos de navegador graban con la herramienta de secuencias EveryStep, para que captures una ruta una vez y la reproduzcas desde cualquier nodo.
Capturando fantasmas AAAA de terceros con monitoreo en navegador real
Tu origen puede soportar IPv6 perfectamente y tus páginas aún pueden fallar para usuarios IPv6. La razón es todo lo que no alojas. Una página moderna incorpora un CDN, fuentes web, una etiqueta de analíticas, un widget de chat y un procesador de pagos. Cuando un usuario solo IPv6 carga esa página, el navegador intenta obtener cada uno de esos recursos también sobre IPv6.
Si un tercero nunca publicó un registro AAAA o descarta paquetes IPv6, el navegador se queda colgado en ese recurso. Espera a que la conexión expire y puede detener el resto del renderizado mientras espera. El resultado visible es una página a medio cargar: navegación faltante, marcos de recursos vacíos, un botón de pago que nunca funciona. Tu panel interno de salud se mantiene verde todo el tiempo, porque tu origen está bien. La falla está en la red de otro.
El monitoreo de Aplicaciones Web detecta esto cargando la página completa en un navegador real desde un nodo solo IPv6 y grabando cada solicitud en la cascada. Para una sola página en lugar de una transacción completa, el monitoreo de Páginas Web funciona igual. En lugar de un resultado pasa/falla, ves cuál recurso específico se resolvió, cuál agotó el tiempo y dónde se estancó el render. La tabla a continuación muestra el patrón que aparece.
| Perfil de prueba | HTML principal | CDN y recursos multimedia | Scripts de terceros | Lo que ve el usuario |
|---|---|---|---|---|
| Monitoreo IPv4 | Se resuelve (registro A) | Se resuelve | Se resuelve | La página completa se renderiza normalmente. |
| Monitoreo solo IPv6 | Se resuelve (registro AAAA) | No logra resolverse | Agota el tiempo | Carga parcial: diseño roto, marcos vacíos, pago detenido. |
Tomemos un flujo de compra como ejemplo. Un script de Aplicaciones Web inicia sesión, añade un artículo y llega al paso de pago. Sobre IPv4 toda la ruta pasa. Desde el nodo solo IPv6, el script del procesador de pagos no tiene registro AAAA, por lo que el navegador se detiene antes de que el formulario sea usable. El script falla en ese paso y te dice cuál recurso lo causó. Un ping de disponibilidad en tu propio dominio nunca habría marcado el pago. Escribir la transacción con monitoreo sintético transforma “el sitio está activo” en “los clientes realmente pueden pagar.”
Cómo el monitoreo de infraestructura de Internet aísla fallas de protocolo IPv6
Las verificaciones en navegador capturan lo que ven los usuarios. También necesitas la capa inferior. El monitoreo de Infraestructura de Internet ejecuta verificaciones a nivel de protocolo contra tus servidores, tan a menudo como una vez por minuto, y las ejecuta desde ubicaciones solo IPv6 igual que hacen los dispositivos navegador.
Esa frecuencia y ese aislamiento son la parte útil. Si tu endpoint HTTP/S o DNS responde sobre IPv4 pero falla sobre IPv6, el monitoreo de Infraestructura Internet reporta el error de protocolo IPv6 por sí solo en lugar de promediarlo con el resultado saludable de IPv4. El monitoreo de Servicios Web hace lo mismo para tus endpoints de API. Obtienes una alerta que nombra el protocolo y la ruta, no un vago “el tiempo de respuesta subió.”
El DNS merece una verificación dedicada. Un sitio de doble pila necesita que ambos, registros A y AAAA, se resuelvan globalmente a igual velocidad, y un registro AAAA obsoleto o ausente es una de las fallas IPv6 más comunes. El monitoreo DNS confirma que ambos registros responden en todas partes y vigila los valores TTL para que un cambio de ruta durante una migración no deje a usuarios IPv6 anclados a una entrada muerta. Cuando se dispara una alerta, un traceroute IPv6 automático muestra si la caída ocurrió en tu origen o dentro de la tabla de enrutamiento de un proveedor de tránsito upstream.
Cómo Dotcom-Monitor expone la latencia de Happy Eyeballs
Algunos problemas de IPv6 nunca se muestran como una caída. Se muestran como un sitio que se siente lento por razones que nadie puede identificar. La causa suele ser Happy Eyeballs.
Happy Eyeballs (RFC 8305) es un fallback de navegador. El navegador empieza su conexión IPv6 primero, espera un intervalo corto (el retraso del intento de conexión, aproximadamente 250 milisegundos por defecto) antes de correr también en carrera la IPv4. Si la ruta IPv6 está rota o lenta, el intento IPv4 gana y lleva la solicitud. La conexión aún tiene éxito, por lo que el usuario rara vez ve un error.
Eso es bueno para el usuario y malo para tu visibilidad. La espera antes de que el navegador abandone IPv6 y se incline hacia IPv4 se suma al Tiempo Real hasta el Primer Byte y a la Mayor Pintura de Contenido. Cada usuario IPv6 paga un impuesto de latencia en una conexión que finalmente funciona sobre IPv4. Las herramientas pasivas y los análisis de usuarios reales registran una carga exitosa y siguen adelante, por lo que la falla estructural permanece invisible mientras la experiencia se degrada silenciosamente.
El monitoreo nativo solo IPv6 mide el impuesto directamente, porque el fallback no está disponible para ocultarse detrás. La ruta IPv6 o tiene buen desempeño o no, y ese número aparece en el informe. Los informes comparativos de cascada ponen los tiempos IPv4 e IPv6 uno junto al otro, de modo que una diferencia de 250 milisegundos que los usuarios sienten pero no pueden describir se convierte en una línea en la que puedes señalar. Si quieres un repaso sobre cómo leer esos gráficos, consulta nuestra guía para gráficos de cascada.
Cómo configurar el monitoreo de doble pila en Dotcom-Monitor
Aquí está la configuración que te da ambos planos sin duplicar tu trabajo de mantenimiento.
- Paso 1: Construye la verificación una vez en EveryStep. Graba tu camino crítico o verificación de protocolo una sola vez. El mismo script EveryStep se ejecuta en cada ubicación, así que no mantienes versiones separadas para IPv4 e IPv6.
- Paso 2: Asigna ubicaciones nativas IPv4 y solo IPv6. Añade la verificación a un nodo nativo IPv4 y a un nodo solo IPv6. Evita ubicaciones 6to4 y NAT64 para la línea base IPv6 para que no haya traducción entre el nodo y tu objetivo.
- Paso 3: Ajusta la frecuencia de la verificación. Ejecuta verificaciones de protocolo de Infraestructura de Internet tan a menudo como una vez por minuto. Programa verificaciones de navegador de Aplicaciones Web en el intervalo que tu SLA requiera.
- Paso 4: Agrega verificaciones DNS para registros A y AAAA. Confirma que ambos registros se resuelvan globalmente a igual velocidad y vigila los valores TTL para que una migración no deje a usuarios IPv6 atrapados en una ruta obsoleta.
- Paso 5: Dispara un traceroute IPv6 ante desviaciones. Configura alertas para ejecutar un traceroute en el momento en que la disponibilidad o el tiempo de respuesta baje, para que puedas distinguir rápidamente una falla de origen de una falla en tránsito upstream.
- Paso 6: Compara las dos cascadas. Revisa los informes IPv4 e IPv6 lado a lado. Cualquier recurso, salto o protocolo que difiera entre ellos es tu problema específico de IPv6.
Conclusión
Doble pila significa que cada solicitud tiene dos maneras de llegarte y dos maneras de fallar. El monitoreo solo IPv4 vigila una de ellas y reporta sobre ambas, que es cómo un sitio obtiene un récord perfecto de tiempo activo mientras que los usuarios IPv6 experimentan tiempos de espera, páginas a medio cargar y una penalización de latencia que nadie puede rastrear.
Dotcom-Monitor cierra esa brecha probando la ruta IPv6 en sus propios términos. Nodos nativos solo IPv6 sin túneles, scripts de navegador de Aplicaciones Web que cargan cada recurso de terceros sobre IPv6, verificaciones de protocolo de Infraestructura de Internet hasta una vez por minuto, y cascadas lado a lado que separan una falla de origen de una de upstream. Dejas de adivinar sobre la mitad de tu tráfico que las verificaciones IPv4 nunca tocaron.
Prueba tu ruta IPv6 antes que tus usuarios
Despliega nodos de monitoreo nativos solo IPv6 y ve exactamente lo que experimentan tus usuarios de doble pila, hasta el recurso de terceros. Comienza una prueba gratuita de 30 días con Dotcom-Monitor.
