IPv4 vs IPv6: diferencias y cómo configurar doble pila

IPv4 e IPv6 son las dos versiones del protocolo que identifica y enruta cada equipo en Internet. IPv4 sigue siendo mayoritario, pero sus direcciones están agotadas desde hace años, mientras que IPv6 ya transporta una parte muy importante del tráfico de los usuarios. En esta guía verás en qué se diferencian, cuándo tiene sentido usar cada uno y cómo dejar un servidor Ubuntu 24.04 funcionando en doble pila, respondiendo por las dos versiones.

Resumen rápido

Espacio de direcciones y por qué importa

IANA entregó los últimos bloques IPv4 a los registros regionales en 2011, y RIPE NCC (Europa) y ARIN (Norteamérica) agotaron sus reservas libres en 2019 y 2015. Hoy una dirección IPv4 se consigue por transferencia en el mercado secundario, con un precio que se repercute en el coste de cada servidor, y los operadores móviles y domésticos reparten una misma IPv4 entre muchos clientes con CGNAT.

Con IPv6, a una red se le asigna normalmente un /64 completo (18 trillones de direcciones) y a un cliente o sitio un /48 o un /56. La escasez desaparece y con ella la necesidad de NAT.

En cuanto a adopción, las estadísticas públicas de Google muestran que alrededor de la mitad de los usuarios que acceden a sus servicios lo hacen ya por IPv6, con países muy por encima de esa media y otros muy por debajo. Una parte importante de las redes móviles funciona solo con IPv6 internamente y traduce a IPv4 con NAT64 o 464XLAT.

Rendimiento

A igualdad de ruta, IPv4 e IPv6 rinden prácticamente igual. La cabecera IPv6 es más grande (40 bytes frente a 20) pero más simple de procesar. Las diferencias reales de latencia vienen de:

• Rutas distintas: la red IPv6 de un operador puede seguir un camino diferente al de IPv4, a veces mejor y a veces peor.
• CGNAT: en redes donde IPv4 pasa por NAT de operador, IPv6 suele ir directo y con menos latencia.
• Happy Eyeballs (RFC 8305): navegadores y sistemas prueban IPv6 e IPv4 casi a la vez y usan el que conecta primero, así que un IPv6 roto se nota como un pequeño retraso y no como un fallo.

Seguridad

IPv6 no es más seguro ni menos seguro por diseño, pero cambia varias cosas:

• Sin NAT, el firewall es obligatorio: con IPv4 muchos equipos quedaban ocultos tras NAT. Con IPv6 cada equipo es alcanzable, así que la política de entrada debe ser explícita.
• No bloquees todo ICMPv6: IPv6 depende de él para NDP y para descubrir la MTU de la ruta. Si lo filtras entero, la red deja de funcionar o las conexiones se quedan colgadas con paquetes grandes.
• Doble configuración: una regla que solo existe en iptables y no en ip6tables deja el servicio expuesto por IPv6. Herramientas como UFW o nftables con la familia inet aplican la misma regla a ambos protocolos.
• Escaneo: recorrer un /64 completo no es viable, pero las direcciones fáciles (::1, ::10) y las publicadas en DNS se descubren igual.

Cuándo usar cada uno

Solo IPv4 sigue siendo lo habitual en redes internas pequeñas y equipos heredados sin soporte IPv6. Para un servidor público ya no es la opción recomendada.

Solo IPv6 tiene sentido en redes internas nuevas, clústeres de Kubernetes, redes móviles y servidores que solo hablan con otros sistemas IPv6. Un servicio público solo IPv6 dejaría fuera a los usuarios que todavía no lo tienen.

Doble pila (IPv4 e IPv6 a la vez) es la opción recomendada para cualquier servicio público: llegas a todos los usuarios y los que tienen IPv6 lo usan directamente. El resto de la guía configura esto.

Requisitos previos

Para configurar la doble pila necesitas:

• Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath, con una dirección IPv4 y una dirección o prefijo IPv6 asignados por tu proveedor, junto con sus puertas de enlace.
• Un usuario no root con privilegios sudo.
• Un dominio cuyo DNS puedas editar, si quieres publicar el servicio por nombre.
• Nginx instalado (sudo apt install nginx) para el paso 3.

Paso 1: Comprobar si ya tienes IPv6

Muchos servidores reciben IPv6 automáticamente por SLAAC o cloud-init. Revisa las direcciones de la interfaz:

ip -6 addr show scope global

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2001:db8:10::10/64 scope global
       valid_lft forever preferred_lft forever

Comprueba que hay una ruta por defecto IPv6:

ip -6 route show default

default via 2001:db8:10::1 dev eth0 proto static metric 1024 pref medium

Si ya aparecen una dirección global y una ruta por defecto, salta al paso 2. Las direcciones que empiezan por fe80:: son de enlace local y no sirven para salir a Internet.

Configurar IPv6 con Netplan

Si falta la dirección, configúrala con Netplan. Primero mira qué archivos existen y el nombre de tu interfaz:

