Usar internet sin conexión IPv4

• Tras un apagón, en una situación donde solo se cayó la conexión IPv4 del ISP y IPv6 seguía funcionando, se usó un VPS de Hetzner con IPv4/IPv6 y un túnel WireGuard para restaurar el acceso a sitios solo con IPv4
• La falla parecía estar en la capa de CG-NAT, donde los paquetes IPv4 no se traducían correctamente y se descartaban, mientras que servicios con soporte IPv6 como Google y Meta seguían accesibles
• Al poner un servidor WireGuard en el VPS y hacer que el cliente use la dirección IPv6 del VPS como endpoint, el tráfico IPv4 puede pasar por el VPS y recuperar la navegación web normal
• La VPN de trabajo y Docker requerían manejo aparte, así que se ejecutaron dentro de un namespace de red basado en vopono, junto con rodeos como unshare y bind mounts de /sys
• El síntoma de que solo algunos sitios no cargaban se debía a que el MTU de WireGuard era demasiado grande, y al bajarlo a 1280, el MTU mínimo de IPv6, se resolvió de inmediato

---

Falla donde solo se cortó IPv4 tras un apagón

• Después de un apagón se restauró el disyuntor, pero no era posible acceder a GitHub ni a varios sitios web, mientras que Google y Meta funcionaban con normalidad
• Al revisar ping -6 y traceroute en la máquina local y en la página de diagnóstico del router, se confirmó que el problema estaba solo en el acceso a servidores IPv4
• El ISP indicó que quizá haría falta la visita de un técnico y que podrían pasar varios días hasta después del fin de semana, lo que complicaba esperar por necesidades de trabajo y de investigación
• Ya existía un VPS de Hetzner con IPv4 estática y dirección IPv6, y como el sitio web de Hetzner soporta IPv6, fue posible entrar a la consola y hacer la configuración

La dependencia de IPv4 creada por NAT y CG-NAT

• Las direcciones IPv4 son de 32 bits y, excluyendo bloques reservados, solo hay alrededor de 3.7 mil millones de direcciones IPv4 públicas, así que no se puede asignar una a cada dispositivo conectado a internet
• NAT permite que varios dispositivos compartan una sola IP pública
  • El router doméstico cambia la IP local de dispositivos como 192.168.1.xxx por su propia IPv4 pública
  • El conntrack de Linux guarda un mapeo entre la IP y puerto de origen originales y el puerto traducido
  • Cuando los paquetes de respuesta llegan a ese puerto, conntrack restaura el destino a la IP y puerto internos originales
  • En Linux se pueden ver los mapeos guardados con conntrack -L de conntrack-tools
• NAT funciona como un firewall implícito, así que normalmente es difícil acceder desde fuera a servicios de dispositivos locales detrás del router sin un reenvío de puertos explícito
• Debido a la escasez de IPv4, el ISP puede aplicar NAT una vez más dentro de su propia red, lo que se conoce como Carrier Grade NAT (CG-NAT)
  • Así como el router doméstico hace NAT para varios dispositivos locales, el router del ISP hace NAT para varios routers domésticos
  • Dependiendo de cuántas direcciones IPv4 tenga el ISP y de su política de asignación, esto puede repetirse en varias capas, por ejemplo por región
• En esta falla, todo indicaba que en algún punto de la capa CG-NAT los paquetes IPv4 no se estaban traduciendo correctamente y eran descartados, dejando completamente interrumpido el tráfico IPv4
• Para métodos de evasión de NAT traversal, vale la pena revisar How NAT Traversal Works de Tailscale

Por qué IPv6 siguió funcionando

• Las direcciones IPv6 son de 128 bits y, aun considerando bloques reservados, ofrecen alrededor de 3.4E38 direcciones
• Es común que un router doméstico reciba una subred /64, lo que equivale a 1.84E19 direcciones
• En IPv6 no hace falta usar NAT en el router de casa para que cada dispositivo tenga una dirección directa en internet
  • Se reducen los problemas de reenvío de puertos
  • A cambio, el router o cada dispositivo necesita reglas de firewall adecuadas para bloquear nuevas conexiones externas arbitrarias
