A pesar de que IPv6 ha existido durante mucho tiempo, el primer borrador se presentó en 1998, no ha desempeñado un papel significativo en muchas arquitecturas de redes hasta ahora. A pesar de que la razón principal de la existencia de IPv6 es abordar el agotamiento de direcciones IPv4, la adopción de IPv6 se ha retrasado debido a algunas soluciones temporales como NAT. Pero ahora con el auge de IoT y dispositivos inteligentes, por un lado, y el aumento de los precios de las direcciones IPv4 por el otro, muchas empresas han comenzado a implementar IPv6.
Desde el 1 de febrero de 2024 AWS cobra por cualquier dirección IPv4 pública, aunque esté asociada a un ENI. Este es un gran incentivo para comenzar a implementar arquitecturas de red basadas en IPv6 en AWS. Pero, ¿no es muy difícil pasar de IPv4 a IPv6? Para nada. En este artículo voy a mostrarle algunos aspectos clave de IPv6 en AWS y una pequeña arquitectura de referencia para trabajar con esta versión del protocolo.
Subnetting #
Lo primero que debemos saber sobre IPv6 es cómo funciona el subnetting. IPv6 usa direcciones de 128 bits mientras que IPv4 usa solo 32 bits. La representación de estas direcciones es en forma de ocho grupos de cuatro dígitos hexadecimales, cada grupo representa 16 bits. Los grupos están separados por dos puntos. Un ejemplo de una dirección IPv6 es:
2001:0db8:85a3:0000:0000:8a2e:0370:7334
Para simplificar, hay algunas reglas que permiten acortar la representación de una dirección IPv6.
- Los ceros a la izquierda en cada grupo se pueden omitir.
- La secuencia más larga de ceros se puede comprimir con dos caracteres de dos puntos
::.
En nuestra dirección de ejemplo esto quedaría como 2001:db8:85a3::8a2e:370:7334 que es bastante más corto.
El subnneting en IPv6 funciona de forma similar a IPv4 Classless Inter-Domain Routing (CIDR), pero en lugar de usar 32 bits utiliza 128 bits en la forma <ipv6-address>/N donde N* es el número de bits que representa la parte de la red. Por ejemplo, la dirección 2001:0db8:85a3::/64 utiliza los primeros 64 bits para establecer la parte de red, y los 64 bits restantes representan la parte de host ( \(2^{64} = 18446744073709551616\) hosts, lo cual son muchos).
AWS utiliza el prefijo /56 por defecto para los rangos CIDR IPv6 de la VPC, pero es posible ajustarlo en el rango /44 a /60 en incrementos de /4. Las subredes tienen un tamaño fijo de /64. Esto simplifica mucho las cosas al diseñar redes con IPv6 en AWS.
Subnets públicas y privadas #
Al igual que con IPv4, una subred IPv6 se considera pública si tiene una tabla de rutas con una ruta por defecto ::/0 apuntando a un Internet Gateway. En el caso contrario, la subred se considera privada. ¿Pero qué sucede con el tráfico de salida en una subred IPv6? Depende, por supuesto, del tipo de subred.
Para IPv6 tenemos dos tipos de subredes privadas.
- Subredes dual-stack IPv4 e IPv6.
- Subredes solo IPv6.
Las subredes dual-stack tienen un CIDR IPv4 y un CIDR IPv6, por lo que todas las ENI de la subred recibirán una IP de cada tipo. El tráfico de salida IPv4 se enrutará a través de un NAT Gateway en una subred pública con una ruta predeterminada 0.0.0/0, y el tráfico de salida IPv6 se enrutará a través de un Egress Only Internet Gateway con la ruta predeterminada ::/0.
Un Egress Only Internet Gateways funciona de manera similar a un Internet Gateway, pero con la diferencia de que solo permite el tráfico saliente y no el tráfico entrante.
Las subredes solo IPv6 tienen un CIDR IPv6 y por tanto todas las ENIs de la subred recibirán una dirección IPv6. Para estas subredes, el tráfico de salida se realiza a través de un Egress Only Internet Gateway, pero esto limita que nuestros destinos sean únicamente IPv6. ¿Significa esto que no podemos llegar a los destinos IPv4? No realmente, pero lo veremos más adelante.
No todos los servicios de AWS funcionan con IPv6 #
Al momento de escribir este artículo, muchos servicios de AWS ya soportan IPv6. Aquí está la lista de servicios de AWS que soportan IPv6. Sin embargo, todavía hay algunos servicios de AWS que permanecen en IPv4 como por ejemplo AWS Systems Manager.
Entonces, ¿cómo lo hacemos con los servicios de AWS que todavía son IPv4? Vamos a verlo.
Accesibilidad IPv4 desde subredes solo IPv6 #
Como vimos anteriormente, las subredes IPv6 permiten el tráfico de salida de IPv6 con el uso de un Egress Only Internet Gateway, pero a veces es necesario acceder a destinos IPv4 en internet.
Para estos casos de uso, AWS ofrece dos tecnologías diferentes que, combinadas, permiten alcanzar destinos IPv4 desde subredes IPv6.
- DNS64
- NAT64
DNS64 #
Las consultas a un DNS resolver pueden ser (entre muchas otras) de tipo A para registros IPv4 o tipo AAAA para registros IPV6. Por lo tanto, cuando se solicita un registro DNS de una subred solo IPv6, si el servicio al que se pretende acceder no admite IPv6, se recibirá una dirección IPv4 y no será posible conectarse. Para resolver este problema, AWS ofrece DNS64.
DNS64, cuando se habilita a nivel de subred, hace que cada consulta enviada al resolver de R53 de la VPC devuelva el contenido del registro AAAA, si hay al menos uno, o una dirección IPv6 sintetizada añadiendo un prefijo /96, definido en RFC6052 (64:9ffb:96), a la dirección IPv4 del registro A.
El servicio IPv6 se comunicará con esta dirección a través de un NAT Gateway que traducirá a su vez esta dirección en una dirección IPv4.
NAT64 #
NAT64 es una característica de NAT Gateway que ya está disponible en todos los NAT Gateway existentes o nuevos. Permite que el servicio IPv6 se comunique con servicios IPv4 al traducir la dirección IPv6 sintetizada dada por DNS64 a una dirección IPv4.
Una vez habilitado DNS64 en la subred, el servicio IPv6 envía tráfico a una dirección IPv6 sintetizada a través de NAT Gateway y sucede lo siguiente:
-
Desde el prefijo
64:ff9b::/96, el NAT Gateway reconoce que el destino original es IPv4 y traduce los paquetes IPv6 a IPv4 reemplazando:-
La IPv6 origen con su propia IP privada, que el Internet Gateway traduce a la dirección IP pública.
-
La IPv6 de destino a IPv4 al truncar el prefijo
64:ff9b::/96.
-
-
El NAT Gateway envía los paquetes IPv4 traducidos al destino a través del Internet Gateway, Virtual Private Gateway o Transit Gateway e inicia una conexión.
-
El host IPv4 envía paquetes de respuesta IPv4. Una vez que se haya establecido una conexión, el NAT Gateway acepta los paquetes de respuesta IPv4 de los hosts externos.
-
Los paquetes de respuesta IPv4 están destinados al NAT Gateway, que recibe los paquetes y revierte la traducción de NAT al reemplazar su IP (IP de destino) por la dirección IPv6 del host y anteponiendo nuevamente
64:ff9b::/96en la dirección IPv4 origen. A continuación, el paquete fluye hacia el host siguiendo la ruta local.
Un ejemplo práctico #
Para ver esto en acción he incluido una arquitectura de ejemplo que implementa una VPC con una subred pública dual-stack y una subred privada IPv6.
La arquitectura cuenta con un NAT Gateway con NAT64 y DNS64 para acceder a destinos IPv4 y Egress Only Internet Gateway para destinos IPv6. Para el tráfico de entrada cuenta con un NLB dual-stack delante de una instancia de prueba con un servidor NGINX.
Una vez desplegado, veamos cómo funciona de una manera práctica. Desde la consola de EC2 conectamos a la instancia de prueba con Session Manger.
Acceder a un servicio compatible con IPv6 #
Vamos a probar a acceder a un servicio que funciona con IPv6 como gitlab.com:
curl -v gitlab.com
* Host gitlab.com:80 was resolved.
* IPv6: 2606:4700:90:0:f22e:fbec:5bed:a9b9
* IPv4: 172.65.251.78
* Trying [2606:4700:90:0:f22e:fbec:5bed:a9b9]:80...
* Connected to gitlab.com (2606:4700:90:0:f22e:fbec:5bed:a9b9) port 80
> GET / HTTP/1.1
> Host: gitlab.com
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
...
Como podemos apreciar gitlab.com resuelve a 2606:4700:90:0:f22e:fbec:5bed:a9b9 por lo que el tráfico se enruta a través de Egress Only Internet Gateway para llegar al destino.
Acceder a un servicio compatible con IPv4 #
Ahora probamos a acceder a un servicio que solo funciona con IPv4 como github.com:
curl -v github.com
* Host github.com:80 was resolved.
* IPv6: 64:ff9b::4d0:1ac5
* IPv4: 4.208.26.197
* Trying [64:ff9b::4d0:1ac5]:80...
* Connected to github.com (64:ff9b::4d0:1ac5) port 80
> GET / HTTP/1.1
> Host: github.com
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Content-Length: 0
< Location: https://github.com/
<
* Connection #0 to host github.com left intact
Podemos observar como github.com resuelve a 64:ff9b::4d0:1ac5. Como vimos anteriormente, esta dirección está precedida por 64:ff9b::/96 y los últimos 32 bits, 4d0:1ac5, corresponden con la dirección IPv4 4.208.26.197.
dig +short github.com
4.208.26.197
En este caso, el tráfico se enruta a través del NAT Gateway que después de las transformaciones requeridas se comunica con el servicio IPv4 y devuelve la respuesta a la instancia.
Exponer un servicio de una subred solo IPv6 #
Pero ¿qué pasa con la comunicación en la otra dirección? Vamos a ver cómo se comporta nuestra solución basada en NLB dual-stack.
Primero, intentamos conectar nuestro NLB desde un dispositivo IPv4:
curl -v ipv6-demo-2ed40c616b42c6e4.elb.eu-west-1.amazonaws.com
* Host ipv6-demo-2ed40c616b42c6e4.elb.eu-west-1.amazonaws.com:80 was resolved.
* IPv6: (none)
* IPv4: 54.154.55.245
* Trying 54.154.55.245:80...
* Connected to ipv6-demo-2ed40c616b42c6e4.elb.eu-west-1.amazonaws.com (54.154.55.245) port 80
> GET / HTTP/1.1
> Host: ipv6-demo-2ed40c616b42c6e4.elb.eu-west-1.amazonaws.com
> User-Agent: curl/8.6.0
> Accept: */*
>
< HTTP/1.1 200 OK
...
Como podemos ver, se resuelve una dirección IPv4 pública 54.154.55.245 y luego llega al NGINX a pesar de que se encuentra en una instancia en una subred IPv6.
A continuación tratamos de conectarnos desde un origen IPv6 (para esta demostración usé la misma instancia de prueba EC2 pero podría ser cualquier otro host en cualquier lugar de Internet).
curl -v ipv6-demo-2ed40c616b42c6e4.elb.eu-west-1.amazonaws.com
* Host ipv6-demo-2ed40c616b42c6e4.elb.eu-west-1.amazonaws.com:80 was resolved.
* IPv6: 2a05:d018:edc:de00:fcd3:24a:53bd:eff1
* IPv4: 54.154.55.245
* Trying [2a05:d018:edc:de00:fcd3:24a:53bd:eff1]:80...
* Connected to ipv6-demo-2ed40c616b42c6e4.elb.eu-west-1.amazonaws.com (2a05:d018:edc:de00:fcd3:24a:53bd:eff1) port 80
> GET / HTTP/1.1
> Host: ipv6-demo-2ed40c616b42c6e4.elb.eu-west-1.amazonaws.com
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 200 OK
...
Ahora vemos que se resuelven ambas direcciones 2a05:d018:edc:de00:fcd3:24a:53bd:eff1 y 54.154.55.245 pero se accede por la dirección IPv6 que muestra el mismo contenido sin ningún problema.
La conclusión de esta parte de la demonstración es que también podríamos proporcionar servicios desde instancias IPv6 compatibles con IPv6 e IPv4 sin mayor problema.
Para finalizar #
En este post hemos visto lo que es IPv6, las diferencias con IPv4 y los problemas que resuelve. Además, hemos visto cómo implementar una arquitectura simple con DNS64 y NAT64 para aprovechar las capacidades IPv6 en nuestras aplicaciones manteniendo la compatibilidad IPv4.
Vale la pena mencionar que AWS también ofrece un conjunto completo de Arquitecturas de referencia para Amazon VPC Dual-Stack e IPv6. Echa un vistazo!!
¿Estás listo para empezar a implementar IPv6?