BGP: Ejemplo IPv6 Only entre FRR y OpenBGPD

FRR:

show run

frr# sh run 

Building configuration...

Current configuration:

!

frr version 8.1

frr defaults traditional

hostname frr

log syslog informational

service integrated-vtysh-config

!

interface l0

 ipv6 address 2001:db8::1/128

exit

!

router bgp 65001

 bgp router-id 1.1.1.1

 no bgp ebgp-requires-policy

 neighbor 2001:db8:12::2 remote-as 65002

 !

 address-family ipv6 unicast

  redistribute connected

  neighbor 2001:db8:12::2 activate

  neighbor 2001:db8:12::2 soft-reconfiguration inbound

 exit-address-family

exit

!

OpenBGPD

Archivo: /etc/bgpd.conf

# macros

ASN="65002"

fib-update yes

log updates

# global configuration

AS $ASN

router-id 2.2.2.2

network 2001:db8::2/128

network inet6 connected

neighbor 2001:db8:12::1 {

    descr "epa"

    remote-as 65001

    announce IPv6 unicast

}

deny from any

deny to any

allow from 2001:db8:12::1

allow to 2001:db8:12::1

#

(por favor notar el espacio en blanco entre la última línea y la antepenúltima línea)

Como crear una ruta IPv6 a null/blackhole en Linux

Caso:

   Como crear una ruta IPv6 a null/blackhole en Linux

Comando:

  ip -6 route add blackhole fd00:12:34::0/48

Espero sea útil

Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64

Parece loco, pero no lo es: Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64 

NGINX Reverse Proxy y Granja de Servidores IPv6 Only

 Introducción

En el presente trabajo presentaremos una manera muy sencilla de ofrecer acceso Web Dual Stack a una granja de servidores IPv6 Only utilizando NGINX. Con el crecimiento continuo de la red y la adopción gradual del protocolo IPv6, es esencial garantizar la conectividad y accesibilidad para aquellos clientes que utilizan tanto IPv4 como IPv6.

Explicaremos cómo configurar NGINX para admitir acceso web Dual Stack; veremos cómo configurar NGINX como un proxy inverso que escucha tanto en direcciones IPv4 como IPv6, y cómo direccionar correctamente las solicitudes entrantes a los servidores backend que solo tienen direcciones IPv6.  Por cierto, lo que estudiaremos en el siguiente artículo es un importante paso para lograr el ansiado ahorro de direcciones IPv4, entre muchos otros beneficios.

¿Qué es un reverse proxy?

Cloudflare define en [1] un Servidor Proxy Inverso o Reverso como:

“Un proxy inverso es un servidor que se sitúa delante de los servidores web y reenvía las solicitudes del cliente (por ejemplo, el navegador web) a esos servidores web. Los proxies inversos suelen implementarse para ayudar a aumentar la seguridad, el rendimiento y la fiabilidad. Para entender mejor cómo funciona un proxy inverso y las ventajas que puede aportar, definamos primero qué es un servidor proxy.”

¿Qué es un servidor proxy?

Nuevamente Cloudflare define en [1] un Servidor Proxy como:

“Un proxy de reenvío, con frecuencia conocido como proxy, servidor proxy o proxy web, es un servidor que se sitúa delante de un grupo de máquinas cliente. Cuando esos ordenadores realizan solicitudes a sitios y servicios en Internet, el servidor proxy intercepta esas peticiones y luego se comunica con los servidores web en nombre de esos clientes, como un intermediario.”

¿Cuáles son los beneficios de un Reverse Proxy?

•     Ofrecer IPv4 o IPv6 transparente a clientes provenientes desde Internet servidos desde una granja de servidores IPv6 Only (en esto nos enfocaremos)

•     Escalabilidad: Al utilizar un proxy inverso, es posible agregar o eliminar servidores backend según sea necesario sin afectar a los usuarios finales. Esto facilita la escalabilidad horizontal de las aplicaciones, lo que permite manejar un mayor número de solicitudes y usuarios simultáneos.

•     Cacheo de contenido estático: NGINX puede almacenar en caché contenido estático como imágenes, archivos CSS y JavaScript, lo que reduce la carga en los servidores backend y acelera la entrega de contenido a los usuarios. Esto mejora el tiempo de carga de las páginas y reduce el ancho de banda necesario.