• Como a IPv6 no se le aplicaba CG-NAT, no se vio afectado por esta falla
• Aun así, hay servidores web como GitHub que todavía no son accesibles por IPv6, así que solo con conectividad IPv6 no era posible usar directamente todo internet

Crear un túnel IPv4 sobre IPv6 con WireGuard

• La solución fue instalar WireGuard en el VPS y configurar un túnel donde el cliente usara la dirección IPv6 del VPS como endpoint
• Una vez establecido el túnel, el tráfico IPv4 funcionaba normalmente pasando por el VPS
  • La latencia aumenta al pasar por el VPS
  • El funcionamiento se parece a una implementación manual de Dual-Stack Lite
• El servidor era un VPS de Hetzner con Arch Linux instalado previamente mediante vps2arch, usado sobre la imagen Debian más reciente de Hetzner
• La configuración de WireGuard se basó en el ejemplo de caso específico de servidor VPN en ArchWiki, ampliado con tráfico IPv6
• La configuración del servidor incluía lo siguiente
  • Address = 10.200.200.1/24, fd42:42:42::1/64, 2001:db8:abcd:1234::1/128
  • Reenvío de IPv4 con MASQUERADE de iptables
  • NAT para IPv6 ULA con SNAT --to-source de ip6tables
  • Activación de forwarding IPv4/IPv6
  • Los peers se dividían en ejemplos como foo, que usa directamente una IPv6 Global Unicast Address, y bar, que usa una IPv6 ULA con NAT
• A diferencia de una configuración estilo .ini, wg-quick permite especificar PostUp y PostDown varias veces, y ejecuta cada comando en orden
  • La implementación relacionada está en wg-quick linux.bash

NAT en IPv6, SNAT y configuración del cliente

• En IPv6 no es obligatorio usar NAT, y si el VPS tiene un bloque IPv6 /64 como en Hetzner, se puede dar a cada peer directamente una Global Unicast Address (GUA)
• Para usar direcciones directas, se reemplazan las Unique Local Address (ULA) del peer y la interfaz por direcciones IPv6 públicas y se elimina la regla ip6tables MASQUERADE
  • Cada peer pasa a ser direccionable directamente desde internet con la IPv6 asignada
  • Este enfoque es adecuado si se quiere reenviar servicios propios desde varios dispositivos
  • El firewall del VPS debe manejar correctamente el tráfico entrante
• Si se tiene la certeza de que la IP del VPS es estática y no cambiará, se puede usar SNAT en lugar de MASQUERADE
  • MASQUERADE consulta la IP de la interfaz en tiempo de ejecución
  • SNAT especifica la dirección directamente, así que es un poco más eficiente
• En la configuración del cliente, la dirección IPv6 del servidor debe ir entre corchetes, por ejemplo Endpoint = [2001:db8:abcd:1234::1]:51820
• Con AllowedIPs = 0.0.0.0/0, ::/0 se envía por el túnel todo el tráfico IPv4/IPv6
• Después de ejecutar en ambos lados, la navegación normal volvió a funcionar y también fue posible conectarse por SSH directamente al servidor usando las direcciones IPv4 e IPv6 locales del túnel
• En Linux también fue sencillo instalar el cliente WireGuard en la máquina de su esposa

Separar la VPN de trabajo con namespaces de red

• Al intentar conectar la VPN de trabajo directamente sobre la conexión WireGuard, surgían conflictos y no se podía usar
• Se usó vopono para ejecutar la VPN de trabajo y las aplicaciones necesarias dentro de un namespace de red
• La idea clave era hacer que la regla MASQUERADE enviara el tráfico no a una interfaz física real, sino a la interfaz WireGuard en uso (foo o bar)
• El tráfico dentro del namespace no percibe directamente las reglas nftables del WireGuard del host, pero en la práctica sí se enruta a través del túnel WireGuard
• wg-quick prefiere nftables cuando puede en lugar de iptables, pero evita conflictos con las reglas estándar de iptables de Docker
• Un ejemplo de ejecución con vopono es el siguiente

$ vopono -v exec --create-netns-only --provider None --protocol None -i bar bash
$ sudo ip netns exec vo_none_none bash
$ (inside netns) ./vpn.sh

