Ubuntu 24.04: IPv6 rompe sitios aleatorios — Arregla dual-stack correctamente (No desactives IPv6)

Qué suele significar “fallos aleatorios” en dual-stack

Cuando los usuarios dicen “algunos sitios no cargan”, no están describiendo aleatoriedad. Están describiendo efectos de selección.
Algunos destinos publican registros AAAA (direcciones IPv6), otros no. Algunos CDNs te dirigen a un borde IPv6 alcanzable, otros a uno que no lo es.
Algunos sitios están detrás de redes que requieren que PMTUD funcione correctamente; otros no. Algunos endpoints usan QUIC sobre UDP; otros se quedan en TCP.

En un host dual-stack, muchas pilas cliente intentarán IPv6 primero si existe un registro AAAA. Si la ruta IPv6 está rota o el servidor DNS devuelve respuestas IPv6 malas,
obtendrás timeouts, cargas largas de páginas o discusiones del tipo “funciona en mi teléfono, no en mi portátil”. Eventualmente, Happy Eyeballs puede volver a IPv4, pero “eventualmente”
no es una estrategia de experiencia de usuario.

Tu objetivo no es “hacer que IPv6 desaparezca”. Tu objetivo es hacer que IPv6 sea correcto para que el dual-stack se comporte como una utilidad aburrida.
Aburrido es bueno. Aburrido paga las facturas.

Broma #1: Desactivar IPv6 porque es inestable es como quitar el detector de humo porque pita cuando la batería está baja. Silencia, sí. Inteligente, no.

Hechos y contexto que explican por qué esto ocurre

• Hecho 1: IPv6 se estandarizó a finales de los 90, pero los despliegues empresariales tardaron décadas; son comunes las implementaciones “que funcionan en su mayoría”.
• Hecho 2: Muchos sistemas operativos prefieren IPv6 por defecto cuando existen A y AAAA, guiados por las reglas de selección de direcciones RFC 6724.
• Hecho 3: “Happy Eyeballs” (inicialmente RFC 6555, luego actualizado) existe específicamente porque las rutas IPv6 rotas eran muy comunes.
• Hecho 4: Las Router Advertisements (RA) pueden configurar IPv6 sin DHCPv6; esta conveniencia también facilita que la mala configuración pase desapercibida.
• Hecho 5: DNS64/NAT64 puede permitir que clientes solo-IPv6 lleguen a servicios IPv4; cuando se despliega accidentalmente o está medio roto, crea fallos surrealistas.
• Hecho 6: Los agujeros negros de Path MTU fueron históricamente más visibles en IPv4 por el comportamiento de fragmentación; en IPv6, los routers no fragmentan por ti.
• Hecho 7: Algunos clientes VPN y “agentes de seguridad” todavía manejan mal IPv6, sobre todo en split tunneling y enrutamiento DNS para AAAA.
• Hecho 8: Proveedores cloud y CDNs a menudo tienen bordes IPv6 e IPv4 distintos; no siempre estás alcanzando “el mismo servidor, solo direcciones diferentes”.
• Hecho 9: systemd-resolved cambió cómo muchos escritorios y servidores Linux hacen resolución stub; es rápido cuando está bien y confuso cuando está mal.

Guía rápida de diagnóstico (verificar primero/segundo/tercero)

Primero: confirma si los fallos se correlacionan con búsquedas AAAA (IPv6)

Si los sitios rotos tienen de forma fiable registros AAAA y los sitios que funcionan no, deja de fingir que es “aleatorio”. Es preferencia por IPv6 + una ruta IPv6 rota.
Si existen A y AAAA y IPv4 funciona pero IPv6 se cuelga, estás ante problemas de enrutamiento, MTU, firewall o transporte DNS.

Segundo: valida la configuración IPv6 local y la ruta por defecto

La forma más rápida de perder una tarde es depurar el comportamiento de una aplicación antes de haber confirmado que el kernel tiene una dirección IPv6 válida,
una ruta por defecto y descubrimiento de vecinos funcionando.

Tercero: prueba la conectividad IPv6 básica y el comportamiento de DNS por separado

Problemas de DNS y de reenvío de paquetes pueden parecer idénticos desde un navegador. Sepáralos pronto:
(1) ¿puedes resolver AAAA rápidamente? y (2) ¿puedes conectar a la dirección IPv6 resuelta rápidamente?

Cuarto: si “conecta pero se queda estancado”, sospecha MTU/PMTUD o un firewall con estado