•     Seguridad: NGINX actúa como un punto de entrada a la aplicación, lo que proporciona una capa adicional de seguridad. Puede realizar funciones como filtrado de solicitudes, prevención de ataques DDoS, protección contra inyecciones SQL y autenticación de clientes. Además, NGINX puede habilitar el uso de SSL/TLS para cifrar la comunicación entre los clientes y el servidor backend.

•     Enrutamiento avanzado: Un proxy inverso permite realizar enrutamiento avanzado según diferentes criterios, como el nombre de dominio, la URL o las cabeceras HTTP. Esto es útil en casos donde se necesite dirigir el tráfico a diferentes servidores backend según las características de la solicitud.

•     Consolidación de servicios: NGINX puede actuar como un punto de entrada único para varios servicios backend. Esto simplifica la infraestructura al consolidar múltiples servicios en un solo servidor, lo que facilita la administración y el mantenimiento.

•     Mejora del rendimiento: NGINX está diseñado para ser liviano y eficiente en el uso de recursos. Su arquitectura optimizada y su capacidad para manejar grandes cantidades de conexiones simultáneas lo convierten en una opción popular para mejorar el rendimiento de las aplicaciones web.

•  Balanceo de carga: Un proxy reverso como NGINX puede distribuir el tráfico entrante a través de varios servidores backend. Esto ayuda a equilibrar la carga de trabajo y garantiza que ningún servidor esté sobrecargado, lo que mejora el rendimiento y la capacidad de respuesta de la aplicación. 

Topología que vamos a usar

¿Qué vamos a lograr el día de hoy?

El servidor en el borde (Servidor Proxy Reverso) va a ser capaz de recibir peticiones HTTP en IPv4 e IPv6, y dependiendo del sitio Web que se desea visitar (dominio) re-enviará la consulta al servidor correcto. En el ejemplo actual ocurrirá lo siguiente:

El Cliente visita      Petición enviada a:

server-a.com   →   2001:db8:123::101

server-b.com   →   2001:db8:123::102

server-c.com   →   2001:db8:123::103

Prerrequisitos

• Linux con Nginx en el Servidor Proxy Reverso 

• Acceso super usuario

• Servidor Web en cada uno de los servidores de la granja

• Conectividad a Internet IPv4 e IPv6

• Conectividad interna en IPv6

Manos a la obra

1) Instalar nginx en todos los servidores 

   #apt update

   #apt install nginx

2) Crear los sitios Web en el Proxy Reverso NGINX 

Archivo  /etc/nginx/sites-available/server-a.com

server {

listen 80;

listen [::]:80;

    server_name server-a.com;

    location / {

        proxy_pass http://[2001:db8:123::101];

    }

}

Archivo  /etc/nginx/sites-available/server-b.com

server {

listen 80;

listen [::]:80;

    server_name server-b.com;

    location / {

        proxy_pass http://[2001:db8:123::102];

    }

}

Archivo  /etc/nginx/sites-available/server-c.com

server {

listen 80;

listen [::]:80;

    server_name server-c.com;

    location / {

        proxy_pass http://[2001:db8:123::103];

    }

}

3) Crear links simbólicos para habilitar los sitios configurados:

root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sites-available/server-a.com /etc/nginx/sites-enabled/server-a.com

root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sites-available/server-b.com /etc/nginx/sites-enabled/server-b.com

root@ProxyReverseSRV:/etc/nginx/sites-enabled# ln -s /etc/nginx/sites-available/server-c.com /etc/nginx/sites-enabled/server-c.com

4) Recordemos reiniciar nginx:

$sudo systemctl restart nginx

Sobre los logs

Los registros de conexión (logs) son de suma importancia para cualquier empresa e ISP que desea realizar alguna revisión de las conexiones entrantes.

  Lo que ocurre es que NGINX por defecto utilizará su propia dirección IP cuando realice las conexiones salientes, lo que trae como consecuencia que se pierde la dirección del cliente que originó la solicitud HTTP.  Pero no se preocupen, NGINX tiene la solución, se llama proxy_set_header y la configuración se divide en el servidor final y en el servidor Proxy Reverso.

1. En el Servidor Proxy Reverso, archivo del sitio web.

# Ejemplo de  nginx reverse proxy que permite conservar la dirección

# y puerto de original del cliente