• /etc/netns/vo_none_none/ se monta como /etc mediante ip netns exec, por lo que se puede tener un resolv.conf específico para ese namespace
• Si se quiere priorizar la resolución DNS IPv4, también se puede ajustar gai.conf de la misma manera
  • Esta configuración se usó mientras se depuraban problemas de tráfico IPv6 por el túnel
  • El ejemplo se basó en esta respuesta de AskUbuntu
• Después de conectarse a la VPN de trabajo, si se agrega el servidor DNS interno en /etc/netns/vo_none_none/resolv.conf, las aplicaciones ejecutadas luego dentro de ese namespace funcionan correctamente
• También es posible ejecutar aplicaciones como Chrome dentro del namespace con permisos de usuario normal

$ vopono -v exec -i bar --provider None --protocol None google-chrome-stable

Ejecutar Docker dentro del mismo namespace

• Docker no funciona simplemente ejecutándolo dentro de un namespace de red como cualquier otra aplicación
  • Esto se debe a que el socket de Docker activado por systemd fue creado fuera del namespace
  • La conectividad interna no queda asegurada
• Aunque se detenga el Docker externo y se intente crear de nuevo dockerd y el socket dentro del namespace, eso no resuelve todo de inmediato
  • ip netns exec crea un mount namespace y vuelve a montar /sys
  • Por eso deja de verse /sys/fs/cgroup del host
• En este caso puede aparecer el siguiente error

Error: OCI runtime error: runc: runc create failed: no cgroup mount found in mountinfo

• El rodeo consiste en usar unshare para hacer un bind mount de /sys, y desmontar el /sys interno creado por ip netns exec
  • Este método se basa en una publicación de Unix StackExchange
  • Después de eso, /sys dentro del mount namespace pasa a ser un bind mount del /sys del host
• Los comandos de ejemplo son los siguientes

$ sudo systemctl stop docker && sudo systemctl stop docker.socket
$ sudo -E unshare -m sh -c 'mount --bind /sys /sys; exec ip netns exec vo_none_none sudo --user youruser --preserve-env bash'
$ sudo umount /sys
$ sudo dockerd --host=unix:///var/run/docker-netns.sock --data-root=/var/lib/docker-netns
$ DOCKER_OPTS="--dns=YOURDNSHERE" DOCKER_HOST=unix:///var/run/docker-netns.sock sudo --user youruser --preserve-env docker ...

• Si dockerd y los comandos de Docker se ejecutan dentro de la misma sesión, comparten el mismo namespace de red y el mismo mount namespace
• La configuración DNS de Docker también puede ponerse en /etc/netns/vo_none_none/docker/daemon.json
• Este método fue suficiente para trabajos que necesitaban contenedores auxiliares y contenedores conectados mediante redes de Docker, aunque puede que no funcione igual en configuraciones de Docker más complejas que requieran bridges y similares

Depuración de problemas de MTU en WireGuard

• Después de reiniciar, la conexión WireGuard parecía seguir activa, pero solo algunas páginas cargaban y sitios como GitHub no abrían
• ping, ping -6 y wg show se veían normales, así que fue difícil encontrar la causa
• Al probar con ping de distintos tamaños, se confirmó que los paquetes grandes fallaban

$ ping6 -s 1400 fd42:42:42::1
$ ping6 -s 1200 fd42:42:42::1
$ ping6 -s 800 fd42:42:42::1

• El tamaño 1400 fallaba, mientras que 1200 y 800 funcionaban, confirmando que el problema era la configuración de MTU
• Si se baja el MTU de la interfaz WireGuard local, el stack IP del kernel deja de crear paquetes mayores que ese valor
  • Así, el paquete UDP final con el overhead de encapsulación de WireGuard tampoco es descartado en enlaces del camino con un MTU pequeño