El handshake TCP tiene éxito, TLS se atasca, HTTP cuelga, QUIC falla: ahí viven los agujeros negros de MTU y los tiempos de espera de estado del firewall.
Diagnostícalo con pings dirigidos y capturas de paquetes, no con intuiciones.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son las tareas que realmente ejecuto en un host Ubuntu 24.04 cuando el dual-stack se siente embrujado. Cada tarea incluye qué significa la salida y qué decisión tomar a continuación.
Ejecútalas en orden; normalmente atrapas al culpable entre las tareas 7–10.

Tarea 1: confirma que el host tiene IPv6 global y la interfaz correcta

cr0x@server:~$ ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
    inet6 fe80::a00:27ff:fe4e:66a1/64 scope link
       valid_lft forever preferred_lft forever
    inet6 2001:db8:120:34::25/64 scope global dynamic mngtmpaddr
       valid_lft 7100sec preferred_lft 3500sec

Significado: Quieres una dirección scope global en la interfaz que esperas (no solo fe80::/64 link-local).
Si solo ves link-local, IPv6 no alcanzará Internet sin algún túnel especial.

Decisión: ¿No hay IPv6 global? Detente. Arregla RA/DHCPv6 en la red o la configuración de netplan antes de depurar navegadores.

Tarea 2: verifica que exista la ruta por defecto IPv6 y apunte a algo sensato

cr0x@server:~$ ip -6 route show
2001:db8:120:34::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
default via fe80::1 dev enp0s31f6 proto ra metric 1024 pref medium

Significado: La ruta por defecto vía una puerta de enlace link-local (como fe80::1) aprendida por RA es normal.
Lo que no es normal es no tener default, o múltiples defaults que fluctúan entre interfaces.

Decisión: ¿Falta la ruta por defecto? Concéntrate en las Router Advertisements (o enrutamiento estático) antes del DNS. ¿Múltiples defaults? Puedes estar lidiando con VPNs, Wi‑Fi + Ethernet o métricas de ruta mal configuradas.

Tarea 3: comprueba que el descubrimiento de vecinos no esté fallando (comprobación L2/L3)

cr0x@server:~$ ip -6 neigh show dev enp0s31f6
fe80::1 lladdr 00:11:22:33:44:55 router STALE

Significado: Si la entrada del router nunca aparece, o se queda en FAILED, no tienes adyacencia IPv6 básica.

Decisión: Si el descubrimiento de vecinos está roto, sospecha VLANs, aislamiento Wi‑Fi, RA-guard, seguridad de switch o un firewall local demasiado agresivo.

Tarea 4: prueba conectividad IPv6 directa a una dirección conocida (evita DNS)

cr0x@server:~$ ping -6 -c 3 2606:4700:4700::1111
PING 2606:4700:4700::1111(2606:4700:4700::1111) 56 data bytes
64 bytes from 2606:4700:4700::1111: icmp_seq=1 ttl=57 time=9.89 ms
64 bytes from 2606:4700:4700::1111: icmp_seq=2 ttl=57 time=10.12 ms
64 bytes from 2606:4700:4700::1111: icmp_seq=3 ttl=57 time=10.02 ms

--- 2606:4700:4700::1111 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Significado: ICMPv6 exitoso no demuestra que TCP funcionará, pero fallo aquí es una señal gigante: IPv6 está roto de raíz.

Decisión: Si esto falla pero el ping IPv4 funciona, concéntrate en enrutamiento/firewall/ISP/VPN en lugar de configuraciones de aplicación.

Tarea 5: confirma que DNS devuelve AAAA y A, y con qué rapidez

cr0x@server:~$ resolvectl query example.com
example.com: 2606:2800:220:1:248:1893:25c8:1946
             93.184.216.34

-- Information acquired via protocol DNS in 42.0ms.
-- Data is authenticated: no

Significado: Obtuviste AAAA y A rápidamente. Si las consultas tardan segundos o devuelven solo AAAA cuando el sitio tiene también A, eso es rareza del resolvedor/transporte.

Decisión: DNS lento? Investiga servidores ascendentes de systemd-resolved, comportamiento EDNS, o un problema de captura DNS por VPN.

Tarea 6: inspecciona qué servidores DNS están en juego (importa por enlace)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 2001:4860:4860::8888
       DNS Servers: 2001:4860:4860::8888 8.8.8.8

Link 2 (enp0s31f6)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 2001:4860:4860::8888
       DNS Servers: 2001:4860:4860::8888 8.8.8.8

Significado: systemd-resolved puede tener DNS por interfaz. Una VPN a menudo inyecta DNS en su enlace, lo que puede cambiar respuestas AAAA o romperlas.

Decisión: Si los servidores DNS difieren por enlace, confirma que la ruta por defecto y el enlace DNS coinciden con tu intención (especialmente con VPNs y split tunnels).

Tarea 7: fuerza conexiones IPv6 e IPv4 por separado al mismo hostname

