Estudio y Comparación de Métodos para la Implementación de Conectividad IPv6 en Redes sin Soporte Nativo

Equation Chapter 1 Section 1 Trabajo Fin de Grado en Ingeniería de las Tecnologías de Telecomunicación Estudio y Comparación de Métodos para la Implementación de Conectividad IPv6 en Redes sin Soporte Nativo Autor: Adrián Garrido Real Tutor: Juan Antonio Ternero Muñiz Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2025 iii Trabajo Fin de Grado en Ingeniería de las Tecnologías de Telecomunicación Estudio y Comparación de Métodos para la Implementación de Conectividad IPv6 en Redes sin Soporte Nativo Autor: Adrián Garrido Real Tutor: Juan Antonio Ternero Muñiz Profesor colaborador Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2025 v Trabajo Fin de Grado: Estudio y Comparación de Métodos para la Implementación de Conectividad IPv6 en Redes sin Soporte Nativo Autor: Adrián Garrido Real Tutor: Juan Antonio Ternero Muñiz El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2025 El Secretario del Tribunal vii Agradecimientos En primer lugar, me gustaría agradecer a mis padres por haberme apoyado durante todos estos años, por confiar siempre en mí y por ayudarme a no perder nunca las fuerzas ni la motivación para seguir adelante. También, agradecer a mi hermana, mi familia y mis amigos por estar siempre presentes, especialmente en los momentos más difíciles, brindándome su apoyo y su cariño. Quisiera dedicar una mención muy especial a mi abuela. Ella siempre tuvo la ilusión de verme graduado y cumplir mis sueños. Aunque, por desgracia, no haya podido acompañarme en este momento, sé que desde el cielo nunca ha dejado de apoyarme. Ella ha sido mi motor y mi fuerza en los momentos en los que estuve a punto de rendirme. En general, quiero agradecer a todas las personas que siempre han estado a mi lado, tanto en los buenos como en los malos momentos. Aunque algunas ya no están a mi lado, siempre guardaré cariño especial hacia cada una de ellas. Por último, agradecer a todos los profesores que he tenido a lo largo de la carrera, por compartir todo su conocimiento y contribuir a mi formación. En particular, quiero agradecer a mi profesor Juan Antonio Ternero por acompañarme durante el desarrollo de este proyecto y por estar dispuesto a ayudarme en cualquier necesidad. ix Resumen El uso de IPv6 ha dejado de ser algo futuro para convertirse en una necesidad actual, debido a la escasez de direcciones IPv4 que está provocando la migración hacia la nueva versión del protocolo IP. Este Trabajo Fin de Grado tiene como objetivo analizar y estudiar diferentes servicios que proporcionen conectividad IPv6 en redes donde la operadora no ofrece este direccionamiento de manera nativa. Para ello, el proyecto se inicia con un análisis detallado del protocolo IPv6, destacando sus características más relevantes. Seguidamente, analizamos distintos servicios que proporcionen conectividad IPv6 a la red, como TunnelBroker de Hurricane Electric, una VPN con soporte IPv6 y la creación de una VPN Wireguard configurando como servidor una VPS contratada, la cual posee una dirección pública IPv4 y direcciones globales IPv6. Posteriormente, estudiamos distintos parámetros de red claves para el correcto funcionamiento de la red, tales como latencia, RTT, pérdida de paquetes, ancho de banda, jitter, MTU y tiempo de resolución DNS. Para su evaluación, se emplean herramientas profesionales como PingPlotter, NetScanTools, WireShark, Mtr y SpeedTest para obtener mediciones precisas de cada servicio implementado. Para el proyecto, llevamos a cabo un conjunto de pruebas prácticas donde implementamos y configuramos los distintos servicios, midiendo y analizando cada parámetro estudiado previamente, comparando los resultados obtenidos para extraer una conclusión sobre cada servicio. Además, podremos observar las ventajas y desventajas de cada uno de ellos. Así, concluimos que mientras la conectividad Ipv6 nativa ofrece el mejor rendimiento de manera general, soluciones como los túneles o VPNs son alternativas fiables y que ofrecen un buen rendimiento para redes que no tengan conectividad Ipv6 de manera nativa. Finalmente, el proyecto cuenta con un apartado donde se incluyen propuestas para poder mejorarlo con nuevas extensiones futuras, convirtiéndose como una guía para implementar IPv6 en redes donde no se ofrece Ipv6 de manera nativa. ÍNDICE DE FIGURAS Figura 1-1 Impacto IPv6 global 1 Figura 2-1 Cabecera IPv6 4 Figura 2-2 Cabecera ICMPv6 7 Figura 3-1 Paquete IPv6 Nativo 13 Figura 3-2 Interfaz Servicio Nativo 13 Figura 3-3 Conectividad IPv6 Nativo 14 Figura 3-4 Paquete IPv4 Hurricane Electric 15 Figura 3-5 Paquete Ipv6 Hurricane Electric 15 Figura 3-6 Interfaz Hurricane Electric 16 Figura 3-7 Configuraciones Hurricane Electric 17 Figura 3-8 Conectividad IPv6 Hurricane Electric Windows 17 Figura 3-9 Conectividad IPv6 Hurricane Ubuntu 18 Figura 3-10 Paquete UDP VPN Hide.me 19 Figura 3-11 Configuración VPN Hide.me 19 Figura 3-12 Interfaz VPN Hide.me 20 Figura 3-13 Paquete IPv4 VPN Wireguard 21 Figura 3-14 Paquete IPv6 VPN Wireguard 21 Figura 3-15 Configuración Servidor Wireguard 22 Figura 3-16 Configuración Cliente Wireguard 23 Figura 3-17 Conectividad IPv6 VPN Wireguard 24 Figura 4-1 RTT 26 Figura 4-2 Pérdida de paquetes 27 Figura 4-3 Ancho de banda 28 Figura 4-4 Jitter 29 Figura 4-5 MTU 30 Figura 4-6 Tiempo de resolución DNS 30 Figura 4-7 Rutas 31 Figura 4-8 Herramienta NetScanTools 32 Figura 4-9 Herramienta PingPlotter 33 Figura 4-10 Herramienta Mtr 34 Figura 4-11 Herramienta Wireshark 35 xvii Figura 4-12 Web Speedtest 36 Figura 4-13 Comando Netsh Interface IPv6 Show Subinterfaces 36 Figura 4-14 Comando ifconfig 37 Figura 4-15 Herramienta nslookup 37 Figura 4-16 Herramienta dig 38 Figura 5-1 Resultado PingPlotter DNS IPv6 Nativo 40 Figura 5-2 RTT Mínima DNS IPv6 Nativo 40 Figura 5-3 RTT Máxima DNS IPv6 Nativo 41 Figura 5-4 RTT Media DNS IPv6 Nativo 41 Figura 5-5 RTT de resolución DNS IPv6 Nativo 42 Figura 5-6 RTT Minima Dominios IPv6 Nativo 42 Figura 5-7 RTT Máxima Dominios IPv6 Nativo 42 Figura 5-8 RTT Media Doninios IPv6 Nativo 43 Figura 5-9 Resultado PingPlotter IPv6 Hurricane Electric 44 Figura 5-10 RTT Mínima DNS Hurricane Electric Windows 44 Figura 5-11 RTT Maxima DNS Hurricane Electric Windows 45 Figura 5-12 RTT Media DNS Hurricane Electric Windows 45 Figura 5-13 Tiempo de resolución DNS Hurricane Electric Windows 46 Figura 5-14 RTT Mínima Dominios Hurricane Electric Windows 46 Figura 5-15 RTT Máxima Dominios Hurricane Electric Windows 47 Figura 5-16 RTT Media Dominios Hurricane Electric Windows 47 Figura 5-17 RTT Mínima DNS Hurricane Electric Ubuntu 48 Figura 5-18 RTT Máxima DNS Hurricane Electric Ubuntu 48 Figura 5-19 RTT Media DNS Hurricane Electric Ubuntu 49 Figura 5-20 Tiempos de resolución DNS Hurricane Electric Ubuntu 49 Figura 5-21 RTT Mínima Dominios Hurricane Electric Ubuntu 50 Figura 5-22 RTT Máxima Dominios Hurricane Electric Ubuntu 50 Figura 5-23 RTT Media Domimios Hurricane Electric Ubuntu 51 Figura 5-24 Resultado PingPlotter DNS VPN Wireguard 52 Figura 5-25 RTT Mínima DNS VPN Wireguard 52 Figura 5-26 RTT Máxima DNS VPN Wireguard 53 Figura 5-27 RTT Media DNS VPN Wireguard 53 Figura 5-28 Tiempo de resolución DNS VPN Wireguard 54 Figura 5-29 RTT Mínima Dominios VPN Wireguard 54 Figura 5-30 RTT Máxima Dominios VPN Wireguard 55 Figura 5-31 RTT Media Dominios VPN Wireguard 55 Figura 5-32 RTT Mínima Servicios NetScanTools/Ping 56 Figura 5-33 RTT Máxima Servicios NetScanTools/Ping 56 Figura 5-34 RTT Media Servicios NetScanTools/Ping 57 Figura 5-35 RTT Mínima Servicios PingPlotter/Mtr 57 Figura 5-36 RTT Máxima Servicios PingPlotter/Mtr 58 Figura 5-37 RTT Media Servicios PingPlotter/Mtr 58 Figura 5-38 Tiempos de resolución DNS Servicios 71 Figura 5-39 Tiempos Descargas Gran Volumen Servicios 71 Figura B-1 Servidor VPS 79 Figura B-2 Configuraciones VPS 79 Figura B-3 Ubicación VPS 80 xix Notación IPv6 Internet Protocol versión 6 IPv4 Internet Protocol versión 6 RFC Request For Comments TCP Transmission Control Protocol UDP User Datagram Protocol RIR Regional Internet Registry IANA Internet Assigned Numbers Authority ICMPv6 Internet Control Message Protocol version 6 VPN Virtual Private Network GRP Global Route Prefix SLAAC StateLess Address Auto Configuration ISP Internet Service Provider IGMP Internet Group Management Protocol ARP Address Resolution Protocol MTU Maximum Transmission Unit MAC Media Access Control NS Neighbor Solicitation NA Neighbor Advertisement RS RA Router Solicitation Router Advertisement DHCP Dynamic Host Configuration Protocol DAD Duplicate Address Detection MLD Multicast Listener Discovery DNS Domain Name System TTL Time To Live RTT Round-trip time VPS Virtual Private Server ISO International Organization for Standardization 1 1 INTRODUCCIÓN Y OBJETIVOS La evolución de Internet y su creciente demanda han provocado una escasez de direcciones IPv4. Este protocolo, es utilizado desde los inicios de Internet, ofreciendo un espacio de direcciones de 32 bits que, en un primer momento, se consideró suficiente, ya que nadie imaginaba la inmensidad y la rápida extensión que alcanzaría este protocolo. Con el paso del tiempo, la cantidad total de direcciones IPv4 disponibles fue disminuyendo considerablemente, temiendo una posible escasez de direcciones en un periodo corto de tiempo. Por esta razón, se planteó y desarrolló la idea de migrar hacia un sistema más escalable y eficiente, con una nueva versión del protocolo IP, conocida como IPv6. El protocolo IPv6, definido en el RFC 2460, incorporó numerosas mejoras y resolvió el problema principal que estaba sometiendo al mundo moderno: la escasez de direcciones IPv4. No obstante, su adopción al mundo está siendo más lento de lo esperado, ya sea por el temor de interrumpir servicios existentes o simplemente por el acostumbramiento del mundo a una vida con IPv4. Ante esta situación, los profesionales se vieron obligados a desarrollar soluciones de transición para el protocolo IPv4 para combatir esa escasez de direcciones mientras la adopción de IPv6 se hiciera realidad. Figura 1-1 Impacto IPv6 global [1] 1.1 Objetivos El objetivo principal de este proyecto es analizar el comportamiento de distintos servicios implementados para poder obtener conectividad IPv6 en redes que no disponen inicialmente de este protocolo de forma nativa por parte del proveedor de servicios. Los objetivos a tener en cuenta son los siguientes: ● Analizar el protocolo IPv6, sus características, novedades y su aplicación al mundo real. ● Analizar y estudiar las diferentes alternativas de acceso a IPv6, tales como túneles y VPN. Introducción y Objetivo 2 ● Realizar pruebas de conectividad a los diferentes servicios de red utilizando herramientas prácticas como Ping, dig, Wireshark, etc. ● Comparar los resultados obtenidos entre los distintos servicios, extrayendo conclusiones sobre su eficiencia, estabilidad, implementación y rendimiento. 1.2 Metodología de trabajo Para una organización adecuada, el proyecto lo hemos estructurado con una metodología basada en las siguientes fases: ● Investigación: Llevamos a cabo una investigación previa sobre los conceptos básico y fundamentales necesarios para poder desarrollar el proyecto. Realizamos una investigación detallada del protocolo IPv6 y de los diferentes servicios para poder implementar a una red sin IPv6 nativa. Asimismo, realizamos un estudio profundo y detallado de los distintos parámetros que afectan al rendimiento de la red, así como las herramientas profesionales utilizadas para poder realizar las mediciones correspondientes. ● Implementación práctica: Configuración e implementación de los distintos tipos de servicios para la obtención de IPv6. ● Pruebas: Realización de las pruebas para medir los distintos parámetros de red que afectan a cada servicio. Utilizamos software profesional para llevar a cabo las pruebas y obtener un análisis detallado. ● Comparación: Comparación de los resultados obtenidos para cada servicio implementado, evaluando su comportamiento para obtener el que ofrece mayor rendimiento. ● Documentación: Elaboración de un documento técnico que recoja todo el proceso seguido en el desarrollo del proyecto. 1.3 Estructura del Proyecto Vamos a dividir el proyecto en los siguientes apartados: ● Introducción: Conceptos fundamentales que abordaran al proyecto, así como un estudio previo de la estructura y el desarrollo del proyecto. ● IPv6: Análisis en profundidad del protocolo IPv6, incluyendo los fundamentos teóricos, como su cabecera, direccionamiento, mejoras frente a IPv4, nuevos procedimientos, entre otros. ● Servicios y herramientas: Descripción y estudio previo de los servicios implementados para poder obtener conectividad IPv6, así como las herramientas empleadas para llevar a cabo el análisis. ● Pruebas: Análisis detallado de los resultados obtenidos en cada servicio implementado. ● Comparaciones y futuro: Conclusiones sobre el proyecto, realizando una valoración final y posibles mejoras para una extensión futura. 3 2 INTERNET PROTOCOL VERSION 6 (IPV6) E n este apartado vamos a introducir el concepto del protocolo IPv6, clave para el desarrollo del proyecto. Explicaremos todo lo esencial de este protocolo, las principales diferencias respecto a su versión anterior, y ofreceremos una visión a futuro con una reflexión subjetiva del comportamiento que adoptará este protocolo en los próximos años. 2.1. Introducción El protocolo IPv6 (Internet Protocol versión 6) es una nueva versión del protocolo IP (Interrnet Protocol), definida en el RFC 2460, diseñada para sustituir a IPv4 (Internet Protocol versión 4). 2.1.1 Cabecera IPv6 La cabecera del protocolo IPv6 tiene una extensión fija de 40 bytes, lo que beneficia al proceso de encaminamiento en los equipos intermedios. A diferencia de IPv4, cuya cabecera tiene una longitud variable, IPv6 elimina y modifica varios campos de IPv4, reduciendo la complejidad en el procesamiento de los paquetes y mejorando el rendimiento de la red. Los principales cambios de la cabecera IPv6 con respecto a la cabecera IPv4 son los siguientes [2]: ● Eliminación de las opciones IP, sustituidas por las cabeceras de extensión. Este mecanismo nos permite añadir información adicional únicamente cuando sea necesario. Además, son procesadas por el destino, mejorando considerablemente el rendimiento de los nodos intermedios. ● Eliminación del tratamiento de la fragmentación, eliminándose los campos de Identificador, Flags y Offset presentes en IPv4. La fragmentación ahora es gestionada exclusivamente por el emisor, indicada a través de una cabecera de extensión. ● Eliminación de la suma de verificación (Checksum), asumiendo que las capas superiores ya realizan estas verificaciones de integridad. ● Eliminación del campo de longitud de la cabecera, pasando a ser innecesario por el tamaño fijo de 40 bytes que presenta la cabecera de IPv6. ● Uso de un alineado a 64 bits, ayudando a reducir la carga de procesamiento en los routers al reenviar paquetes. La cabecera IPv6 se compone de la siguiente estructura [2]: Internet Protocol Version 6 (IPv6) 4 Figura 2-1 Cabecera IPv6 [2] La función de estos campos es la siguiente: ● Version: Es un campo de 4 bits que nos indica la versión del Protocolo, en este caso la versión 6. ● Traffic Class: Campo de 8 bits utilizado por los nodos de origen y/o por los routers para clasificar los paquetes IP según clases de tráfico o prioridades. ● Flow Label: Es un campo de 20 bits que nos permite identificar los flujos de paquetes que requieren un tratamiento especial. Entendemos por flujo a un conjunto de paquetes que son tratados de la misma manera. ● Next Header: Campo de 8 bits utilizado para indicar el siguiente protocolo que le sigue a la cabecera IPv6. A través de este campo, podemos indicar protocolos como TCP o UDP, de la capa de transporte, o bien podemos indicar una funcionalidad exclusiva de IPv6 llamadas cabeceras de extensión. ● Hop Limit: Campo de 8 bits que representa el número máximo de saltos que un paquete puede realizar por la red antes de pasar a ser descartado. Empieza con un valor determinado que se decrementará con cada salto que realice por la red. Si su valor llega a 0, procederá a ser descartado, evitando asi la aparición de bucles en la red. ● Source Address: Campo de 128 bits que nos indica la dirección IPv6 del equipo. ● Destination Address: Campo de 128 bits que nos indica la dirección IPv6 del equipo destino al que queremos enviar el paquete. 2.1.2 Direccionamiento IPv6 El direccionamiento IPv6 constituye una versión mejorada respecto al protocolo IPv4, ampliando el espacio de direcciones disponible. Sus direcciones pasan a tener una longitud de 128 bits, lo que permite una cantidad de direcciones prácticamente ilimitada [3]. 2.1.2.1 Formato General Estas direcciones están divididas en tres campos de longitud variable. Estos campos son [4]: 5 Internet Protocol Version 6 (IPv6) ● Global Routing Prefix (GRP): Es el prefijo de red asignado a una organización o proveedor. Identifica la red de manera global. ● ID Subred: Es el rango de dirección utilizado para la creación de subredes. ● ID Interfaz: Identifica de manera única una interfaz en el enlace. Es el rango de direcciones que puede tomar un equipo dentro de la subred establecida. Una dirección IPv6 se compone de 8 bloques de 16 bits expresados en formato hexadecimal y separados por el carácter “:”. Un ejemplo de dirección IPv6 seria 2001:0000:130F:0000:0000:09AB:234a:1231. La particularidad de estas direcciones es que se pueden simplificar en ciertos momentos. Existen varias reglas para aplicar la simplificación de direcciones. Estas son: ● Simplificación de ceros a la izquierda: Los ceros iniciales de cada bloque son opcionales y pueden ser simplificados. ● Omisión de bloques consecutivos de ceros: Varios bloques sucesivos a 0 pueden ser sustituidos por “::”, aunque este procedimiento solo puede realizarse una única vez por dirección. Siguiendo las reglas descritas anteriormente, la dirección anterior se puede simplificar de la siguiente manera: 2001:0:130F::9AB:234a:1231. 2.1.2.2 Tipos de dirección A diferencia de IPv4, una misma interfaz en IPv6 podemos encontrar varios tipos de direcciones asignadas. Podemos clasificar los tipos de direcciones en tres grandes grupos. Estos son [4]: ● Unicast: Son identificadores para una interfaz en particular. Designa una interfaz de un nodo. ● Anycast: Es una dirección o un identificador asignado a varias interfaces de equipos distintos. Un paquete enviado a esta dirección será recibido por el nodo más cercano. Son direcciones que no deben usarse como dirección origen ni por un sistema final. Su uso es en parte experimental. ● Multicast: Son direcciones asignadas a varias interfaces de equipos distintos. El paquete con destino esta dirección será entregado a todas las interfaces que posean esta dirección. Dentro de las direcciones Unicast nos encontramos con los siguientes tipos de direcciones: ● Globales: Son el tipo de dirección utilizada para el encaminamiento a través de Internet. Esta dirección está dividida en tres campos: o GRP (Global Route Prefix): El prefijo identifica el tipo de dirección. o SLA (Site-Level Aggregator): Usada por el poseedor del GRP para organizar su red jerárquicamente en distintas subredes. o Interface-ID: Identifica interfaces en un enlace de manera única. ● Local a la ubicación: Son unas direcciones en el rango FEC0::/10. Son similares a las direcciones privadas de IPv4 (192.168.x.x). Además, no deben ser enrutadas en Internet. Sin embargo, se han convertido en direcciones obsoletas y se han reemplazado por las direcciones localmente únicas. ● Local al enlace: Son direcciones en el rango FE80::/10, las cuales son obligatorias y no deberían aparecer en Internet. Son utilizadas para funciones como la autoconfiguración o para el descubrimiento de vecinos, entre otras funciones. ● Localmente única: Estas direcciones están en el rango FC00::/8 o FD00::/8. Son direcciones privadas no enrutables en Internet, pero válidas en áreas reducidas. Además, son direcciones independientes de Métodos de acceso a IPv6 12 Figura 3-1 Paquete IPv6 Nativo 3.1.2 Configuración Servicio Nativo En este proyecto para realizar el estudio sobre los distintos servicios que ofrecen IPv6, utilizaremos una red doméstica la cual contiene IPv6 nativo ofrecido por parte de la operadora de red. Como dirección IP tendremos la dirección 2a0c:5a84:7201:ce00:bb30:7323:aedb:13e3, obtenida a través de un servidor DHCP configurado en el router. Además, realizaremos el estudio de esta red probando diferentes tipos de servidores DNS para obtener la mayor velocidad y el mejor tiempo de respuesta posible. Utilizando el comando ipconfig, podemos ver la configuración de la interfaz de red a través de la siguiente imagen: Figura 3-2 Interfaz Servicio Nativo Una vez configurado y establecido el servicio, podemos corroborar que la red contiene conectividad IPv6 a través de distintas webs. Podemos ver su conectividad a través de la siguiente imagen: 13 Métodos de acceso a IPv6 Figura 3-3 Conectividad IPv6 Nativo 3.2 Túneles Ipv6 sobre Ipv4 Cuando la operadora de red no nos proporciona un plan de direccionamiento IPv6 de manera nativa, una gran alternativa a la que podemos recurrir es la de utilizar túneles, cuya función es encapsular paquetes IPv6 dentro de paquetes IPv4. Esta solución permite un rendimiento más que aceptable, proporcionando una buena experiencia al usuario. 3.2.1 TunnelBroker (Hurricane Electric) TunnelBroker de Hurricane Electric [16] es uno de los servicios más populares y utilizados hoy en día, ya que se trata de un servicio gratuito que permite a cualquier usuario de una red que disponga de una dirección IPv4 pública libre de CG-NAT, poder obtener una dirección IPv6 global, aunque su operadora no se la proporcione de manera nativa. 3.2.1.1 Funcionamiento El servicio consta de la creación de un túnel IPv6 sobre IPv4, utilizando el protocolo 41, facilitando el acceso a la red IPv6 de manera global. Su funcionamiento una vez realizado la configuración correspondiente es el siguiente [16] [17]: ● Una vez realizada la configuración del túnel en el equipo origen, el usuario recibirá un prefijo /64 junto con una dirección IPv6 global, teniendo la posibilidad de poder acceder a Internet. ● Cuando el usuario quiere acceder a un dominio como Google.com, el equipo genera un paquete IPv6 para resolver el dominio mediante la consulta a un servidor DNS, el cual le proporciona la dirección IPv6 destino correspondiente. ● El paquete IPv6 generado para acceder a Google.com por medio de IPv6, se encapsula dentro de un paquete IPv4 usando el protocolo 41. La dirección IPv4 origen es la del equipo origen y la dirección destino la IPv4 del otro extremo del túnel, el cual será el servidor de Hurricane Electric. ● El paquete encapsulado es enviado por el túnel, el cual viaja como un paquete IPv4 normal con la diferencia de que dentro lleva encapsulado un paquete IPv6. Métodos de acceso a IPv6 14 ● Una vez recibido por el extremo del túnel, el servidor desencapsula el paquete, quedándose con el paquete IPv6 original. ● Este paquete IPv6 es enviado por la red IPv6 global hasta alcanzar su destino. ● Una vez el destino recibe el paquete, envía su respuesta a través de un paquete IPv6 dirigido al servidor de Hurricane Electric. ● El servidor vuelve a encapsular el paquete IPv6 de respuesta en un paquete IPv4, reenviándolo de vuelta al usuario por el túnel. ● Una vez llega al equipo, desencapsula el paquete IPv4 recibido, recuperando el paquete IPv6 de respuesta para su posterior procesamiento. Como podemos intuir, es un proceso más complejo que el plan de direccionamiento nativo, ya que se deben de utilizar procedimientos como la encapsulación del paquete Ipv6 en un nuevo paquete IPv4, además de un mayor número de saltos intermedios para poder llegar al destino. Esto se traduce en una subida en parámetros como la latencia y la pérdida de paquetes, pero sigue siendo una solución bastante precisa y eficiente. A través de la herramienta Wireshark podemos analizar los paquetes enviados por la red: Figura 3-4 Paquete IPv4 Hurricane Electric Figura 3-5 Paquete Ipv6 Hurricane Electric 3.2.1.2 Configuración Servicio Hurricane Electric Para el servicio TunnelBroker de Hurricane Electric, la red debe estar libre de la restricción impuesta por muchas compañías de red, llamada CG-NAT. Esta restricción hace que tu red no disponga de una dirección IPv4 pública que sea exclusivamente de tu propiedad, por lo que será compartida por miles de usuario realizando NAT en el router del operador. Al realizar este procedimiento, los servicios externos no pueden ver tu dirección desde fuera, por lo que servicios como este de Hurricane Electric resulta imposible instalarlos teniendo esta restricción. Sin embargo, para librarse de esta restricción, podemos contactar con nuestra operadora de red para que a través de una subida de precio te liberen de esta restricción y te proporcionen una dirección IPv4 pública y exclusiva. 15 Métodos de acceso a IPv6 Para este proyecto, la red sin IPv6 tenía impuesta esta restricción, por lo que resultaba imposible la instalación del servicio. Afortunadamente, comentando la situación con el operador de red, a través de un pago extra la red fue liberada de la restricción impuesta. Para la instalación y configuración del servicio, seguimos los siguientes pasos: ● Para la instalación del servicio Hurricane Electric, en primer lugar, debemos acceder a la web oficial de Hurricane Electric. Una vez dentro elegimos la opción Free IPv6 Tunnel Broker donde tendremos que registrarnos. ● Posteriormente, una vez realizado el registro, habría que acceder a la pestaña Create Regular Tunnel donde habría que especificar tu dirección IPv4 pública y la zona geográfica donde quieres que se aloje. ● Finalmente, una vez introducido estos valores, se crea el túnel. Una vez realizado la creación, el servicio nos proporciona varios parámetros muy interesantes para poder configurar el túnel en tu equipo. ● Para la configuración del servicio, el usuario tiene que seleccionar la pestaña Example Configurations y seleccionar el sistema operativo donde desee configurar el servicio. ● Una vez seleccionado, mostrará una serie de comandos para que el usuario ejecute en su equipo y poder así completar la instalación de este servicio. Tras el registro y la creación del túnel, obtuvimos varios parámetros de configuración claves para poder obtener conectividad IPv6. Como dirección IP, el túnel nos ofrece la dirección IPv6 2001:470:1f08:3e9::2/64 [16]. El servidor de Hurricane Electric o el extremo remoto del túnel, utiliza la dirección IPv6 2001:470:1f08:3e9::1/64 y como dirección IPv4 la 216.66.80.26. Además, nos proporciona un prefijo de red el cual nos permite la posibilidad de asignar direcciones IPv6 a otros equipos interesados en obtener un plan de direccionamiento IPv6. Para la resolución de dominios, nos ofrece varios servidores DNS, uno de ellos utilizando IPv6 y el otro IPv4. El servidor DNS que utiliza IPv6 utiliza la dirección 2001:470:20::2. Para el caso de IPv4, el servidor utiliza la dirección 74.82.42.42. Por tanto, el conjunto de todos los parámetros nos permite implementar una red IPv6. Esta red nos permite gozar de un plan de direccionamiento IPv6, pudiendo acceder de manera completa a la red global IPv6 con un excelente rendimiento. Para poder ver la configuración de la interfaz de red, utilizamos el comando ipconfig: Figura 3-6 Interfaz Hurricane Electric Métodos de acceso a IPv6 16 Figura 3-7 Configuraciones Hurricane Electric [16] Para el servidor de Hurricane Electric implementado en Windows, podemos afirmar la conectividad a través de la siguiente imagen: Figura 3-8 Conectividad IPv6 Hurricane Electric Windows [15] Como vemos en la Figura 3-8, podemos afirmar que efectivamente se establece la conectividad en la red, mostrándonos la dirección IPv6 asignada y su ubicación, la cual nos indica que es de Hurricane. Para el mismo servicio de Hurricane pero implementado en el sistema operativo Ubuntu, podemos confirmar su conectividad a través de la siguiente imagen: 17 Métodos de acceso a IPv6 Figura 3-9 Conectividad IPv6 Hurricane Ubuntu [15] 3.2.2 VPN con soporte Ipv6 Una VPN es una red virtual privada. Su objetivo es mejorar la privacidad, la seguridad y mantener el anonimato mientras navegas, permitiendo acceder a servicios de otros lugares que no son accesibles desde tu región [18]. Este software permite ocultar tu dirección IP real, proporcionando una dirección IP ubicada en otra zona geográfica. Además, las comunicaciones entre el equipo y el servidor están encriptadas, garantizando al usuario una mayor privacidad. Muchas de estas VPNs ofrecen un plan de direccionamiento IPv6, haciendo que redes que no dispongan de IPv6 de manera nativa, puedan gozar de este protocolo. 3.2.2.1 Funcionamiento El funcionamiento de una VPN con soporte para direccionamiento IPv6 es el siguiente [18]: ● Una vez completada la configuración correspondiente, el cliente obtiene una dirección IPv6 global para ser usada a través de Internet. Al no disponer de IPv6 en la red local, el paquete IPv6 no puede ser enviado directamente, por lo que es necesario encapsular el paquete dentro de un paquete IPv4. ● El cliente al querer acceder a algún destino IPv6 en Internet, por ejemplo Google.com, la resolución DNS se realiza a través del túnel establecido, obteniendo la dirección IPv6 del dominio asociado. ● El equipo origen genera un paquete IPv6 con la IP que le ha entregado el servidor DNS, y lo encapsula en un paquete UDP dentro de IPv4. ● El paquete UDP atraviesa el túnel hasta el servidor, el cual lo descifra y desencapsula recuperando el paquete IPv6 original, reenviándolo por la red IPv6 hasta el destino. ● Una vez llega al destino, este genera un paquete IPv6 de respuesta enviándolo de vuelta al cliente. ● El servidor, lo vuelve a cifrar y encapsular en un paquete UDP con IPv4 y lo envía de vuelta por el túnel hasta ser recibido por el cliente. ● El cliente desencapsula el paquete, obteniendo el paquete IPv6 original para poder procesarlo posteriormente. Las VPNs con soporte para direccionamiento IPv6 son una opción a tener en cuenta a la hora de querer obtener Métodos de acceso a IPv6 18 conectividad IPv6. El inconveniente sigue siendo el tema de la velocidad que, en aspectos como la descarga de archivos grandes, puede notarse una bajada de rendimiento. Aun así, es una gran alternativa para tener en cuenta a la hora de querer obtener IPv6. A través de la herramienta Wireshark, podemos observar los paquetes que se tramitan por lar red para cualquier servicio implementado: Figura 3-10 Paquete UDP VPN Hide.me 3.2.2.2 Configuración Servicio VPN Hide.me Para nuestro proyecto, utilizaremos el software Hide.me [19], que nos ofrece un plan gratuito de un mes proporcionándonos un plan de direccionamiento IPv6, ideal para el estudio que estamos realizando. El proceso de configuración es el siguiente: ● A través de página oficial de Hide.me, podremos elegir el plan gratuito seleccionando el icono del sistema operativo donde queremos instalarlo. ● Al seleccionar el icono te descarga un ejecutable, el cual al iniciarse aparece una interfaz gráfica. A través de esta gráfica puedes elegir utilizar el plan gratuito. ● Una vez dentro, simplemente basta con iniciar la VPN, seleccionar la región geográfica que nos interese y darle a comenzar. Una vez establecido la conexión, el sistema operativo crea una nueva interfaz de red, donde se asignan una dirección IPv4 pública y direccionamiento IPv6, el cual será de gran utilidad para realizar el estudio correspondiente en nuestro proyecto. 19 Métodos de acceso a IPv6 Figura 3-11 Configuración VPN Hide.me A través del comando ipconfig, podemos observar la configuración de la interfaz de red: Figura 3-12 Interfaz VPN Hide.me 3.2.3 VPN con Wireguard con servidor una VPS Wireguard es un protocolo VPN que se caracteriza por ser extremadamente simple, ya que tiene un código base bastante pequeño en comparación a otras soluciones como OpenVPN. Esta reducción de código hace que sea una solución bastante rápida y para nada complejo [20]. También, ofrece una criptografía moderna, implementando últimas tecnologías criptográficas para asegurar las conexiones. Además, se integra bastante bien con muchos sistemas operativos, haciendo que sea bastante versátil. Para este proyecto, hemos realizado el estudio de Wireguard implementando como servidor y alojador del direccionamiento IPv6 una VPS que hemos contratado previamente. Un VPS es un entorno virtualizado dentro de un servidor físico. Dentro del servidor físico, se extienden varios servidores virtuales independientes, con recursos dedicados, a pesar de compartir el mismo hardware con otros VPS. Cada VPS funciona como una máquina virtual aislada con sus propias características. Además, posee bastante flexibilidad, ya que permite al usuario realizar los cambios que desee sin provocar interrupciones. Métodos de acceso a IPv6 20 3.2.3.1 Funcionamiento Una vez realizada la configuración en ambos extremos, el funcionamiento es el siguiente [20]: ● En primer lugar, una vez configurado ambos extremos, se establece un túnel a partir de claves públicas y privadas y se establece una conexión segura a través del protocolo de transporte UDP. ● El equipo cliente quiere enviar tráfico IPv6, enviando por ejemplo una consulta al dominio Google.com ● El equipo realiza una consulta al servidor DNS que haya sido configurado para obtener la dirección IPv6 del dominio. ● Una vez obtenida, el cliente crea un paquete IPv6 que Wireguard cifra y encapsula dentro de un paquete UDP con dirección IPv4 destino la IP pública de la VPS. ● Este paquete es enviado por la red, atravesando los nodos intermedios hasta ser recibido por el servidor VPN que en este caso es la VPS. ● El paquete se desencapsula, recuperando el paquete IPv6 original. ● El servidor VPS encamina el paquete IPv6 original por la red global IPv6 hasta su destino. ● Cuando el destino recibe el paquete IPv6, genera un paquete IPv6 de respuesta de vuelta al servidor. ● El servidor recibe el paquete, cifrándolo nuevamente y lo encapsula dentro de un paquete UDP con IPv4, el cual envía de vuelta al cliente. ● El cliente recibe el paquete, lo desencapsula y recupera el paquete IPv6 original para poder procesarlo posteriormente. Este servicio es una gran solución para el problema del direccionamiento IPv6. Como hemos comentado, es una VPN bastante rápida por su pequeño código base, con apenas 3000 líneas de código. Además, posee una buena seguridad y se integra muy bien con muchos sistemas operativos. El inconveniente es que contratar una VPS no es gratis, por lo que debe pagarse una cuota mensual para poder tener siempre el servidor activo. Por lo demás, es una solución bastante fiable, rápida y estable. Utilizando la herramienta Wireshark, podemos observar los paquetes enviados por la red para analizar su contenido y poder analizar con más detalle los servicios implementados: Figura 3-13 Paquete IPv4 VPN Wireguard 21 Métodos de acceso a IPv6 Figura 3-14 Paquete IPv6 VPN Wireguard 3.2.3.2 Configuración Servicio Wireguard+VPS Para realizar el proyecto, hemos considerado elegir una VPS a través del proveedor Heztner [21], que destaca por su reconocida fiabilidad y su costo, el cual es bastante reducido. Además, la VPS viene con una dirección IPv4 pública y un rango de direcciones IPv6 globales, perfecto para nuestro estudio. En cuanto a la conectividad que nos ofrece, este servicio trabaja tanto con IPv4 como con IPv6, algo que es fundamental para nuestro proyecto. La dirección IPv4 que trae asignada es la 195.201.217.41 y su prefijo IPv6 global la 2a01:4f8:1c0c:7b00::/64. Para la configuración del servidor, hemos utilizado la VPS de Hetzner la cual contiene el sistema operativo Ubuntu. Su configuración se puede observar en la imagen siguiente: Figura 3-15 Configuración Servidor Wireguard Como podemos observar en la Figura 3-15, en la sección Interface vamos a definir la configuración principal del servidor. En el campo Address especificamos la dirección IPv6 que va a tener el servidor en el túnel. Además, este servidor escucha conexiones en el puerto que le especifiquemos en la opción ListenPort. PostUp y PostDown son opciones que utilizamos en la configuración de Wireguard que se ejecutan al activar o desactivar la interfaz de red wg0. Al encender la interfaz establecemos con sysctl -w net.ipv6.conf.all.forwarding=1 el reenvío de paquetes IPv6. Además, empleamos varias reglas de firewall que pemiten el reenvío del tráfico a través del túnel. Al apagar la interfaz, utilizamos ip6tables -D FORWARD para eliminar todas las reglas creadas previamente cuando estaba encendida. En la sección Peer es donde se configura cada cliente que quiere tener acceso a este servidor. Como podemos observar, tenemos tres clientes configurados en el servidor y para su configuración simplemente basta con indicar su clave pública y la opción AllowedIPs donde se especifica la dirección o el prefijo del cliente. Parámetros de evaluación y herramientas empleadas 28 28 mucho menor. Además, disponer de una buen rendimiento y experiencia en aplicaciones en tiempo real, como videollamadas, juegos en línea, entre otros. Este parámetro se puede medir con muchas herramientas. Una de las más populares es la web speedtest.net, que evalúa el ancho de banda de nuestra red y nos proporciona la medida del ancho de banda de descarga y subida. El ancho de banda recomendado por usuario para cada servicio lo podemos representar en la siguiente tabla: Servicio Ancho de banda recomendado Navegación Web 3-5 Mbps Correo electrónico 3-5 Mbps Descarga de archivos 10-50 Mbps Juegos en línea 50-100 Mbps Descarga de archivos de gran tamaño 100-150 Mbps Transmisión de video en diferentes resoluciones 5-15 Mbps Tabla 4-1 Ancho de banda recomendado [29] El ancho de banda necesario es el que necesita cada equipo de la red para realizar cada actividad de las mencionadas. Cada una de ellas restará un porcentaje de ancho de banda total disponible. Por tanto, mientras más usuarios existan en la red con requerimientos altos de red, conviene tener un buen ancho de banda para que todos los servicios previamente analizados estén bien cubiertos y no ofrezcan una mala experiencia al usuario. Figura 4-3 Ancho de banda 4.1.4 Jitter El jitter mide la variación en el tiempo de llegada de los paquetes de datos en una red. Indica si los paquetes llegan de manera constante o presentan variaciones en su retardo [30]. Para poder entenderlo de una manera mucho más práctica, pondremos un ejemplo. Imaginemos que enviamos cada 20 milisegundos dos paquetes a un destino en concreto. El primer paquete llega en 20 ms y el segundo en 22 ms. Si los dos paquetes hubiesen llegado en 20 milisegundos, no existiría jitter. Pero al existir una variación en los tiempos, tendremos un jitter de 2 milisegundos. Las consecuencias que pueden causar la aparición del jitter son varias. Las más comunes son las siguientes: ● Hardware de baja calidad: Un hardware o infraestructura de red de una baja calidad puede provocar que las señales se retrasen durante la transmisión. ● Red congestionada: Una red congestionada puede provocar que los paquetes se retrasen, aumentando el jitter. ● Ruta variable: Los paquetes no siempre siguen una ruta lineal de origen a destino, muchos pueden tomar diferentes rutas para el mismo destino, desembocando en tiempos de llegadas diferentes. El jitter tiene un mayor impacto en servicios en tiempo real, como las videollamadas, juegos en línea o llamadas VoIP. Un jitter elevado puede provocar la aparición de interrupciones, retrasos y, en general, problemas que impiden el correcto funcionamiento de estos servicios. Por el contrario, el jitter apenas influye en servicios como la navegación web, descarga de archivos, correo electrónico, entre otros. En general, los servicios en tiempo real deben de tener un bajo jitter para mantener una calidad constante. Mantener el jitter por debajo de los 30 milisegundos es lo ideal para el correcto funcionamiento de estos servicios. Para medir este parámetro de red podemos utilizar varias herramientas. Una de las más populares es la web SpeedTest de Cloudflare, la cual hace una medición de varios parámetros de red, entre los que se encuentra el jitter. Figura 4-4 Jitter 4.1.5 MTU La MTU determina el tamaño máximo de un paquete de datos que puede ser enviado a través de la red sin tener que recurrir al proceso de fragmentación. Su unidad de medida es el byte [31]. Si un paquete excede el MTU permitido, deberá ser fragmentado en varios paquetes más pequeños, provocando una mayor latencia y afectando negativamente al rendimiento general de la red. Una buena configuración de MTU puede mejorar considerablemente la eficiencia de la red, reduciendo la fragmentación de paquetes. En cambio, una mala configuración de MTU puede generar una mayor cantidad de paquetes, trayendo consigo una posible sobrecarga y afectando negativamente al rendimiento general de la red. El valor de MTU puede variar dependiendo del tipo de conexión de red. Por ejemplo, en redes Ethernet lo común es tener una MTU de 1500 bytes. Sin embargo, este valor puede variar dependiendo de la configuración de red. Para medir este parámetro de red podemos utilizar varias herramientas: ● En Windows, una herramienta muy popular para comprobar la MTU de una interfaz es netsh. El comando netsh interface ipv4/ipv6 show subinterfaces, te permite ver entre otros parámetros la MTU que tiene cada interfaz, tanto para IPv4 como para el protocolo IPv6. ● En Linux, los comandos como ip link show o ifconfig nos permiten ver las interfaces de red y su configuración, donde se indica la MTU. Parámetros de evaluación y herramientas empleadas 30 30 Además, estas herramientas te dan la opción de poder modificar la MTU que tienen las interfaces por defecto, ya sea de manera temporal o permanente. Figura 4-5 MTU 4.1.6 Tiempo de resolución DNS El tiempo de resolución DNS es un parámetro con el que podremos calcular el tiempo que un equipo tarda en traducir un dominio a su dirección IP. Es un proceso necesario y obligatorio, ya que los equipos se comunican por IPs y no por dominios [32]. Los dominios son utilizados para ofrecer una mejor experiencia de navegación al usuario al no tener que depender de memorizar cada dirección IP de cada servicio al que quiera acceder. El tiempo de resolución DNS incluye la consulta que un equipo realiza al servidor DNS correspondiente y la respuesta que este le devuelve. Además, existe la posibilidad de que el servidor DNS tenga que consultar a otros servidores para obtener una respuesta definitiva. Este proceso suele ser del orden de milisegundos. Un tiempo de resolución bajo reduce el tiempo de carga de una página web, mejorando la experiencia del usuario. Para ofrecer una buena experiencia de usuario lo ideal es mantener la resolución DNS por debajo de los 100 milisegundos. Aunque lo óptimo es tener un tiempo de resolución DNS por debajo de los 50 milisegundos [30]. Para medir este parámetro de red utilizamos varias herramientas: ● Para el sistema operativo Windows, utilizamos la herramienta nslookup para poder realizar una consulta al servidor DNS para un dominio asociado. Combinando esta herramienta con la herramienta Wireshark, podremos capturar los paquetes que se tramitan para esa resolución DNS. A través de esa captura, podemos calcular la diferencia de tiempo entre la solicitud y la respuesta, obteniendo así el tiempo de resolución DNS. ● Para el sistema operativo Linux, utilizamos la herramienta dig que realiza la misma función que nslookup, pero además nos proporciona el tiempo que ha tardado en realizar la consulta, eliminando la necesidad de usar Wireshark para calcular los tiempos de resolución. Figura 4-6 Tiempo de resolución DNS 4.1.7 Rutas La ruta es el camino lógico y físico que siguen los paquetes desde su origen hasta el destino. Este camino no siempre es directo, sino que en muchas ocasiones necesita pasar por nodos intermedios que se encargan de encaminar el paquete hasta el destino. Los diferentes saltos entre sistemas intermedios son posibles gracias a la tabla de encaminamiento de cada router, la cual es utilizada para encaminar el paquete recibido por la interfaz adecuada, basándose en la dirección IP destino. Para conocer la ruta completa que sigue un paquete tenemos varias herramientas: ● En Linux, la más popular es la herramienta traceroute, la cual realiza un análisis detallado de cada salto que tiene que realizar el paquete para llegar a su destino. ● En Windows se utiliza tracert, que realiza la misma función que el comando traceroute de Linux. Estas herramientas nos proporcionan el RTT entre el origen y cada salto, indicando la IP de cada nodo intermedio. Conocer la ruta que sigue un paquete nos sirve para realizar un diagnóstico de red, pudiendo detectar problemas que estén ocurriendo en algún punto intermedio de esta. Figura 4-7 Rutas Parámetros de evaluación y herramientas empleadas 32 32 4.2 Herramientas utilizadas En el desarrollo de este proyecto hemos utilizado los sistemas operativos Windows y Linux, concretamente Windows 11 y Ubuntu. Para ello, se han implementado distintas herramientas específicas para el cálculo de cada parámetro de red. A continuación, comentamos las principales herramientas empleadas y su utilidad en el proyecto. 4.2.1 NetScanTools NetScanTools es un software diseñado para profesionales de redes. Es una herramienta diseñada para sistemas operativos Windows, ofreciendo una interfaz gráfica bastante intuitiva donde podemos llevar a cabo diversas opciones para realizar un análisis profesional de red [33]. En este proyecto, utilizamos la licencia gratis que nos ofrece este software, que permite un uso durante un tiempo limitado para llevar a cabo todas las mediciones sobre los distintos servicios implementados. En nuestro caso, utilizamos este software para realizar pruebas a los distintos servicios implementados, midiendo tanto el tiempo de ida y vuelta como la pérdida de paquetes para un destino en concreto. Para llevar a cabo estas mediciones, configuramos el envío de un número alto de paquetes hacia un destino en concreto, por ejemplo 1000. Cuando finalice el envío de paquetes, el software nos proporciona los valores máximos, mínimos y media del tiempo de ida y vuelta. Además, nos proporciona el total de paquetes que han sido capaces de llegar al destino, dejando así la oportunidad de poder calcular el porcentaje de pérdida de paquetes con la siguiente fórmula: Pérdida (%) = (Numero de paquetes perdidos / Número total de paquetes enviados al destino) * 100 Su capacidad para poder integrar múltiples funciones en una sola opción lo hacen un software bastante interesante y llamativo para los profesionales de redes. Figura 4-8 Herramienta NetScanTools [33] 4.2.2 PingPlotter PingPlotter es una herramienta disponible principalmente en sistemas operativos Windows. Dispone de una interfaz gráfica para monitorizar en tiempo real la calidad de una conexión [34]. En este proyecto utilizamos la licencia gratis en la que durante un tiempo limitado podremos hacer uso para poder realizar las mediciones de parámetros de red claves como la latencia, el porcentaje de paquetes perdidos y la ruta que siguen para llegar al destino. Una de las principales ventajas de esta herramienta es la combinación de varias funcionalidades, además de mostrarlas gráficamente en tiempo real. Es una herramienta que realiza un seguimiento de los paquetes enviados al destino, destacando la ruta que siguen estos, los tiempos de ida y vuelta y el porcentaje de paquetes perdidos en cada salto dado. Su capacidad para combinar varias funciones y poder mostrarlas en gráficas en tiempo real, lo convierten en un software muy útil para profesionales de redes. Figura 4-9 Herramienta PingPlotter [34] 4.2.3 Mtr (My traceroute) Mtr es una herramienta utilizada en sistemas Linux que combina funciones de distintas herramientas como ping y traceroute. Puede ejecutarse por línea de comandos o a través de su interfaz gráfica. Proporciona valores de parámetros de red esenciales como son el tiempo de ida y vuelta, el porcentaje de paquetes perdidos y la ruta que siguen para llegar al destino [35]. Es una herramienta diseñada principalmente para equipos con sistema operativo Linux. La instalación de esta herramienta se realiza a través del terminal y depende del gestor de paquetes que se utilice. En entornos como Debian y Ubuntu se realiza utilizando el comando sudo apt install mtr. Como la información se va actualizando periódicamente, podemos monitorizar constantemente la conexión siendo posible identificar puntos donde la conexión se ve degradada o genera retardos. Es una herramienta que al combinar varias funcionalidades en una sola y su capacidad para ir actualizando la información periódicamente, la hacen una de las mejores herramientas de Linux para el análisis profesional de una red. Parámetros de evaluación y herramientas empleadas 34 34 Figura 4-10 Herramienta Mtr [35] 4.2.4 Wireshark Wireshark es una de las herramientas más populares para el análisis de protocolos de red. Es de código abierto y gratuita. Además, posee una interfaz gráfica fácil de usar para que el usuario pueda capturar todo el tráfico de red en tiempo real y tenga la posibilidad de poder analizarlo de manera detallada [37]. Su poder para filtrar las búsquedas permite al usuario poder analizar un tipo de información específica en la captura correspondiente. Además, soporta cientos de protocolos, ya sea protocolos comunes como TCP, UDP, o protocolos más específicos como SIP. En este proyecto utilizamos este software principalmente para medir los tiempos de resolución dns, filtrando previamente los paquetes tramitados y analizando y calculando el tiempo que tarda en resolver los dominios seleccionados. Con cada servicio implementado analizamos el comportamiento detallado de los paquetes enviados para poder estudiar y entender con mayor precisión cada servicio, su comportamiento y como está establecido. Su capacidad para mostrar el contenido detallado de los paquetes que se tramitan por la red lo hacen una herramienta ideal para analizar el comportamiento de una red de manera detallada y profesional. Figura 4-11 Herramienta Wireshark [37] 4.2.5 Speedtest Cloudflare Cloudflare Speed es una herramienta en línea que permite medir el rendimiento de la conexión de un usuario. Permite medir parámetros de red claves como: ● Ancho de banda. ● Latencia. ● Jitter. ● Pérdida de paquetes. ● Ubicación del servidor para realizar las pruebas correspondientes. ● IP y ubicación de la red analizada. Con solo acceder a la web, la prueba empezará a medir todos los parámetros de red. Además, cuenta con una interfaz sencilla, permitiendo al usuario obtener los resultados sin una previa configuración. Esta herramienta es bastante práctica para medir parámetros interesantes como jitter y ancho de banda que no son obtenibles con herramientas tradicionales. Su facilidad de uso y precisión a la hora de obtener los resultados la convierten en una herramienta ideal y muy utilizada por profesionales de redes. Parámetros de evaluación y herramientas empleadas 36 36 Figura 4-12 Web Speedtest [38] 4.2.6 Netsh/ifconfig Para obtener la MTU de cada servicio implementado en este proyecto utilizamos diferentes herramientas según el sistema operativo seleccionado: ● En Windows, utilizamos la herramienta netsh. Nos permite mostrar y modificar la configuración de red de manera avanzada. Para mostrar la MTU de cada interfaz utilizamos el comando netsh interface ipv4/ipv6 show subinterfaces. Este comando muestra una lista de subinterfaces ya sea de IPv4 o IPv6, en la que se especifican parámetros claves entre los que se encuentra la MTU. Figura 4-13 Comando Netsh Interface IPv6 Show Subinterfaces ● En Linux, la herramienta ifconfig nos permite ver y modificar las configuraciones de cada interfaz de red. Entre todos los parámetros que nos muestra la herramienta, nos encontramos la MTU de cada interfaz. Tan solo nos basta con pasar por la línea de comandos la entrada ifconfig para que nos muestre la configuración de todas las interfaces de red. Figura 4-14 Comando ifconfig En este proyecto utilizamos estas herramientas para visualizar la MTU correspondiente de todos los servicios que implementamos, teniendo la posibilidad de modificarla para ver el impacto que tiene en la red. 4.2.7 Dig/nslookup Para realizar consultas DNS y obtener los tiempos de resolución, empleamos una herramienta en función del sistema operativo seleccionado: ● En Windows, utilizamos la herramienta nslookup para realizar consultas DNS, obteniendo la dirección IP asociada a ese dominio. Esta herramienta no muestra directamente el tiempo de resolución, por lo que debemos combinar su uso con la herramienta Wireshark. A través de esta herramienta capturamos los paquetes enviados para la resolución DNS, calculando la diferencia de tiempos de cada uno de ellos para poder obtener el tiempo de resolución DNS. Figura 4-15 Herramienta nslookup ● En Linux, utilizamos la herramienta dig para realizar consultas DNS y obtener la dirección del dominio correspondiente. Esta herramienta incluye el tiempo que le ha llevado resolver ese dominio. Resultados y análisis de las mediciones 44 44 Figura 5-9 Resultado PingPlotter IPv6 Hurricane Electric [34] Para el cálculo del RTT y la pérdida de paquetes a la dirección IP destino la de cada servidor DNS que estamos analizando, obtenemos la siguiente donde se representan los tiempos máximos, mínimos y la media realizada. Figura 5-10 RTT Mínima DNS Hurricane Electric Windows Cloudflare Google Hurricane 33,5 34 34,5 35 35,5 36 36,5 RTT Mínimo (ms) Figura 5-11 RTT Máxima DNS Hurricane Electric Windows Figura 5-12 RTT Media DNS Hurricane Electric Windows Observamos en las Figuras 5-10, 5-11 y 5-12 como el servidor que ofrece un RTT más bajo es el servidor Nativo de Hurricane Electric, aunque todos los servidores manejan tiempos bastante parecidos. Para la pérdida de paquetes, obtenemos la siguiente tabla donde se muestra el porcentaje de pérdida de paquetes de cada servidor DNS: Servidor Porcentaje (%) Nativo 0 Google 0 Cloudflare 0 Tabla 5-2 Paquetes Perdidos Ipv6 Hurricane Electric Windows Tras ver la Tabla 5-2, vemos como todos los servidores ofrecen pérdidas del 0%, afirmando que presentan una conexión estable. Para el tiempo de resolución DNS, utilizamos como destino los dominios Google.com, Facebook.com y Wikipedia.com, comparando la eficiencia de cada servidor DNS. Cloudflare Google Hurricane 0 20 40 60 80 100 120 140 RTT Máximo (ms) Cloudflare Google Hurricane 38 38,5 39 39,5 40 40,5 41 41,5 42 42,5 RTT Media (ms) Resultados y análisis de las mediciones 46 46 Esta comparación es representada en la siguiente gráfica: Figura 5-13 Tiempo de resolución DNS Hurricane Electric Windows En términos generales, observando la Figura 5-13, vemos como el servidor DNS de Cloudflare es el servidor que ofrece los menores tiempos de resolución. Para los tiempos de ida y vuelta hacia la IP obtenida por las resoluciones anteriores, obtenemos las siguientes gráficas Figura 5-14 RTT Mínima Dominios Hurricane Electric Windows Cloudflare Google Nativo 0,00 20,00 40,00 60,00 80,00 100,00 120,00 RTT Mínimo (ms) www.google.com www.facebook.com www.wikipedia.com Figura 5-15 RTT Máxima Dominios Hurricane Electric Windows Figura 5-16 RTT Media Dominios Hurricane Electric Windows De nuevo, observando las Figuras 5-14, 5-15, 5-16, el servidor DNS de Cloudflare es el que ofrece los mejores tiempos totales para los dominios analizados, ofreciendo un tiempo medio aceptable sin picos demasiado exagerados. En conclusión, en base a los resultados obtenidos, podemos concluir que el servidor DNS óptimo y que permite al servicio ofrecer su mayor rendimiento es el servidor DNS de Cloudflare con dirección IPv6 2606:4700:4700::1111. 5.1.3 TunnelBroker de Hurricane Electric implementado en Ubuntu Para el servicio de Hurricane Electric implementado en un sistema operativo Linux, vamos a utilizar los siguientes servidores DNS: ● Servidor DNS público de Google, con direcciones IPv6 2001:4860:4860::8888 y 2001:4860:4860::8844. ● Servidor DNS público de Cloudflare, con direcciones IPv6 2606:4700:4700::1111 y 2606:4700:4700::1001. ● Servidor DNS Nativo de Hurricane Electric, con dirección IPv6 2001:470:20::2. Cloudflare Google Nativo 0,00 20,00 40,00 60,00 80,00 100,00 120,00 140,00 160,00 180,00 RTT Máximo (ms) www.google.com www.facebook.com www.wikipedia.com Cloudflare Google Nativo 0,00 20,00 40,00 60,00 80,00 100,00 120,00 RTT Media (ms) www.google.com www.facebook.com www.wikipedia.com Resultados y análisis de las mediciones 48 48 Para todo este procedimiento de elegir el servidor DNS óptimo, utilizamos el script comentado anteriormente que automatiza todo el proceso eliminando la necesidad de realizar varias pruebas. En cuanto al tiempo de ida y vuelta, representamos los tiempos máximos, mínimos y su media en las siguientes gráficas: Figura 5-17 RTT Mínima DNS Hurricane Electric Ubuntu Figura 5-18 RTT Máxima DNS Hurricane Electric Ubuntu Figura 5-19 RTT Media DNS Hurricane Electric Ubuntu Como podemos apreciar en las Figuras 5-17, 5-18, 5-19, el servidor DNS de Hurricane Electric es el que ofrece Cloudflare Google Hurricane 34,20 34,40 34,60 34,80 35,00 35,20 35,40 35,60 35,80 36,00 RTT Mínimo (ms) Cloudflare Google Hurricane 104,00 104,50 105,00 105,50 106,00 106,50 107,00 107,50 108,00 108,50 109,00 RTT Máximo (ms) Cloudflare Google Hurricane 37,00 37,50 38,00 38,50 39,00 39,50 40,00 40,50 41,00 RTT Media (ms) unos tiempos menores, aunque son tiempos bastante equilibrados en cada servidor. Para la pérdida de paquetes, obtenida también del script, obtenemos la siguiente tabla donde se representan los diferentes porcentajes de paquetes perdidos: Servidor Porcentaje (%) Nativo 0 Google 0 Cloudflare 0 Tabla 5-3 Paquetes Perdidos Ipv6 Hurricane Electric Ubuntu Observando la Tabla 5-3, afirmamos que todos los servidores DNS ofrecen una conectividad estable con un porcentaje de pérdida de paquetes del 0%. Para el tiempo de resolución DNS, hemos utilizado como destino los dominios Google.com, Facebook.com y Wikipedia.com, pasándolo como argumento al script. Figura 5-20 Tiempos de resolución DNS Hurricane Electric Ubuntu Tal como se refleja en la Figura 5-20, los tiempos están bastantes equilibrados en todos los servidores DNS, sin una diferencia significativa, aunque cada uno destaca ligeramente en uno de los dominios. El último paso es calcular los distintos tiempos de ida y vuelta de las IP obtenidas por las resoluciones anteriores. Una vez obtenidos los datos, los representamos en las siguientes gráficas: Resultados y análisis de las mediciones 50 50 Figura 5-21 RTT Mínima Dominios Hurricane Electric Ubuntu Figura 5-22 RTT Máxima Dominios Hurricane Electric Ubuntu Figura 5-23 RTT Media Dominios Hurricane Electric Ubuntu Analizando las Figuras 5-21, 5-22, 5-23, observamos como el servidor DNS de Cloudflare ofrece los tiempos más bajos en todas las pruebas, posicionándolo como la opción para obtener el mayor rendimiento del servicio. Cloudflare Google Nativo 0,00 20,00 40,00 60,00 80,00 100,00 120,00 RTT Mínimo (ms) www.google.com www.facebook.com www.wikipedia.com Cloudflare Google Nativo 0,00 20,00 40,00 60,00 80,00 100,00 120,00 140,00 160,00 180,00 RTT Máximo (ms) www.google.com www.facebook.com www.wikipedia.com Cloudflare Google Nativo 0,00 20,00 40,00 60,00 80,00 100,00 120,00 RTT Media (ms) www.google.com www.facebook.com www.wikipedia.com Finalmente, nos decantamos por el servidor DNS de Cloudflare como servidor para ser implementado en este servicio que destaca por su fiabilidad y su gran rendimiento. 5.1.4 VPN de Hide.me A diferencia de los servicios anteriores, para la VPN implementada en este proyecto no es posible configurar manualmente un servidor DNS, ya que la resolución de nombres es un procedimiento realizado por la propia infraestructura de la VPN. Dado que no se puede realizar una comparación de varios servidores DNS para obtener el que ofrezca mayor rendimiento, vamos a utilizar el servidor DNS nativo proporcionado por la VPN con dirección IP fd00:6968:6564:cc::1. 5.1.5 Wireguard+VPS En el servicio donde se implementa una conexión VPN a través de Wireguard, utilizando como servidor una VPS contratada, vamos a utilizar los siguientes servidores DNS: ● Servidor DNS público de Google, con direcciones IPv6 2001:4860:4860::8888 y 2001:4860:4860::8844. ● Servidor DNS público de Cloudflare, con direcciones IPv6 2606:4700:4700::1111 y 2606:4700:4700::1001. ● Servidor DNS público de Quad9, con dirección IPv6 2620:fe::fe. Figura 5-24 Resultado PingPlotter DNS VPN Wireguard [34] Resultados y análisis de las mediciones 52 52 En primer lugar, realizamos la medición de los tiempos de ida y vuelta y la pérdida de paquetes con destino la IP de cada servidor DNS. Para este análisis utilizamos la herramienta PingPlotter. El tiempo RTT máximo, mínimo y su media podemos observarlas en las siguientes gráficas: Figura 5-25 RTT Mínima DNS VPN Wireguard Figura 5-26 RTT Máxima DNS VPN Wireguard Figura 5-27 RTT Media DNS VPN Wireguard A través de las Figuras 5-25, 5-26, 5-27, observamos como los resultados muestran que el servidor DNS de Google ofrece los tiempos más bajos, además de una mayor estabilidad. Para la pérdida de paquetes obtenemos la siguiente tabla: Cloudflare Google Quad9 0 10 20 30 40 50 60 RTT Mínimo (ms) Cloudflare Google Quad9 0 10 20 30 40 50 60 70 RTT Máximo (ms) Cloudflare Google Quad9 0 10 20 30 40 50 60 70 RTT Media (ms) Servidor Porcentaje (%) Nativo 0 Google 0 Cloudflare 0 Tabla 5-4 Paquetes Perdidos VPN Wireguard A partir de la Tabla 5-4, vemos como todos los servidores DNS ofrecen pérdidas del 0%, por lo que todos son válidos desde el punto de vista de la estabilidad. Para los tiempos de resolución DNS, utilizamos como dominios a Google.com, Facebook.com y Wikipedia.com. Sus tiempos son medidos y representados en la siguiente gráfica: Figura 5-28 Tiempo de resolución DNS VPN Wireguard Tal como indica la Figura 5-28, los tiempos de resolución son bastante equilibrados en cada servidor, aunque el servidor de Google ofrece un rendimiento algo mejor. Para terminar el estudio, medimos los tiempos de ida y vuelta de las IP obtenidas en las resoluciones anteriores. Los representamos en las siguientes gráficas: Figura 5-29 RTT Mínima Dominios VPN Wireguard Cloudflare Google Nativo 0,00 10,00 20,00 30,00 40,00 50,00 60,00 70,00 RTT Mínimo (ms) www.google.com www.facebook.com www.wikipedia.com Resultados y análisis de las mediciones 60 60 (%) Hurricane Windows www.google.com 1 2001:470:1f08:3e9:: 1 tunnel955780.tunnel .tserv5.lon1.ipv6.he. net 1 2 2001:470:0:67::1 e019.core2.lon2.he.net 1 3 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 4 2001:7f8:4::3b41:1 2001:7f8:4::3b41:1 1 5 2001:4860:0:1::776 1 2001:4860:0:1::776 1 0 6 2001:4860:0:1::54d 1 2001:4860:0:1::54d 1 9,9 7 2a00:1450:4009:81f ::2004 www.google.com 0 Hurricane Windows www.facebook.com 1 2001:470:1f08:3e9:: 1 tunnel955780.tunnel .tserv5.lon1.ipv6.he. net 1 2 2001:470:0:67::1 e019.core2.lon2.he.net 1 3 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 4 2001:7f8:4::b62:1 ge0.linx.londen03.uk.b b.gin.ntt.net 1 5 2001:728:0:5000::1 989 2001:728:0:5000::1 989 0 6 2620:0:1cff:dead:be ef::5e30 po404.asw02.lhr7.tf bnw.net 7,9 7 2620:0:1cff:dead:be ef::4e09 po291.psw02.lhr8.tf bnw.net 1 8 2a03:2880:f058:ffff: :4d be2.msw1am.01.lhr 8.tfbnw.net 0 9 2a03:2880:f158:82:f ace:b00c:0:25de edge-star-mini6-shv01lhr8.facebook.com 0 10 2620:0:1cff:dead:be ef::57f7 po248.psw04.fra5.tf bnw.net 2 11 2a03:2880:f083:ffff: :ab be4.msw1ah.01.fra5 .tfbnw.net 1 12 2a03:2880:f176:84:f ace:b00c:0:25de www.facebook.com 0 Hurricane Windows www.wikipedia.com 1 2001:470:1f08:3e9:: 1 tunnel955780.tunnel .tserv5.lon1.ipv6.he. net 0 2 2001:470:0:67::1 e019.core2.lon2.he.net 1 3 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 4 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 5 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 6 2001:7f8:1::a501:49 07:1 ae1-380.cr1esams.wikimedia.or g 0 7 2a02:ec80:300:fe04: :2 et-0-0-48.asw1bw27esams.wikimedia.or g 33,7 8 2a02:ec80:300:ed1a: :3 www.wikipedia.com 1 Tabla 5-7 Rutas IPv6 Hurricane Electric Windows Analizando la tabla 5-7, observamos que los paquetes hacia los destinos siguen unas rutas un tanto más largas que el servicio Nativo, presentando además unas pérdidas superiores. Podemos concluir lo siguiente: ● Pérdidas frecuentes en nodos intermedios: En las rutas hacia los destinos se observan pérdidas en varios nodos intermedios, algunas superando incluso el 10%. Estas pérdidas sugieren la existencia de posible congestión o limitaciones en la infraestructura del túnel o nodos intermedios. ● Número de saltos: El uso de túnel induce más saltos que otros servicios, reflejando un camino menos optimizado debido a factores como la encapsulación adicional. ● Tiempos de espera agotados para la solicitud: En varios saltos intermedios aparece esta respuesta, pudiendo indicar posibles filtrados ICMPv6. Resultados y análisis de las mediciones 62 62 Servicio Destino Saltos IP Nombre Porcentaje de pérdidas (%) Hurricane Ubuntu www.google.com 1 2001:470:1f08:3e9 ::1 tunnel955780.tunnel .tserv5.lon1.ipv6.he. net 0,2 2 2001:470:0:67::1 e019.core2.lon2.he.net 0,4 3 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 4 2001:7f8:4::3b41:1 2001:7f8:4::3b41:1 1,8 5 2001:4860:0:1::7d d9 2001:4860:0:1::7dd 9 15 6 2001:4860:0:1::73 c9 2001:4860:0:1::73c9 14,2 7 2a00:1450:4009:8 27::2004 lhr48s49-inx04.1e100.net 1,4 Hurricane Ubuntu www.facebook.com 1 2001:470:1f08:3e9 ::1 tunnel955780.tunnel .tserv5.lon1.ipv6.he. net 0,4 2 2001:470:0:67::1 e019.core2.lon2.he.net 0,4 3 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 4 2001:7f8:4::b62:1 ge0.linx.londen03.uk.b b.gin.ntt.net 0,4 5 2001:728:0:5000:: 1989 2001:728:0:5000::1 989 0,4 6 2620:0:1cff:dead:b eef::5e30 po404.asw02.lhr7.tf bnw.net 0,8 7 2620:0:1cff:dead:b eef::4e09 po291.psw02.lhr8.tf bnw.net 1 8 2a03:2880:f058:fff f::4d be2.msw1am.01.lhr 8.tfbnw.net 8,2 9 2a03:2880:f158:82 edge-star-mini6-shv0,8 :face:b00c:0:25de 01lhr8.facebook.com Hurricane Ubuntu www.wikipedia.com 1 2001:470:1f08:3e9 ::1 tunnel955780.tunnel .tserv5.lon1.ipv6.he. net 0,6 2 2001:470:0:67::1 e019.core2.lon2.he.net 0,6 3 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 4 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 5 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 6 2001:7f8:1::a501:4 907:1 ae1-380.cr1esams.wikimedia.or g 0,4 7 2a02:ec80:300:fe0 4::2 et-0-0-48.asw1bw27esams.wikimedia.or g 36,9 8 2a02:ec80:300:ed1 a::3 ncredirlb.esams.wikimedia. org 1,4 Tabla 5-8 Rutas IPv6 Hurricane Electric Windows A través de la Tabla 5-8 analizada, podemos concluir lo siguiente: ● Pérdidas frecuentes en nodos intermedios: En las rutas hacia los diferentes destinos, se detectan pérdidas frecuentes en nodos intermedios, algunas superando incluso el 10%. Este comportamiento puede generar congestión o sobrecarga en los nodos. ● Tiempos de respuesta agotados: Algunas rutas aparecen con el letrero de tiempo de espera agotado y un porcentaje de pérdida del 100%. Esto sugiere un posible filtrado de paquetes ICMPv6 que, aunque no impiden el acceso al destino final, dificultan el diagnóstico completo de la ruta que sigue el paquete tramitado. ● Camino menos optimizado: El uso del túnel implica realizar procedimientos como la encapsulación adicional, provocando un aumento de la latencia y el rendimiento general de la red. Servicio Destino Saltos IP Nombre Porcentaje de pérdidas (%) Resultados y análisis de las mediciones 64 64 VPN www.google.com 1 fd00:6968:6564:cc:: 1 fd00:6968:6564:cc:: 1 0 2 2001:bc8:1201:721:: 1 2001:bc8:1201:721:: 1 0 3 2001:bc8:1000:1::36 2001:bc8:1000:1::36 0 4 2001:bc8:1000:1::11 8 2001:bc8:1000:1::11 8 0 5 2001:bc8:1000:1::13 2 2001:bc8:1000:1::13 2 0 6 2001:bc8:1000:1::de 2001:bc8:1000:1::de 0 7 2001:bc8:0:2::3 2001:bc8:0:2::3 2 8 2001:4860:1:1::644 2001:4860:1:1::644 0 9 2001:4860:0:1::7f87 2001:4860:0:1::7f87 0 10 2001:4860:0:1::216 d 2001:4860:0:1::216 d 0 11 2a00:1450:4007:80d ::2004 par10s21-inx04.1e100.net 0 VPN www.facebook.com 1 fd00:6968:6564:cc:: 1 fd00:6968:6564:cc:: 1 0 2 2001:bc8:1201:721:: 1 2001:bc8:1201:721:: 1 0 3 2001:bc8:1000:1::3a 2001:bc8:1000:1::3a 0 4 2001:bc8:1000:1::11 c 2001:bc8:1000:1::11 c 0 5 2001:bc8:1000:1::12 a 2001:bc8:1000:1::12 a 0 6 2001:bc8:1000:1::d4 2001:bc8:1000:1::d4 20,8 7 2001:bc8:0:2::27 2001:bc8:0:2::27 39,6 8 2620:0:1cff:dead:be ee::ab2 ae0.pr06.cdg5.tfbnw .net 0 9 2620:0:1cff:dead:be ef::64c6 po202.asw04.cdg4.tf bnw.net 0 10 2620:0:1cff:dead:be ef::224d po1008.psw03.cdg4. tfbnw.net 0 11 2a03:2880:f08e:ffff: :341 be7.msw1ae.02.cdg 4.tfbnw.net 0 12 2a03:2880:f17b:187 :fase:b00c:0:25de www.facebook.com 0 VPN www.wikipedia.com 1 fd00:6968:6564:cc:: 1 fd00:6968:6564:cc:: 1 0 2 2001:bc8:1201:721:: 1 2001:bc8:1201:721:: 1 0 3 2001:bc8:1000:1::3a 2001:bc8:1000:1::3a 0 4 2001:bc8:1000:1::44 2001:bc8:1000:1::44 0 5 2001:bc8:1000:1::12 c 2001:bc8:1000:1::12 c 0 6 2001:bc8:1000:1::d4 2001:bc8:1000:1::d4 0 7 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 8 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 9 2001:7f8:36::3a3b:0 :1 2001:7f8:36::3a3b:0 :1 0 10 2a02:ec80:600:fe06: :2 et-0-0-48.asw1-b12drmrs.wikimedia.or g 0 11 2a02:ec80:600:ed1a: :3 ncredirlb.drmrs.wikimedia. org 0 Tabla 5-9 Rutas IPv6 VPN Hide.me A través de la tabla 5-9, podemos llegar a la siguiente conclusión: ● Varias pérdidas en nodos intermedios: Se presentan pérdidas en algunos nodos intermedios, algunas siendo incluso del 20-30%., y aunque no impiden llegar al destino, podrían generar una posible degradación. ● Tiempos de espera agotados: En la ruta hacia el destino Wikipedia, observamos varios saltos con el mensaje de tiempo de espera agotados para esta solicitud. Esta alerta sugiere un posible filtrado del tráfico ICMPv6, sin afectar al encaminamiento real. ● Mayor número de saltos: El uso de la VPN implica un mayor número de saltos que los servicios anteriormente analizados, rondando entre los 10-12 saltos para cada destino. Resultados y análisis de las mediciones 66 66 Servicio Destino Saltos IP Nombre Porcentaje de pérdidas (%) Wireguard+VPS www.google.com 1 2a01:4f8:1c0c:7b 00::1 2a01:4f8:1c0c:7b 00::1 0 2 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 3 2a01:4f8:0:e0c0:: 5852 18869.yourcloud.host 0 4 2a01:4f8:0:e0c0:: 5801 2a01:4f8:0:e0c0:: 5801 0 5 2a01:4f8:0:e0c0:: a1dd spine6.cloud1.nb g1.hetzner.com 0 6 2a01:4f8:0:e0c0:: a1b5 spine16.cloud1.n bg1.hetzner.com 0 7 2a01:4f8:0:e0c0:: a1e1 core11.nbg1.hetz ner.com 0 8 2a01:4f8:0:3::32 6 core5.fra.hetzner. com 0 9 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 10 2a00:1450:8461: :1 2a00:1450:8461: :1 33,7 11 2001:4860:0:1::9 e 2001:4860:0:1::9 e 0 12 2001:4860:0:1::8 886 2001:4860:0:1::8 886 0 13 2001:4860::c:40 03:3648 2001:4860::c:40 03:3648 0 14 2001:4860::9:40 01:31f2 2001:4860::9:40 01:31f2 91,3 15 2001:4860:0:1::8 69b 2001:4860:0:1::8 69b 0 16 2001:4860:0:1::3 167 2001:4860:0:1::3 167 0 17 2a00:1450:4001: 810::2004 fra16s50-inx04.1e100.net 0 Wireguard+VPS www.facebook.com 1 2a01:4f8:1c0c:7b 00::1 2a01:4f8:1c0c:7b 00::1 0 2 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 3 2a01:4f8:0:e0c0:: 5852 18869.yourcloud.host 0 4 2a01:4f8:0:e0c0:: 5801 2a01:4f8:0:e0c0:: 5801 0 5 2a01:4f8:0:e0c0:: a1dd spine6.cloud1.nb g1.hetzner.com 0 6 2a01:4f8:0:e0c0:: a289 spine15.cloud1.n bg1.hetzner.com 0 7 2a01:4f8:0:3::2a 1 core11.nbg1.hetz ner.com 0 8 2a01:4f8:0:3::1d core4.fra.hetzner. com 0 Resultados y análisis de las mediciones 68 68 9 2620:0:1cff:dead :beee::19f0 ae1.pr02.fra2.tfb nw.net 0 10 2620:0:1cff:dead :beef::7b0 po181.asw01.fra 5.tfbnw.net 0 11 2620:0:1cff:dead :beef::ba7 po215.psw01.fra 3.tfbnw.net 0 12 2a03:2880:f084:f fff::22b be1.msw1av.02.f ra3.tfbnw.net 0 13 2a03:2880:f177: 185:face:b00c:0: 25de edge-star-mini6shv-02fra3.facebook.co m 0 Wireguard+VPS www.wikipedia.com 1 2a01:4f8:1c0c:7b 00::1 2a01:4f8:1c0c:7b 00::1 1 2 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 100 3 2a01:4f8:0:e0c0:: 5852 18869.yourcloud.host 2 4 2a01:4f8:0:e0c0:: 5801 2a01:4f8:0:e0c0:: 5801 0 5 2a01:4f8:0:e0c0:: a1d9 spine5.cloud1.nb g1.hetzner.com 0 6 2a01:4f8:0:e0c0:: a281 spine15.cloud1.n bg1.hetzner.com 0 7 2a01:4f8:0:3::2a 1 core11.nbg1.hetz ner.com 1 8 2a01:4f8:0:3::32 6 core5.fra.hetzner. com 0 9 2001:7f8:13::a50 1:4907:1 2001:7f8:13::a50 1:4907:1 0 10 Tiempo de espera agotado para esta solicitud. Tiempo de espera agotado para esta solicitud. 1,7 11 2a02:ec80:300:e d1a::3 ncredirlb.esams.wikime dia.org 1 Tabla 5-10 Rutas IPv6 VPN Wireguard Analizando la tabla 5-10, podemos llegar a la siguiente conclusión: ● Pérdidas en nodos intermedios: En algunos nodos intermedios ocurren pérdidas que pueden ir desde pérdidas insignificantes con porcentajes que ronda el 1% hasta pérdidas bastante elevadas sobrepasando en varios casos el 30%. ● Tiempos de espera agotados para esta solicitud: En varios nodos intermedios aparece este mensaje con unas pérdidas del 100%, sugiriendo que estos nodos filtran las respuestas ICMPv6. ● Mayor número de saltos: Para este servicio, los paquetes deben de realizar mayor número de saltos para llegar al destino que los servicios analizados anteriormente. Este número de saltos varía entre 13 y 17 dependiendo del dominio. A pesar de este incremento de saltos, no implica necesariamente un mayor retardo si la red está bien gestionada, que es el caso de este servicio. 5.2.3 Tiempo de resolución DNS Para medir el tiempo de resolución DNS utilizamos las siguientes herramientas: ● Para Windows, utilizamos la combinación de las herramientas Nslookup y Wireshark para capturar los paquetes tramitados y medir con precisión le tiempo entre consulta y respuesta. ● Para Linux, utilizamos la herramienta dig, que permite obtener información detallada de la resolución DNS. Los resultados obtenidos se muestran en la siguiente gráfica: Anexo A. Equipos utilizados 76 76 ANEXO A. EQUIPOS UTILIZADOS En este apartado vamos a mostrar los equipos donde se han llevado a cabo la instalación y configuración de los distintos servicios implementados y la posterior medición de los distintos parámetros de red. A.1 MSI GF63 Thin 9SC Este equipo se utilizó como entorno de pruebas principal para los servicios que requerían del sistema operativo Windows. Además, es el alojador de las distintas herramientas empleadas para el cálculo de los diferentes parámetros de red. Las características más relevantes de este equipo son las siguientes: ● Hardware o Intel® Core™ i7-9750H @ 2.60 GHz (6 núcleos, 12 hilos) o Memoria RAM de 16,0 GB (15,8 GB usable) o Arquitectura de 64 bits o Gráfica GTX 1650 Max-Q de Nvidia o Almacenamiento en 500 GB de SSD tipo PCIe 3.0 ×4 o Conectividad a través de wifi 802.11 ac, Bluetooth 5.0, Ethernet ● Sistema operativo o Windows 11 Home Single Language, versión 23H2 (build 22631.5549) A.2 Laptop HP Este equipo fue utilizado principalmente para implementar los servicios que requerían del uso del sistema operativo Linux. Además, fue utilizado para el desarrollo del script utilizado para el cálculo del servidor DNS óptimo. Las características de este equipo son las siguientes: ● Hardware o Memoria RAM de 4 GB o Procesador Intel® Celeron® N2840 @ 2.16 GHz (2 núcleos) o Gráfica integrada Intel HD Graphics (Bay Trail) o Almacenamiento HDD de 500 GB ● Sistema operativo o Ubuntu 20.04.6 LTS o Sistema operativo de 64 bits o GNOME 3.36.8 o Sistema de ventanas X11 A.3 Proveedor de red contratado y tipo de conexión empleado Para el desarrollo de este proyecto se ha hecho de dos redes domésticas distintas, proporcionadas por diferentes proveedores. En una de ellas el proveedor de red proporcionaba direccionamiento IPv6 de manera nativa y en la otra no. Esta situación nos permitió poder configurar estos servicios y comprobar las diferencias entre unos y otros. ● Red sin soporte nativo de IPv6 En esta red como hemos comentado anteriormente, hemos implementado la mayoría de los servicios que proporcionan conectividad IPv6 mediante túneles. Esta conexión corresponde a una tarifa contratada a FiberPlus, el cual es una empresa local de telecomunicaciones especializada en fibra óptica y telefonía móvil. La velocidad contratada es de 600 Mb simétricos y su tipo de conectividad se realiza a través de una dirección IPv4 pública, ya que la operadora de red no nos proporciona direccionamiento IPv6 global. ● Red con soporte nativo IPv6 En esta red hemos hecho las pruebas de IPv6 nativo, el cual no tiene la necesidad de utilizar servicios de túnel. La velocidad contratada en esta red es de 500 Mb simétricos y el tipo de conectividad es a través de una dirección IPv4 pública y una serie de prefijos de red IPv6. Para las pruebas realizadas en ambas redes, hemos utilizado una conexión cableada a través de cables Ethernet de categoría 6. Este tipo de cable permite una velocidad de hasta 1 Gbps por segundo, haciendo que los servicios implementados obtengan el mayor rendimiento posible, ya que una conexión por Wi-Fi podría provocar un mayor número de pérdidas por diversas condiciones como las interferencias. Anexo B. VPS contratada 78 78 ANEXO B. VPS CONTRATADA Para el desarrollo de este proyecto optamos por utilizar una VPS a través del proveedor Hetzner, una empresa de origen alemán, que destaca por su fiabilidad y una gran calidad en sus servicios. A través de la página oficial de Hetzner, podemos registrarnos y obtener una VPS realizando el correspondiente pago, el cual es mensual. Figura B-1 Servidor VPS En nuestro proyecto, el tipo de instancia seleccionada para la VPS fue el modelo llamado cx22, el cual dispone de los siguientes recursos: ● 4 GB de memoria RAM ● 40 GB de almacenamiento Local ● Hasta 20 Tb de tráfico mensual incluido ● 2 núcleos de CPU virtuales En cuanto al precio, no es una VPS generalmente cara. En nuestro caso, el pago a mensual a realizar es de 3,98€, lo que lo convierte en una opción más que rentable para desarrollo de pruebas o proyectos como el que estamos realizando. En cuanto a la conectividad que nos ofrece, este trabaja tanto con IPv4 como con IPv6, algo que es fundamental para nuestro proyecto. La dirección IPv4 que trae asignada es la 195.201.217.41 y su prefijo IPv6 global la 2a01:4f8:1c0c:7b00::/64. Figura B-2 Configuraciones VPS Además, otro aspecto relevante es su ubicación geográfica, ubicada físicamente en Nuremberg (Alemania). Esta ubicación ha sido relevante para evaluar la latencia real desde España hasta un nodo remoto en el centro de Europa. Figura B-3 Ubicación VPS Una de las ventajas que nos ofrece la VPS es la posibilidad del usuario de poder personalizar varios parámetros en el momento de la contratación y su creación. Una de las opciones es la elección de sistema operativo, el cual hemos optado por utilizar Linux, utilizando la distribución Debian. Para poder acceder a la VPS de manera remota, utilizamos el protocolo SSH (Secure Shell), que permite el acceso seguro a través de la red, ya que sus conexiones están cifradas. Anexo C. Script para DNS óptimo 80 80 ANEXO C. SCRIPT PARA DNS ÓPTIMO Para el procedimiento de obtención del servidor DNS con mejor rendimiento para el servicio implementado en Linux, desarrollamos un script que automatice todo el proceso. El script consta del siguiente código: #!/bin/bash #Colours greenColour="\e[0;32m\033[1m" endColour="\033[0m\e[0m" redColour="\e[0;31m\033[1m" blueColour="\e[0;34m\033[1m" yellowColour="\e[0;33m\033[1m" purpleColour="\e[0;35m\033[1m" turquoiseColour="\e[0;36m\033[1m" grayColour="\e[0;37m\033[1m" function ctrl_c(){ echo -e "\n$redColour[+] Saliendo del script...$endColour\n" exit 0 } trap ctrl_c INT function helpPannel(){ echo -e "\n$yellowColour Panel de ayuda$endColour" echo -e "\n$yellowColour d)$endColour$turquoiseColour Direccion IPv6 del servidor DNS$endColour" echo -e "\n$yellowColour u)$endColour$turquoiseColour Dominios a analizar$endColour\n" } function analizarDNS(){ DNS=$1 echo -e "\n$yellowColour[+]$endColour$blueColour No se detectó caché DNS local. No es necesario vaciarla.$endColour\n" echo -e "$yellowColour[+]$endColour$blueColour Estableciendo servidor DNS temporalmente en $greenColour$DNS$endColour$blueColour...$endColour\n" if [ -L /etc/resolv.conf ]; then echo "$redColour[i]$endColour$greenColour /etc/resolv.conf es un enlace simbólico. Se reemplazará temporalmente.$endColour" sudo rm /etc/resolv.conf fi #sudo tee /etc/resolv.conf > /dev/null sudo bash -c "echo 'nameserver $DNS' > /etc/resolv.conf" echo -e "$yellowColour[+]$endColour$blueColour Comprobando el contenido actual de $greenColour/etc/resolv.conf$endColour$blueColour...$endColour\n" #Latencia media=$(ping6 www.google.com -c 1 | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $2}') #Latencia maxima=$(ping6 www.google.com -c 1 | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $3}') #Latencia minima=$(ping6 www.google.com -c 1 | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $1}') echo -e "$yellowColour[+]$endColour$blueColour Medicion de la Latencia a servidor DNS con IP$endColour $greenColour$DNS$endColour$blueColour... $endColour\n" Result=$(ping6 $DNS -c 100 | tail -n 5) Latencia_minima=$(echo "$Result" | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $1}') Latencia_maxima=$(echo "$Result" | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $3}') Latencia_media=$(echo "$Result" | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $2}') echo -e "$purpleColour La latencia minima es $endColour$greenColour$Latencia_minima$endColour\n" echo -e "$purpleColour La latencia maxima es $endColour$greenColour$Latencia_maxima$endColour\n" echo -e "$purpleColour La latencia media es $endColour$greenColour$Latencia_media$endColour\n" Perdida=$(echo "$Result" | tail -n 2 | awk -F 'received,' '{print $2}' | awk -F ',' '{print $1}') echo -e "$purpleColour El porcentaje de perdida de paquetes es:$endColour$greenColour$Perdida$endColour\n" } function analizarDominio1(){ Dominio1=$1 echo -e "$yellowColour[+]$endColour$blueColour Tiempo de resolucion DNS del Dominio $endColour$greenColour$Dominio1$endColour\n" Resolucion=$(dig -6 $Dominio1 AAAA) #echo "$Resolucion" IP=$(echo "$Resolucion" | tail -n 6 | head -n 1 | awk '{print $NF}') echo -e "$purpleColour La IP para el dominio$endColour $greenColour$Dominio1$endColour$blueColour es: $endColour$greenColour$IP$endColour\n" Anexo C. Script para DNS óptimo 82 82 Tiempo=$(echo "$Resolucion" | tail -n 4 | head -n 1 | awk -F ':' '{print $2}') #echo -e "$Tiempo" echo -e "$purpleColour El tiempo de resolucion DNS para este dominio es:$endColour$greenColour$Tiempo$endColour\n" echo -e "$yellowColour[+]$endColour$blueColour Calculo de la latencia de la IP del dominio introducido...\n$endColour" Resultado=$(ping6 $IP -c 100 | tail -n 5) Latencia_minima2=$(echo "$Resultado" | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $1}') Latencia_maxima2=$(echo "$Resultado" | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $3}') Latencia_media2=$(echo "$Resultado" | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $2}') echo -e "$purpleColour La latencia minima es $endColour$greenColour$Latencia_minima2$endColour\n" echo -e "$purpleColour La latencia maxima es $endColour$greenColour$Latencia_maxima2$endColour\n" echo -e "$purpleColour La latencia media es $endColour$greenColour$Latencia_media2$endColour\n" Perdida2=$(echo "$Resultado" | tail -n 2 | awk -F 'received,' '{print $2}' | awk -F ',' '{print $1}') echo -e "$purpleColour El porcentaje de perdida de paquetes es:$endColour$greenColour$Perdida2$endColour\n" } function analizarDominio2(){ echo -e "$yellowColour[+]$endColour$blueColour Tiempo de resolucion DNS del Dominio $endColour$greenColour$Dominio2$endColour\n" Resolucion2=$(dig -6 $Dominio2 AAAA) #echo "$Resolucion2" IP2=$(echo "$Resolucion2" | tail -n 6 | head -n 1 | awk '{print $NF}') echo -e "$purpleColour La IP para el dominio$endColour $greenColour$Dominio2$endColour$blueColour es: $endColour$greenColour$IP2$endColour\n" Tiempo2=$(echo "$Resolucion2" | tail -n 4 | head -n 1 | awk -F ':' '{print $2}') #echo -e "$Tiempo2" echo -e "$purpleColour El tiempo de resolucion DNS para este dominio es:$endColour$greenColour$Tiempo2$endColour\n" echo -e "$yellowColour[+]$endColour$blueColour Calculo de la latencia de la IP del dominio introducido...\n$endColour" Resultado2=$(ping6 $IP2 -c 100 | tail -n 5) Latencia_minima3=$(echo "$Resultado2" | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $1}') Latencia_maxima3=$(echo "$Resultado2" | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $3}') Latencia_media3=$(echo "$Resultado2" | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $2}') echo -e "$purpleColour La latencia minima es $endColour$greenColour$Latencia_minima3$endColour\n" echo -e "$purpleColour La latencia maxima es $endColour$greenColour$Latencia_maxima3$endColour\n" echo -e "$purpleColour La latencia media es $endColour$greenColour$Latencia_media3$endColour\n" Perdida3=$(echo "$Resultado2" | tail -n 2 | awk -F 'received,' '{print $2}' | awk -F ',' '{print $1}') echo -e "$purpleColour El porcentaje de perdida de paquetes es:$endColour$greenColour$Perdida3$endColour\n" } function analizarDominio3(){ echo -e "$yellowColour[+]$endColour$blueColour Tiempo de resolucion DNS del Dominio $endColour$greenColour$Dominio3$endColour\n" Resolucion3=$(dig -6 $Dominio3 AAAA) #echo "$Resolucion3" IP3=$(echo "$Resolucion3" | tail -n 6 | head -n 1 | awk '{print $NF}') echo -e "$purpleColour La IP para el dominio$endColour $greenColour$Dominio3$endColour$blueColour es: $endColour$greenColour$IP3$endColour\n" Tiempo3=$(echo "$Resolucion3" | tail -n 4 | head -n 1 | awk -F ':' '{print $2}') #echo -e "$Tiempo3" echo -e "$purpleColour El tiempo de resolucion DNS para este dominio es:$endColour$greenColour$Tiempo3$endColour\n" echo -e "$yellowColour[+]$endColour$blueColour Calculo de la latencia de la IP del dominio introducido...\n$endColour" Resultado3=$(ping6 $IP3 -c 100 | tail -n 5) Latencia_minima4=$(echo "$Resultado3" | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $1}') Latencia_maxima4=$(echo "$Resultado3" | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $3}') Latencia_media4=$(echo "$Resultado3" | tail -n 1 | awk -F '=' '{print $2}' | awk -F '/' '{print $2}') echo -e "$purpleColour La latencia minima es $endColour$greenColour$Latencia_minima4$endColour\n" echo -e "$purpleColour La latencia maxima es $endColour$greenColour$Latencia_maxima4$endColour\n" echo -e "$purpleColour La latencia media es $endColour$greenColour$Latencia_media4$endColour\n" Perdida4=$(echo "$Resultado3" | tail -n 2 | awk -F 'received,' '{print $2}' | awk -F ',' '{print $1}') echo -e "$purpleColour El porcentaje de perdida de paquetes es:$endColour$greenColour$Perdida4$endColour\n" } declare -i parameter_counter=0 while getopts "d:u:h" arg; do case $arg in Anexo C. Script para DNS óptimo 84 84 d) DNS=$OPTARG; let parameter_counter+=1;; u) Dominio1=$OPTARG shift $((OPTIND -1)) Dominio2=$1 Dominio3=$2 let parameter_counter+=2;; h) helpPannel exit 0;; esac done if [ $parameter_counter -eq 1 ]; then analizarDNS $DNS elif [ $parameter_counter -eq 3 ]; then analizarDNS $DNS analizarDominio1 $Dominio1 if [[ -n "$Dominio2" ]]; then analizarDominio2 fi if [[ -n "$Dominio3" ]]; then analizarDominio3 fi else helpPannel fi REFERENCIAS [1] M. Ford, «An Eye On The Numbers: IPv6 Deployment,» Internet Society Pulse, 9-jun-2022. [En línea]. Available: https://pulse.internetsociety.org/blog/an-eye-on-the-numbers-ipv6-deployment. [2] S. Deering, «Internet Protocol, Version 6 (IPv6) Specification,» RFC 8200, [En línea]. Available: https://tools.ietf.org/html/rfc8200. [3] R. Hinden, «rfc 4291 - IPv6 Adressing Architecture,» [En línea]. Available: https://tools.ietf.org/html/rfc4291. [4] J. M. V. Torres, Introducción a IPv6. [5] A. Conta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification," RFC 4443, March 2006. [Online]. Available: https://www.rfc-editor.org/rfc/rfc4443 [6] T. Narten, «Neighbor Discovery for IP version 6 (IPv6),» [En línea]. Available: https://tools.ietf.org/html/rfc4861. [7] S. Thomson, «IPv6 Stateless Address Autoconfiguration,» [En línea]. Available: https://tools.ietf.org/html/rfc4862. [8] J. McCann, «Path MTU Discovery for IP version 6,» [En línea]. Available: https://tools.ietf.org/html/rfc8201. [9] S. Deering, «Multicast Listener Discovery (MLD) for IPv6,» [En línea]. Available: https://tools.ietf.org/html/rfc2710. [10] S. Kent, «Security Architecture for the Internet Protocol,» [En línea]. Available: https://tools.ietf.org/html/rfc4301. [11] S. Kent, «IP Authentication Header,» [En línea]. Available: https://tools.ietf.org/html/rfc4302. [12] S. Kent, «IP Encapsulating Security Payload (ESP),» [En línea]. Available: https://tools.ietf.org/html/rfc4303. [13] C. Kaufman, «Internet Key Exchange Protocol Version 2 (IKEv2),» [En línea]. Available: https://tools.ietf.org/html/rfc7296. [14] D. McGrew, «Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH),» [En línea]. Available: https://tools.ietf.org/html/rfc7321. [15] «IPv6Ready.me - Prueba de compatibilidad IPv6,» [En línea]. Available: https://ipv6ready.me/index.html.es_ES. [16] «Hurricane Electric,» [En línea]. Available: http://he.net/ [17] E. Nordmark, «Basic Transition Mechanisms for IPv6 Hosts and Routers», RFC 4213, octubre 2005. [En línea]. Available: https://datatracker.ietf.org/doc/html/rfc4213.