ls /etc/netplan/
ip -br link

En servidores creados con cloud-init, la red suele estar en /etc/netplan/50-cloud-init.yaml y cloud-init puede regenerarla. En ese caso crea /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg con el contenido network: {config: disabled} antes de editarla. Abre el archivo:

sudo nano /etc/netplan/50-cloud-init.yaml

Un ejemplo de configuración estática en doble pila, sustituyendo las direcciones de documentación por las tuyas:

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 203.0.113.10/24
        - 2001:db8:10::10/64
      routes:
        - to: default
          via: 203.0.113.1
        - to: default
          via: 2001:db8:10::1
      nameservers:
        addresses:
          - 1.1.1.1
          - 2606:4700:4700::1111

Aplica los cambios con netplan try, que revierte automáticamente a los 120 segundos si pierdes la conexión y no confirmas:

sudo netplan try

Pulsa Enter para confirmar si la sesión SSH sigue respondiendo.

Paso 2: Verificar la conectividad IPv6

Comprueba que el servidor alcanza Internet por IPv6:

ping -6 -c 4 2606:4700:4700::1111

4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.021/1.110/1.244/0.083 ms

Comprueba también la resolución de nombres y la dirección pública con la que sales:

curl -6 https://ifconfig.co

2001:db8:10::10

Si ping funciona pero curl falla con un nombre de dominio, el problema está en el DNS y no en la conectividad.

Paso 3: Hacer que los servicios escuchen en IPv6

Cada servicio debe escuchar también en IPv6. En Nginx, cada bloque server necesita una directiva listen por protocolo. Edita tu sitio, por ejemplo /etc/nginx/sites-available/default:

server {
    listen 80;
    listen [::]:80;
    server_name your_domain;
    root /var/www/html;
}

Valida y recarga:

sudo nginx -t
sudo systemctl reload nginx

Comprueba qué servicios escuchan en IPv6:

sudo ss -ltnp -6

State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      511             [::]:80           [::]:*    users:(("nginx",pid=1235,fd=7))
LISTEN 0      4096            [::]:22           [::]:*    users:(("sshd",pid=801,fd=4))

OpenSSH escucha en IPv4 e IPv6 por defecto. Para otros servicios revisa su opción de escucha: por ejemplo, en PostgreSQL listen_addresses = '*' incluye ambos protocolos.

Cuando uses una dirección IPv6 literal en una URL, ponla entre corchetes: http://[2001:db8:10::10]:8080/.

Paso 4: Aplicar el firewall a ambos protocolos

UFW gestiona IPv4 e IPv6 a la vez siempre que IPV6=yes esté en /etc/default/ufw, que es el valor por defecto en Ubuntu:

grep IPV6 /etc/default/ufw

IPV6=yes

Abre SSH y HTTP y activa el firewall:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx Full                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx Full (v6)            ALLOW       Anywhere (v6)

Las reglas marcadas con (v6) confirman que se aplican también a IPv6. UFW permite por defecto el ICMPv6 necesario para NDP y el descubrimiento de MTU, así que no hace falta añadir reglas para ello.

Paso 5: Publicar el registro AAAA

En el panel de tu proveedor de DNS, añade un registro AAAA para your_domain con la dirección IPv6 del servidor, junto al registro A existente. Cuando se propague, compruébalo:

dig +short AAAA your_domain

2001:db8:10::10

Y prueba el servicio desde fuera forzando cada protocolo:

curl -4 -I http://your_domain
curl -6 -I http://your_domain

Ambos deben devolver HTTP/1.1 200 OK. Publica el registro AAAA solo cuando el servicio funcione por IPv6: si el DNS anuncia una dirección que no responde, los clientes con IPv6 sufrirán retrasos o errores.

Solución de problemas

• Hay dirección global pero no hay salida: falta la ruta por defecto IPv6 o la puerta de enlace es incorrecta. Revisa ip -6 route y la sección routes de Netplan.
• Conexiones que se abren pero se cuelgan con respuestas grandes: algo en la ruta filtra ICMPv6 "Packet Too Big". Revisa reglas propias de ip6tables o nftables.
• El sitio funciona por IPv4 pero no por IPv6: falta listen [::]:80 en algún bloque server, o el registro AAAA apunta a otra dirección.
• La configuración de Netplan desaparece tras reiniciar: cloud-init la regenera. Desactiva su gestión de red como se indica en el paso 1.

Conclusión

IPv4 seguirá siendo necesario durante años, pero IPv6 ya no es opcional para un servicio público: una parte muy grande de los usuarios llega por él y evita el CGNAT de su operador. La doble pila es la opción práctica: mismos servicios, el mismo firewall para ambos protocolos y registros A y AAAA en el DNS. Como siguientes pasos, emite certificados TLS con Certbot (valida por los dos protocolos), revisa que tus logs y límites por IP manejan direcciones IPv6 y monitoriza la disponibilidad del servicio por ambas vías.