cr0x@server:~$ curl -6 -I --max-time 8 https://example.com
HTTP/2 200
cache-control: max-age=604800
content-type: text/html; charset=UTF-8
server: ECS (nyb/1D2A)

cr0x@server:~$ curl -4 -I --max-time 8 https://example.com
HTTP/2 200
cache-control: max-age=604800
content-type: text/html; charset=UTF-8
server: ECS (nyb/1D2A)

Significado: Si -4 funciona y -6 agota el tiempo (o se queda a mitad de transferencia), tienes un problema real de ruta IPv6.

Decisión: ¿Solo IPv6 falla? Ve a las tareas de MTU y firewall. ¿Ambas fallan? Eso es conectividad más amplia, proxy o inspección TLS.

Tarea 8: comprueba la elección de ruta para un destino IPv6 específico

cr0x@server:~$ ip -6 route get 2606:4700:4700::1111
2606:4700:4700::1111 from :: via fe80::1 dev enp0s31f6 proto ra metric 1024 pref medium

Significado: Confirma qué interfaz/puerta de enlace se usará. Si muestra una interfaz VPN o una NIC inesperada, hallaste tu “aleatoriedad”.

Decisión: ¿Interfaz de salida equivocada? Ajusta métricas de ruta, configuración de netplan o la política de enrutamiento de la VPN.

Tarea 9: prueba síntomas MTU/PMTUD con una sonda “no fragmentar” (estilo IPv6)

cr0x@server:~$ ping -6 -c 3 -s 1452 2606:4700:4700::1111
PING 2606:4700:4700::1111(2606:4700:4700::1111) 1452 data bytes
1452 bytes from 2606:4700:4700::1111: icmp_seq=1 ttl=57 time=10.88 ms
1452 bytes from 2606:4700:4700::1111: icmp_seq=2 ttl=57 time=10.95 ms
1452 bytes from 2606:4700:4700::1111: icmp_seq=3 ttl=57 time=11.01 ms

--- 2606:4700:4700::1111 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms

Significado: Esto no es una validación perfecta de PMTUD, pero si pings pequeños funcionan y los grandes fallan o cuelgan, sospecha un agujero negro de MTU.
VPNs, túneles y PPPoE son reincidentes.

Decisión: Si paquetes grandes fallan, limita MSS en el borde, ajusta MTU de la interfaz o arregla que ICMPv6 Packet Too Big esté bloqueado.

Tarea 10: verifica que ICMPv6 no esté “asegurado” hasta morir localmente

cr0x@server:~$ sudo nft list ruleset | sed -n '1,160p'
table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif "lo" accept
    ip6 nexthdr icmpv6 icmpv6 type { echo-request, echo-reply, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert, packet-too-big, time-exceeded, parameter-problem } accept
    tcp dport { 22 } accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
  }
  chain output {
    type filter hook output priority filter; policy accept;
  }
}

Significado: En IPv6, ICMPv6 no es opcional. Si alguien bloqueó “todo ICMP” por reflejo de seguridad, puedes romper ND y PMTUD.

Decisión: Asegura que los tipos esenciales de ICMPv6 estén permitidos. Si estás en un servidor con policy drop, sé explícito.

Tarea 11: comprueba los interruptores del kernel para desactivar IPv6 (sí, la gente los cambia)

cr0x@server:~$ sysctl net.ipv6.conf.all.disable_ipv6 net.ipv6.conf.default.disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0

Significado: Si estos son 1, IPv6 está deshabilitado a nivel de kernel. A veces se hace “temporalmente” y luego se fossiliza.

Decisión: Si está deshabilitado, vuélvelo a habilitar y arregla el verdadero problema. Si está habilitado, sigue: tu problema es más sutil (y por tanto más entretenido).

Tarea 12: confirma a qué apunta /etc/resolv.conf realmente

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Apr 19 10:07 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Significado: Ubuntu usa comúnmente el resolvedor stub de systemd. Si esperabas NetworkManager o un resolv.conf estático, tu modelo mental está desactualizado.

Decisión: Si es stub-resolv.conf, usa resolvectl para la verdad. Si es un archivo estático, asegúrate de que contenga servidores DNS alcanzables sobre ambas pilas.

Tarea 13: verifica que no sufras fallo de transporte DNS sobre IPv6

cr0x@server:~$ resolvectl query -4 example.com
example.com: 93.184.216.34

-- Information acquired via protocol DNS in 16.8ms.

cr0x@server:~$ resolvectl query -6 example.com
example.com: 2606:2800:220:1:248:1893:25c8:1946

-- Information acquired via protocol DNS in 2105ms.

Significado: Misma consulta, pero el transporte IPv6 al servidor DNS es lento. Eso por sí solo puede hacer que “sitios aleatorios” parezcan rotos.