• Cada router del trayecto tiene su propio MTU, y los paquetes mayores que el MTU más pequeño pueden ser descartados
• El tráfico del túnel añade alrededor de 32 bytes de overhead por la encapsulación de WireGuard, lo que puede agravar el problema de MTU
• Los mensajes de Path MTU Discovery pueden llegar por ICMP desde routers intermedios, pero como muchos firewalls bloquean ICMP, el ajuste automático puede no ocurrir
• Como la especificación de IPv6 define un MTU mínimo de 1280, ese valor debería funcionar siempre en túneles WireGuard sobre IPv6

Opciones operativas que quedaron tras la recuperación

• El resultado de la configuración incluyó lo siguiente
  • Un servidor VPN WireGuard en un VPS con IPv4 e IPv6
  • Soporte tanto para tráfico IPv6 directo como para IPv6 con NAT
  • Ejecución de la VPN de trabajo dentro de un namespace de red
  • Uso del rodeo con unshare para ejecutar Docker dentro del mismo namespace de red
  • Depuración del problema de MTU en WireGuard
• En trabajo remoto, los problemas de conectividad a internet siempre son un riesgo, y en este caso fue posible rodear la falla con herramientas de Linux sin esperar a que el ISP restaurara su configuración
• El VPS de Hetzner permite túneles WireGuard y uso general legítimo, aunque no permite port scanning, traffic spoofing ni minería de criptomonedas
• VPNs como AirVPN, ProtonVPN y AzireVPN, que soportan reenvío de puertos, también pueden ser una alternativa para reenviar puertos de un homeserver sin depender del ISP
• Si se usa un router con OpenWRT, se puede depurar más del lado del router y manejar este tipo de configuración de rodeo directamente con WireGuard en el router, sin configurarlo por separado en cada dispositivo

[GN⁺]

Opiniones de Hacker News

• El título es un poco engañoso. Más precisamente, se trata de acceder a Internet IPv4 mediante un túnel IPv6 a través de un VPS, algo que normalmente también se llama 4in6.
  Aun así, es interesante. Desde el punto de vista del ISP, la naturaleza de los problemas de soporte es bastante distinta cuando se rompe IPv4 que cuando se rompe IPv6. Una falla de IPv4 suele ser un estado claramente “caído”, así que los usuarios se quejan mucho, pero es simple. En cambio, una falla de IPv6 aparece en formas raras: fallas parciales, arranques lentos por el fallback, situaciones en las que el gateway cree que hay IPv6, etc.

  • La última vez que se cayó IPv4, lo noté sobre todo porque Github no funcionaba. Hoy en día, la mayoría de los sitios web de consumo funcionan incluso solo con IPv6.
    Pero quienes tenían configurados solo servidores DNS IPv4 en el router sufrieron una caída total. Si Microsoft hubiera limpiado un poco sus activos incompetentes, creo que la mayor preocupación habría sido recordar el hostname mDNS pegado al router para iniciar sesión y comprobar si IPv4 había vuelto.
  • La larga cola de IPv4 sin duda existe, pero la última vez que se cortó IPv4 en casa, mi esposa ni se dio cuenta. Fue porque Google, Facebook, Apple/iCloud y la mayor parte del hosting de CloudFlare siguieron funcionando con IPv6.
  • Coincide con mi experiencia. Los problemas de IPv6 son frustrantemente difíciles de clasificar y reproducir, y hay muchas situaciones tipo “en mi computadora sí funciona”.
  • La mayoría de los ISP todavía bloquean IPv6 por completo. Como suele pasar que pequeños operadores prueban IPv6 una vez y luego olvidan cosas como actualizar los registros AAAA, para el usuario parece que su servicio de nicho favorito funciona en otra red, pero no con el ISP por el que paga.
    Es un problema raro, y no sé si haya una buena solución aparte de esperar que IPv4 desaparezca algún día. Se suponía que Happy Eyeballs iba a resolver esto, pero el problema a menudo aparece muy por encima de la capa de aplicación, y como las aplicaciones pueden hacer cualquier cosa, es difícil resolverlo con un protocolo general sin abstracciones con fugas. Personalmente, estoy usando un compromiso: activo IPv6 en la red y desactivo DNS IPv6 en todos los navegadores, pero es bastante insatisfactorio.

