Para que un dispositivo pueda comunicarse con otros dispositivos en Internet a través del llamado, Protocolo de Internet (IP), primero se le debe asignar una dirección numérica única. El aspecto de esta dirección depende de la versión de dirección IP que se utilice: IPv4 o IPv6.
IPv4 se implementó por primera vez en 1983. Es la versión de dirección IP que dio origen a la red de Internet moderna y sigue siendo el protocolo dominante hoy en día. IPv6 se remonta a 1998, pero no ha sido hasta la última década cuando ha empezado a cobrar impulso, de hecho, su adopción aumentó desde menos del 1 % al 30-40 % (el porcentaje varía según quien elabore el informe, los datos que midan y la forma en que lo hagan).
Teniendo en cuenta el aumento del número de dispositivos conectados, que supera con creces el número de direcciones IPv4 disponibles, y el incremento de sus costes, el espacio de direcciones mucho mayor que ofrece IPv6 debería haberlo convertido ya en el protocolo dominante. Sin embargo, vamos a ver que no es así.
Cloudflare ha sido un firme defensor de IPv6 durante muchos años y, gracias a Cloudflare Radar, hemos seguido de cerca la adopción de IPv6 en Internet. Radar, que nació hace tres años, sigue siendo una plataforma relativamente reciente. Si nos remontamos atrás en el tiempo, podemos recurrir brevemente a nuestros amigos de APNIC1, uno de los cinco registros regionales de Internet (RIR). Sus datos, que se remontan a 2012, nos permiten ver que el protocolo IPv6 experimentó un periodo de crecimiento aparentemente exponencial hasta mediados de 2017, manteniendo después un crecimiento lineal que aún continúa:
La adopción de IPv6 se ve frenada por la falta de compatibilidad entre ambos protocolos — los dispositivos deben tener asignadas tanto una dirección IPv4 como una IPv6 — y el hecho de que prácticamente todos los dispositivos de Internet siguen siendo compatibles con IPv4. No obstante, IPv6 es fundamental para el futuro de Internet y es necesario seguir tratando de aumentar su implementación.
Cloudflare Radar, al igual que APNIC y la mayoría de las demás fuentes actuales, publica cifras que reflejan principalmente hasta qué punto los proveedores de acceso a Internet han implementado IPv6: el lado cliente. Se trata de un aspecto muy importante y que afecta directamente a los usuarios finales, pero también está el otro extremo de la ecuación : el lado servidor.
Teniendo esto presente, te invitamos a que nos acompañes en un rápido experimento para conocer la adopción de IPv6 en el lado servidor, así como la frecuencia con la que los clientes son realmente (o probablemente) capaces de comunicarse con los servidores a través de IPv6. Nos basaremos en el DNS en este análisis y, como se suele decir, los resultados pueden sorprenderte.
Adopción de IPv6 en el lado cliente (desde la perspectiva de HTTP)
A finales de octubre de 2023, desde la perspectiva de Cloudflare, la adopción de IPv6 en Internet era de aproximadamente el 36 % de todo el tráfico, si bien había ligeras variaciones según la hora del día y el día de la semana. Si se excluyen los bots, la estimación se eleva a algo más del 46 %, mientras que si se excluyen los usuarios humanos, se reduce a cerca del 24 %. Estas cifras se refieren a la proporción de solicitudes HTTP servidas a través de IPv6 en todo el contenido habilitado para IPv6 (la configuración por defecto).
Para este ejercicio, lo que más importa es el número que corresponde a humanos y a bots. Hay muchas razones que explican la diferencia de adopción entre ambos tipos de tráfico, desde los distintos niveles de compatibilidad de IPv6 en la gran variedad de software cliente utilizado, hasta los distintos niveles de implementación de IPv6 dentro de las numerosas redes de las que procede el tráfico, pasando por el tamaño variable de dichas redes, etc. Sin embargo, dejamos esta encrucijada para otro día. Si tienes curiosidad por conocer las cifras de un país o una red en concreto, puedes consultar Cloudflare Radar y nuestro informe Resumen del año de 2023.
Con uno no basta
Tu, como lector, podrías pensar que el cálculo del lado cliente de la ecuación cliente-servidor solo nos cuenta la mitad de la historia. Para que un cliente IPv6 establezca una conexión con un servidor a través de IPv6, el servidor también debe ser compatible con IPv6.
Aquí se nos plantean dos preguntas:
- ¿Cuál es el alcance de la adopción de IPv6 en el lado servidor?
- ¿Hasta qué punto coincide la adopción de IPv6 en el lado cliente con la adopción en el lado servidor?
Hay varias respuestas posibles, dependiendo de si estamos hablando de usuarios, dispositivos, bytes transferidos, etc. Nos centraremos en las conexiones (quedará claro por qué en un momento), y la pregunta conjunta que planteamos es:
¿Con qué frecuencia puede un cliente compatible con IPv6 utilizar el protocolo IPv6 al conectarse a servidores en Internet, según patrones de uso típicos?
Los patrones de uso típicos incluyen usuarios que pasan el día visitando algún sitio web con más frecuencia que otros o clientes automatizados que llaman a la API. Recurriremos al DNS para conocer esta perspectiva.
Entra en escena el DNS
Antes de que un cliente pueda intentar establecer una conexión con un servidor por su nombre, utilizando el protocolo clásico IPv4 o el más moderno IPv6, debe buscar la dirección IP del servidor en la agenda de Internet, el sistema de nombres de dominio (DNS).
Buscar un nombre de host en el DNS es un proceso recursivo. Para encontrar la dirección IP de un servidor, hay que seguir la jerarquía de dominios (los componentes separados por puntos del nombre de un servidor) en varios servidores DNS autoritativos hasta que uno de ellos devuelva la respuesta deseada. La mayoría de los clientes, sin embargo, no lo hacen así directamente, en su lugar piden a un servidor intermediario llamado solucionador recursivo que lo haga por ellos. Cloudflare opera uno de estos solucionadores recursivos que todo el mundo puede utilizar: 1.1.1.1.
A modo de ejemplo sencillo, cuando un cliente pregunta a 1.1.1.1 por la dirección IP donde se aloja " www.example.com", 1.1.1.1 preguntará al servidor raíz de DNS3 por ".com", luego preguntará al servidor DNS de .com por "example.com", y finalmente preguntará al servidor DNS de example.com por "www.example.com", que tiene el conocimiento directo y responderá con una dirección IP. Para agilizar la tarea del siguiente cliente que haga una pregunta similar, 1.1.1.1 almacena en caché (recuerda durante un tiempo) tanto la respuesta final como los pasos intermedios.
Esto significa que 1.1.1.1 está en muy buena posición para calcular la frecuencia con la que los clientes intentan buscar direcciones IPv4 (consultas de tipo A) frente a la frecuencia con la que intentan buscar direcciones IPv6 (consultas de tipo AAAA), cubriendo la mayor parte de la red de Internet observable.
Pero, ¿cómo sabe un cliente cuándo debe solicitar la dirección IPv4 de un servidor o su dirección IPv6?
La respuesta corta es que los clientes que disponen de IPv6 solicitan ambos. Realizan búsquedas A y AAAA por separado para cada servidor al que desean conectarse. Estos clientes IPv6 priorizarán la conexión a través de IPv6 cuando obtengan una respuesta AAAA no vacía, independientemente de que también obtengan una respuesta A no vacía (que casi siempre obtienen, como veremos). El algoritmo que impulsa esta preferencia por la modernidad se llama Happy Eyeballs, por si te interesan los detalles.
Ya estamos listos para comenzar a analizar algunos datos reales...
Adopción de IPv6 en el lado cliente (desde la perspectiva del DNS)
El primer paso consiste en establecer un punto de referencia midiendo la implementación de IPv6 de los clientes a partir de 1.1.1.1 y compararlo con los números de las solicitudes HTTP con las que partimos.
Es tentador calcular la frecuencia con la que los clientes se conectan a 1.1.1.1 utilizando IPv6, pero los resultados son engañosos por un par de razones, la más importante de las cuales está oculta a simple vista: 1.1.1.1 es la dirección más recordada del conjunto de direcciones IPv4 e IPv6 que los clientes pueden utilizar para realizar búsquedas de DNS a través del servicio 1.1.1.1. Lo ideal es que el cliente IPv6 que utilice 1.1.1.1 como su solucionador recursivo tenga configuradas las cuatro direcciones IP siguientes, no solo las dos primeras:
- 1.1.1.1 (IPv4)
- 1.0.0.1 (IPv4)
- 2606:4700:4700::1111 (IPv6)
- 2606:4700:4700::1001 (IPv6)
Pero, cuando se trata de una configuración manual4, los usuarios encuentran que las direcciones IPv6 son menos fáciles de recordar que las direcciones IPv4y es menos probable que las configuren, ya que consideran que las direcciones IPv4 son suficientes.
Un factor de confusión relacionado, pero menos obvio, es que muchos clientes IPv6 seguirán realizando búsquedas de DNS en IPv4 aunque las direcciones IPv6 de 1.1.1.1. estén configuradas, ya que la distribución de las búsquedas entre las direcciones disponibles es una opción predeterminada popular.
Un enfoque más sensato para evaluar la adopción de IPv6 a partir de la actividad de los clientes DNS es calcular el porcentaje de consultas de tipo AAAA sobre la cantidad total de consultas de tipo A, asumiendo que los clientes IPv6 siempre realizan ambas5, como se ha mencionado anteriormente.
Entonces, desde la perspectiva de 1.1.1.1, la adopción de IPv6 en el lado cliente se estima en un 30,5 % por volumen de consultas. Esta cifra es algo inferior a la observada en el tráfico HTTP durante el mismo periodo (35,9 %), pero esta diferencia entre dos perspectivas distintas no es extraña.
Un apunte sobre los TTL
No solo los solucionadores recursivos almacenan en caché las respuestas DNS, la mayoría de los clientes DNS también tienen sus propias cachés locales. Tu navegador web, tu sistema operativo e incluso tu enrutador doméstico guardan las respuestas con la esperanza de agilizar las consultas posteriores.
El tiempo que cada respuesta permanece en la caché depende del campo tiempo de vida (TTL) devuelto con el registro DNS. Si estás familiarizado con el DNS, puede que te preguntes si los registros A y AAAA tienen TTL similares. Si no es así, es posible que estemos recibiendo menos consultas para uno de estos dos tipos (porque se almacena en caché durante más tiempo a nivel de cliente), sesgando las cifras de adopción resultantes.
Los gráficos desglosan los TTL mínimos devueltos por 1.1.1.1 en respuesta a las consultas A y AAAA6. Hay alguna diferencia entre ambos tipos, pero la diferencia es mínima.
Adopción de IPv6 en el lado servidor
El siguiente gráfico muestra la frecuencia con la que las consultas de tipo A y AAAA obtienen respuestas no vacías, lo que arroja luz sobre la adopción de IPv6 del lado servidor y nos acerca a la respuesta que buscamos:
La adopción de IPv6 de los servidores se estima en un 43,3 % por volumen de consultas, notablemente superior a la observada para los clientes.
Frecuencia con la que el cliente y el servidor realizan conexiones
Si el 30,5 % de las búsquedas de direcciones IP gestionadas por 1.1.1.1 pudieran hacer uso de una dirección IPv6 para conectarse a sus destinos previstos, pero solo el 43,3 % de esas búsquedas obtuvieran una respuesta no vacía, eso nos daría una buena indicación de la frecuencia con la que se realizan conexiones IPv6 entre cliente y servidor, aproximadamente el 13,2 % del tiempo.
El impacto potencial de los dominios populares
La adopción de IPv6 del lado servidor, medida por el volumen de consultas para los dominios de la lista Top 100 de Radar es del 60,8 %. Si excluimos estos dominios de nuestros cálculos generales, la cifra anterior del 13,2 % se reduce al 8 %. Esta es una diferencia significativa, pero no es extraña, ya que los 100 dominios principales representan más del 55 % de todas las consultas A y AAAA a 1.1.1.1.
La evaluación de la adopción de IPv6 en Internet supone:
- Contabilizar los usuarios con acceso a Internet compatible con IPv6.
- Contabilizar los dispositivos compatibles con IPv6 o software en dichos dispositivos (cliente y/o servidores).
- Calcular la cantidad de tráfico que pasa a través de las conexiones IPv6, medida en bytes.
- Contabilizar la proporción de conexiones (o solicitudes individuales) en IPv6.
En este ejercicio elegimos analizar las conexiones y las solicitudes. Teniendo en cuenta que la realidad subyacente solo se puede entender realmente considerando varias perspectivas diferentes, observamos tres cifras diferentes de adopción de IPv6:
- 35,9 % (del lado cliente) cuando se contabilizan las solicitudes HTTP servidas desde la CDN de Cloudflare.
- 30,5 % (del lado cliente) si se cuentan las consultas DNS de tipo A y AAAA gestionadas por 1.1.1.1.
- 43,3 % (del lado servidor) de respuestas positivas a consultas DNS de tipo AAAA, también desde 1.1.1.1.
Combinamos las cifras del lado cliente y del lado servidor desde la perspectiva del DNS para calcular con qué frecuencia es probable que las conexiones a servidores de terceros se establezcan a través de IPv6 en lugar de IPv4, y el resultado es solo el 13,2% de las veces.
Para mejorar estas cifras, los proveedores de acceso a Internet, los proveedores de nube y alojamiento, y las empresas deben acelerar la implementación de IPv6 en los dispositivos de sus redes. Sin embargo, los sitios web importantes y las fuentes de contenido también tienen un papel fundamental a la hora de permitir que los clientes IPv6 utilicen IPv6 más a menudo, ya que el 39, 2% de las consultas de dominios en el Top 100 de Radar (que representan más de la mitad de todas las consultas A y AAAA a 1.1.1.1) todavía se limitan a respuestas IPv4 únicamente.
En el camino hacia la plena adopción de IPv6, Internet va a la zaga. Sin embargo, el esfuerzo continuo de todos los involucrados puede ayudar a que siga avanzando, y tal vez incluso a acelerar el progreso.
En el lado servidor, Cloudflare lleva muchos años trabajando para este fin, y por ello ofrece compatibilidad IPv6 gratuita para todos los dominios. En el lado cliente, la aplicación 1.1.1.1 habilita automáticamente tu dispositivo para IPv6 incluso si tu proveedor de acceso a Internet no la facilita. Y, si por casualidad gestionas una red solo IPv6, la compatibilidad DNS64 de 1.1.1.1 también te cubre.
***
1La resolución DNS pública de Cloudflare (1.1.1.1) opera en asociación con APNIC. Puedes obtener más información en la publicación del blog del anuncio original y en la política de privacidad de 1.1.1.1..
2Sigue leyendo sobre el funcionamiento de DNS en la sección "¿Qué es DNS?” de nuestro sitio web. Si prefieres aprender de forma práctica, te sugerimos que eches un vistazo a "mess with dns" de Julia Evans.
3Cualquier solucionador recursivo ya conocerá de antemano las direcciones IP de los 13 servidores raíz. Cloudflare también participa en el nivel superior de DNS proporcionando servicio Anycast a las instancias E y F-Root, lo que facilita a 1.1.1.1 ese primer paso de búsqueda.
4Cuando se utiliza la aplicación 1.1.1.1, las cuatro direcciones IP se configuran automáticamente.
5Para simplificar, suponemos que la cantidad de clientes que solo utilizan IPv6 sigue siendo insignificante. Es una suposición razonable en general, y otros conjuntos de datos de los que disponemos lo confirman.
61.1.1.1, al igual que otros solucionadores recursivos, devuelve TTL ajustados: el TTL original del registro menos el número de segundos transcurridos desde que el registro se almacenó en caché por última vez. Las respuestas A y AAAA vacías se almacenan en caché durante el tiempo definido en el registro de Inicio de autoridad (SOA) del dominio, tal y como se especifica en RFC 2308.