Decisión: Arregla la alcanzabilidad IPv6 a tu resolvedor DNS, o prefiere temporalmente un resolvedor IPv4 mientras reparas enrutamiento/MTU para el resolvedor IPv6.

Tarea 14: captura evidencia (tcpdump corto y dirigido)

cr0x@server:~$ sudo tcpdump -ni enp0s31f6 ip6 and host 2606:4700:4700::1111
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s31f6, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:14:01.233445 IP6 2001:db8:120:34::25 > 2606:4700:4700::1111: ICMP6, echo request, seq 1, length 64
12:14:01.243110 IP6 2606:4700:4700::1111 > 2001:db8:120:34::25: ICMP6, echo reply, seq 1, length 64

Significado: Estás verificando que los paquetes salgan y que las respuestas regresen por la interfaz esperada. Si las peticiones salen y nada vuelve, es upstream.
Si nada sale, es enrutamiento/firewall local.

Decisión: Usa esto para probar dónde está la falla antes de cambiar configuraciones “solo para ver”.

Causas principales: DNS, enrutamiento, MTU, RA/DHCPv6 y firewalls

1) Las respuestas DNS están bien; el transporte DNS no

Una de las variantes más desagradables: tu resolvedor es alcanzable vía IPv4 e IPv6, pero IPv6 hacia el resolvedor está roto (MTU, asimetría de enrutamiento, firewall).
systemd-resolved puede preferir la dirección IPv6 del resolvedor, atascar consultas y luego reintentar. Desde la perspectiva de la aplicación: “algunos dominios agotan el tiempo”.

La solución no es eliminar registros AAAA (no puedes) ni desactivar IPv6 (no deberías). La solución es hacer fiable la ruta IPv6 al DNS, o restringir
qué servidores DNS se usan en qué interfaces para no preferir un transporte roto.

2) Existe ruta por defecto, pero gana la equivocada

Los fallos dual-stack adoran el multihoming: Ethernet + Wi‑Fi, LAN + VPN, puentes Docker y herramientas “útiles” que añaden rutas.
Puedes tener una ruta por defecto IPv4 perfectamente buena y una ruta por defecto IPv6 rota, y el host aún elegirá IPv6 para destinos con AAAA.

Arregla las métricas de ruta o elimina la fuente RA deshonesta. Si estás en una empresa, desconfía de Wi‑Fi de invitados que anuncian IPv6 pero en realidad no lo enrutan.
Ocurre más a menudo de lo que piensas, porque alguien habilitó IPv6 en un dispositivo de borde con un clic y nunca verificó upstream.

3) Agujeros negros de MTU (el clásico “conecta y luego se atasca”)

IPv6 requiere que PMTUD funcione correctamente; los routers no fragmentan por ti. Si los mensajes ICMPv6 Packet Too Big son bloqueados en algún sitio,
o un túnel reduce la MTU y nadie avisa a los endpoints, TCP puede conectar y luego quedarse colgado en registros TLS grandes o respuestas HTTP.

Las VPNs son culpables comunes. También los firewalls con reglas por defecto que accidentalmente descartan tipos de ICMPv6 que no reconocen.
Cuando oigas “carga páginas pequeñas pero no las grandes”, no discutas. Ve a probar MTU.

4) RA y DHCPv6 no están alineados con la realidad

La configuración IPv6 puede venir de Router Advertisements (SLAAC), DHCPv6 o ambos.
Una red puede darte una dirección IPv6 global pero no una ruta por defecto funcional, o darte servidores DNS que no son alcanzables.
Terminas “configurado” pero no funcional.

En clientes Ubuntu, netplan + NetworkManager o systemd-networkd pueden comportarse de forma diferente respecto a RA y DHCPv6.
Asegúrate de saber qué renderer está activo y qué componente debe aceptar RA.

5) Firewalls: “bloquear ICMP” no es un plan

En IPv4, a veces puedes salirte con políticas de ICMP laxas. En IPv6 no puedes.
El descubrimiento de vecinos, el descubrimiento de routers y PMTUD dependen de ICMPv6.
Bloquearlo no te hace más seguro; te deja ciego y con fallos intermitentes.

systemd-resolved en Ubuntu 24.04: en qué confiar y qué verificar

Ubuntu 24.04 usa systemd-resolved en configuraciones predeterminadas comunes. Hace caching, DNS por enlace, DNS dividido, y presenta un resolvedor stub local.
Eso está bien. También es una fuente frecuente de confusión porque la gente inspecciona /etc/resolv.conf y piensa que aprendió algo.
A menudo solo aprendieron que hay un symlink.

En qué confío