• Si quieres probar IPv6 pero tu ISP no lo ofrece, Hurricane Electric lleva años ofreciendo un servicio de túneles.
  https://tunnelbroker.net
  https://ipv6.he.net
  También hay scripts para levantar un dispositivo tun en el sistema o el router y enrutar el tráfico: https://fedoraproject.org/wiki/IPv6_tunnel_via_Hurricane_Ele..., https://brandonrozek.com/blog/obtaining-ipv6-address-hurrica..., https://wiki.dd-wrt.com/wiki/index.php/IPv6_setup_Hurricane_..., https://forum.mikrotik.com/t/auto-update-script-for-hurrican..., https://docs.rockylinux.org/guides/network/hurricane_electri...

  • La advertencia molesta de estos túneles es que los servicios de streaming los bloquean como si fueran VPN para evadir restricciones regionales, así que si hace falta hay que averiguar cómo apagar el túnel.
    Aun así, funciona bien. Aunque el router no soporte túneles de HE, con el poder de RA puedes asignar direcciones IPv6 a todos los dispositivos de la red. Cualquier dispositivo que anuncie un /64 se convierte en router IPv6. Claro, siempre que el router no filtre RA por motivos de seguridad. Es muy útil para alojar servicios dentro de una red doméstica sin tocar reglas de port forwarding.
  • Hurricane Electric es excelente, pero a medida que más gente usa el IPv6 que ofrece su ISP, los usuarios “normales” abandonan los túneles, y los servicios de red empezaron a marcar los túneles de he.net como abuso.
    Demasiados sitios pusieron barreras o directamente se negaron a funcionar, así que tuve que dejar de usar IPv6 en la mayor parte de mi red.
  • Algo a tener en cuenta es que, hasta donde sé, los túneles de HE solo funcionan cuando el ISP te asigna una IPv4 pública. Si estás detrás de NAT de grado operador, lamentablemente necesitas otra solución para llevar IPv6 a tu casa.
  • Soy un “cliente” satisfecho. He usado un túnel 6in4 gratuito con OpenBSD durante unos 5 años, y no he tenido problemas dignos de mención.
    Lo configuro solo con archivos de interfaz de red de OpenBSD como /etc/hostname.gif0: tunnel, inet6 128 alias, !route -n add -inet6 default. Uso esta conexión para acceder a un clúster de VPS en AWS que configuré intencionalmente sin direcciones IPv4 públicas. De lo contrario, por culpa de gente como Jeff Bezos que monetiza agresivamente el espacio de direcciones IPv4, eso habría representado una parte importante del costo mensual.

• Si en un entorno realmente solo IPv6 necesitas conectividad IPv4 rápidamente, puedes usar una puerta de enlace pública DNS64+NAT64. La lista está en https://nat64.net/public-providers
  Para el uso normal, basta con cambiar el servidor DNS. DNS64 sintetiza registros DNS AAAA que apuntan a una caja NAT64 para destinos que no tienen registros AAAA: $ dig +short @2a00:1098:2c::1 AAAA github.com → 2a01:4f8:c2c:123f:64:5:141a:9cd7. NAT64 hace la conversión de protocolo y el NAT del tráfico que llegó hacia él debido a DNS64: $ curl --resolve github.com:443:[2a01:4f8:c2c:123f:64:5:141a:9cd7] [https://github.com/](<https://github.com/>;)

  • Venía a decir esto. En Europa, al menos https://nat64.net/ en sí funciona bastante bien. Solo he tenido buenas experiencias
  • Con Cloudflare WARP debería ser mucho más rápido. A través de WARP también puedes conectarte directamente a direcciones IPv4

• Así que ese mítico usuario de Internet solo IPv6 sí existe de verdad :) Excelente ingeniería de redes
  Antes necesité algo parecido para el objetivo contrario, que era más común: hacer cosas relacionadas con IPv6 desde una conexión solo IPv4. Si tienes control total de un servidor, una solución más limitada pero rápida es usar ssh -D 1080 -N myserver para crear un proxy SOCKS5 y configurarlo en el navegador. Supongo que también se podría configurar a nivel de todo el sistema, pero me pregunto si eso rompería la conexión ssh original y haría que todo se viniera abajo