location /examples {

  proxy_pass http://[2001:db8:123::103];

  proxy_buffering off;

  proxy_set_header X-Real-IP $remote_addr;

  proxy_set_header X-Forwarded-Host $host;

  proxy_set_header X-Forwarded-Port $server_port;

  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

2. En el servidor final en el archivo: /etc/nginx/nginx.conf agregar en la sección http lo siguiente:

   set_real_ip_from 2001:db8:123::100; #sustituir la dirección IP por la del Proxy

   real_ip_header X-Forwarded-For;

   real_ip_recursive on;

Ejemplo:

http {

    …

    set_real_ip_from 2001:db8:123::100;

    real_ip_header X-Forwarded-For;

    real_ip_recursive on;

   …

}

  Luego de estas configuraciones el servidor final confiará en la cabecera llamada X-Forwarded-For que provenga del IP 2001:db8:123::100 y en sus registros (/var/log/nginx/access.log) se podrá apreciar la dirección origen del cliente.

Conclusiones

Se puede percibir que con el diseño propuesto podemos administrar una granja de servidores web 100% IPv6 Only con acceso al mundo tanto IPv4 e IPv6 de una manera muy sencilla, escalable y eficiente. Lo anterior trae consigo diferentes beneficios tales como: administrar solo un stack TCP/IP, simplicidad, seguridad e incluso ahorro de direcciones IPv4.

Referencias

• [1] https://www.cloudflare.com/es-es/learning/cdn/glossary/reverse-proxy/

• https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-a-reverse-proxy-on-ubuntu-22-04

• Archivos de configuración de todo el proyecto en el Github de LACNIC:  https://github.com/LACNIC/BlogPostHelpFiles/tree/main/2023_Ofreciendo_conectividad_Dual_Stack_a_servidores_Web_en_una_granja_de_servidores_100_IPv6_Only

ortodoncia invisible madrid

Muchos memes divertidos de IPv6, IPv4 NAT y CGNAT

 

Google devuelve: 403. That’s an error. Your client does not have permission to get URL / from this server. That’s all we know.

Introducción:

  Quieres hacer una búsqueda en google y la página te devuelve: "403. That’s an error.

Your client does not have permission to get URL / from this server. That’s all we know."

En mi caso me encontraba utilizando un túnel IPv6 con Hurricane Electric, específicamente el /64 que entregan en los tuneles. 

¿Solución?

   Pedirle a Hurricane Electric en el portal un /48 enrutado.  Listo!, quité el anterior prefijo /64 del SLAAC del router, dejé solo un /64 perteneciente al /48.

Suerte!

Bar chart race - Despliegue IPv6 en LAC desde Mayo 2014 a Junio 2023

 

Una mirada a los miembros IPv6 Only de LACNIC

Introducción

El siguiente trabajo busca analizar la publicación de prefijos y el estado de los mismos, por parte de los miembros de LACNIC conocidos como IPv6 Only.

Se trata de organizaciones que han recibido prefijos IPv6, con o sin sistema autónomo (ASN), y no cuentan con prefijo IPv4 asignado por LACNIC. Los resultados de este análisis nos ayudarán a mejorar nuestra comprensión de los usos y necesidades de nuestros asociados en la región.

Fuentes de información utilizadas en este análisis

 La fuente de información utilizada en este análisis  fue el whois de LACNIC, con datos  obtenidos a lo largo del mes de enero de 2023. Esta información  incluye únicamente a aquellos miembros que posean IPv6 y no poseen IPv4 por parte de LACNIC. Pueden o no tener asignado un sistema autónomo.

Procesamiento de los datos

Python3 sobre un notebook Jupyter. Nos apoyamos en los API públicos de LACNIC y de RIPE NCC

            WHOIS de LACNIC

            RIPE NCC API

            APNIC Penetración IPv6 por ASN

            Delegated Extended de LACNIC:

Resultados

  Obtuvimos 483 miembros de LACNIC que se consideran IPv6 Only, a los que dividimos en:

            IPv6 Only con ASN: 343 miembros

            IPv6 Only sin ASN: 140 miembros

Resultados sobre los 483 miembros IPv6 Only (con y sin ASN):

 De los 483 miembros analizados obtuvimos la siguiente información:

-261 Anuncian el prefijo en su totalidad o parcialmente

-208 Anuncian el prefijo recibido por LACNIC en su totalidad

-53 Anuncian el prefijo recibido por LACNIC parcialmente

-222 No anuncian el prefijo

Resultados sobre los 343 miembros IPv6 Only con ASN:

De los 483 miembros IPv6 Only 343 tienen ASN (71%)

De los 343 con ASN:

                        163 anuncian el prefijo (47,52%)

120 Anuncian el prefijo IPv6 completo (73,61 %)

43 Anuncian el prefijo IPv6 parcialmente (26,38 %

180 No anuncian el prefijo Pv6  (52,48%)

Resultados sobre los 140 miembros IPv6 Only Sin ASN

De los 483 miembros IPv6 Only 140 no tienen ASN (29%)

De los 140 sin ASN obtuvimos

98 Anuncian el prefijo (70%)

82 Anuncian el prefijo completo (83,67%)

16 Anuncian el prefijo parcialmente (16,32%)

42 No anuncian el prefijo (30%)

¿Qué podemos extraer de los gráficos anteriores?

Lo primero que me llama poderosamente la atención es que los miembros IPv6 Only sin ASN poseen 23 puntos porcentuales más anuncios que aquellos miembros de LACNIC que si poseen su ASN. Es decir, estos miembros han pedido a otra organización que anuncie su prefijo.

En ambos casos la cantidad de prefijos no anunciados es muy alta; puede ser interesante averiguar si existe algún motivo detrás de esta situación. 

Es particularmente llamativo que el porcentaje de anuncio parcial es casi idéntico (11% miembros con ASN y 12% miembros sin ASN)

Intentando identificar si los ASNs poseen tráfico IPv6

Conociendo que existen 343 ASNs con prefijos IPv6 asignados y pensando que además son IPv6 Only, se puede presumir que deben tener un tráfico IPv6 “medio alto”.  Por ello, evaluamos cada AS para conocer su tráfico IPv6 para el 23 de Enero 2023.

¿Cómo averiguamos si un ASN posee tráfico IPv6?

Como es conocido por varios de ustedes, APNIC lleva muchos años midiendo el tráfico IPv6 de cada ASN. Se puede conocer más de estos estudios aquí: https://stats.labs.apnic.net/ipv6

En base a lo anterior, con los ASNs conocidos de los miembros IPv6 Only de LACNIC quisimos averiguar si efectivamente poseen tráfico IPv6 (es decir, más allá de realizar el anuncio de su prefijo). 

Lastimosamente no se pudo conseguir información de 274 ASs (79,88 %) de los 343 evaluados, Sin embargo, es importante destacar que esto no necesariamente significa que no hayan desplegado IPv6, sino que el tráfico generado es muy bajo y no aparecen en las mediciones de APNIC. 32 ASN fueron reportados con 0% de tráfico IPv6 y 1 ASN con 88% de tráfico IPv6.

¿Nuestros miembros IPv6 Only son en realidad tan IPv6 Only?

Finalmente, quisimos averiguar si efectivamente nuestros miembros (IPv6 Only con ASN) son tan IPv6 Only como nosotros los llamamos.

Para este caso en particular nos apoyamos en el API de RIPE NCC para obtener la información presentada a continuación.

De los 343 miembros con ASNs obtuvimos:

-540 prefijos totales anunciados (entre v4 y v6)

                        Anuncios v4: 220

                        Anuncios v6: 320

                        La máscara media en los anuncios v4 es: 23,56

                        La longitud de prefijo media en los anuncios IPv6 es: 38,09

-66 miembros se “volvieron” DualStack, es decir el ASN anuncia IPv4 e IPv6

-90 miembros anuncian solo IPv6

-27 miembros anuncian solo IPv4

-160 no anuncian prefijo alguno

Y los prefijos IPv4 que anuncian los miembros IPv6 Only de LACNIC,  ¿a cuál RIR pertenecen?

LACNIC ARIN RIPE NCC AFRINIC APNIC

28 166 17 9 0

Diagrama Sankey – Mirada a los miembros IPv6 Only

Conclusiones

Los resultados sugieren que, aunque existe una cantidad significativa de miembros de LACNIC que se consideran IPv6 Only, pudimos notar que más del 50% de ellos no han comenzado con el anuncio de su prefijo v6. A su vez pudimos apreciar que muchos de los que han desplegado IPv6 continúan utilizando IPv4. Esto significa que, aunque la adopción de IPv6 en la región ha crecido en los últimos años, aún hay un largo camino por recorrer para alcanzar un despliegue generalizado de IPv6. En cualquier caso, es importante continuar monitoreando la adopción del nuevo protocolo.

Finalmente ser un miembro IPv6 Only de LACNIC igualmente permite a las organizaciones participar en el ecosistema de Internet.

Despliegue de IPv6 en la región LACNIC - Bar Chart Race IPv6 a Junio 2022

El video muestra la adopción de IPv6 en la región atendida por LACNIC desde Mayo 20214 a Junio 2022. Hecho con https://flourish.studio/

Video: Retirada Implícita y Explícita de prefijos en BGP / BGP Explicit/Implicit Withdraw

En el video se explica con detalle los conceptos de Retirada Implícita y Retirada Explicita de prefijos en BGP. Se realiza un Demo con 5 enrutadores utilizando un prefijo IPv6. Finaliza con capturas de wireshark de los mensajes UPDATE.

El Metaverso será posible gracias al IPv6

El Metaverso promete ser uno de los desarrollos tecnológicos que mayor impacto traerá en el futuro las formas de uso y consumo en Internet[1].

Aunque por ahora la promesa de Mark Zuckerberg sigue siendo un poco gaseosa y el uso práctico en la actualidad se reduce a la comunidad de los denominados “GAMERS”, el desarrollo, masificación y despliegue del denominado “Metaverso”  será posible gracias a la tecnología que soporta el protocolo IPv6[1].

¿Por qué el IPV6 es tan importante para el Desarrollo del Metaverso?

Por: Gabriel E. Levy B. y Alejandro Acosta
www.galevy.com – blog.acostasite.com

En su casi medio siglo de vida los protocolos TCP/IP han servido para conectar a miles de millones de personas.

Desde la creación de Internet, han sido los estándares universales sobre los cuales se transmite la información por la red, haciendo posible que Internet funcione[3].

La sigla IP puede referirse a dos conceptos vinculados entre ellos; El primero es un protocolo (Internet Protocol – Protocolo de Internet en Español) y su principal función es el uso bidireccional (origen y destino) de transmisión de datos basado en la norma OSI (Open System Interconnection)[4].

La segunda posible referencia cuando se habla de IP, está vinculada a una asignación numérica de direcciones físicas conocida como Dirección IP, un identificativo lógico y jerárquico asignado a una interfaz de un dispositivo dentro de una red que utilice el protocolo de Internet (Internet Protocol – IP), la cual corresponde al nivel de red o nivel 3 del modelo de referencia OSI.

IPv4 hace referencia al Protocolo de Internet en su cuarta versión (en inglés, Internet Protocol version 4, IPv4), un estándar de interconexión de redes basados en Internet, y que fue implementado en 1983 para el funcionamiento de ARPANET y la posterior migración a Internet[5].

El IPv4 usa direcciones de 32 bits, equivalentes a 4.2 mil millones de bloques de numeración únicas, una cifra que, para la década de los años 80 parecía sencillamente inagotable, no obstante, y por el crecimiento enorme e inesperado de Internet, para el año 2011 pasó lo que nunca se creyó que fuera a ocurrir, todas las direcciones se agotaron[6].

IPv6 como solución al Cuello de botella

Para solucionar la falta de direcciones disponibles, conocido como “RECURSOS”, los grupos de ingeniería responsables de Internet, han recurrido a múltiples soluciones que van desde la creación de subredes privadas, de tal forma que con una misma dirección se puedan conectar múltiples usuarios, hasta la creación de un nuevo protocolo denominado IPv6 que promete ser la solución definitiva del problema y el cual fue lanzado oficialmente el 6 de junio de 2012[7]:

“Previendo el agotamiento de la dirección disponibles en IPv4 y como una solución de largo plazo, el organismo que se encarga de la estandarización de los protocolos de Internet (IETF, Internet Engineering Task Force), diseñó una nueva versión del Protocolo de Internet, concretamente la versión 6 (IPv6), con una casi inagotable disponibilidad, a partir de una nueva longitud de 128 bits, es decir alrededor 340 sextillones de direcciones”[8].

Es importante aclarar que la creación del protocolo IPv6, no implica una migración, es decir un cambio de un protocolo a otro como si fuera un proceso de remplazo, sino que se diseñó un mecanismo que permite por un tiempo la coexistencia articulada de ambos protocolos.

Para garantizar una transición transparente para los usuarios y que garantice un tiempo prudencial para que los fabricantes incorporen la nueva tecnología y los proveedores de Internet la implementen en sus propias redes, la organización encargada de la estandarización de los protocolos de Internet (IETF, Internet Engineering Task Force), diseñó junto con el mismo protocolo IPV6, una serie de mecanismos que se denominan de transición y coexistencia.

“Es como una balanza, en la que hoy en día el lado con el mayor peso representa el tráfico IPv4, pero poco a poco, gracias a esta coexistencia, conforme más contenidos y servicios estén disponibles con IPv6, el peso de la báscula irá hacia el otro lado, hasta que IPv6 sea predominante. Esto es lo que llamamos la transición”[9].

El diseño del protocolo IPv6 da preferencia a IPv6 frente a IPv4, si ambos están disponibles (IPv4 e IPv6). De ahí que se produzca ese desplazamiento del peso en “nuestra balanza”, de una forma natural, en función de múltiples factores, y sin que podamos determinar durante cuánto tiempo seguirá existiendo IPv4 en la Red y en qué proporciones. Posiblemente podamos pensar, intentando mirar en la bola de cristal, que IPv6 llegará a ser predominante en 3-4 años, y en ese mismo entorno de tiempo, IPv4 desaparecerá de Internet, al menos en muchas partes de ella” [10].

 Sin IPv6 quizás no haya metaverso

Cómo lo analizamos en pasados artículos, los Metaversos o Metauniversos, son entornos donde los humanos interactúan social y económicamente como iconos, a través de un soporte lógico en un ciberespacio, como una metáfora amplificada del mundo real, pero sin las limitaciones físicas o económicas[11].

“Puedes pensar en el Metauniversos como una Internet encarnada.

En lugar de ver contenido, estás en él y te sientes presente con otras personas como si estuvieras en otros lugares teniendo diferentes experiencias que no podrías tener en una aplicación 2D o página web“. Mark Zuckerberg Ceo de Facebook[12].

El Metaverso necesariamente “corre” o se “Ejecuta” sobre Internet, que a su vez utiliza el IP o (Internet Protocol) para funcionar.

El Metaverso es un tipo de simulación que mediante “Avatares” permite a los usuarios tener conexiones mucho más inmersivas y realistas, desplegando un universo virtual que corre en línea, razón por la cual se hace necesario garantizar que el Metaverso sea Inmersivo, multisensorial, Interactivo, que corran en tiempo real, que permitan diferenciar de manera precisa a cada usuario, que despliegue herramientas gráficas simultáneas y complejas, entre muchos otros elementos, que simplemente sería imposible de garantizar sobre el Protocolo IPv4, puesto que ni existen suficientes “Recursos IP” para cada conexión, ni es posible garantizar que con tecnologías como el NAT pueda correr adecuadamente.

Los elementos claves:

• El IPV6 es el único protocolo puede garantizar la cantidad suficiente de “Recursos IP” para soportar el Metaverso.
• El IPV6 evita el mecanismo de NAT en las redes que complicaría tecnológicamente el despliegue del Metaverso.
• El RTT/Delay de los enlaces de IPv6 es mucho menor que el de IPv4, permitiendo que las representaciones gráficas de los “avatares”, incluyendo los hologramas puedan desplegarse de forma sincrónica.
• Teniendo en cuenta la alta cantidad de datos que implica el despliegue del Metaverso, es necesario garantizar la menor perdida de datos posible, razón por la cual el IPv6 se convierte en la mejor opción pues la evidencia muestra que la pérdida de datos es un 20% menor que la de IPv4[13].

El Rol de los Pequeños ISP

Teniendo en cuenta que los pequeños ISP son los grandes responsables de la conectividad de millones de personas en las regiones más apartadas de todo Latinoamérica y como lo hemos analizado anteriormente, son los grandes responsables de la disminución de la Brecha Digital[14], es muy importante que estos operadores aceleren el proceso de migración hacia IPV6, no solamente para ser más competitivos frente a sus grandes competidores, sino para que puedan garantizarle a sus usuarios que tecnologías como El Metaverso funcionarán en sus dispositivos sin mayores traumatismos tecnológicos.

En Conclusión, si bien aún es incierto el alcance real que tendrá El Metaverso, su despliegue, implementación y masificación será posible gracias al Protocolo IPv6, una tecnología que ha dado solución a la disponibilidad de los recursos IP, evitando el engorroso procedimiento de la traducción de NAT, mejorando los tiempos de respuesta, disminuyendo el RTT o Delay y evitando la perdida de muchos paquetes, al tiempo que facilitará la simultaneidad de usuarios.

Todo lo anterior nos permite afirmar que El Metaverso sin IPv6, no sería posible.

 

Descargo de Responsabilidades: Este artículo corresponde a una revisión y análisis en el contexto de la transformación digital en la sociedad de la información, y está debidamente soportado en fuentes académicas y/o periodísticas confiables y verificadas, las cuales han sido demarcadas y publicadas.

La información que contienen este artículo periodístico y de opinión, no necesariamente representa la postura de Andinalink, o las entidades con las que desarrolla sus relaciones comerciales.

^[1] Artículo Andinalink: Metaversos y el Internet del Futuro

^[2] Artículo Andinalink: Metaversos: Expactativas VS Realidad

[3] En el artículo: El agotamiento del protocolo IP explicamos las características del protocolo TCP: El Agotamiento del Protocolo IP

[4] Documento estándar de referencia sobre el Modelo de conectividad OSI

[5] En el artículo: ¿Fue creada Arpanet para soportar una guerra nuclear?, se detalla las características e historia de Arpanet.:

[6] Documento de Lacnic sobre las fases del agotamiento de IPV4

[7] Documento de IETF sobre el lanzamiento oficial de IPV6 en su sexto aniversario

[8] Guía de referencia de Transición de IPV6 de Mintic Colombia

[9]  Guía de referencia de Transición de IPV6 de Mintic Colombia

[10]  Guía de referencia de Transición de IPV6 de Mintic Colombia

^[11] Artículo Andinalink sobre los Metaversos

[12] MARK IN THE METAVERSE: Facebook’s CEO on why the social network is becoming ‘a metaverse company: The Verge Podcast

^[13] Análisis de Alejandro Acosta de LACNIC, sobre el impacto del IPV6 en sistemas táctiles.

^[14] Artículo Andinalink: Los Wisp disminuyen la brecha digital

Microcuento de navidad de IPv4 e IPv6

Transcurre el año 2043, en un pequeño pueblo en Netland, justo antes de navidad, IPv6 se encuentra sentado en un pequeño microchip dentro de un router; como si fuese una chimenea sentía el calor de las compuertas lógicas y justo antes de ser inyectado en la red WiFi percibe una soledad y vienen muchos recuerdos, una imagen que ya hace mucho no se podría recuperar del caché del equipo, viene a su memoria un viejo compañero de guerra, un señor llamado IPv4 que casi nunca aparece en estos días. Lo primero que viene a su memoria eran las competencias que existían 20 años atrás, cuando su dueño les pedía hacer algo salían juntos lo más rápido con el objetivo de llegar primeros y darle respuesta lo más rápido posible. Siempre fue una carrera muy cerrada y el pronóstico del ganador era siempre reservado. Luego recuerda con dolor aquellos sufrimientos por los que pasaba IPv4 antes de llegar a su destino, era literalmente una mutación lo que ocurría, IPv6 nunca lo entendió pero sabe que no fueron momentos agradables, IPv4 a veces incluso ganaba la carrera pero el dueño no quedaba contento y no recibía su premio. Un recuerdo nada satisfactorio era la pérdida de algún compañero, sobre todo al comienzo de la misma, muy frecuentemente IPv4 sencillamente desaparecía en esos primeros 100 metros. Existía un recuerdo que siempre le sacaba una sonrisa a IPv6, rememoraba aquellos primeros momentos, cuando era aún un pequeño bebé en sus primeros años y no tenía buenos resultados en sus recorridos, comúnmente perdía. Hoy en día se llena de orgullo pensando que es un ganador que luchó innumerables batallas ante un gran guerrero. Nanosegundos antes sentir el viento dentro de la red WiFi, IPv6 toma ánimo, a pesar de que ya es un ganador no baja la guardia, lucha sus batallas y como deseo de año nuevo pide cosas sencillas: a) que no existan congestión de redes, b) adiós a las colisiones, c) que no haya pérdida de paquetes y que todo el planeta tenga Internet. Feliz navidad 2021 y feliz año 2022. Alejandro Acosta,