• resolvectl status es la verdad actual sobre qué servidores DNS se usan por interfaz y globalmente.
• resolvectl query es una forma decente de medir tiempo de respuesta DNS sin añadir herramientas extra.
• El caching de systemd-resolved es generalmente estable y acelera búsquedas comunes.

Qué verifico

• Si un enlace de VPN inyectó servidores DNS y se convirtió en la ruta por defecto para IPv6 (a menudo accidentalmente).
• Si los servidores DNS son alcanzables por IPv6 sin problemas de MTU o firewall.
• Si existen reglas de DNS dividido que envían algunos dominios a resolvers internos que no sirven AAAA o agotan el tiempo.

Si sospechas que systemd-resolved está trabado, puedes reiniciarlo—después de haber capturado síntomas. Reiniciarlo primero es cómo escapan los bugs.

cr0x@server:~$ sudo systemctl restart systemd-resolved
cr0x@server:~$ resolvectl statistics
Transactions
  Current Transactions: 0
  Total Transactions: 1249
Cache
  Current Cache Size: 317
  Cache Hits: 802
  Cache Misses: 447
DNSSEC Verdicts
  Secure: 0
  Insecure: 1249
  Bogus: 0

Significado: Estás confirmando que el daemon está sano y cacheando. Esto no prueba que el upstream esté sano.

Decisión: Si los reinicios “lo arreglan”, todavía tienes una causa raíz; solo añadiste un ritual. Vuelve a revisar la alcanzabilidad de transporte y DNS por enlace.

Peculiaridades de Netplan que destruyen silenciosamente IPv6

Netplan es genial cuando lo tratas como configuración declarativa y lo mantienes aburrido. Es menos genial cuando editas YAML bajo presión a las 2 a.m.
YAML es un lenguaje diseñado para castigar la sobraconfianza.

Confusión de renderer: NetworkManager vs systemd-networkd

En escritorios, NetworkManager es típico. En servidores, systemd-networkd es común. Su comportamiento respecto a RA, DHCPv6 y DNS puede diferir.
Al depurar, identifica el renderer en uso y no mezcles suposiciones.

cr0x@server:~$ sudo netplan get
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s31f6:
      dhcp4: true
      dhcp6: true
      accept-ra: true

Significado: Este host acepta RA y usa DHCPv6. Si pusiste accept-ra: false por accidente, puedes perder la ruta por defecto.

Decisión: Si IPv6 está parcialmente configurado, verifica que dhcp6 y accept-ra coincidan con tu diseño de red.

IPv6 estático malo + RA: el problema de “dos verdades”

Una dirección IPv6 estática con una longitud de prefijo equivocada, combinada con rutas proporcionadas por RA, puede dar un comportamiento bizarro.
El host cree que tiene una dirección global; las respuestas remotas van a otro sitio o regresan por un camino distinto.
IPv4 sigue funcionando, así que todos culpan “a la app”.

cr0x@server:~$ ip -6 route show table main | head
default via fe80::1 dev enp0s31f6 proto ra metric 1024 pref medium
2001:db8:120:34::/64 dev enp0s31f6 proto kernel metric 256 pref medium
2001:db8:120:99::/64 dev enp0s31f6 proto kernel metric 256 pref medium

Significado: Tener dos prefijos globales en una interfaz puede ser válido, pero a menudo es señal de configuración estática antigua chocando con RA actual.

Decisión: Si no pretendías direccionamiento multiprefijo, límpialo. Reduce variables antes de depurar capas superiores.

Errores comunes (síntoma → causa raíz → solución)

1) Síntoma: “Algunos sitios agotan el tiempo, pero ping6 funciona”

Causa raíz: Echo ICMPv6 funciona, pero TCP/UDP está bloqueado o NAT64/DNS64 interfiere, o MTU está roto para paquetes grandes.

Solución: Prueba con curl -6 -I, luego examina MTU. Verifica reglas de firewall que permitan IPv6 saliente y tipos esenciales de ICMPv6, especialmente Packet Too Big.

2) Síntoma: “Búsquedas DNS IPv6 lentas; IPv4 rápidas”

Causa raíz: El resolvedor es alcanzable por IPv4, pero la ruta IPv6 hacia el resolvedor está rota (enrutamiento/MTU/firewall), o el IPv6 del resolvedor está limitando tasa upstream.

Solución: Cambia DNS a un resolvedor alcanzable por IPv6, o prefiere temporalmente transporte DNS por IPv4 mientras reparas la alcanzabilidad IPv6 al resolvedor.

3) Síntoma: “Funciona en Wi‑Fi, falla en Ethernet (o viceversa)”

Causa raíz: Diferentes RAs, diferentes servidores DNS, o diferentes rutas por defecto y métricas IPv6 por enlace.