• Estoy en la misma situación. Ya van 2 semanas oyendo que “el ticket está abierto y un técnico lo revisará pronto”, y es bastante frustrante
  No sé si le dan baja prioridad porque IPv6 funciona, así que no lo ven como una caída total. En Alemania hay una ley que garantiza compensación al consumidor en estos casos, y pronto voy a verificar si esto también aplica aquí. La solución de este post tiene el problema de que varios endpoints bloquean por completo los rangos de IP de datacenters o piden varios CAPTCHA, y lo mismo pasa con los proveedores de VPN comunes. Quería arreglar la red de toda la casa, así que tenía que manejarlo en el router, y tener un dispositivo no estándar como un Ubiquiti EdgeRouter ayudó para configurar el enrutamiento de Wireguard y las reglas de NAT. No sé cómo lo habría hecho con equipos como un FritzBox. La desventaja es que el rendimiento del router no alcanza para manejar muchas conexiones, así que tendría que cambiar a IPSec con soporte de offloading por hardware

  • En realidad, FritzBox también tiene una GUI para configurar conexiones VPN bastante buena. Está pensada para conexiones entre FritzBox, pero sirve con cualquier VPN compatible. También se pueden configurar rutas estáticas IPv4/IPv6
    Lo más probable es que el mayor problema sea averiguar qué configuración de cifrado IPsec espera el otro extremo. Wireguard puede ser mucho más fácil, pero entonces puede aparecer el problema de la aceleración por hardware. Si hace falta, también puedes respaldar el archivo de configuración del FritzBox, editar el volcado para configurar manualmente el endpoint VPN, recalcular el checksum e importarlo de nuevo. AVM tiene muchas opciones de configuración a las que el usuario no puede acceder y que se pueden ajustar así, pero hacen que el acceso sea un poco difícil para no convertir el router en un ladrillo por accidente
  • No sé cómo sea la situación en Alemania, pero en Países Bajos, si usas conexión fija y móvil con el mismo ISP y se cae la conexión fija, puedes pedir datos móviles gratis hasta que se solucione la falla
    Podría ser una opción que valga la pena preguntarle al ISP

• Algo que me gusta de las reglas de la App Store de Apple es el requisito de que todas las apps funcionen en redes solo IPv6. Es una regla que existe desde hace años
  Como desarrollador, al principio sorprende un poco, pero como usuario me alegra que exista

  • Si usas la app, ¿Github también es accesible por IPv6?
  • Pero eso no significa que el servidor tenga que tener una dirección IPv6

• Si me pasara lo mismo, crearía muy fácilmente un proxy ssh con ssh -D 8080 user@hostname
  Una vez creada la conexión, basta con indicar en el navegador que use localhost:8080 como proxy SOCKS

  • Justo iba a dar el mismo consejo. Para un problema temporal es una solución mucho más simple, y también puede servir como herramienta permanente cuando necesitas un proxy
    Para usar esta función, AllowTcpForwarding debe estar habilitado en sshd_config
  • Siempre hago esto cuando uso wifi público. Sin pagar por una VPN ni tener que confiar en una VPN, hago SOCKS forwarding de todo hacia mi servidor de infomaniak

