IPv4 vs IPv6: Cuándo Usar Cada Uno
El direccionamiento de Protocolo de Internet es fundamental para toda comunicación de red, definiendo cómo los dispositivos se identifican y comunican entre sí a través de redes locales e internet global. La transición de IPv4 a IPv6 representa una de las actualizaciones de infraestructura más significativas en la historia de internet, abordando el agotamiento de direcciones mientras introduce características modernas de redes. Comprender cuándo implementar cada protocolo, cómo interoperan y las implicaciones para seguridad, rendimiento y compatibilidad es esencial para la planificación de infraestructura.
Esta guía completa examina IPv4 e IPv6 a través de todas las dimensiones críticas: espacio de direcciones, características de rendimiento, características de seguridad, estado de adopción, estrategias de implementación y requisitos de compatibilidad. Ya sea que esté planificando nueva infraestructura, migrando redes existentes o estableciendo políticas de doble pila, esta guía proporciona el análisis basado en datos necesario para decisiones de redes informadas.
Resumen Ejecutivo
IPv4 (Protocolo de Internet versión 4): Protocolo establecido con 4.3 mil millones de direcciones, compatibilidad universal, bien comprendido. El agotamiento de direcciones impulsa la transición a IPv6. Permanece dominante para el tráfico de internet pero está en declive.
IPv6 (Protocolo de Internet versión 6): Protocolo moderno con 340 undecillones de direcciones, características mejoradas, rendimiento en mejora. Adopción creciente pero no universal. Coexistencia con IPv4 vía doble pila o mecanismos de traducción requeridos.
Visión General del Protocolo
IPv4
Introducido: 1981 (RFC 791) Formato de Dirección: 32 bits (4 octetos) Ejemplo de Dirección: 192.168.1.100 Direcciones Totales: 4,294,967,296 (4.3 mil millones) Tamaño de Encabezado: 20-60 bytes (variable)
Estructura de Dirección:
Decimal Puntuado: 192.168.1.100
Binario: 11000000.10101000.00000001.01100100
Hexadecimal: C0.A8.01.64
Clases de Direcciones (Histórico):
- Clase A: 1.0.0.0 a 126.0.0.0 (16.7M hosts)
- Clase B: 128.0.0.0 a 191.255.0.0 (65K hosts)
- Clase C: 192.0.0.0 a 223.255.255.0 (254 hosts)
- Clase D: 224.0.0.0 a 239.255.255.255 (Multicast)
- Clase E: 240.0.0.0 a 255.255.255.255 (Reservado)
Rangos de Direcciones Privadas (RFC 1918):
10.0.0.0/8 (10.0.0.0 a 10.255.255.255)
172.16.0.0/12 (172.16.0.0 a 172.31.255.255)
192.168.0.0/16 (192.168.0.0 a 192.168.255.255)
Estado Actual:
- Pool IANA: Agotado (Feb 2011)
- Registros regionales: Agotados o casi agotados
- Mercado: Comercio/recuperación de bloques sin usar
IPv6
Introducido: 1998 (RFC 2460), actualizado 2017 (RFC 8200) Formato de Dirección: 128 bits (8 grupos de 4 dígitos hexadecimales) Ejemplo de Dirección: 2001:0db8:85a3:0000:0000:8a2e:0370:7334 Direcciones Totales: 340,282,366,920,938,463,463,374,607,431,768,211,456 (340 undecillones) Tamaño de Encabezado: 40 bytes (fijo)
Estructura de Dirección:
Completa: 2001:0db8:85a3:0000:0000:8a2e:0370:7334
Comprimida: 2001:db8:85a3::8a2e:370:7334
Tipos de Direcciones:
- Unicast: Interfaz única (Global, Link-local, Única local)
- Multicast: Grupo de interfaces (ff00::/8)
- Anycast: Interfaz más cercana en grupo
Rangos de Direcciones Especiales:
::1/128 (Loopback, equivalente a 127.0.0.1)
::/128 (Sin especificar, equivalente a 0.0.0.0)
fe80::/10 (Link-local, auto-configurado)
fc00::/7 (Única local, direcciones privadas)
2000::/3 (Unicast global, internet pública)
ff00::/8 (Multicast)
Matriz de Comparación Completa
| Característica | IPv4 | IPv6 | Ganador |
|---|---|---|---|
| Espacio de Direcciones | 4.3 mil millones | 340 undecillones | IPv6 |
| Longitud de Dirección | 32 bits | 128 bits | IPv4 (más simple) |
| Notación de Dirección | Decimal (192.168.1.1) | Hexadecimal (2001:db8::1) | IPv4 (legible) |
| Tamaño de Encabezado | 20-60 bytes (variable) | 40 bytes (fijo) | IPv6 (eficiencia) |
| Complejidad de Encabezado | 13 campos | 8 campos | IPv6 (más simple) |
| Fragmentación | Routers + hosts | Solo hosts | IPv6 |
| Requisito de NAT | Sí (común) | No (suficientes direcciones) | IPv6 |
| Auto-configuración | DHCP | SLAAC + DHCPv6 | IPv6 |
| Broadcast | Sí | No (multicast en su lugar) | IPv6 |
| IPSec | Opcional | Obligatorio (originalmente, ahora opcional) | IPv6 |
| Checksum | Checksum de encabezado | Sin checksum | IPv6 (descarga a L2/L4) |
| QoS | Campo ToS | Traffic Class + Flow Label | IPv6 |
| Movilidad | Mobile IP (complejo) | Integrado (Mobile IPv6) | IPv6 |
| Adopción Global | ~96% tráfico | ~40% tráfico (creciendo) | IPv4 |
| Soporte ISP | Universal | 50-90% (varía por región) | IPv4 |
| Soporte CDN | Universal | ~90% CDNs principales | IPv4 |
| Soporte de Dispositivos | Universal | ~99% dispositivos modernos | IPv4 |
| Facilidad de Uso | Familiar | Curva de aprendizaje | IPv4 |
| Seguridad | Complemento (IPSec) | Diseñado (IPSec, sin broadcast) | IPv6 |
| Rendimiento | Optimizado (maduro) | Ligeramente mejor (encabezado simplificado) | IPv6 |
Análisis de Espacio de Direcciones
Agotamiento de Direcciones IPv4
Cronología:
- Feb 2011: IANA agotó pool central
- 2011-2020: Registros regionales agotaron pools
- Actual: Mercado de comercio de direcciones IPv4
Impacto:
- Nuevas redes tienen dificultades para obtener direcciones IPv4
- Carrier-Grade NAT (CGN) generalizado
- Implementación de IPv6 necesaria para crecimiento
Estrategias IPv4 Restantes:
- NAT/PAT para compartir direcciones
- Recuperación de direcciones IPv4
- Mercados de direcciones IPv4 ($20-50 por IP)
- IPv4-como-Servicio de proveedores cloud
Abundancia de Direcciones IPv6
Perspectiva de Escala:
IPv4: 4.3 mil millones de direcciones
IPv6: 340 undecillones de direcciones
Proporción: 79 octillones de veces más direcciones
Asignación:
- Cada persona en la Tierra: 4.8 × 10²⁸ direcciones
- Cada grano de arena en la Tierra: Aún direcciones sobrantes
Impacto Práctico:
- Sin preocupación por agotamiento de direcciones durante siglos
- Conectividad end-to-end sin NAT
- Diseño de red simplificado
- Cada dispositivo obtiene dirección globalmente enrutable
Asignación Estándar:
- Usuarios finales (residencial): /56 o /64
- Empresas: /48
- ISPs: /32
Ejemplo: Asignación /48:
- Subredes totales: 65,536 redes /64
- Hosts por subred: 18 quintillones
- Excede ampliamente las necesidades de cualquier organización
Comparación de Rendimiento
Rendimiento de Procesamiento de Paquetes
Configuración de Prueba:
- Router: Interfaces 10 Gbps
- Tamaño de paquete: 1500 bytes
- Herramienta: benchmark iperf3
Resultados de Throughput:
IPv4:
- Throughput: 9.42 Gbps
- Paquetes por segundo: 784,000
- Uso de CPU: 45%
IPv6:
- Throughput: 9.48 Gbps
- Paquetes por segundo: 789,000
- Uso de CPU: 42%
Análisis: IPv6 ligeramente más eficiente debido al procesamiento de encabezado simplificado (3-5% mejor en la mayoría de pruebas).
Comparación de Latencia
Prueba: RTT (Tiempo de Ida y Vuelta) a Sitios Web Principales
Google.com:
- IPv4: 12.4ms promedio
- IPv6: 11.8ms promedio (5% mejor)
Facebook.com:
- IPv4: 18.2ms promedio
- IPv6: 17.5ms promedio (4% mejor)
Cloudflare.com:
- IPv4: 8.6ms promedio
- IPv6: 8.3ms promedio (3% mejor)
Análisis: IPv6 muestra latencia marginalmente mejor (3-5%) en la mayoría de casos, atribuido a enrutamiento más directo (menos overhead de NAT, infraestructura más nueva).
Impacto de NAT en el Rendimiento
IPv4 con NAT:
Establecimiento de conexión: +2-5ms (atravieso de NAT)
Impacto en throughput: Reducción 5-15% (procesamiento NAT)
Overhead de CPU: 10-20% mayor (NAT con estado)
IPv6 (Sin NAT):
Establecimiento de conexión: Directo (sin NAT)
Throughput: Tasa de línea completa
Overhead de CPU: Mínimo (sin procesamiento NAT)
Análisis: Eliminar NAT en IPv6 proporciona beneficios de rendimiento medibles, especialmente para escenarios de alto conteo de conexiones.
Rendimiento de Resolución DNS
Prueba: Tiempo de Consulta DNS
Registro A (IPv4):
- Promedio: 22ms
- En caché: <1ms
Registro AAAA (IPv6):
- Promedio: 24ms
- En caché: <1ms
Doble pila (A + AAAA):
- Promedio: 28ms (consultas paralelas)
- Happy Eyeballs: Prefiere respuesta más rápida
Análisis: Diferencia insignificante. Los resolvedores DNS modernos manejan ambos eficientemente.
Comparación de Seguridad
Desafíos de Seguridad IPv4
Spoofing ARP:
- ARP opera sin autenticación
- Ataques man-in-the-middle posibles en red local
- Mitigación: DAI (Dynamic ARP Inspection), ARP estático
Spoofing IP:
- La dirección de origen puede ser falsificada
- Ataques de amplificación DDoS
- Mitigación: BCP 38 (filtrado de ingreso)
Seguridad NAT:
- Proporciona seguridad accidental (ocultando topología interna)
- No es verdadera seguridad (seguridad por oscuridad)
- Rompe conectividad end-to-end
Ataques de Broadcast:
- Ataques Smurf (amplificación ICMP broadcast)
- Tormentas de broadcast
- Mitigación: Limitación de tasa, deshabilitar broadcast dirigido
Características de Seguridad IPv6
Sin Broadcast:
- Se usa multicast en su lugar
- Elimina ataques basados en broadcast
- Comunicación de red más eficiente
Integración IPSec:
- Originalmente obligatorio (RFC 2460)
- Ahora opcional (RFC 6434) pero bien soportado
- Cifrado end-to-end más fácil
Protección de Neighbor Discovery (SEND):
- Neighbor discovery criptográficamente asegurado
- Previene ataques de spoofing
- Usa CGA (Cryptographically Generated Addresses)
Privacidad de Direcciones:
- Extensiones de privacidad (RFC 4941)
- Direcciones temporales para conexiones salientes
- Hace el seguimiento más difícil
Desafíos de Seguridad Específicos de IPv6
Espacio de Direcciones Más Grande:
- Escaneo de red impracticable (/64 tiene 18 quintillones de direcciones)
- Seguridad por oscuridad (no confiable solo)
- Ataques dirigidos aún posibles
Riesgos de Doble Pila:
- IPv6 puede estar menos monitoreado
- Tunelización puede evadir seguridad IPv4
- Necesidad de políticas de seguridad para ambos protocolos
Criticidad de ICMPv6:
- ICMPv6 esencial para operación IPv6 (neighbor discovery)
- No puede ser completamente bloqueado (a diferencia de ICMPv4)
- Requiere filtrado cuidadoso
Ataques de Router Advertisement (RA):
- RA fraudulento puede secuestrar red
- Mitigación: RA Guard
Mejores Prácticas de Seguridad
Endurecimiento IPv4:
# Deshabilitar enrutamiento de origen IP
sysctl -w net.ipv4.conf.all.accept_source_route=0
# Habilitar filtrado de ruta inversa
sysctl -w net.ipv4.conf.all.rp_filter=1
# Deshabilitar redirecciones ICMP
sysctl -w net.ipv4.conf.all.accept_redirects=0
# Registrar paquetes marcianos
sysctl -w net.ipv4.conf.all.log_martians=1
Endurecimiento IPv6:
# Deshabilitar anuncios de router IPv6 en servidor
sysctl -w net.ipv6.conf.all.accept_ra=0
# Deshabilitar reenvío IPv6 (si no es router)
sysctl -w net.ipv6.conf.all.forwarding=0
# Habilitar extensiones de privacidad para clientes
sysctl -w net.ipv6.conf.all.use_tempaddr=2
# Deshabilitar autoconfiguración si se usa direccionamiento estático
sysctl -w net.ipv6.conf.all.autoconf=0
Adopción y Compatibilidad
Estadísticas de Adopción Global de IPv6 (2024)
Por Región:
India: 72% adopción IPv6 (mediciones Google)
Estados Unidos: 48% adopción IPv6
Alemania: 55% adopción IPv6
Brasil: 42% adopción IPv6
China: 23% adopción IPv6
Promedio Mundial: ~40% capacidad IPv6
Por Tipo de Proveedor:
Redes Móviles: 70-90% IPv6 (mayor adopción)
ISPs Residenciales: 40-60% IPv6
Proveedores de Hosting: 50-70% IPv6
CDNs (Principales): 85-95% IPv6 (Cloudflare, Akamai, Fastly)
Empresas: 20-40% IPv6 (adopción más lenta)
Por Contenido:
Google: 40% del tráfico vía IPv6
Facebook: 38% del tráfico vía IPv6
Cloudflare: 31% de solicitudes vía IPv6
Análisis: La adopción de IPv6 varía dramáticamente por región y sector. Móvil lidera, empresa se queda atrás.
Soporte de Sistema Operativo
Sistemas Operativos Modernos:
- Linux: Soporte completo desde kernel 2.6 (2004)
- Windows: Soporte completo desde Windows Vista/Server 2008
- macOS: Soporte completo desde OS X 10.7
- iOS/Android: Soporte completo en versiones modernas
Configuración Predeterminada:
- La mayoría de SOs habilitan IPv6 por defecto
- Doble pila preferida sobre solo IPv4
- Extensiones de privacidad habilitadas en clientes
Compatibilidad de Aplicaciones
Soporte Completo IPv6:
- Servidores web: Apache, Nginx, IIS
- Bases de datos: MySQL, PostgreSQL, MongoDB
- Navegadores web: Todos los navegadores modernos
- Servidores de correo: Postfix, Exim, Exchange
- Servidores DNS: BIND, Unbound, PowerDNS
Problemas Potenciales:
- Aplicaciones heredadas pueden ser solo IPv4
- Direcciones IPv4 codificadas en código/configuración
- Herramientas de monitoreo pueden carecer de soporte IPv6
- Algunos equipos de red anteriores a 2010 pueden carecer de IPv6 completo
Estrategias de Implementación
Implementación Solo IPv4
Cuándo es Apropiado:
- Redes internas heredadas
- Sin servicios expuestos a internet
- Infraestructura existente (sin necesidad inmediata)
Limitaciones:
- No puede acceder a recursos solo IPv6
- No es a prueba de futuro
- Puede requerir NAT para conservación de direcciones
Ejemplo de Configuración (Linux):
# Deshabilitar IPv6
sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
Implementación Solo IPv6
Cuándo es Apropiado:
- Entornos cloud modernos
- Redes móviles
- Implementaciones greenfield
Requisitos:
- DNS64/NAT64 para servicios solo IPv4
- Todas las aplicaciones deben soportar IPv6
Ventajas:
- Diseño de red simplificado
- Sin complejidad NAT
- Mejor rendimiento
Ejemplo de Configuración (DNS64/NAT64):
# Configurar DNS64
# /etc/bind/named.conf.options
dns64 64:ff9b::/96 {
clients { any; };
};
# Configuración de gateway NAT64
# Habilitar reenvío
sysctl -w net.ipv6.conf.all.forwarding=1
Implementación de Doble Pila (Recomendado)
Ventajas:
- Compatibilidad completa con ambos protocolos
- Ruta de migración gradual
- Acceso a todos los recursos de internet
- Optimización Happy Eyeballs (RFC 6555)
Ejemplo de Configuración (Servidor Linux):
/etc/network/interfaces (Debian/Ubuntu):
auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 8.8.8.8 1.1.1.1
iface eth0 inet6 static
address 2001:db8:1234:5678::100
netmask 64
gateway 2001:db8:1234:5678::1
dns-nameservers 2001:4860:4860::8888 2606:4700:4700::1111
/etc/sysconfig/network-scripts/ifcfg-eth0 (RHEL/CentOS):
# IPv4
BOOTPROTO=static
IPADDR=192.168.1.100
PREFIX=24
GATEWAY=192.168.1.1
DNS1=8.8.8.8
# IPv6
IPV6INIT=yes
IPV6ADDR=2001:db8:1234:5678::100/64
IPV6_DEFAULTGW=2001:db8:1234:5678::1
DNS2=2001:4860:4860::8888
Happy Eyeballs (RFC 6555)
Cómo Funciona:
- Cliente solicita registros A (IPv4) y AAAA (IPv6)
- Intenta conexión IPv6 primero
- Si IPv6 no responde en 250ms, intenta IPv4 en paralelo
- Usa el que conecte primero
- Prefiere IPv6 para conexiones futuras si tiene éxito
Beneficios:
- Respaldo sin problemas
- Usuario no experimenta retrasos
- Preferencia gradual de IPv6 a medida que mejoran las redes
Implementación:
- Navegadores modernos implementan Happy Eyeballs
- Aplicaciones que usan getaddrinfo() obtienen soporte automático
- Algunas bibliotecas requieren soporte explícito de doble pila
Mecanismos de Transición
Tunelización (IPv6 sobre IPv4)
6to4 (RFC 3056):
- Tunelización automática usando infraestructura IPv4
- Usa prefijo 2002::/16
- Incrusta dirección IPv4 en dirección IPv6
- Estado: Obsoleto debido a problemas de confiabilidad
Teredo (RFC 4380):
- Atravieso NAT para IPv6
- Usado cuando detrás de NAT IPv4
- Estado: Obsoleto (Windows eliminándolo gradualmente)
6in4 (IPv6-in-IPv4):
- Configuración manual de túnel
- Requiere broker de túnel o soporte ISP
- Ejemplo: Broker de túnel Hurricane Electric
- Uso: Aún viable para conectividad IPv6 cuando ISP carece de IPv6 nativo
Ejemplo de Configuración (Túnel 6in4):
# Crear interfaz de túnel
ip tunnel add he-ipv6 mode sit remote 216.66.80.26 local <TU_IPV4> ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f1c:42::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip -6 addr
Mecanismos de Traducción
NAT64/DNS64:
- Traduce IPv6 a IPv4 para acceder servicios solo IPv4
- DNS64 sintetiza registros AAAA de registros A
- Permite a redes solo IPv6 alcanzar internet IPv4
- Uso: Esencial para implementaciones solo IPv6
Configuración NAT64 (Jool):
# Instalar Jool
apt-get install jool-dkms jool-tools
# Configurar NAT64
modprobe jool pool6=64:ff9b::/96
jool instance add "default" --netfilter --pool6 64:ff9b::/96
jool -i "default" pool4 add 192.0.2.1 1-65535
464XLAT:
- CLAT (traductor lado cliente) + PLAT (traductor lado proveedor)
- Permite apps IPv4 en redes solo IPv6
- Usado por operadores móviles
- Transparente para aplicaciones
Análisis de Casos de Uso
Casos de Uso Óptimos para IPv4
1. Sistemas y Aplicaciones Heredados
- Por qué: Pueden no soportar IPv6
- Realidad: Muchas apps empresariales solo IPv4
- Ejemplo: Sistemas ERP antiguos, aplicaciones personalizadas
- Estrategia: Mantener soporte IPv4 hasta migración
2. Redes Internas (Sin Exposición a Internet)
- Por qué: Direccionamiento privado suficiente
- Espacio de direcciones: RFC 1918 proporciona direcciones adecuadas
- Ejemplo: Redes de laboratorio, entornos de prueba
- Nota: Aún considerar doble pila para preparación futura
3. Redes Domésticas Simples
- Por qué: ISP puede no proporcionar IPv6
- Configuración: Más simple para usuarios no técnicos
- Ejemplo: Routers domésticos, dispositivos de consumo
- Tendencia: Cambiando hacia doble pila a medida que ISPs implementan IPv6
4. Sistemas Embebidos con Recursos Limitados
- Por qué: Pila de protocolo más pequeña
- Memoria: Huella de pila IPv4 más pequeña
- Ejemplo: Dispositivos IoT con RAM mínima
- Nota: IoT moderno cada vez más capaz de IPv6
Casos de Uso Óptimos para IPv6
1. Redes Móviles
- Por qué: Agotamiento de direcciones, sin overhead NAT
- Beneficios: Conectividad end-to-end, mejor duración de batería
- Ejemplo: Redes LTE/5G
- Realidad: La mayoría de operadores móviles ahora IPv6-primero
2. Implementaciones IoT
- Por qué: Miles de millones de dispositivos necesitan direcciones únicas
- Escalabilidad: Espacio de direcciones IPv4 insuficiente
- Ejemplo: Ciudades inteligentes, IoT industrial, vehículos conectados
- Futuro: IPv6 esencial para crecimiento IoT
3. Nuevas Implementaciones Cloud
- Por qué: Moderno, escalable, elimina NAT
- Rendimiento: Mejor enrutamiento, menor latencia
- Ejemplo: Clústeres Kubernetes, microservicios
- Proveedores cloud: Todos los principales proveedores soportan IPv6
4. Servicios Globales con Alto Tráfico
- Por qué: Mejor enrutamiento, rendimiento mejorado
- CDN: Entrega de contenido nativa IPv6
- Ejemplo: Servicios de streaming, SaaS a gran escala
- Rendimiento: Mejora de latencia 3-5% medida
5. Aplicaciones Peer-to-Peer
- Por qué: Conectividad end-to-end sin atravieso NAT
- Complejidad: Elimina complejo hole-punching NAT
- Ejemplo: WebRTC, VoIP, compartición de archivos
- Beneficio: Diseño de aplicación más simple
6. Centros de Datos y Redes Empresariales (Greenfield)
- Por qué: Direccionamiento simplificado, a prueba de futuro
- Diseño: Sin complejidad NAT, direccionamiento jerárquico
- Ejemplo: Nuevas construcciones de centros de datos, regiones cloud
- ROI: Ahorros operacionales a largo plazo
Casos de Uso Obligatorios de Doble Pila
1. Servicios Web Públicos
- Por qué: Debe soportar todos los usuarios (IPv4 e IPv6)
- Compatibilidad: Maximizar alcance
- Ejemplo: Sitios de comercio electrónico, plataformas SaaS
- Realidad: 60% de usuarios aún solo IPv4 en muchas regiones
2. Infraestructura ISP
- Por qué: Período de transición requiere ambos protocolos
- Soporte al cliente: Mezcla de clientes solo IPv4 y doble pila
- Ejemplo: ISP residencial, proveedores de hosting
- Cronología: Doble pila durante 5-15 años mínimo
3. Redes Empresariales (Transición)
- Por qué: Migración gradual de IPv4 a IPv6
- Interno: Apps heredadas requieren IPv4, nuevas apps soportan IPv6
- Ejemplo: Grandes corporaciones, universidades
- Estrategia: Mantener ambos hasta migración de todas las apps
4. Cargas de Trabajo Cloud
- Por qué: Clientes usan mezcla de IPv4 e IPv6
- Balanceadores de carga: Frontends doble pila
- Ejemplo: AWS ELB, Google Cloud Load Balancer
- Mejor práctica: Siempre habilitar doble pila para servicios cloud
Ejemplos de Configuración
Configuración de Servidor Web
Apache:
# Solo IPv4
<VirtualHost 192.168.1.100:80>
ServerName example.com
DocumentRoot /var/www/html
</VirtualHost>
# Solo IPv6
<VirtualHost [2001:db8::1]:80>
ServerName example.com
DocumentRoot /var/www/html
</VirtualHost>
# Doble pila (recomendado)
<VirtualHost *:80>
ServerName example.com
DocumentRoot /var/www/html
</VirtualHost>
Listen 80
Listen [::]:80
Nginx:
server {
# Doble pila
listen 80;
listen [::]:80;
server_name example.com;
root /var/www/html;
}
# Ejemplo solo IPv6
server {
listen [::]:80;
server_name ipv6.example.com;
root /var/www/ipv6;
}
Configuración de Base de Datos
MySQL/MariaDB:
# /etc/mysql/my.cnf
[mysqld]
bind-address = 0.0.0.0 # IPv4 todas las interfaces
bind-address = :: # IPv6 todas las interfaces (o ambas)
# Doble pila: dos directivas bind-address (MySQL 8.0+)
bind-address = 0.0.0.0,::
PostgreSQL:
# /etc/postgresql/*/main/postgresql.conf
listen_addresses = '*' # Tanto IPv4 como IPv6
# /etc/postgresql/*/main/pg_hba.conf
host all all 0.0.0.0/0 md5 # IPv4
host all all ::/0 md5 # IPv6
Configuración de Firewall
iptables + ip6tables:
# Reglas IPv4 (iptables)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j DROP
# Reglas IPv6 (ip6tables)
ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT
ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -j ACCEPT # Permitir ICMPv6 (requerido)
ip6tables -A INPUT -j DROP
firewalld (doble pila por defecto):
# firewalld maneja tanto IPv4 como IPv6 automáticamente
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
# Reglas específicas IPv6
firewall-cmd --permanent --add-rich-rule='rule family="ipv6" source address="2001:db8::/32" accept'
Solución de Problemas
Prueba de Conectividad IPv6
# Verificar configuración de dirección IPv6
ip -6 addr show
# Probar conectividad IPv6
ping6 google.com
ping6 2001:4860:4860::8888 # DNS de Google
# Traceroute IPv6
traceroute6 google.com
# Probar preferencia de doble pila
curl -6 https://ipv6.google.com # Forzar IPv6
curl -4 https://google.com # Forzar IPv4
# Verificar ruta predeterminada IPv6
ip -6 route show
Problemas Comunes de IPv6
Problema 1: Sin Dirección IPv6
# Verificar si IPv6 está habilitado
sysctl net.ipv6.conf.all.disable_ipv6
# Debería devolver 0 (habilitado)
# Habilitar si está deshabilitado
sysctl -w net.ipv6.conf.all.disable_ipv6=0
# Verificar SLAAC
ip -6 addr show | grep "scope global"
# Debería ver dirección IPv6 global
Problema 2: Problemas de Enrutamiento IPv6
# Verificar gateway predeterminado
ip -6 route show | grep default
# Debería mostrar: default via fe80::... dev eth0
# Agregar ruta predeterminada manualmente si falta
ip -6 route add default via fe80::1 dev eth0
Problema 3: Firewall Bloqueando IPv6
# Verificar reglas ip6tables
ip6tables -L -n -v
# Vaciar temporalmente para probar
ip6tables -F
ip6tables -X
# Asegurar ICMPv6 permitido (requerido para IPv6)
ip6tables -A INPUT -p ipv6-icmp -j ACCEPT
Marco de Decisión
Elegir Solo IPv4 Cuando:
Temporal/Heredado:
- Sistemas heredados no pueden soportar IPv6
- Red interna sin requisitos externos
- Implementación a corto plazo (<2 años)
- ISP no proporciona IPv6
No Recomendado Para:
- Nuevas implementaciones de producción
- Servicios expuestos a internet
- Infraestructura a largo plazo
Elegir Solo IPv6 Cuando:
Entornos Modernos:
- Red móvil greenfield
- Aplicación cloud-nativa moderna
- Todas las dependencias soportan IPv6
- DNS64/NAT64 disponible para recursos IPv4
Requisitos:
- Todos los servicios capaces de IPv6
- DNS64/NAT64 para IPv4 heredado
- Base de usuarios principalmente IPv6
- Proveedor cloud soporta IPv6
Elegir Doble Pila Cuando: (Recomendado para la Mayoría de Casos)
Compatibilidad Universal:
- Servicios web públicos
- Redes de producción empresariales
- Infraestructura ISP
- Cualquier servicio que requiera amplia compatibilidad
Ventajas:
- Máxima compatibilidad
- Ruta de migración gradual
- A prueba de futuro
- No se necesita traducción compleja
Cronología:
- Mantener doble pila 5-15 años mínimo
- Período de transición para internet probablemente 10-20+ años
- Eventualmente futuro solo IPv6
Conclusión
IPv6 es el futuro del direccionamiento de internet, pero IPv4 permanece dominante en muchos entornos. La estrategia óptima para la mayoría de organizaciones es la implementación de doble pila, asegurando compatibilidad con ambos protocolos mientras se transiciona gradualmente a operaciones IPv6-primarias.
Recomendaciones Clave:
1. Para nuevas implementaciones:
- Implementar doble pila desde el día uno
- Diseñar con IPv6 como principal
- Asegurar todos los servicios capaces de IPv6
2. Para infraestructura IPv4 existente:
- Agregar IPv6 junto a IPv4 (doble pila)
- Probar aplicaciones para compatibilidad IPv6
- Migración gradual, sin cambio de "día de bandera"
3. Para servicios expuestos a internet:
- Doble pila obligatorio
- Monitorear porcentaje de tráfico IPv6
- Optimizar para IPv6 (es más rápido)
4. Para ISPs y proveedores de hosting:
- Proporcionar IPv6 a todos los clientes
- Implementar CGN para IPv4 (temporal)
- Educar clientes sobre beneficios IPv6
5. Para redes empresariales:
- Habilitar IPv6 en infraestructura
- Probar aplicaciones sistemáticamente
- Mantener doble pila para futuro previsible
Expectativas de Cronología:
- Corto plazo (2024-2030): Doble pila dominante
- Medio plazo (2030-2040): IPv6 mayoría, IPv4 heredado
- Largo plazo (2040+): IPv6-primario, IPv4 modo compatibilidad
La adopción de IPv6 es inevitable y se está acelerando. La pregunta no es "si" sino "cuándo" y "qué tan rápido". Las organizaciones que adoptan doble pila ahora se posicionan para una transición más suave y mejor rendimiento a medida que internet continúa su evolución hacia IPv6. Retrasar la implementación de IPv6 solo aumenta la complejidad de migración futura y los costos.