Solución: Compara resolvectl status e ip -6 route en cada enlace. Arregla métricas de ruta o detén la fuente RA deshonesta.

4) Síntoma: “Después de activar una VPN, sitios aleatorios se rompen”

Causa raíz: La VPN se anuncia como ruta por defecto IPv6 pero no transporta IPv6 correctamente; o secuestra DNS y maneja mal AAAA.

Solución: Asegura que la VPN soporte IPv6 end-to-end, o configura correctamente split tunneling. Valida con ip -6 route get para destinos que fallan.

5) Síntoma: “El navegador gira, pero curl -4 funciona inmediatamente”

Causa raíz: IPv6 es preferido; los tiempos de fallback de Happy Eyeballs hacen que el navegador parezca colgado.

Solución: Arregla la ruta IPv6 (no la ocultes). Como mitigación temporal, ajusta DNS o enrutamiento para que IPv6 se use solo cuando realmente funcione.

6) Síntoma: “Solo las descargas grandes fallan por IPv6”

Causa raíz: Agujero negro de MTU o ICMPv6 Packet Too Big bloqueado.

Solución: Permite ICMPv6 PTB. Limita MSS en el dispositivo de borde si lo controlas. Reduce MTU del túnel o repara PMTUD end-to-end.

7) Síntoma: “Hay dirección IPv6, pero no hay ruta por defecto”

Causa raíz: No se recibe RA, RA ignorada (accept-ra: false), RA filtrada (RA-guard), o el router no anuncia default.

Solución: Confirma recepción de RA con logs de networkd/NetworkManager; corrige netplan; arregla la configuración RA-guard en el switch.

8) Síntoma: “Todo funciona un tiempo, luego se rompe hasta reconectar”

Causa raíz: Las direcciones de privacidad rotan y algún ACL upstream o caché de vecinos roto no puede seguir el ritmo; o rutas obsoletas de una interfaz transitoria.

Solución: Busca flaps de ruta y cambios de dirección. Prefiere direccionamiento estable para servidores; para clientes, arregla el filtrado upstream y la estabilidad de enrutamiento.

Tres mini-historias corporativas desde el frente

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana desplegó Ubuntu 24.04 en una flota de desarrolladores. En un día, el helpdesk interno tuvo una nueva categoría: “internet inestable.”
Los desarrolladores reportaron que instalaciones de paquetes se quedaban estancadas, algunos paneles SaaS cargaban a medias, y redirecciones de autenticación fallaban ocasionalmente.
El equipo de red insistía en que su WAN estaba limpia. El equipo de endpoint insistía en que era una actualización del navegador. Todos tenían razón, lo que es el tipo de razón más molesta.

La suposición equivocada fue pequeña y letal: “Si el cliente tiene una dirección IPv6, IPv6 debe funcionar.” En su Wi‑Fi de invitados y en algunos pisos de oficina,
los puntos de acceso enviaban Router Advertisements con un prefijo global (así los clientes configuraban IPv6), pero el enrutamiento upstream para ese prefijo faltaba en un switch de distribución.
Los paquetes IPv6 salían del cliente y desaparecían en la nada. IPv4 seguía funcionando, así que nadie fue notificado por “internet caído”.

El patrón de síntomas parecía aleatorio porque solo los destinos con registros AAAA activaban la ruta IPv6 rota. Y porque distintos CDNs devolvían AAAA para diferentes regiones,
dos personas sentadas juntas podían alcanzar bordes distintos que fallaban.

La solución fue aburrida: dejar de anunciar lo que no puedes enrutar. Corregrieron la configuración RA en los SSIDs afectados y validaron que cada prefijo anunciado tenía una ruta upstream.
También añadieron una comprobación cliente simple en la incorporación de dispositivos: si existe la ruta por defecto IPv6, verificar una lista corta de pruebas de conectividad IPv6 antes de declarar “red saludable.”

Mini-historia 2: La optimización que salió mal

Otra organización decidió “optimizar la latencia DNS” estandarizando en resolvers IPv6 únicamente. La razón sonaba moderna y ordenada: menos dependencias legacy, mejor preparación a futuro,
y una sola pila que depurar. Lo desplegaron vía gestión de endpoints, reemplazando resolvedores mixtos IPv4/IPv6 por direcciones solo-IPv6.

Funcionó bien en la sede. Funcionó bien en los centros de datos. Luego oficinas remotas empezaron a reportar que “cosas de Microsoft van lentas” y “algunos sitios no cargan”.
El equipo persiguió caches de navegador, agentes de seguridad endpoint e incluso throttling de CPU—porque los fallos no se reproducían en la LAN corporativa.