• Hay puntos en los que apagar IPv4 se complica: la mayoría de los motores de búsqueda alternativos parecen no ofrecer conectividad IPv6, y GitHub, la última vez que se revisó, no tenía IPv6 en absoluto
  Si esperas algo bueno porque es Microsoft, no deberías; más bien hay que esperar lo peor. Hace poco incluso rompieron noscript/basic (x)html en issues. Ni siquiera sé si todavía se puede crear una cuenta con un navegador noscript/basic (x)html, correo autoalojado y literales IP(v6) como mailbox@[ipv6:...]. Steam y los juegos tampoco los he revisado últimamente, pero sospecho que muchos CDN/servidores de juegos, o una parte considerable, siguen siendo solo IPv4. Muchos servidores de correo también bloquean servidores de correo autoalojados y suelen usar listas de bloqueo torpes e inadecuadas creadas por empresas dudosas de Suiza y Andorra, como Spamhaus. Además, muchas aplicaciones de red no aprovechan las ventajas de IPv6. Por ejemplo, las aplicaciones cliente-servidor como la web deberían usar una dirección IPv6 generada aleatoriamente para cada sesión, siempre que el ISP no entregue un prefijo demasiado pequeño. Los ISP móviles con IPv6 parecen asignar direcciones IPv6/128 arbitrarias dentro del prefijo, pero deberían ofrecer un prefijo estable, quizá de unos 96 bits, para que las aplicaciones del dispositivo puedan elegir una dirección IPv6 “fija” para llamadas directas de voz/video sin resolución de nombres centralizada en línea. También se necesita un nuevo servicio del sistema operativo a nivel de usuario para coordinar direcciones IPv6 entre aplicaciones de usuario. Eso sí, hay que cuidarse de la complejidad tonta que algunos proveedores y desarrolladores intentarán imponer para encerrar a usuarios y desarrolladores de apps

  • En mi mini homelab, funcionar solo con IPv6 iba bien, pero se rompió cuando por algún motivo necesité GitHub. Así que monté NAT64+NAT64
    Fue una verdadera lástima tener que hacerlo solo por GitHub. Algún día lo habría necesitado por el servidor de correo, pero como razón para necesitar NAT64 tan pronto fue bastante mala. Lo veo como una de las muchas desventajas de que la gente use GitHub como medio de distribución de software
  • Hace unos meses tuve que pelearme con Spamhaus. Por alguna razón, la dirección IPv6 de mi VPS terminó en la lista de bloqueo de Spamhaus
    No tengo ni idea de por qué pasó. Esa máquina no ejecuta nada capaz de enviar correo y, hasta donde sé, Digital Ocean también bloquea SMTP, así que era literalmente imposible que esa máquina enviara emails. Spamhaus no ayudó en absoluto a resolverlo, y DO tampoco
  • Por el problema de que muchos CDN/servidores de juegos siguen siendo solo IPv4, hice un proxy DNS. Agrega los registros AAAA correctos para esos dominios
    https://gitlab.com/miyurusankalpa/IPv6-dns-server
  • Puedo confirmar que Steam necesita IPv4. Algunos juegos que requieren autenticación para jugar también
  • Salvo en casos donde hay descuento por operar solo con IPv6, como en servicios VPS, parece que todavía nadie considera seriamente abandonar IPv4
    En la práctica, lo más probable es que sigamos teniendo conectividad IPv4 de alguna forma, solo que cada vez es más probable que sea a través de CGNAT. GitHub me molesta especialmente. Hicieron pruebas durante algunas semanas y todo parecía funcionar bien, pero luego volvieron a ser solo IPv4. Los servidores de correo, de todos modos, viven en un mundo de hace 10 o 20 años. Incluso desactivar soporte para SSL 3.0 o TLS 1.0 en servidores de correo es difícil sin arriesgar la entregabilidad. El soporte y los filtros de spam de Microsoft Outlook ni siquiera parecen reconocer servidores de correo con IPv6, aunque al ver los encabezados parece que internamente usan IPv6 desde hace mucho tiempo. Me gustaría que IPv6 se aprovechara más, pero el miedo a que funcione un poco peor para una minoría de clientes parece congelar cualquier intento de usar realmente la tecnología. La razón por la que se ven comportamientos extraños de IP en operadores móviles probablemente tenga mucho que ver con cómo funciona IP en redes móviles. Si vas hablando por una autopista o sentado en un tren de alta velocidad, el teléfono está haciendo handovers constantemente, y la dirección IP necesita cierto nivel de estabilidad. Incluso al cruzar una frontera y cambiar a una red extranjera, toda la pila debe mantener una conexión sin cortes. Dentro de las redes celulares hay sistemas de enrutamiento especiales, y algunos aprovechan muy bien funciones de IPv6, pero eso dificulta entregar al teléfono una dirección unicast global estática “normal”. Intentan que parezca lo más normal posible, pero no es fácil lograr esa estabilidad como en una conexión doméstica cableada