El fallo clásico fue MTU. Varias sedes remotas usaban un enlace WAN con overhead de encapsulación; la MTU efectiva era menor que 1500.
IPv4 ya tenía años de cicatrices en su entorno: el clamp de MSS ya estaba en su lugar para patrones de tráfico IPv4. IPv6 no recibió el mismo cuidado.
DNS sobre IPv6 a los resolvers se quedaba intermitentemente atascado cuando respuestas cruzaban el límite de MTU y los mensajes ICMPv6 Packet Too Big eran mal manejados por el perfil del firewall de borde.

Revertir a resolvers mixtos redujo el impacto de inmediato, pero la solución real fue reparar la historia MTU para IPv6: permitir ICMPv6 esencial, clamping de MSS cuando proceda,
y validar con tamaños de carga reales. La lección no fue “IPv6 es malo”. La lección fue: si optimizas un sistema que no mides, acabas de inventar una nueva clase de incidentes.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una entidad financiera (del tipo que ama congelar cambios y odia sorpresas) tenía una práctica estricta: cada cambio de red requería una comprobación de salud dual-stack desde un host canario.
No una plataforma sintética sofisticada—solo un script en una pequeña VM Ubuntu en cada sitio, registrando tiempos DNS, sanidad de rutas IPv4/IPv6 y algunas solicitudes HTTP HEAD sobre ambas pilas.

Durante una actualización rutinaria de firmware de firewall, un ingeniero aplicó una plantilla de política “endurecida”. La plantilla permitía tipos ICMP IPv4 esperados,
pero para IPv6 por defecto hacía “deny unknown ICMPv6.” El descubrimiento de vecinos y Packet Too Big fueron daños colaterales.
En minutos, los registros del canario mostraron peticiones HTTP IPv6 atascadas mientras IPv4 permanecía sana.

La práctica aburrida salvó el día porque detectó la regresión antes de que los usuarios se dieran cuenta. El on-call no tuvo que interpretar tickets vagos como “Slack está raro.”
Tenían marcas temporales, modos de fallo y un diff claro: IPv6 se rompió exactamente cuando se aplicó la plantilla de política.

Arreglarlo fue igualmente aburrido: permitir explícitamente los tipos ICMPv6 necesarios para ND, RA y PMTUD. El postmortem fue corto, tranquilo y útil.
Nadie aprendió un truco emocionante. Todos mantuvieron su fin de semana.

Listas de verificación / plan paso a paso

Paso a paso: hacer que dual-stack sea correcto en Ubuntu 24.04

1. Confirma que el síntoma está relacionado con IPv6.
   Usa curl -4 vs curl -6 para un hostname que falla. Si IPv6 falla, deja de culpar al navegador.
2. Valida dirección IPv6 + ruta por defecto.
   Comprueba ip -6 addr y ip -6 route. Sin dirección global o sin ruta por defecto no estás listo para depuración de aplicaciones.
3. Verifica descubrimiento de vecinos.
   Revisa ip -6 neigh. Si la entrada del router falta/FAILED, tienes problemas L2/L3 o filtrado de RA.
4. Prueba alcanzabilidad IPv6 sin DNS.
   Haz ping a una dirección IPv6 conocida. Si falla, céntrate en enrutamiento/firewall/VPN upstream.
5. Prueba tiempos y transporte DNS.
   Usa resolvectl query, compara consultas -4 y -6. DNS IPv6 lento sigue siendo una caída IPv6.
6. Confirma qué servidores DNS se usan por enlace.
   resolvectl status. Si la VPN inyecta DNS, verifica que sea intencional y que funcione por IPv6.
7. Comprueba MTU y señales PMTUD.
   Usa pings IPv6 grandes y busca estancamientos. Si controlas el borde, asegúrate de permitir ICMPv6 Packet Too Big.
8. Audita política de firewall para la realidad IPv6.
   Usa nft list ruleset. Permite tipos esenciales de ICMPv6. No “asegures” el protocolo hasta romperlo.
9. Fija la corrección de netplan.
   Confirma renderer, aceptación de RA, ajustes DHCPv6. Aplica cambios con cuidado y mantenlos mínimos.
10. Captura evidencia antes y después.
    Un tcpdump corto vale mil hilos de Slack. Guárdalo con fecha y nombre de interfaz.

Lista operativa: mantenerlo para que no vuelva

• Mantén un canario dual-stack (tiempos DNS + HTTP sobre v4/v6) por sitio/VLAN/perfil VPN.
• Requiere que los revisores de cambios consideren explícitamente reglas ICMPv6, no como pensamiento posterior.
• Rastrear dónde se originan las RAs; trata “RA deshonesta” como un modo de fallo real, no como teoría.
• Documenta métricas de ruta y política de enrutamiento cuando hay VPNs involucradas.
• Cuando cambies MTU en cualquier parte, valida PMTUD IPv6 con tamaños de carga reales.