• En el trabajo operamos algunas VPN solo IPv6 para acceder a infraestructura interna
  Hasta ahora, el mayor problema es que los clientes de Windows y macOS necesitan un servidor DNS IPv6. Si no, ni siquiera intentan resolver v6onlyhost.vpn.example.com. Como el cliente puede estar o no en una red con IPv6, tenemos que operar un servidor DNS dentro de la VPN e inyectárselo al cliente, pero si después de que se corta la VPN la app de Wireguard por alguna razón no revierte el DNS a su estado anterior, pueden aparecer todo tipo de problemas

  • Aunque usaba una red solo IPv4 del ISP, macOS podía hacer conexiones solo IPv6 sin ese servidor DNS
    Ya no recuerdo los detalles, pero cuando lo investigué hace unos años, macOS funcionaba bien así siempre que tuviera una dirección IPv6. Basta con asignar una dirección ULA al host. Claro, eso supone que el usuario sabe hacerlo. Según la aplicación de VPN, también se podría agregar un script que añada una ULA al entrar a una red solo IPv6. Eso sí, si se deja una ULA falsa de forma permanente, puede causar problemas cuando el usuario se mueva a una red con IPv6
  • Esto no es un problema de Windows. También tuve problemas similares en hotspots aleatorios, aunque no en todos. Creo que se debe a hotspots tontos que no devuelven registros AAAA cuando IPv6 está desactivado

• Incluso después de tanto tiempo, todavía no veo una razón convincente para pasarme varios días arrancándome los pelos intentando cambiar todas mis máquinas y mi homelab a IPv6
  Las reglas de port forwarding y firewall me resultan más intuitivas que pasar semanas solucionando problemas, reconfigurando el firewall y renumerando direcciones de red. ¿Qué me estoy perdiendo?

  • Lo que te estás perdiendo es que no es tan difícil como parece. Si no tienes una red doméstica muy compleja, configurar IPv6 debería tomar, como mucho, una tarde
    En mi red, con Comcast como ISP, basta con activar IPv6 en el router para que reciba un prefijo del ISP y lo anuncie localmente, y luego agregar una regla de firewall para aquello que quieras hacer accesible desde afuera
  • No te estás perdiendo nada. En entornos empresariales, los beneficios de adoptar IPv6 no superan las desventajas
    Administro unas 3500 dispositivos, 7 edificios, dos WAN de 10 gigas y una WAN de 4 gigas, y usamos unas 26 direcciones IPv4 públicas más NAT. Aun así, no hay una razón fuerte para adoptar IPv6. Una configuración dual-stack solo agrega tráfico y complejidad innecesarios sin mucho beneficio. Incluso hoy es difícil obtener un bloque de direcciones IPv6 estáticas; lo solicitamos dos veces y nos lo rechazaron. No solo hay poco margen de mejora, sino que conseguir un bloque sigue siendo difícil. Los requisitos de elegibilidad de https://www.arin.net/resources/guide/ipv6/first_request/ también son cosas como tener una asignación IPv4, planear multihoming IPv6 inmediato, contar con 13 sitios finales en un año, usar 2,000 direcciones IPv6 en un año o usar 200 subredes /64 en un año
  • Por ahora no te estás perdiendo gran cosa. Algún día, grandes empresas como Google o Cloudflare podrían cansarse del costo cada vez mayor de las direcciones IPv4 e incentivar IPv6. Por ejemplo, podrían empezar a limitar IPv4
    Ya hay señales tempranas. AWS antes cobraba solo por direcciones Elastic IP IPv4 no utilizadas, pero ahora cobra sin importar si se usan o no. Sinceramente, basta con dejarlo preparado la próxima vez que actualices el gateway o el router; no te estás perdiendo nada urgente ahora. También puedes usar IPv4 e IPv6 al mismo tiempo. Si lo activas en el router, los dispositivos solo IPv4 seguirán funcionando bien. Una cosa a tener en cuenta es que el autodescubrimiento de IPv6 en su momento era bastante caótico. Existían SLAAC, la autoconfiguración de direcciones IPv6 y DHCPv6, y originalmente la autoconfiguración ni siquiera admitía obtener servidores DNS. Ahora se está consolidando en torno a SLAAC, pero los ISP seguirán usando DHCPv6 durante muchísimo tiempo