Una cita que vale la pena tener en tu monitor

“La esperanza no es una estrategia.” — Gene Kranz (idea parafraseada)

Sustituye “desactivar IPv6” por “esperanza” y tendrás la moraleja de todo este embrollo.

Preguntas frecuentes

1) ¿Por qué solo algunos sitios se rompen?

Porque solo algunos sitios publican registros AAAA, y solo algunos CDNs te dirigen a un borde IPv6 que tu red no puede alcanzar de forma fiable.
Tu navegador intenta IPv6 primero, choca con una ruta muerta y luego finalmente vuelve a IPv4.

2) ¿Debería simplemente desactivar IPv6 en Ubuntu 24.04?

Como medida de contención temporal en un solo host durante un incidente, quizá. Como “solución”, no.
Desactivar IPv6 oculta la falla y te garantiza que no notarás cuando tu red esté medio rota otra vez.

3) Si ping6 funciona, ¿no prueba eso que IPv6 está bien?

No. El eco ICMPv6 puede tener éxito mientras TCP/UDP falla por política de firewall, problemas MTU/PMTUD o enrutamiento asimétrico.
Trata ping6 como punto de partida, no como veredicto.

4) ¿Cuál es la causa real más común?

En primer lugar: enrutamiento IPv6 roto anunciado por RA (los clientes obtienen direcciones y prefieren IPv6) combinado con upstream que en realidad no enruta ese prefijo.
En segundo lugar: agujeros negros MTU causados por bloqueo de ICMPv6 Packet Too Big.

5) ¿Cómo sé si systemd-resolved es el problema?

Si resolvectl query es lento o inconsistente, y especialmente si resolvectl status muestra servidores DNS inalcanzables,
el resolvedor está exponiendo un problema de transporte. El daemon rara vez es la causa raíz.

6) ¿Por qué una VPN lo empeora?

Las VPNs a menudo cambian rutas y servidores DNS. Si la VPN reclama enrutamiento por defecto IPv6 pero no transporta IPv6 correctamente, tu host enviará IPv6 dentro de un túnel a ninguna parte.
O el resolvedor DNS de la VPN maneja mal AAAA. En cualquier caso: la preferencia dual-stack amplifica la rotura.

7) ¿Qué tipos de ICMPv6 deben permitirse?

Como mínimo: neighbor solicitation/advertisement, router solicitation/advertisement, packet-too-big, time-exceeded y parameter-problem.
La política exacta depende de tu entorno, pero “bloquear todo ICMPv6” es un generador de fallos autoinfligidos.

8) ¿Cómo se presentan los problemas MTU en los navegadores?

Verás conexiones que empiezan pero no terminan: handshakes TLS atascados, recursos grandes que agotan el tiempo, o QUIC fallando mientras TCP a veces funciona.
Si las cargas pequeñas tienen éxito y las grandes fallan, sospecha MTU/PMTUD de inmediato.

9) ¿Esto es específico de Ubuntu 24.04?

Los modos de fallo subyacentes son universales. Lo que cambia entre versiones es la plomería: comportamiento del resolvedor, valores por defecto de netplan, versiones de NetworkManager,
y cuán agresivamente las aplicaciones prefieren IPv6. Ubuntu 24.04 es lo bastante moderno como para no evitar educadamente tu IPv6 roto.

10) ¿Cuál es la mitigación segura más rápida mientras arreglo la red?

Prefiere transporte DNS estable y enrutamiento estable. Por ejemplo, asegura que los servidores DNS sean alcanzables por IPv6 (o usa temporalmente resolvers IPv4),
y evita que una interfaz/VPN rota sea la ruta por defecto IPv6. Evita desactivar IPv6 a nivel kernel salvo que estés conteniendo un incidente activo.

Conclusión: próximos pasos que no envejecerán mal

El dual-stack debería ser aburrido. Cuando no lo es, casi nunca es “IPv6 místico”. Son los mismos pecados operativos de siempre:
anunciar rutas que no puedes llevar, bloquear paquetes de plano de control que necesitas realmente, y tratar la MTU como un concepto teórico.

Haz esto a continuación, en orden: ejecuta la guía rápida de diagnóstico, aísla si es transporte DNS o enrutamiento/MTU, y luego arregla la red para que IPv6 sea
verdaderamente funcional o no se anuncie. No enseñes a tu flota a convivir con una pila rota. Así acabas con políticas que solo funcionan los martes.

Broma #2: La buena noticia es que IPv6 tiene direcciones de sobra para cada dispositivo que posees. La mala noticia es que también tiene suficientes formas de configurarlas mal.