RAE. TITULO: DISEÑO Y SIMULACIÓN DE LAS HERRAMIENTAS BÁSICAS PARA LA IMPLEMENTACIÓN DE REDES CON SOPORTE IPv6

Transcripción

1 RAE TIPO DE DOCUMENTO: Trabajo realizado sobre las herramientas básicas para la implementación de redes con soporte IPv6, con el fin de obtener el titulo de Ingeniero Electronico. TITULO: DISEÑO Y SIMULACIÓN DE LAS HERRAMIENTAS BÁSICAS PARA LA IMPLEMENTACIÓN DE REDES CON SOPORTE IPv6 AUTOR: Ricardo Almario Zea LUGAR: Bogota D.C. FECHA: Enero 2012 PALABRAS CLAVES: IPv6, 6to4, ISATAP, TEREDO, Tunnel Broker, TSP, Dual- Stack, RIPng, OSPFv3, MP-BGP, IS-IS. DESCRIPCIÓN DEL TRABAJO: En este proyecto se estudia el funcionamiento del protocolo IPv6, sus características y a su vez los mecanismos de transición que ayudaran a acelerar el proceso de migración. Todos los diseños realizados fueron simulados para que puedan ser debidamente evaluados. LINEA DE INVESTIGACIÓN: Este trabajo se desarrolla en el marco de la Línea institucional-tecnologías actuales y sociedad. FUNTES CONSULTADAS: Migrating to IPv6. A practical Guide to Implementing IPv6 in Mobile and Fixed Networks. Marc Blanchet. John Wiley & Sons, ltd Québec, Canada. Handbook of IPv4 to IPv6 transition. Metodologies for institutional and corporate networks. John J. Amoss & Daniel Minolli

2 Auerback publications. Taylor & Francis Group. Boca Raton, Fl. USA. Understanding IPv6. Joseph davies Microsoft Press. Redmond, Washington. Configuring IPv6 for Cisco IOS. Deploy IPv6 on the Cisco IOS. Sam Brown, Brian Browne, Neal Chen, Paul J. Fong Syngress Publishing. Rockland, MA USA. IPv6 para todos. Guía de uso y aplicación para diversos entornos. Guillermo Cicileo, Roque Gagliano, otros Internet society, capítulo Argentina. CONTENIDOS: Durante el desarrollo de este proyecto se estudiará el protocolo IPv6 y se experimentará sobre sus diversos tópicos, con el fin de poder brindar a la comunidad universitaria las herramientas básicas necesarias para impulsar y fomentar las adopción del protocolo IPv6 en diferentes entornos, explicando de manera clara los pasos y requerimientos para configurar e implementar la nueva versión del protocolo IP en el ámbito que sea necesario. METODOLOGIA: El desarrollo de este proyecto tiene un enfoque empíricoanalítico el cual tiene un interés técnico, orientado a la interpretación y transformación del mundo material. Proporciona además una estructura particular a la metodología de investigación en tanto que orienta el trabajo a la contrastación permanente de las aseveraciones teóricas con la verificación experimental, de manera que los cálculos generados a través de modelos matemáticos y simulaciones computacionales se deben retroalimentar con la experimentación, en la búsqueda de información cada vez más confiable y práctica para la solución del problema. CONCLUSIONES: Este proyecto pretende ser un primer paso hacia el desarrollo investigativo sobre el protocolo IPv6 en la Universidad San Buenaventura, promoviendo y construyendo conocimiento, con el fin de abrir puertas a nuevos productos, servicios y aplicaciones, que serán desarrollados en el futuro gracias a todas la ventajas que este protocolo brinda.

3 DISEÑO Y SIMULACIÓN DE LAS HERRAMIENTAS BÁSICAS PARA LA IMPLEMENTACIÓN DE REDES CON SOPORTE IPv6 RICARDO ALMARIO ZEA UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA INGENIERÍA ELECTRÓNICA BOGOTÁ 2011

4 DISEÑO Y SIMULACIÓN DE LAS HERRAMIENTAS BÁSICAS PARA LA IMPLEMENTACIÓN DE REDES CON SOPORTE IPv6 RICARDO ALMARIO ZEA Trabajo de grado para optar por el título de ingeniero electrónico Director Luis Carlos Gil Bernal UNIVERSIDAD DE SAN BUENAVENTURA FACULTAD DE INGENIERÍA INGENIERÍA ELECTRÓNICA BOGOTÁ 2011

5 CONTENIDO Pág. INTRODUCCIÓN 1. PLANTEAMIENTO DEL PROBLEMA ANTECEDENTES DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA JUSTIFICACIÓN OBJETIVOS DE LA INVESTIGACIÓN Objetivo general Objetivos específicos ALCANCES Y LIMITACIONES DEL PROYECTO 6 2. METODOLOGÍA 8 3. LÍNEA DE INVESTIGACIÓN 9 4. MARCO TEÓRICO Y CONCEPTUAL EL PROTOCOLO IPV4 Y SUS LIMITACIONES Nacimiento del protocolo ipv4 y agotamiento 10 de direcciones Soluciones al agotamiento de direcciones INTRODUCCIÓN AL PROTOCOLO IPV Nacimiento del Protocolo IPv Descripción y características del Protocolo IPv6 17

6 4.2.3 IPV4 frente a IPV Estado de Adopción de IPv Por qué no se despliega IPv6 con mayor rapidez? EL PROTOCOLO IPv Cabecera IPv Cabeceras de Extensión Cabecera de Opciones Salto a Salto Cabecera de enrutamiento Cabecera de Fragmentación Cabecera Opciones de Destino Cabecera de Autentificación Cabecera de Carga de Seguridad Encapsulada Cabecera siguiente valor Consideraciones sobre el tamaño del paquete Problemas de protocolo de capa superior Sumas de Verificación de Capa Superior Tiempo de Vida Máximo de un Paquete Tamaño Máximo de la Carga Útil de Capa Superior Respuesta a Paquetes que Llevan Cabeceras 47 de Enrutamiento 4.4 DIRECCIONAMIENTO IPV Tipos de Direcciones IPv Direcciones Unicast Direcciones Multicast Direcciones Anycast Direcciones ipv6 para host y router Direcciones únicas ULA (Unique Local Address) Identificador de interfaz (IID) 56

7 4.4.5 Direcciones IPv4 e IPv6 equivalentes Políticas de distribución y asignación Qué están haciendo los RIR y los ISP? FUNCIONALIDADES DE IPv ICMPv6 (Internet Control Message Protocol) Descubrimiento de Vecinos (Neighbor Discovery Protocol) Descubrimiento de direcciones de capa de enlace Descubrimiento de Routers y prefijos Detección de direcciones duplicadas Redireccionamiento Autoconfiguración de direcciones stateless DHCPv6 (Dynamic Host Configuration) Path MTU Discovery Jumbograms Gestión del grupo Muticast DNS (Domain Name System) QoS (Quality Of Servise) MOVILIDAD IPV SEGURIDAD EN IPv DESARROLLO INGENIERIL INSTALACIÓN DE IPV Instalación de IPv6 en Windows XP/ Instalación IPv6 en Vista Instalación IPv6 en Windows Instalación IPv6 en Windows

8 5.1.5 Comprobación de IPv6 Windows Configuración de IPv6 Windows SIMULADOR GNS Uso de GNS Emulación Router CISCO Emulación de Switches Ethernet Simulación de PC s Almacenamiento de topología ENRUTAMIENTO IPv Consideraciones Cómo funciona el router? Tabla de enrutamiento Ruta por defecto Enrutamiento Estático Configuración de enrutamiento estático IPv Protocolos de Enrutamiento Interno RIPng Configuración RIPng OSPFv3 (Open Shortes Path First Version 3) Configuración OSPFV IS-IS (Intermediate System to Intermediate System) Protocolo de enrutamiento externo BGP (Border Gateway Protocol) BGP Multiprotocolo Tabla BGP Configuración BGP 164

9 5.4 COEXISTENCIA Y TRANSICIÓN Doble Pila Configuración Dual-Stack (Doble Pila) Técnicas de tunelizacion Tunnel Broker Túnel Broker con Hurricane Electric Tunel Broker con GoGo Túnel 6to Configuración Tunel 6to ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) Configuración ISATAP Teredo GRE (Generic Routing Encapsulation) Tunnel GNRE IPv Análisis comparativo entre las estrategias de transición Técnicas de traducción SIIT BIS BIA TRT CONCLUSIONES RECOMENDACIONES 232 ANEXO A: Instalación y configuración de GNS3 en Windows XP 233 GLOSARIO 240 BIBLIOGRAFÍA 244

10 LISTA DE TABLAS Pág. Tabla 4.1: Clases de direcciones IPv4 12 Tabla 4.2: Diferencias entre IPv4 e IPv6 20 Tabla 4.3: Direcciones reservadas para Multicast 52 Tabla 4.4: Direcciones IPv4 equivalentes 58 Tabla 4.5: Mensajes de Error 63 Tabla 4.6: Mensajes de Información 64 Tabla 5.1 Tabla comparativa entre los simuladores usados 109 Tabla 5.2 Lista de adaptadores correspondientes a cada tipo de plataforma 110

11 LISTA DE GRAFICAS Pág. Figura 4.1: Distribución Actual de Direcciones IPv6 24 Figura 4.2: Asignaciones de IPv6 de RIRs a ISPs (Septiembre 2010) 25 Figura 4.3: Cabecera IPv6 29 Figura 4.4: Cambio de Nombre en 4 Campos de la Cabecera 30 Figura 4.5: Cabecera de extensión 33 Figura 4.6: Cabecera de Opciones Salto a Salto 34 Figura 4.7: Cabecera de enrutamiento Genérica 36 Figura 4.8: Cabecera de enrutamiento Tipo 0 37 Figura 4.9: Cabecera de Fragmentación 39 Figura 4.10: Cabecera de Opciones de destino 40 Figura 4.11: Cabecera de Autenticación 41 Figura 4.12: Cabecera de Carga de Seguridad Encapsulada 42 Figura 4.13: Pseudo Cabecera TCP y UDP para IPv6 45 Figura 4.14: Descubrimiento de direcciones 69 Figura 4.15: Descubrimiento de Routers 70 Figura 4.16: Mensajes Binding 87 Figura 5.1: Instalación de IPv6 en Windows XP 98 Figura 5.2: Instalación Windows Vista 99 Figura 5.3: Instalación Windows Figura 5.4: Índice correspondiente a cada Interfaz 104 Figura 5.5: Rutas configuradas en cada interfaz 107 Figura 5.6: ventana principal GNS3 112 Figura 5.7: Menú de opciones de un router 112 Figura: 5.8 Ventana de configuración del nodo 113 Figura: 5.9 Menú de opciones de un router 113

12 Figura 5.10: Menú de opciones de un router 114 Figura 5.11: Menú de opciones de un router 114 Figura 5.12: Menú de opciones de un router 114 Figura 5.13: Ventana principal GNS3 116 Figura 5.14: Menú de opciones de un switch 116 Figura 5.15: Ventana de configuración del nodo 117 Figura 5.16: Sección settings de la ventana de configuración del nodo 117 Figura 5.17 Comandos disponibles en VPC s 119 Figura 5.18 configuración de los PC s virtuales 119 Figura 5.19 Ventana de configuración nodo 120 Figura 5.20 Configuración de PCs virtuales 121 Figura 5.21 Configuración de PC s virtuales 121 Figura 5.22 Tipos de enlaces disponibles 122 Figura 5.23 Interfaces disponibles en router 122 Figura 5.24 Ventana principal de GNS3 123 Figura 5.25 Menú de opciones de una nube 123 Figura 5.26 Ventana de configuración de nodo 124 Figura 5.27 ventana de cambio de nombres de host 125 Figura 5.28 Ventana de cambio de nombre de host 126 Figura 5.29 Comandos para guardar la configuración de routers 126 Figura 5.30 Ventana de almacenamiento configuraciones 126 Figura 5.31 Opciones de archivos 127 Figura 5.32 Ruteo estático IPv4 Ipv6 138 Figura 5.33 Cabecera RIPng 145 Figura: 5.34 RIPng 146 Figura 5.35 Diagrama OPSFv3 150 Figura 5.36 Topología OSPFv3 152 Figura 5.37 Ejemplo topología BGP 159 Figura 5.38: BGP Multiprotocolo 165 Figura 5.39 Diagrama Dual Stack 172

13 Figura 5.40 Topología Dual Stack 174 Figura 5.41 Pagina Hurricane Electric 179 Figura 5.42 Registro Hurricane Electric 179 Figura 5.43 Registro completado 180 Figura 5.44 Creación del Túnel 180 Figura 5.45 Descripción del nuevo túnel creado 181 Figura 5.46 Detalles del túnel creado 181 Figura 5.47 Configuración del túnel en el Host 182 Figura 5.48: Pagina gogo6 183 Figura 5.49: Registro Gogo6 184 Figura 5.50: Verificación de solicitud por mail 184 Figura 5.51: Creación del perfil 185 Figura: 5.52 Descarga de un archivo setup 185 Figura: 5.53 Descarga de la aplicación para Windows 186 Figura: 5.54 Conexión al servidor Gogo6 186 Figura: 5.55 Prueba de conexión IPv6 187 Figura 5.56: Formato dirección 6to4 188 Figura 5.57: Comunicación entre clientes 6to4 que están en redes diferentes 189 Figura 5.58: Comunicación cliente/router 6to4 con un servidor ipv6 191 Figura 5.59: Comunicación cliente 6to4 con un servidor ipv6 utilizando solo un relay 6to4 (rutas de ida y vuelta iguales) 193 Figura 5.60: Comunicación cliente 6to4 con un servidor ipv6 utilizando dos relays 6to4 diferentes (rutas de ida y vueltas diferentes) 196 Figura 5.61: Topología 6to4 198 Figura 5.62: Inicio ISATAP 203 Figura 5.63: Comunicación entre clientes ISATAP en la misma red 204 Figura 5.64: Comunicación entre clientes en redes diferentes 205 Figura 5.65: Comunicación entre clientes ISATAP y computadoras IPv6 207 Figura 5.66: Topología básica ISATAP 208

14 Figura 5.67: Formato de dirección teredo 213 Figura 5.68: Túnel Teredo 215 Figura 5.69: Comunicaciones a través de NAT tipo Cono 216 Figura 5.70: Comunicaciones a través de NAT restringido 218 Figura 5.71: Topología Tunnel GNRE IPv6 222

15 INTRODUCCIÓN La versión 4 del protocolo de Internet (IPv4) proporciona los medios de comunicación básicos dentro del conjunto de protocolos TCP/IP, siendo el protagonista del desarrollo y la expansión de Internet en las últimas décadas. El crecimiento masivo que ha sufrido Internet gracias a la diversificación en los servicios que brinda y el incremento evidente en la cantidad de usuarios, ha generado que el protocolo IPv4 deje al descubierto sus limitaciones. El protocolo Ipv4 fue creado en la década de los 70 s como una forma de interconectar un reducido número de redes, es decir nunca se pensó en que sería la base de una red de millones de usuarios, desarrollando así el protocolo con un número reducido de direcciones que junto a problemas de arquitectura han restringido y limitado el desarrollo de nuevas aplicaciones y tecnologías en Internet. Es por esto que se tuvo la necesidad de crear un nuevo protocolo, que añadiera más y mejores características, por ejemplo, incrementar el número de direcciones de Internet, incluir autenticación y encriptación de los datos para realizar comunicaciones más seguras, etc. El 25 de Julio de 1994 Internet Engineering Task Force (IETF), propuso un nuevo protocolo de comunicación en Internet, llamado Internet de próxima generación (IPng) conocido años después como IPv6. En Colombia el 3 de Diciembre de 2010 el MinTIC (Ministerio de Tecnologías de la Información y las Comunicaciones) propició un evento denominado Experiencias internacionales en políticas para adopción del protocolo de interconectividad de redes IPv6 aplicadas al caso colombiano, en el cual se divulgo la creación de un proyecto de resolución para la adopción de IPV6 en Colombia, en el que se crearán políticas, regulaciones y objetivos para la completa apropiación del protocolo IPv6.

16 A través del presente proyecto se plantea la idea de conocer en detalle el funcionamiento del protocolo IPv6 y experimentar con él en la Universidad San Buenaventura sede Bogotá, pues de acuerdo con el último reporte emitido por LACNIC (Latin American and Caribbean Internet Addresses Center) el pasado 3 de Febrero del 2011, el stock central de direcciones IPv4 administrado por la IANA (Internet Assigned Numbers Authority), ha quedado finalmente agotado, lo que significa que los diferentes actores de Internet, tanto usuarios como ISPs (Internet Service Providers) deberán comenzar a adoptar el protocolo IP versión 6 (IPv6). Durante el desarrollo de este proyecto se estudiará el protocolo IPv6 y se experimentará sobre sus diversos tópicos, con el fin de poder brindar a la comunidad universitaria las herramientas básicas necesarias para impulsar y fomentar las adopción del protocolo IPv6 en diferentes entornos, explicando de manera clara los pasos y requerimientos para configurar e implementar la nueva versión del protocolo IP en el ámbito que sea necesario. También se analizarán las diferentes estrategias de transición IPv4/IPv6 para determinar cuáles son las más convenientes y recomendables de utilizar. Todos los diseños desarrollados serán simulados y podrán ser puestos a prueba antes de ser implementados.

17 1. PLANTEAMIENTO DEL PROBLEMA 1.1 ANTECEDENTES A nivel internacional se han adelantando investigaciones con respecto a la implementación de redes IPv6 para diferentes aplicaciones: En la UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA en Chile se desarrolló la investigación Estudio e implementación de una red ipv6 en la UTFSM 1. A través de este proyecto se diseñó e implementó correctamente una red IPv6 operando en modalidad dual-stack, sobre la red institucional de la UTFSM. La red permite conectar a las distintas unidades administrativas y departamentos directamente a Internet mediante IPv6, sin necesidad de utilizar túneles o traducción de protocolos. Además, con el desarrollo de este trabajo los autores lograron comprobar que el grado de desarrollo actual del protocolo IPv6 permite sin mayores contratiempos la implementación de redes que funcionan únicamente sobre IPv6, ya que el soporte IPv6 existente en los equipos de red, permite prescindir totalmente de IPv4 para la totalidad de servicios que una red tradicionalmente ofrece, incluyendo funciones avanzadas como MPLS, IPSec y Mobile IP, las cuales ya cuentan con soporte oficial en redes IPv6. El trabajo realizado demostró que es necesario hacer una revisión exhaustiva de las alternativas al momento de actualizar o implementar una red IPv6. Se descubrió que muchos fabricantes anuncian soporte IPv6 en sus productos, pero en la realidad dicho soporte es parcial o se incluirá en futuras actualizaciones. En 1 Universidad Técnica Federico Santa María [Internet] [consultado 2 Julio de 2010] [Hora 11:28]. Disponible en 1

18 dichos casos son útiles las iniciativas como el programa IPv6 Ready que certifican el soporte IPv6 de equipos y programas, realizando una serie de pruebas sobre ellos. También en este trabajo se trato el tema de la seguridad en las redes IPv6. A pesar del gran avance que se ha hecho en este tema en los últimos años, fue posible constatar que aún existen problemas y vulnerabilidades importantes en las redes IPv6. Los ataques presentados hacen necesario tomar las debidas precauciones cuando se implementan redes IPv6 a gran escala. Se constató que faltan soluciones para contrarrestar eficazmente las vulnerabilidades del protocolo ICMPv6 (Internet Control Message Protocol version 6). En la UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO 2 se han estado desarrollando investigaciones sobre IPv6 desde 1998, siendo la red de esta universidad el primer nodo 6Bone (red IPv6 internacional de carácter experimental) en México, lo cual se registró en junio de Posteriormente en septiembre del mismo año, a partir de resultados de pruebas realizadas por su propia trayectoria en telecomunicaciones e importancia académica, la Universidad Nacional Autónoma de México fue aceptada como uno de los 100 backbones que a la fecha operan en 6Bone, obteniendo un rango de direcciones tipo TLA (Top Level Aggregation). Con este tipo de direcciones, la Universidad Nacional Autónoma de México ha podido delegar bloques y configurar túneles a instituciones en México y en el mundo, interesadas en realizar pruebas con IPv6, lo que constituye un paso muy importante en el uso y desarrollo del nuevo protocolo en el continente americano. 2 Universidad Nacional Autónoma de México [Internet] [consultado 10 Julio de 2010] [Hora 3:42]. Disponible en 2

19 En el ámbito educativo la UNIVERSIDAD AUSTRAL DE CHILE ha desarrollo un trabajo llamado Modelo de Tele-enseñanza utilizando protocolo IPv6 3, exponiendo el desarrollo de una herramienta telemática de migración de IPv4 a IPv6, la cual consiste en la actualización de librerías, pizarra virtual y un canal de comunicación sobre el protocolo de Internet RTP (Real Time Transport Protocol), para enviar en tiempo real la información al receptor. Además de abarcar la interacción alumno-profesor, se pretende aportar al desarrollo de actividades relacionadas con teleconferencia, motivando su aplicación en otras áreas. Aprovechando la capacidad del protocolo IPv6 de brindar soportes para dispositivos multimedia como audio conferencia, pizarra virtual, dispositivos móviles, etc., en tiempo real, lograron la implementación de un prototipo que utiliza tanto la comunicación entre profesor-alumno a través de un canal de texto, como la pizarra virtual en un aula virtual con la incorporación de las TICs, utilizando IPv6 como protocolo de comunicación. A nivel nacional se han adelantando investigaciones con respecto a la implementación de redes IPv6 para diferentes aplicaciones: En la UNIVERSIDAD DEL VALLE en Cali se desarrolló el proyecto MANEJO A TRAVÉS DE INTERNET DEL ROBOT MICROBOT TEACHMOVER USANDO UN SISTEMA EMBEBIDO CON INTERFAZ BLUETOOTH Y EL PROTOCOLO IPv6 4. Este proyecto trabaja la manipulación del robot Microbot Teachmover a través de una aplicación de computador que permite la interacción con éste tanto de una manera local como remota, así como también el manejo de dicho robot a través de una aplicación desarrollada en un dispositivo móvil. El objetivo era la utilización de los protocolos BNEP (Bluetooth Networking Encapsulation Protocol) 3 Universidad Austral de Chile [Internet] [consultado 13 Julio de 2010] [Hora 23:40]. Disponible en 4 Universidad del Valle [Internet] [consultado 16 Julio de 2010] [Hora 21:15]. Disponible en G-0417.pdf 3

20 e IPv6 con el fin de tener una pila de protocolos que permitiera la interconexión de varios dispositivos de forma inalámbrica bajo el protocolo IP, permitiendo llevar el desarrollo existente sobre Bluetooth hacia la convergencia IP. 1.2 DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA IPv4 ha demostrado con el paso del tiempo ser un protocolo de gran capacidad, pues aunque en un principio IPv4 fue creado con la idea de interconectar redes simples, ha sido capaz de soportar el crecimiento desmedido de Internet. Sin embargo, en los últimos años han sobresalido diversos problemas existentes en IPv4 asociados con el crecimiento de Internet, como la falta de seguridad y el nacimiento de nuevas tecnologías y servicios que requieren conectividad IP. El problema más evidente y reconocido del protocolo IPv4, es el agotamiento del espacio de direcciones gracias al crecimiento exponencial de Internet y a los ineficientes métodos de asignación de direcciones IP por clases, en los que se asignaron grandes bloques de direcciones a organizaciones que solo requerían unas pocas. Esto obligó a las organizaciones a utilizar el traductor de direcciones de red NAT (Network Address Traslator), con el fin de asignar múltiples direcciones privadas a una o varias direcciones IP públicas. Es por esto que se ha impulsado la creación de nuevas tecnologías como el direccionamiento sin clase, las direcciones CIDR (Classless Inter-Domain Routing) e IPv6. Con el paso del tiempo también ha sido necesario introducir modificaciones y protocolos complementarios a IPv4, pues el crecimiento en los requerimientos del usuario que utiliza Internet hace necesarias nuevas capacidades, tales como la seguridad, ya que servicios como el comercio electrónico, que ha tenido un gran auge en los últimos años, exige a la red completa privacidad en la transferencia de datos. 4

21 IPv6 es una manera potencial de reducir al mínimo los problemas presentes en el protocolo IPv4. Es por esto que la Universidad San Buenaventura sede Bogotá, dado su nivel tanto educativo como investigativo, tiene el deber de fomentar la utilización del protocolo IPv6, aportando el conocimiento y la experiencia necesaria, con el fin de capacitar personas que puedan promover la transición hacia este protocolo a nivel nacional, impulsando así avances tecnológicos con el propósito de generar aplicaciones innovadoras. Cuál es la mejor forma realizar la transición de una red IPv4 a una red que soporte IPv6? 1.3 JUSTIFICACIÓN El nuevo protocolo IPv6, dispone de 340 billones de billones de billones de direcciones, lo que hace que la cantidad de direcciones IPv4 parezca insignificante. Con este mayor espacio de direcciones, IPv6 ofrece una variedad de ventajas en términos de estabilidad y flexibilidad en la operación de las redes y simplicidad en su administración. También es probable que la era IPv6 genere una nueva ola de innovación en la creación de aplicaciones y en oferta de servicios. Pero es imposible deshabilitar todas las redes IPv4 y actualizarlas a IPv6 al mismo tiempo. Es por esto que es necesario un proceso de migración, el cual debe realizarse en forma gradual y progresiva. Este proyecto pretende ser un primer paso hacia el desarrollo investigativo sobre el protocolo IPv6 en la Universidad San Buenaventura, promoviendo y construyendo conocimiento, con el fin de abrir puertas a nuevos productos, servicios y aplicaciones, que serán desarrollados en el futuro gracias a todas la ventajas que este protocolo brinda. 5

22 1.4 OBJETIVOS DE LA INVESTIGACIÓN Objetivo General Investigar y Simular el funcionamiento de las diferentes estrategias de transición del protocolo IPv4 al protocolo IPv6 para las diferentes topologías típicas de red posibles e implementarlas a nivel de laboratorio Objetivos Específicos Analizar el protocolo IPv6 en cuanto a sus objetivos, funcionamiento, estructura, encabezados de capa de red y direccionamiento. Realizar una descripción detallada y comparativa de los mecanismos de migración y convivencia propuestos por la IETF como son: Pila (Dual- Stack), Traducción de encabezados y Tunneling. Implementar en el laboratorio diversos ejemplos de casos típicos. Modelar, simular e implementar a nivel de laboratorio, los mecanismos de migración en diversas topologías de red con el objetivo de comprender y evaluar su comportamiento individual y poder compararlos entre sí, mediante la medición de eventos generados, para determinar cuál es el más adecuado dependiendo de la topología de red. 1.5 ALCANCES Y LIMITACIONES DEL PROYECTO Este proyecto se realiza con la finalidad de conocer el funcionamiento del protocolo IPv6, sus características y a su vez comprobar los mecanismos de transición que ayudaran a acelerar el proceso de migración. Todos los diseños que se realicen, será simulados para que puedan ser debidamente evaluados. El 6

23 objetivo de este proyecto no es la implementación de una red IPv6 en la universidad; más bien el interés es brindar las pautas tanto teóricas como prácticas necesarias para una futura transición. Es importante aclarar que para las simulaciones de las redes diseñadas con base en el nuevo protocolo IPv6, se depende del grado de desarrollo que tengan actualmente tanto el protocolo como los simuladores de red. También es necesario aclarar que para la realización de las implementaciones a nivel de laboratorio y para la posible ejecución de algunas pruebas se requiere de la completa colaboración del administrador de la red de la USB. En caso contrario se tendrá limitaciones. 7

24 2. METODOLOGIA El desarrollo de este proyecto tiene un enfoque empírico-analítico el cual tiene un interés técnico, orientado a la interpretación y transformación del mundo material. Proporciona además una estructura particular a la metodología de investigación en tanto que orienta el trabajo a la contrastación permanente de las aseveraciones teóricas con la verificación experimental, de manera que los cálculos generados a través de modelos matemáticos y simulaciones computacionales se deben retroalimentar con la experimentación, en la búsqueda de información cada vez más confiable y práctica para la solución del problema. 8

25 3. LINEA DE INVESTIGACION DE USB / SUB-LINEA DE FACULTAD / CAMPO TEMATICO DEL PROGRAMA Línea institucional-tecnologías actuales y sociedad La sociedad requiere de conocimientos técnicos y científicos de vanguardia que ayuden a la solución de problemas o faciliten los procesos de mejoramiento de la calidad de vida de las personas que pertenecen a un grupo social determinado. Sub-Línea de Facultad-Sistemas de Información y Comunicación. Con este proyecto se pretende conocer y utilizar correctamente los más modernos protocolos y sistemas de información utilizados en las redes de comunicación, con el fin de lograr mejoras tecnológicas que permitan desarrollar proyectos orientados a satisfacer necesidades específicas, para así, atender los requerimientos del sector empresarial o industrial en la implementación o mejoramiento de este tipo de sistemas. Campo Temático del Programa-Comunicaciones El desarrollo de este proyecto está relacionado con los elementos capaces de llevar o traer información a través del aire o de ductos específicos, de acuerdo con las necesidades, capacidad y forma de la información que deben manejar los usuarios. 9

26 4. MARCO TEORICO Y CONCEPTUAL 4.1 EL PROTOCOLO IPV4 Y SUS LIMITACIONES Nacimiento del Protocolo IPv4 y Agotamiento de Direcciones En 1966 el Departamento de Defensa (DoD - Department of Defense) del gobierno de Estados Unidos, a través de su Agencia de Investigación de Proyectos Avanzados (ARPA - Advanced Research Projects Agency), inició un proyecto para interconectar las computadoras de los centros militares y de investigación. Este sistema de comunicación y control distribuido con fines militares recibió el nombre de ARPANET, su principal objetivo teórico era crear una arquitectura de red sólida y robusta que, incluso en caso de falla de alguna estación, pudiera trabajar con las computadoras y enlaces restantes. En 1969 se instalaron los primeros cuatro nodos de la red en la Universidad de Los Ángeles (UCLA), la Universidad de California en Santa Bárbara (UCSB), el Instituto de Investigaciones de Standford (SRI) y la Universidad de Utah. En sus inicios, ARPANET trabajaba con diferentes protocolos de comunicación, siendo NCP (Network Control Protocol) el principal. El primero de enero 1983, cuando la red ya contaba con 562 hosts, todas las máquinas de ARPANET adoptaron como estándar los protocolos TCP/IP, permitiendo así el crecimiento ordenado de la red y eliminando las restricciones que presentaban los protocolos anteriores. El protocolo IP tiene dos funciones básicas: la fragmentación, que permite enviar paquetes mayores que el límite de tráfico establecido para un enlace dividiéndolos en paquetes más pequeños, y el direccionamiento, que permite identificar el destino y el origen de los paquetes con base en la dirección almacenada en el encabezado del protocolo. La versión del protocolo IP que se utilizaba en aquella época y continúa utilizándose en la actualidad es la versión 4 o IPv4. Esta versión 10

27 demostró ser muy robusta, de fácil implementación e interoperabilidad, sin embargo el proyecto original no previó algunos aspectos tales como: El crecimiento de las redes y el posible agotamiento de las direcciones IP El crecimiento de la tabla de enrutamiento Problemas relacionados con la seguridad de los datos transmitidos Prioridad en la entrega de determinados tipos de paquetes Las especificaciones de IPv4 reservan 32 bits para direccionamiento, permitiendo generar más de 4 mil millones de direcciones diferentes. Inicialmente, estas direcciones se dividieron en tres clases de tamaño fijo de la siguiente manera: Clase A: Definía el bit más significativo como 0, utilizaba los 7 bits restantes del primer octeto para identificar la red y los 24 bits restantes para identificar el host. Estas redes utilizaban el rango de a Clase B: Definía los 2 bits más significativos como 10, utilizaba los 14 bits siguientes para identificar la red y los 16 bits restantes para identificar el host. Estas redes utilizaban el rango de a Clase C: Definía los 3 bits más significativos como 110, utilizaba los 21 bits siguientes para identificar la red y los 8 bits restantes para identificar el host. Estas redes utilizaban el rango de a Aunque la intensión de esta división era flexibilizar la distribución de direcciones abarcando redes de diferentes tamaños, este tipo de clasificación demostró ser ineficiente. Así, la clase A atendía un número muy pequeño de redes pero ocupaba la mitad de todas las direcciones disponibles. Para direccionar 300 dispositivos en una red era necesario obtener un bloque de direcciones clase B, 11

28 con lo cual se desperdiciaba prácticamente la totalidad de las 65 mil direcciones; y las 256 direcciones clase C no satisfacían las necesidades de la gran mayoría de las redes. La tabla 4.1 muestra la totalidad de redes y direcciones en cada clase. Tabla 4.1: Clases de direcciones IPv4 CLASE FORMATO REDES HOSTS A 7 Bits Redes, 24 Bits Host B 14 Bits Redes, 16 Bits Host C 21 Bits Redes, 8 Bits Host Otro factor que contribuyó al desperdicio de direcciones fue el hecho de que decenas de rangos clase A fueron asignados íntegramente a grandes organizaciones tales como IBM, AT&T, Xerox, HP, Apple, MIT, Ford, el Departamento de Defensa de Estados Unidos, entre muchas otras, poniendo a disposición de cada una de ellas millones de direcciones. En 1990 ya había hosts conectados a la red y algunos estudios comenzaban a hablar de un colapso provocado por la falta de direcciones. Otros problemas tales como el crecimiento de la tabla de enrutamiento también se agudizaban a medida que Internet evolucionaba. Debido a la tasa de crecimiento de Internet y a la política de distribución de direcciones, en mayo de 1992 ya se habían distribuido 38% de los rangos de direcciones clase A, 43% de la clase B y 2% de la clase C. En esa época ya había hosts conectados a la red. 12

29 En 1993, la creación del protocolo HTTP (Hypertext Transfer Protocol) y la liberación de Internet por parte del Gobierno de Estados Unidos para su utilización comercial produjeron un salto aun mayor en la tasa de crecimiento de la red, que pasó de de hosts en 1993 a más de de hosts en Soluciones al agotamiento de direcciones Ante este escenario la IETF (Internet Engineering Task Force) comenzó a debatir estrategias para resolver el tema del agotamiento de las direcciones IP y el problema del crecimiento de la tabla de enrutamiento. Para ello, en noviembre de 1991 se formó el grupo de trabajo ROAD (ROuting and ADdressing), que para solucionar estos problemas propuso la utilización de CIDR (Classless Inter-domain Routing). Las ideas básicas del CIDR eran poner fin al uso de clases de direcciones para permitir la distribución de bloques de tamaño adecuado a las necesidades reales de cada red y la agregación de rutas para reducir el tamaño de la tabla de enrutamiento. Los bloques CIDR se identifican mediante prefijos de red. Por ejemplo, en la dirección a.b.c.d/x, los x bits más significativos indican el prefijo de red. Otra manera de indicar el prefijo es a través de máscaras, donde la máscara indica un prefijo /8, indica un /16, y así sucesivamente. Otra solución, presentada por la IETF fue el protocolo DHCP (Dynamic Host Configuration Protocol). A través del protocolo DHCP un host puede obtener una dirección IP automáticamente y adquirir información adicional como por ejemplo la máscara de subred, la dirección del router por defecto y la dirección del servidor DNS local. DHCP ha sido muy utilizado por los ISPs debido a que les permite asignar direcciones IP temporarias a sus clientes conectados. De esta forma ya no es 13

30 necesario obtener una dirección para cada cliente, sino que basta con asignar direcciones dinámicamente a través del servidor DHCP. Este servidor tendrá una lista de direcciones IP disponibles: cada vez que un nuevo cliente se conecte a la red le será asignada una de estas direcciones de forma aleatoria, dirección que será devuelta en el momento en que el cliente se desconecte. NAT (Network Address Translation) fue otra técnica desarrollada para resolver el problema del agotamiento de las direcciones IPv4. La idea básica es permitir que varios hosts puedan salir a Internet utilizando una única dirección IP pública o a través de un número pequeño de estas direcciones. Dentro de una red, cada equipo recibe una dirección IP privada única que es utilizada para enrutar el tráfico interno. Sin embargo, cuando un paquete debe ser enrutado fuera de la red, las direcciones IP privadas se traducen a direcciones IP públicas globalmente únicas. Para que este esquema sea posible se utilizan los tres rangos de direcciones IP declarados como privados, siendo la única regla de utilización que ningún paquete que contiene estas direcciones puede atravesar la Internet pública. Los tres rangos reservados son los siguientes: a / a / a /16 El uso de NAT demostró ser eficiente en cuanto a la economía de direcciones IP, además de presentar algunos otros aspectos positivos tales como facilitar la numeración interna de las redes, ocultar la topología de las redes y solo permitir la entrada de paquetes generados en respuesta a una solicitud de la red. No 14

31 obstante, el uso de NAT presenta inconvenientes que no compensan las ventajas que ofrece. NAT rompe con el modelo end-to-end de Internet ya que no permite conexiones directas entre dos hosts, lo que dificulta el funcionamiento de una serie de aplicaciones tales como P2P (Peer-to-Peer), VoIP (Voice Over IP) y VPN (Virtual Private Network). Otro problema es la baja escalabilidad, ya que el número de conexiones simultáneas es limitado y además requiere una gran capacidad de procesamiento por parte del dispositivo traductor. El uso de NAT también imposibilita rastrear el camino del paquete mediante herramientas como traceroute y dificulta la utilización de algunas técnicas de seguridad como IPSec (Internet Protocol Security). Además, su uso genera una falsa sensación de seguridad ya que, a pesar de no permitir la entrada de paquetes no autorizados, NAT no realiza ningún tipo de filtrado ni verificación de los paquetes que lo atraviesan. Aunque estas soluciones han disminuido la demanda de direcciones IP, no han sido suficientes para resolver los problemas derivados del crecimiento de Internet. De hecho, estas medidas permitieron que hubiera más tiempo para desarrollar una nueva versión del protocolo IP, una versión que se basara en los principios que contribuyeron al éxito de IPv4 pero que también fuese capaz de superar las fallas que se detectaron. 4.2 INTRODUCCIÓN AL PROTOCOLO IPV Nacimiento del Protocolo IPv6 En diciembre de 1993 la IETF formalizó las investigaciones sobre la nueva versión del protocolo IP solicitando el envío de proyectos y propuestas para el nuevo protocolo. Esta fue una de las primeras acciones del grupo de trabajo de la IETF 15

32 denominado Internet Protocol next generation (IPng). Los principales aspectos que debían ser abordados al elaborar la siguiente versión del protocolo IP eran: Escalabilidad Seguridad Configuración y Administración de Redes Soporte para QoS Movilidad Políticas de Enrutamiento Transición Varios proyectos comenzaron a estudiar los efectos del crecimiento de Internet. Entre estos se destacaron CNAT, IP Encaps, Nimrod y Simple CLNP. De estas propuestas surgieron el TCP and UDP with Bigger Addresses (TUBA), que fue una evolución de Simple CLNP, y el IP Address Encapsulation (IPAE), una evolución de IP Encaps. Algunos meses después se presentaron los proyectos Paul s Internet Protocol (PIP), Simple Internet Protocol (SIP) y TP/IX. Una nueva versión del protocolo SIP, que englobaba algunas funcionalidades de IPAE fue presentada poco antes de agregarse al PIP, obteniéndose como resultado el Simple Internet Protocol Plus (SIPP). En este mismo período TP/IX pasó a llamarse Common Architecture for the Internet (CATNIP). En enero de 1995, el IPng presentó un resumen de la evaluación de las tres principales propuestas: CATNIP Fue concebido como un protocolo de convergencia para permitir que cualquier protocolo de la capa de transporte se ejecutara sobre cualquier protocolo de la capa de red, creando así un ambiente común entre los protocolos de Internet, OSI y Novell. 16

33 TUBA Proponía aumentar el espacio para direccionamiento IPv4 y volverlo más jerárquico, intentando evitar la necesidad de modificar los protocolos de la capa de transporte y aplicación. Pretendía una migración simple y a largo plazo, basada en la actualización de los host y servidores DNS pero sin necesidad de encapsulado o traducción de paquetes ni mapeo de direcciones SIPP Concebido para ser una etapa evolutiva del protocolo IPv4, sin cambios radicales y conservando la interoperabilidad con la versión 4 del protocolo IP, proveía una plataforma para nuevas funcionalidades de Internet, aumentaba el espacio para direccionamiento de 32 bits a 64 bits, presentaba un mayor nivel de jerarquía y estaba compuesto por un mecanismo que permitía ampliar la dirección denominado cluster addresses. Ya tenía encabezados de extensión y un campo flow para identificar el tipo de flujo de cada paquete. Sin embargo, las tres propuestas también presentaban problemas significativos. Finalmente, la recomendación para el nuevo Protocolo de Internet se basó en una versión revisada del SIPP, que pasó a incorporar direcciones de 128 bits, junto con los elementos de transición y autoconfiguración del TUBA, el direccionamiento basado en CIDR y los encabezados de extensión. El protocolo CATNIP fue descartado por ser considerado muy incompleto. A raíz de esta definición, la nueva versión del Protocolo de Internet pasó oficialmente a llamarse IPv Descripción y características del Protocolo IPv6 Las especificaciones de IPv6 fueron inicialmente presentadas en diciembre de 1995 y reestructuradas en diciembre de Entre sus principales características se destacan: 17

34 Mayor capacidad de direccionamiento: el espacio de direccionamiento aumentó de 32 bits a 128 bits, permitiendo: niveles más específicos de agregación de direcciones, identificar una cantidad mucho mayor de dispositivos en la red e implementar mecanismos de autoconfiguración. También se mejoró la escalabilidad del enrutamiento multicast mediante la adición del campo "alcance" (o ámbito) en la dirección multicast. También se definió un nuevo tipo de direcciones, las direcciones anycast. Simplificación del formato del encabezado: con el objetivo de reducir el costo de procesamiento de los paquetes en los routers, algunos campos del encabezado IPv4 se eliminaron o se convirtieron en opcionales. Soporte para encabezados de extensión: las opciones dejaron de formar parte del encabezado base, permitiendo un enrutamiento más eficaz, límites menos rigurosos en cuanto al tamaño y la cantidad de opciones y una mayor flexibilidad para la introducción de nuevas opciones en el futuro. Capacidad de identificar flujos de datos: se agregó un nuevo recurso que permite identificar paquetes que pertenecen a determinados flujos de tráfico que pueden requerir tratamientos especiales Direccionamiento eficiente y jerárquico: IPv6 posee una estructura de enrutamiento eficiente y jerárquica que permite a los routers principales que trabajan en el Internet, poseer tablas de enrutamiento más pequeñas de acuerdo con la infraestructura que tenga cada ISP. Autoconfiguración: Las direcciones IPv6 pueden ser configuradas manualmente o en forma automática, aún en ausencia de un router. Esto debido a que si se desea, los hosts pueden autoconfigurarse con direcciones de enlace-local (link-local addresses). 18

35 Soporte para autenticación y privacidad: se especificaron encabezados de extensión capaces de proveer mecanismos de autenticación y garantizar l a integridad y confidencialidad de los datos transmitidos. QoS: El tráfico es priorizado mediante el campo clase de tráfico (Traffic Class). Además, un campo de la cabecera de los datagramas IPv6 permite a los routers identificar y proporcionar un tratamiento especial a los paquetes que pertenecen a un determinado flujo. Interacción con nodos vecinos: Mediante un protocolo llamado Neighbor Discovery (ND), IPv6 puede manejar una serie de mensajes que permiten la interacción de nodos vecinos entre sí y de estos nodos con los routers conectados a la red. Extensibilidad: IPv6 puede ser fácilmente modificado, ya que añadiendo extensiones a la cabecera IPv6 se puede obtener nuevas características para el protocolo. Además, IPv6 también modificó el tratamiento de la fragmentación de los paquetes que pasó a ser realizada sólo en el origen, permitiendo el uso de conexiones extremo a extremo, principio que se había roto en IPv4 debido al uso generalizado de NAT. También aportó recursos para facilitar la configuración de redes IPV4 frente a IPV6 IPv6 mantiene varias de las funciones usadas en IPv4; en cambio, funciones que eran usadas en muy pocas ocasiones o no eran usadas han sido eliminadas. Esto permite añadirle a este nuevo protocolo nuevas características que provean nuevas funcionalidades para la comunicación a través del Internet. 19

36 Las diferencias más importantes entre IPv4 e IPv6 se muestran en la Tabla 4.2 a continuación: Tabla 4.2: Diferencias entre IPv4 e IPv6 IPv4 IPV6 Las direcciones de origen y destino tienen una longitud de 32 bits (4 bytes). La implementación de IPSec es opcional. La cabecera del datagrama no contiene mecanismos para la identificación de flujo de paquete para ofrecer QoS. La fragmentación involucra tanto al host como a los routers, de modo que este proceso produce retardos en el rendimiento del router. No tiene ningún requisito para el tamaño de un paquete de capa de enlace y debe ser capaz de reensamblar un paquete de 576 bytes. La cabecera incluye un checksum para el control, de errores que debe ser recalculado en cada router. Las direcciones de origen y destino tienen una longitud de 128 bits (16 bytes). La implementación y soporte para IPSec es obligatorio. La Identificación de flujos de paquete está presente en la cabecera IPv6 usando el campo "Flow Label", con lo cual se puede ofrecer QoS. El proceso de fragmentación solamente involucra a los hosts de origen y destino. La capa de enlace de soportar un paquete de 1280 bytes de tamaño y debe ser capaz de reensamblar un paquete de 1500 bytes. La cabecera no incluye Checksum. 20

37 La cabecera incluye campos llamados opciones. ARP envía tramas broadcast para realizar peticiones ARP de modo que se pueda resolver una dirección IPv4 en una dirección de capa física. IGMP (Internet Group Management Protocol) es usado para manejar grupos de subredes locales. ICMP Router Discovery es usado para determinar la dirección IPv4 del mejor "gateway" y es opcional. Las direcciones de broadcast son utilizadas para enviar tráfico a todos los nodos en una subred. Las direcciones deben ser configuradas manualmente o mediante DHCP. Todos los datos opcionales son movidos a cabeceras de extensión. Las tramas para solicitar peticiones ARP son reemplazadas con mensajes multicast "Neighbor Discovery". IGMP es reemplazado por MLD (Multicast Listener Discovery) que es un set de mensajes que son intercambiados por los routers para descubrir direcciones multicast. ICMPv4 es reemplazado por mensajes ICMPv6 y es necesariamente requerido. No existen direcciones IPv6 de broadcast, en su lugar se emplean direcciones multicast que permiten comunicación con todos los nodos del enlace. La configuración de direcciones puede ser manual, a través de DHCP o mediante autoconfiguración. 21

38 Usa recursos de registros de direcciones de host A para asignar nombres a direcciones IP a través de DNS. Usa registros AAAA para asignar nombres a direcciones IPv6 a través de DNS Estado de adopción de IPv6 El despliegue de IPv6 se inicio en el año 2002, momento en el cual ya se podía considerar estandarizado en los aspectos básicos que prácticamente lo igualaban a IPv4. En ese momento, la mayoría de los fabricantes de Sistemas Operativos ofrecían IPv6 en sus productos, al igual que los fabricantes de equipamiento de redes (enrutadores fundamentalmente), con diferentes grados de madurez y soporte técnico y/o comercial. En ese mismo año se produjeron los primeros grandes despliegues en el mundo, siendo el caso más relevante posiblemente el de NTT (en Japón), que no sólo ofreció IPv6 en sus redes intercontinentales, sino que para poder lanzar los servicios comerciales de IPTV, decidió que era más viable utilizar multicast (multidifusión) IPv6, aún cuando hubiera que desplegarlo partiendo de cero, que usar multicast IPv4. La situación actual es que el 99% de los grandes carriers (los denominados tier 1 ), ofrecen IPv6, muchos de ellos desde hace varios años, en sus redes intercontinentales y en muchos casos regionales, mientras que sólo algunos proveedores de Internet nacionales (aunque es difícil de estimar, quizás un 20% en todo el mundo), proporcionan el servicio y cuando lo proporcionan, muy pocos lo ofrecen en la última milla, salvo para clientes corporativos. 22

39 Esto es debido fundamentalmente a que los CPEs (Customer Premises Equipment), han sido los equipos con mayor demora en su introducción comercial, y especialmente los de gama baja, que son los que habitualmente suministran los ISPs a los clientes residenciales. Esta situación ha cambiado radicalmente en los últimos dos años. También existen numerosos ISPs realizando pilotos con diferentes números de usuarios, algunos de ellos muy importantes, como Comcast y TMobile. Los proveedores de contenidos dieron sus primeros pasos en el año 2.006, anticipándose Google, que desde hace ya 3 años ofrece sus servicios con IPv6, seguido FaceBook, Netflix, Yahoo, CNN y ebay entre otros. Del mismo modo diversas prensas online, radios y TV por Internet, por supuesto incluyendo YouTube, soportan IPv6. Del mismo modo, algunos proveedores de Content Delivery Networks (CDNs o Redes Suministradoras de Contenidos), en las que se basan grandes proveedores de contenidos, como Limelight Networks ya ofrecen soporte de IPv6 y otros como Akamai, los han anunciado para los próximos meses. Similar es el caso de grandes proveedores de servicios de hosting y housing. Por último, desde el punto de vista de servicios de infraestructura de la Red, el otro servicio que es importante, DNS (Domain Name System, Sistema de Nombres de Dominio ), está preparado desde hace años en lo que se denomina la Raíz (root), así como en la mayoría de los TLDs (Top Level Domains). Es decir, en los dominios genéricos y en más del 65% de los dominios de países, con la notable excepción (si nos fijamos en los cctlds de mayor número de dominios registrados), de España (.es). IANA, siguiendo indicaciones del IETF y de acuerdo con políticas globales, ha entregado a los RIR s (Registros Regionales de Internet), bloques IPv6 para su 23

40 distribución a los ISPs de la región. La última entrega de un prefijo /12 para cada RIR, se produjo en el 2006 y se espera que esta entrega sea suficiente para muchos años. Figura 4.1: Distribución Actual de Direcciones IPv6 Fuente: A su vez, los RIRs entregan a los ISPs bloques con una longitud de prefijo de 32 bits o menores, según la necesidad justificada por el ISP. Dado que los ISPs entregan prefijos de 48 bits a los usuarios, con un bloque /32 un ISP puede direccionar aproximadamente clientes; con un /31 el doble y así sucesivamente. Para facilitar la uniformidad de las estadísticas, estas se realizan utilizando como base un prefijo /32. Figura 4.2: Asignaciones de IPv6 de RIRs a ISPs (Septiembre 2010) Fuente: 24

41 Otra cuestión muy importante es el aspecto de qué proporción del tráfico de Internet utiliza IPv6. La problemática estriba en que, por cuestiones técnicas inherentes al diseño del protocolo y su coexistencia con IPv4, cuando la última milla de ambos extremos de una determinada comunicación no tiene IPv6 habilitado, que es la situación más habitual hoy en día, aunque los ISPs no estén dando servicio IPv6, entran en funcionamiento los denominados mecanismos de transición, algunos de los cuales son automáticos (o bien otros configurados por los usuarios). Es por ello que ante la pregunta de cuánto tráfico IPv6 tienen en sus redes los grandes carriers, que ya ofrecen servicio IPv6, la respuesta suele estar entre el 3 y el 5%. Sin embargo, algunos estudios (6METER, RIPE55) demuestran que si se mide el tráfico IPv6 encapsulado en IPv4 (el que se genera con los mecanismos de transición), que por otro lado no es nada fácil de medir, hay niveles de tráfico que llegan a superar el 35%. Este tráfico es fundamentalmente peer to peer, pero con la disponibilidad de contenidos en IPv6 (ejemplo, YouTube), también está creciendo de manera muy significativa el tráfico cliente-servidor Por qué no se despliega IPv6 con mayor rapidez? Se ha comentado que la infraestructura de las grandes redes está preparada, y que ya se genera tráfico IPv6. Se debe añadir que dicho tráfico se incrementa rápidamente, dado que todos los Sistemas Operativos tienen IPv6 activado por defecto (con la excepción de RIM/BlackBerry) y por definición de los estándares, cuando un servicio (ya sea cliente en caso de peer to peer o servidor en caso de cliente servidor), está habilitado tanto con IPv4 como con IPv6, tiene preferencia utilizar IPv6. Es decir, el tráfico IPv6 va ganando terreno paulatinamente al tráfico IPv4, en teoría de una forma transparente para los usuarios, aún cuando los ISPs no desplieguen IPv6. Esto es posible porque los mecanismos de transición cumplen su función, sin embargo, y especialmente los automáticos, no son perfectos y generan problemas a los usuarios y a los proveedores de contenidos. Normalmente se generan 25

42 retardos, pérdida de calidad en los accesos a los contenidos, e incluso en ocasiones la total imposibilidad de acceder a algunos contenidos. Obviamente la solución no es desactivar IPv6, sino dar los pasos que hace años ya debieran haberse dado, para que se despliegue IPv6 de una forma más rápida. A mayor velocidad del despliegue de IPv6, menos problemas para los proveedores de contenidos y usuarios. El desconocimiento de IPv6 es precisamente el factor principal por el que no haya sido desplegado con mayor celeridad. Habitualmente se tiene la percepción de que desplegar IPv6 supone un coste muy importante y la realidad es que si se planifica adecuadamente y con anticipación, no es el caso. Concretando un poco más, dado que la mayoría de los equipos de las redes de core de los ISPs y de las organizaciones públicas y privadas tienen antigüedades inferiores a 4 o 5 años, es seguro que ya tienen soporte IPv6. En muchos casos es tan sólo cuestión de activarlo y configurarlo. En algunos casos hace falta actualizar el software (lo que puede requerir una licencia). El mayor coste tiene que ver con la formación de los ingenieros que gestionan dichas redes y el equipamiento. Recientemente se ha evaluado que se requiere formar a unos 20 millones de ingenieros en todo el mundo en los próximos dos años para una correcta transición a IPv6. Como ya se ha indicado anteriormente, el otro coste importante es la necesidad de reemplazar los CPEs (Customer Premises Equipment). La disponibilidad de los mismos, con un adecuado soporte de IPv6, se ha demorado en comparación con el resto de equipos de la red, precisamente porque los fabricantes no han sido motivados por falta de demanda de los mismos por parte de los ISPs. 26

43 Sin embargo, en una primera fase, no es estrictamente necesario reemplazar los CPEs, pues si los ISPs despliegan mecanismos de transición en lugar de que los usuarios dependan de los mecanismos de transición automáticos, se alivian los defectos que generan estos últimos. De hecho, se espera que la mayoría de los ISPs suministren CPEs con IPv6 a los usuarios nuevos, pero que los equipos de los suarios antiguos sean reemplazados con ocasión de otros cambios tecnológicos (por ejemplo provisión de servicios de IPTV, mayores anchos de banda, otras tecnologías de conexión a Internet, etc.). Otro de los motivos aducidos para evitar la transición a IPv6 por parte de los ISPs ha sido la falta de contenidos, lo cual ha cambiado rápidamente desde el momento en que Google comenzó a ofrecer sus servicios con el nuevo protocolo y obviamente ello impacta en la competencia que se ve obligada a reaccionar. Además, los ISPs indican que no hay oportunidad de negocio, que IPv6 no es atractivo desde el punto de vista económico. De nuevo se trata de una falsa percepción por desconocimiento no solo de IPv6, sino de la inevitable situación de agotamiento de IPv4. Por último, no completar la transición a IPv6 a la mayor brevedad, implicaría la necesidad de utilizar tecnologías de traducción en las redes de banda ancha, lo que se ha dado en llamar Carrier Grade NAT, que supondría no sólo grandes costes (en torno a un millón de dólares por cada dispositivo, sin que aún se haya determinado cuantos miles de usuarios podrá atender), sino además perpetuar en la red la existencia de NAT, dificultando el desarrollo de aplicaciones extremo a extremo. No moverse a IPv6 tiene graves consecuencias para los ISPs en cuanto a la pérdida de negocio. Es obvio que algunos irán por delante y los rezagados perderán cuota de mercado. Pero es más grave para la Sociedad de la 27

44 Información, pues los usuarios se ven abocados a una nueva brecha digital, algo así como a una doble Internet en la que no se puede garantizar a todos los ciudadanos el acceso a todos los contenidos de una forma adecuada y ni siquiera que unos usuarios puedan conectarse con otros. Evitar esto es posible y sin grandes inversiones. 4.3 EL PROTOCOLO IPv Cabecera IPv6 Se realizaron algunos cambios en el formato del encabezado base de IPv6 respecto al de IPv4 para volverlo más simple (solo ocho campos y un tamaño fijo de 40 bytes), más flexible y más eficiente, previendo su extensión por medio de encabezados adicionales que no necesitan ser procesados por todos los routers intermedios. Estos cambios permiten que, incluso con un espacio de direccionamiento de 128 bits, cuatro veces mayor que los 32 bits de IPv4, el tamaño total del encabezado de IPv6 sea apenas dos veces mayor que el de la versión anterior. Los campos de la cabecera IPv6 pueden verse en la Figura

45 Figura 4.3: Cabecera IPv6 Fuente: Migrating to IPv6 Entre los cambios realizados se destaca la eliminación de seis campos del encabezado de IPv4 debido a que sus funciones ya no son necesarias o bien son implementadas por los encabezados de extensión. Las opciones adicionales ahora forman parte de los encabezados de extensión de IPv6. Por lo tanto se pudieron eliminar los campos Opciones y Complementos. El campo Tamaño del Encabezado también se eliminó, ya que el tamaño del encabezado de IPv6 es fijo. Los campos Identificación, Flags y Desplazamiento del Fragmento se eliminaron, ya que los datos referentes a la fragmentación ahora se incluyen en un encabezado de extensión apropiado. Para aumentar la velocidad de procesamiento de los datagramas en los routers se eliminó el campo Suma de Verificación, ya que éste cálculo es realizado por los protocolos de las capas superiores. 29

46 También se cambió el nombre y la ubicación de los cuatro campos que se muestran en la Figura 4.4. Estos cambios de posición se definieron para facilitar el procesamiento de estos datos por parte de los routers. Figura 4.4: Cambio de Nombre en 4 Campos de la Cabecera También se agregó un nuevo campo, el Identificador de Flujo (Flow Label), agregándole al protocolo IP otro mecanismo de soporte para QoS. Más adelante se mostrará más detalles sobre este campo y cómo el protocolo IPv6 trata el tema de QoS. La siguiente lista describe el tamaño y la función de cada campo en la cabecera: Version (4 bits): Identifica la versión del protocolo IP utilizado. En el caso de IPv6 el valor de este campo es 6. Traffic Class (8 bits): Identifica y diferencia los paquetes por clases de servicios o prioridad. Este continúa ofreciendo las mismas funcionalidades y definiciones del campo Tipo de Servicio de IPv4. Flow Label (20 bits): Identifica y diferencia paquetes del mismo flujo en la capa de red. Este campo permite que el router identifique el tipo de flujo de cada paquete, sin necesidad de verificar su aplicación. 30

47 Payload Length (16 bits): Indica la longitud de los datos después de la cabecera. Next Header (8 bits): Indica cual es la cabecera de extensión siguiente, si existe, o el protocolo de capa superior (TCP o UDP). Reemplaza al campo Protocol Type de IPv4. Hop Limit (8 bits): Indica la cantidad de routers por los que un paquete IPv6 puede pasar antes de ser descartado. Reemplaza al campo Time-to-Live (TTL) de IPv4. Source Address (128 bits): Indica la dirección IP del emisor del paquete. Destination Address (128 bits): Indica la dirección del nodo destino del paquete. (Nota: este campo puede no contener la dirección IPv6 del último destino si está presente la cabecera de extensión Routing Header (encabezado de extensión de enrutamiento). A diferencia de lo que ocurre en IPv4 donde todos los datos opcionales se incluyen en el encabezado base, en IPv6 estos datos se incluyen a través de encabezados de extensión. Estos encabezados se encuentran entre el encabezado base y los datos del datagrama, ademas no tienen una cantidad ni un tamaño fijo. Si en un mismo paquete existen múltiples encabezados de extensión, éstos serán agregados en serie formando una cadena de encabezados. Las especificaciones de IPv6 definen seis encabezados de extensión: Hop-by-Hop Options, Destination Options, Routing, Fragmentation, Authentication Header y Encapsulating Security Payload. 31

48 En IPv6, el uso de encabezados de extensión busca aumentar la velocidad de procesamiento en los routers, ya que el único encabezado de extensión procesado en cada router es el Hop-by-Hop; los demás solo son tratados por el nodo identificado en el campo Dirección de Destino del encabezado base. Además, se pueden definir y utilizar nuevos encabezados de extensión sin tener que modificar el encabezado base. Un paquete IPv6 puede llevar cero, uno o más encabezados de extensión. Éstos se encuentran a continuación del encabezado base IPv6 y son las siguientes: Hop-by-Hop Options Header (encabezado de extensión de opciones salto a salto) Routing Header (encabezado de extensión de enrutamiento) Fragmentation Header (encabezado de extensión de fragmentación) Destination Options Header (encabezado de extensión de opciones de destino) Authentication Header (encabezado de extensión de autenticación) Encapsulating Security Payload Header (encabezado de extensión de encapsulado para la seguridad de la carga útil) Cada encabezado es identificado por el campo Next Header (siguiente encabezado) del encabezado anterior. Con excepción de los encabezados Hopby-Hop Option y Routing Header, los cuales deben ser examinados y procesados por cada nodo a lo largo del camino del paquete, los demás, solamente, son procesados por el nodo destino, respetando estrictamente el orden en el que aparecen en el paquete. Un nodo destino no puede recorrer las cabeceras de extensión buscando un cabecera en particular. La figura 4.5 muestra cómo se forman los paquetes cuando no tienen ninguna cabecera de extensión y cómo se encadenan éstas cuando se tiene una o cuando 32

49 se tienen varias de estas cabeceras. Además se indica el valor del campo Next- Header. Figura 4.5 Cabecera de extensión Fuente: usuarios.multimedia.es Cuando existe más de una cabecera de extensión en un mismo paquete, las cabeceras deben aparecer en el siguiente orden: 1. Hop-by-Hop 2. Routing 3. Fragment 4. Authentication 5. Encapsulating Security Payload 6. Destination Option 7. Upper-layer Cabeceras de Extensión Cabecera de Opciones Salto a Salto La cabecera de Opciones Salto a Salto se utiliza para transportar información opcional que debe ser examinada en todos los routers a lo largo de la ruta de entrega de un paquete. Esta cabecera se identifica por tener un valor cero en el campo Next Header (Cabecera Siguiente). 33

50 Esta cabecera está conformada tal como se muestra en la Figura 4.6 y el significado de los campos es el siguiente: Figura 4.6 Cabecera de Opciones Salto a Salto Cabecera Siguiente: Campo de 8 bits que identifica el tipo de cabecera que sigue inmediatamente a ésta. Longitud de la Cabecera de extensión: Campo de 8 bits que específica la longitud de la cabecera en unidades de 64 bits (8 octetos), no incluye los primeros 64 bits y es un valor entero y sin signo. Opciones: Campo de longitud variable; la longitud de la cabecera completa es un entero múltiplo de 64 bits. Se especifican cuatro opciones salto a salto y son las siguientes: 1. Relleno 1.- Es utilizada para establecer un byte de relleno dentro de la zona de opciones de una cabecera. 2. Relleno N.- Es utilizada para establecer N bytes de relleno dentro de la zona de Opciones de una cabecera. Las opciones de Relleno 1 y Relleno N aseguran que la cabecera tenga una longitud múltiplo de 64 bits. 34

51 3. Carga útil Jumbo.- Es utilizada para enviar paquetes con una carga útil mayor a bytes. Con esta opción, IPv6 permite tamaños de paquete de hasta millones de bytes. Esto hace posible la transmisión de paquetes de video y mejora las capacidades disponibles sobre cualquier medio de transmisión. 4. Alerta al dispositivo de enrutamiento.- Informa al dispositivo de enrutamiento sobre el contenido del paquete o incluye información de control. Las dos opciones de relleno se utilizan cuando es necesario alinear opciones consecutivas y rellenar la cabecera a una longitud múltiplo de 8 bytes Cabecera de enrutamiento La cabecera de enrutamiento puede ser: Cabecera de enrutamiento Genérica Cabecera de enrutamiento Tipo 0 - Cabecera de enrutamiento genérica Esta cabecera es utilizada por el emisor IP para establecer una lista de uno o más nodos intermedios en el camino hacia el destino de un paquete. Cuando existe cabecera de Enrutamiento, el campo de Siguiente cabecera de la cabecera básica o de la cabecera de extensión anterior, tiene un valor igual a 43. La cabecera de enrutamiento Genérica (ver Figura 4.7), tiene los siguientes campos: 35

52 Figura 4.7 Cabecera de enrutamiento Genérica Cabecera Siguiente: Campo de 8 bits que identifica el tipo de cabecera que sigue inmediatamente después de ésta. Longitud Cabecera de Extensión: Campo de 8 bits que específica la longitud de la cabecera de Enrutamiento en unidades de 64 bits. No incluye los primeros 64 bits, es un valor entero y sin signo. Tipo de Enrutamiento: Campo de 8 bits que sirve para identificar una variante particular de cabecera de Enrutamiento. Segmento Restante: Campo de 8 bits que representa el número de nodos que faltan por ser visitados antes de alcanzar el destino final. Es un valor entero y sin signo. Datos Específicos del Tipo: Campo de longitud variable o campo de datos. Múltiplo entero de 64 bits. Si en una cabecera de Enrutamiento el campo Tipo de enrutamiento tiene un valor desconocido, se analiza el campo Segmento restante y se procede de la siguiente manera: Si el Segmento Restante es cero, se debe ignorar la cabecera de Enrutamiento y se procesa la cabecera Siguiente. 36

53 Si el Segmento Restante es diferente de cero, se descarta el paquete y se envía un mensaje ICMP a la Dirección Origen del paquete. - Cabecera de enrutamiento Tipo 0 En la cabecera de Enrutamiento Tipo 0 no existen direcciones multienvío, esta cabecera no se procesa hasta que el paquete llegue a la dirección destino de la cabecera IPv6. La cabecera de Enrutamiento Tipo 0 tiene los siguientes campos: (Figura 4.8) Figura 4.8 Cabecera de enrutamiento Tipo 0 Cabecera Siguiente: Campo de selección de 8 bits que identifica el tipo de cabecera que sigue inmediatamente a la cabecera de Enrutamiento. Longitud de Cabecera de Extensión: Campo de 8 bits que especifica la longitud de la Cabecera de Enrutamiento en unidades de 8 bytes, sin incluir los primeros 8 bytes, es un valor entero y sin signo. 37

54 Segmento Restante: Campo de 8 bits. En él se listan explícitamente el número de nodos ubicados en el camino que aún deben ser visitados antes de alcanzar el destino final; es un valor entero y sin signo. Reservado: Campo reservado de 32 bits. Para la transmisión se inicia en cero y es ignorado en la recepción. Dirección [1 n]: Campo de 128 bits. Es un vector de direcciones numerados desde 1 hasta n Cabecera de Fragmentación La cabecera de Fragmentación en IPv6 es utilizada sólo por el nodo origen. Un paquete es fragmentado si tiene una longitud mayor que la longitud del MTU (Maximum Transfer Unit). Para conocer la longitud del MTU el nodo origen utiliza un algoritmo de obtención de ruta. En caso de que el nodo no ejecute dicho algoritmo de obtención de la ruta, el origen debe limitar todos los paquetes a bytes que es la mínima longitud del MTU utilizada por las redes. Una cabecera de Fragmentación se reconoce porque el valor de la cabecera Siguiente es 44. La cabecera de Fragmentación tiene los siguientes campos: (Figura 4.9). Cabecera Siguiente: Es un campo de selección de 8 bits que identifica el tipo de cabecera inicial de la parte que puede ser fragmentada en el paquete de origen. Reservado: Es un campo de 8 bits. Para la transmisión se inicia en cero y es ignorado en la recepción. 38

55 Desplazamiento del Fragmento (Fragment Offset): Indica la posición del fragmento en unidades de 64 bits dentro de un datagrama. Es un campo de 13 bits cuyo valor es entero y sin signo. Res: Campo reservado de 2 bits. Para la transmisión se inicia en cero y es ignorado en la recepción. Bandera M: Es un campo de 1 bit; si el bit es igual a 1 significa que existen más fragmentos y si el bit es igual a cero significa que es el último fragmento. Identificación: Es un campo de 32 bits que contiene un número entero que identifica al datagrama. Si un datagrama es fragmentado, cada fragmento tendrá el mismo identificador. El nodo origen asume un contador de 32 bits que se incrementa cada vez que un paquete debe fragmentarse. Figura 4.9 Cabecera de Fragmentación Cabecera Opciones de Destino La cabecera Opciones de Destino es utilizada para llevar información opcional que requiere ser analizada solamente por el nodo o los nodos de destino del paquete. La cabecera Opciones de Destino se reconoce porque el campo de Cabecera Siguiente, en la cabecera inmediatamente precedente, tiene un valor de

56 Los campos de la cabecera de Opciones de Destino son los siguientes: (Figura 4.10) Figura 4.10 Cabecera de Opciones de destino Cabecera Siguiente: Campo de 8 bits que identifica el tipo de cabecera que sigue inmediatamente a la cabecera Opciones de Destino. Longitud de Cabecera Extendida: Campo de 8 bits que especifica la longitud de la cabecera en unidades de 64 bits. No incluye los primeros 64 bits, es un valor entero y sin signo. Opciones: Campo de longitud variable. La longitud de la cabecera completa es un entero múltiplo de 64 bits que contiene una o más opciones codificadas TLV Cabecera de Autentificación La cabecera de Autentificación se usa para permitir que el destino de un mensaje pueda verificar que el mensaje proviene realmente de la dirección de origen especificada en la cabecera del paquete y no de un impostor. Los campos de la cabecera de Autentificación (Figura 4.11), se describen a continuación: Cabecera Siguiente: Es un campo de 8 bits que identifica el tipo de cabecera que sigue inmediatamente a ésta. 40

57 Longitud de Datos de Autentificación: Campo de 8 bits. Específica la longitud del campo de Datos de Autentificación en múltiplos de 64 bits. Reservado: Campo de 8 bits para uso en el futuro. Para la transmisión se inicia en cero y es ignorado en la recepción. Índice de Parámetros de Seguridad: Campo de 32 bits; si es combinado con la dirección de origen, identifica el tipo de seguridad determinado en el receptor o los receptores. Datos de Autentificación: Campo variable que contiene el Campo de verificación de Integridad (ICV) para este paquete. El ICV puede incluir un campo implícito, este relleno se incluye para asegurar que la longitud de la cabecera de Autentificación sea un múltiplo de 32 bits para IPv4 o 64 bits para IPv6. Figura 4.11 Cabecera de Autenticación Cabecera de Carga de Seguridad Encapsulada La cabecera de Carga de Seguridad Encapsulada (ESP) está diseñada para proporcionar un conjunto de servicios de seguridad en IPv4 e IPv6. La cabecera de ESP puede ser aplicada sola o en combinación con la Cabecera de 41

58 Autentificación. Se utiliza para proporcionar confidencialidad, autentificación del origen de los datos, integridad sin conexión y confidencialidad limitada al flujo de tráfico. La cabecera ESP se inserta antes de la cabecera IP y después de la cabecera de protocolo de capa superior en modo transporte o después de una cabecera IP encapsulada en modo túnel. La cabecera de Carga de Seguridad Encapsulada (Figura 4.12), está conformada por los siguientes campos: Figura 4.12 Cabecera de Carga de Seguridad Encapsulada Índice de Parámetros de Seguridad (SPI): El tamaño del Campo es 32 bits. Conjuntamente con la dirección de destino IP y con el protocolo de seguridad (ESP) identifican a la Asociación de Seguridad para este datagrama. El conjunto de valores de SPI está en el rango de 1 a 255 reservado por la IANA para usos futuros. El valor de SPI cero está reservado para usarse localmente. Número de sucesión: Campo de 32 bits sin signo que inicia en cero y se incrementa con cada datagrama enviado; debe estar siempre presente. El emisor debe transmitir siempre este campo pero el receptor no necesita actuar sobre él. 42

59 Datos de Carga Útil: Campo de longitud variable que contiene los datos descritos por el campo cabecera Siguiente; es obligatorio y su longitud es un número entero de bytes. Relleno: Campo de longitud variable. El emisor puede agregar de 0 a 255 bytes de relleno para asegurar que los bits que se encriptarán sean múltiplo del tamaño del bloque del algoritmo y para que los datos de autentificación estén alineados en un límite de 4 bytes. Longitud de Relleno: Este campo de 8 bits indica el número de bytes de relleno precedentes a este campo; el rango de valores válidos es de 0 a 255 bytes. Cabecera Siguiente: Campo de 8 bits que indica el tipo de datos contenidos en el campo Datos de la Carga Útil. Datos de Autentificación: Campo de longitud variable que contiene el Valor de Comprobación de Integridad (ICV), calculado sobre el paquete ESP menos los datos de Autentificación. La necesidad para asegurar una confidencialidad completa del datagrama original se puede dar con el encapsulado. El último campo de un paquete que no se encripta, es siempre la cabecera de confidencialidad en caso de existir dicha cabecera. La cabecera de confidencialidad puede funcionar: Entre estaciones Entre una estación y un Firewall Entre dos Firewall 43

60 Cabecera siguiente valor 59 En una cabecera IPv6 o en cualquier otra cabecera de extensión, si el campo cabecera Siguiente tiene un valor de 59 significa que no hay nada más después de esa cabecera. En una cabecera IPv6 cuyo campo Cabecera Siguiente tiene un valor de 59 y el campo Longitud de la Carga Útil indica que hay más octetos de los que debe haber en toda la cabecera, estos octetos deben ignorarse Consideraciones sobre el tamaño del paquete IPv6 necesita que una MTU tenga una longitud de bytes o más para cada enlace en la Internet. Los nodos IPv6 deben implementar el Descubrimiento de la MTU de la Ruta, para saber qué rutas tienen MTUs mayores a bytes. Si se quiere omitir esto, se deben enviar paquetes de tamaño menor a bytes. Si se desea enviar paquetes más grandes que lo indicado por la MTU, se utiliza la fragmentación del paquete original y su respectivo reensamblaje en el destino. Cuando un paquete IPv6 se envía a un destino IPv4, el nodo IPv6 puede recibir un mensaje ICMP indicando que el paquete es muy grande. En este caso el nodo IPv6 no tiene la necesidad de ajustar los paquetes a bytes; el problema es resuelto si se incluye una cabecera de Fragmentación para que el nodo IPv4 obtenga un valor de Identificación para ser usado en los fragmentos IPv4 resultantes Problemas de protocolo de capa superior Los siguientes son problemas que pueden presentarse con los protocolos de capa superior tales como TCP o UDP: 44

61 Sumas de Verificación de Capa Superior Los protocolos de capa superior que incluyen las direcciones IP en su cálculo de suma de verificación deben modificarse cuando se va a utilizar IPv6. En la figura 4.13 se presenta una pseudo cabecera TCP y UDP para IPv6 cuyos campos son los siguientes: Figura 4.13 Pseudo Cabecera TCP y UDP para IPv6 Dirección Origen: Es la dirección desde donde se está enviando el datagrama; esta dirección se incluirá en el último componente de la cabecera de Enrutamiento y en el campo Dirección Destino de la cabecera IPv6 en el receptor o en los receptores. Dirección destino: Si el datagrama IPv6 contiene una cabecera de Enrutamiento, la dirección de destino utilizada en la pseudo cabecera es la del destino final. Longitud del Paquete de Capa Superior: Es la longitud de la cabecera de capa superior junto con los datos. Cero: Es un campo de 24 bits que no está siendo utilizado y debe ser cero. 45

62 Cabecera siguiente: Este campo identifica el protocolo de capa superior. Por ejemplo, es 6 para el protocolo TCP y 17 para el protocolo UDP. Si los datagramas UDP son originados por un nodo IPv6, la suma de verificación UDP no es opcional, es decir, siempre que se origine un paquete UDP, un nodo IPv6 debe calcular una suma de verificación UDP sobre el datagrama y la pseudo cabecera. Si ese cálculo produce un resultado igual a cero, debe cambiarse al hexadecimal FFFF para su colocación en la cabecera UDP. Los receptores IPv6 deben descartar los datagramas UDP que contengan una suma de verificación cero y deben registrar el error. ICMPv6 proporciona la información de error o control entre nodos. El cálculo de la suma de verificación UDP está incluido en el protocolo ICMPv6; con esto se protege al ICMP de una mala entrega o de daños en los campos de la cabecera IPv6. El campo Cabecera Siguiente en la pseudo cabecera para el ICMP contiene el valor 58, que identifica a ICMPv Tiempo de Vida Máximo de un Paquete Cualquier protocolo de capa superior que depende de la capa de Internet para limitar el Tiempo de Vida de un datagrama, debe actualizarse para proporcionar sus propios mecanismos de detección y descarte de paquetes obsoletos. IPv6 no necesariamente debe cumplir con el Tiempo de Vida máximo de un datagrama Tamaño Máximo de la Carga Útil de Capa Superior Al calcular el tamaño máximo de la carga útil disponible para los datos de capa superior, un protocolo de capa superior debe tener en cuenta el tamaño más grande de la cabecera IPv6 respecto a la cabecera IPv4. 46

63 Respuesta a Paquetes que Llevan Cabeceras de Enrutamiento Cuando un protocolo de capa superior envía uno o más datagramas en contestación a un datagrama recibido que incluía una cabecera de Enrutamiento, sólo se permiten los siguientes tipos de datagramas de respuesta: Datagramas de respuesta que no llevan cabeceras de Enrutamiento. Datagramas de respuesta que llevan cabeceras de Enrutamiento en las que no se ha invertido la cabecera de Enrutamiento del datagrama recibido. Datagramas de respuesta que llevan cabeceras de Enrutamiento en las que se ha invertido la cabecera de Enrutamiento del datagrama recibido, si y sólo si, la integridad y autenticidad de la Dirección Origen y de la cabecera de Enrutamiento del paquete recibido han sido verificadas por el nodo que contesta. 4.4 DIRECCIONAMIENTO IPV6 Una dirección IPv6 tiene una longitud de 128 bits divididos en bloques de 16 bits donde cada bloque es representado por 4 dígitos hexadecimales, a diferencia de IPv4 en donde los grupos de 8 bits eran representados por dígitos decimales. Cada bloque de 4 dígitos hexadecimales, es separado por el signo : mientras que en Ipv4 la separación de los bloques se la realiza con el signo.. Existen reglas que pueden ser aplicadas a las direcciones IPv6 con el objetivo de resumir un poco la sintaxis de las direcciones. Por ejemplo una dirección IPv6 válida 2001:0000:1234:0000:0000:C1C0:ABCD:0876 puede aceptar las siguientes simplificaciones: 47

64 Las letras pueden ser mayúsculas o minúsculas y la dirección se puede escribir como 2001:0000:1234:0000:0000:c1c0:abcd:0876 Los ceros consecutivos son opcionales y se pueden representar en la dirección como 2001:0:1234:0:0:c1c0:abcd:876 Los campos con ceros sucesivos pueden ser reemplazados por :: y la dirección puede tomar la forma 2001:0:1234::c1c0:abcd:876. Pero, cualquier dirección que tenga más de una vez la representación :: será una dirección inválida ya que solamente se puede usar esa representación una sola vez. Otra representación importante es la de los prefijos de red. En las direcciones IPv6 continúa escribiéndose del mismo modo que en IPv4, utilizando la notación CIDR. Esta notación se representa con la forma dirección-ipv6/tamaño del prefijo, donde tamaño del prefijo es un valor decimal que especifica la cantidad de bits contiguos a la izquierda de la dirección que comprenden el prefijo. En el ejemplo de prefijo de subred presentado a continuación, de los 128 bits de la dirección, 64 bits se utilizan para identificar la subred y 32 bits para representar el prefijo global. Prefijo 2001:db8:3003:2::/64 Prefijo global 2001:db8::/32 Esta representación también permite agregar las direcciones en forma jerárquica, identificando la topología de la red a través de parámetros tales como ubicación geográfica, proveedor de acceso, identificación de la red, división de la subred, etc. En cuanto a la representación de las direcciones IPv6 en las URL (Uniform Resource Locators), éstas ahora se representan entre corchetes. Esto evitará 48

65 ambigüedades en caso que sea necesario indicar el número de un puerto junto con la URL. Ver los siguientes ejemplos: Tipos de Direcciones IPv6 Existen 3 tipos de direcciones IPv6: unicast, multicast y anycast Direcciones Unicast Identifica una interfaz única en el ámbito de direcciones. Los paquetes que son dirigidos a una dirección unicast son entregados a una interfaz única. Para dar cabida a los sistemas de balanceo de carga, la norma RFC 2373 permite a múltiples interfaces utilizar la misma dirección, siempre y cuando aparezcan como una sola interfaz para la implementación de IPv6 en el host. Existen diferentes tipos de direcciones unicast tales como: globales unicast, link-local, direcciones especiales, direcciones compatibles. - Direcciones globales Las direcciones unicast globales en IPv6 son equivalentes a las direcciones públicas en IPv4. Estas direcciones son enrutables y accesibles a nivel global sobre la porción de IPv6 en Internet. Su estructura fue proyectada para utilizar los 64 bits más hacia la izquierda de la dirección para identificar la red y los 64 bits más hacia la derecha para identificar la interfaz. Por lo tanto, excepto en ciertos casos específicos, todas las subredes 49

66 en IPv6 tienen el mismo tamaño de prefijo, 64 bits (/64), lo que permite tener 2 64 = dispositivos por subred. Actualmente para la atribución de direcciones está reservado el rango 2000::/3 (001), que corresponde a las direcciones de 2000:: a 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. Esto representa el 13% del total de direcciones posibles con IPv6, lo que permite crear 2 (64 3) = (2,3x10 18 ) subredes (/64) diferentes o 2 (48 3) = (3,5x10 13 ) redes /48. Estas direcciones están diseñadas para ser fácilmente agregadas o sumarizadas con el fin de producir una estructura eficiente de enrutamiento. - Direcciones link-local (de enlace local) Son usadas por los nodos que se comunican con los nodos vecinos que se encuentran en el mismo enlace; por ejemplo, en un único enlace IPv6 sin router. Las direcciones link-local (de enlace local) se utilizan para la comunicación entre los hosts dentro del enlace. Las direcciones link-local siempre comienzan con FE80 y terminan con los 64 bits del identificador de interfaz. El prefijo para las direcciones link-local es siempre FE80::/64. Los 64 bits reservados para la identificación de la interfaz se configuran utilizando el formato IEEE EUI-64 (Extended Unique Identifier). Vale la pena destacar que los routers no deben encaminar paquetes cuyo origen o destino sea una dirección link-local hacia otros enlaces. 50

67 - Direcciones IPv6 especiales Existen dos tipos de direcciones especiales que son usadas en IPv6 y son las direcciones no especificadas y las direcciones de loopback. Las direcciones no especificadas (0:0:0:0:0:0:0:0 ó ::) son usadas para identificar la ausencia de una dirección. Esta dirección es típicamente usada como dirección de origen cuando no ha sido aún determinada la dirección. Esta dirección nunca se asigna a una interfaz ni es usada como dirección de destino. La dirección de loopback (0:0:0:0:0:0:0:1 ó ::1) es usada para identificar una interfaz de bucle de prueba, habilitando a un nodo para que pueda enviarse paquetes a sí mismo. Una Dirección mapeada IPv4 es representada mediante 0:0:0:0:0:FFFF:w.x.y.z o ::FFFF:w.x.y.z. Se utiliza para mapear una dirección IPv4 en una dirección IPv6 de 128 bits, donde w.x.y.z representa los 32 bits de la dirección IPv4, utilizando dígitos decimales. Se aplica en técnicas de transición para que se comuniquen nodos IPv6 e IPv4. Por ejemplo ::FFFF: Direcciones compatibles Sirven para ayudar en la migración de IPv4 a IPv6, para la coexistencia de ambas direcciones. Entre estas se tiene: direcciones IPv4 compatibles, direcciones 6over4, direcciones 6to4 y direcciones ISATAP. Las direcciones IPv4 compatibles son usadas por nodos IPv6/IPv4 que se comunican con nodos IPv6 a través de una infraestructura IPv6 pública. Las direcciones 6to4 son usadas para representar a un host en el mecanismo de entunelamiento (tunneling) conocido como 6to4 el cual, junto con otros mecanismos de migración, será descrito posteriormente. 51

68 Direcciones Multicast Las direcciones multicast habilitan el uso eficiente del ancho de banda de la red al enviar un mínimo número de datagramas al número máximo de nodos. En un enlace local, un datagrama multicast es enviado a un ilimitado número de nodos. Un prefijo especial (en IPv4 es /8) identifica a un datagrama multicast IPv6 y una dirección específica dentro del prefijo identifica a cada grupo de nodos. La Tabla 4.3 indica las direcciones IPv6 que son reservadas para multicast. Tabla 4.3 Direcciones reservadas para Multicast Dirección Alcance Descripción FF01::1 Interfaz Todas las interfaces en un nodo (allnodes) FF01::2 Interfaz Todos los routers en un nodo (allrouters) FF02::1 Enlace Todos los nodos del enlace (allnodes) FF02::2 Enlace Todos los routers del enlace (allrouters) FF02::5 Enlace Routers OSFP FF02::6 Enlace Routers OSPF designados FF02::9 Enlace Routers RIP FF02::D Enlace Routers PIM FF02::1:2 Enlace Agentes DHCP FF02::1:FFXX:XXXX Enlace Solicited-node FF05::2 Site Todos los routers en un site FF05::1:3 Site Servidores DHCP en un site FF05::1:4 Site Agentes DHCP en un site FF0X::101 Variado NTP (Network Time Protocol) 52

69 Las direcciones multicast no pueden ser usadas como direcciones de origen o como destinos intermediarios. Las direcciones multicast tienen una estructura especial para identificar las banderas, su ámbito de aplicación y a qué grupo multicast pertenece Direcciones Anycast Una dirección IPv6 anycast se utiliza para identificar un grupo de interfaces, aunque con la propiedad de que un paquete enviado a una dirección anycast es encaminado solamente a la interfaz del grupo más próxima al origen del paquete. Las direcciones anycast se atribuyen a partir del rango de direcciones unicast y no hay diferencias sintácticas entre las mismas. Por lo tanto, una dirección unicast atribuida a más de una interfaz se transforma en una dirección anycast, debiéndose en este caso configurar explícitamente los nodos para que sepan que les ha sido atribuida una dirección anycast. Por otra parte, esta dirección se debe configurar en los routers como una entrada independiente (prefijo /128 host route). Este esquema de direccionamiento se puede utilizar para descubrir servicios en la red, como por ejemplo servidores DNS y proxies HTTP, garantizando la redundancia de estos servicios. También se puede utilizar para realizar balanceo de carga en situaciones en las que múltiples hosts o routers proveen el mismo servicio, para localizar routers que provean acceso a una determinada subred o para localizar los Agentes de Origen en redes con soporte para movilidad IPv6. Todos los routers deben soportar la dirección anycast Subnet-Router. Este tipo de direcciones están formadas por el prefijo de la subred y el IID (Identificador de interfaz) completado con ceros (por ejemplo: 2001:db8:cafe:dad0::/64). Un paquete enviado a la dirección Subnet-Router será entregada al router más próximo al origen dentro de la misma subred. 53

70 También se definió una dirección anycast para ser utilizada en el soporte para movilidad IPv6. Este tipo de direcciones están formadas por el prefijo de la subred seguido por el IID dfff:ffff:ffff:fffe (por ejemplo: 2001:db8::dfff:ffff:ffff:fffe). Son utilizadas por el Nodo Móvil cuando éste necesita localizar un Agente Origen en su Red Original Direcciones ipv6 para host y router Por lo general, a un elemento de red que cuenta con una sola interfaz de red se le puede asignar tan solo una dirección IPv4. Sin embargo, a una interfaz que usa IPv6 se le puede asignar múltiples direcciones. Los tipos de direcciones unicast que pueden ser asignadas a una interfaz de un host o router que usa IPv6 son las siguientes: Una dirección link-local (enlace local) por cada interfaz Una dirección unicast adicional (que puede ser site-local o dirección global) por cada interfaz. La dirección de loopback (::1) para la interfaz de bucle de prueba. Todos los nodos se pueden identificar a través de cualquiera de sus direcciones de interfaz y por lo tanto se hace necesario elegir entre sus múltiples direcciones cuáles se utilizarán como direcciones de origen y destino al establecer una conexión. Para resolver este tema se definieron dos algoritmos, uno para seleccionar la dirección de origen y otro para seleccionar la de destino. Estos algoritmos, que deben ser implementados por todos los nodos IPv6, especifican el comportamiento por defecto de dichos nodos, pero no anulan las decisiones tomadas por las aplicaciones o protocolos de la capa superior. 54

71 Entre las reglas más importantes se destacan las siguientes: Pares de direcciones origen-destino del mismo alcance o tipo tienen preferencia El menor alcance para la dirección de destino tiene preferencia (se utiliza el menor alcance posible) Las direcciones cuyo tiempo de vida no ha expirado tienen preferencia sobre las direcciones con tiempo de vida expirado No se pueden utilizar las direcciones de las técnicas de transición (ISATAP, 6to4, etc.), si hay una dirección IPv6 nativa disponible Si todos los criterios son similares, los pares de direcciones con el mayor prefijo común tendrán preferencia Para las direcciones de origen, las direcciones globales tendrán preferencia sobre las direcciones temporarias En un Nodo Móvil, la Dirección de Origen tiene preferencia sobre una Dirección Remota. Estas reglas deben ser utilizadas cuando no hay ninguna otra especificación. Las especificaciones también permiten configurar políticas que puedan reemplazar estas preferencias estándares por combinaciones de direcciones de origen y destino Direcciones únicas ULA (Unique Local Address) Es una dirección con grandes probabilidades de ser globalmente única pero utilizada solamente para comunicaciones locales, generalmente dentro de un mismo enlace o conjunto de enlaces. Una dirección ULA no debe ser enrutable en la Internet global. 55

72 Una dirección ULA, creada utilizado un ID global distribuido pseudoaleatoriamente, está formada por las siguientes partes: Prefijo: FC00::/7. Flag Local (L): si el valor es 1 (FD) el prefijo es atribuido localmente. Si el valor es 0 (FC), el prefijo debe ser atribuido por una organización central (aun por determinar). Identificador global: identificador de 40 bits usado para crear un prefijo globalmente único. Identificador de la interfaz: identificador de la interfaz de 64 bits. De este modo, la estructura de una dirección ULA es FDUU:UUUU:UUUU:<ID de la subred>:<id de la interfaz> donde U son los bits del identificador único, generado aleatoriamente por un algoritmo específico. Su utilización permite que cualquier enlace posea un prefijo /48 privado y globalmente único. Por lo tanto, en el caso que se interconecten dos redes (por ejemplo de dos empresas diferentes), es probable que no haya conflicto de direcciones ni necesidad de renumerar la interfaz. Además, la dirección ULA es independiente del proveedor, pudiendo ser utilizada en la comunicación dentro del enlace aunque no haya conexión a Internet. Otra ventaja es que su prefijo se puede bloquear fácilmente y si accidentalmente una dirección ULA se anuncia fuera del enlace ya sea a través de un router o vía DNS, no habrá conflicto con otras direcciones Identificador de interfaz (IID) Los identificadores de interfaz (IID), utilizados para distinguir las interfaces dentro de un enlace, deben ser únicos dentro del mismo prefijo de subred. El mismo IID 56

73 se puede usar en múltiples interfaces de un único nodo, pero éstas deben estar asociadas a subredes diferentes. Normalmente se utiliza un IID de 64 bits, el cual se puede obtener de diferentes maneras: Se puede configurar manualmente, a partir del mecanismo de autoconfiguración stateless de IPv6, a partir de servidores DHCPv6 (stateful), o se pueden formar a partir de una clave pública (CGA: Dirección Criptográficamente Generada). Estos métodos se describirán detalladamente en este curso. Aunque pueden ser generados aleatoriamente y de forma temporaria, se recomienda construir el IID con base en la dirección MAC de la interfaz, en el formato EUI-64. Un IID basado en el formato EUI-64 se genera de la siguiente manera: Si la interfaz tiene una dirección MAC de 64 bits (estándar EUI-64), solo debe complementar el séptimo bit más a la izquierda (llamado bit U/L universal/local) de la dirección MAC, es decir, si es 1 se debe cambiar a 0 y si es 0 se debe cambiar a 1. Si la interfaz utiliza una dirección MAC de 48 bits (estándar IEEE 802), primero se agregan los dígitos hexadecimales FF-FE entre el tercero y el cuarto byte de la dirección MAC (para transformar al estándar EUI-64) y luego se complementa el bit U/L. Por ejemplo: Si la dirección MAC de la interfaz es: 48-1E-C C se agregan los dígitos FF-FE en el medio de la dirección: 48-1E-C9-FF-FE C se complementa el bit U/L: 48 =

74 = 4A IID = 4A-1E-C9-FF-FE C Una dirección link local atribuida a esta interfaz sería FE80::4A1E:C9FF:FE21:850C Direcciones IPv4 e IPv6 equivalentes Para resumir la relación entre el direccionamiento IPv4 y el direccionamiento IPv6 la Tabla 4.4 muestra los conceptos de direccionamiento IPv4 y sus equivalentes en IPv6. Tabla 4.4 Direcciones IPv4 equivalentes Direcciones IPv4 Internet address classes Direcciones Multicast ( /4) Dirección de Broadcast La dirección no especificada es La dirección de Loopback es Direcciones IP públicas Dirección IP privada ( /8, /12 y /16) Direcciones IPv6 No es aplicable en IPv6 Dirección multicast IPv6 (FF00::/8) No es aplicable en IPv6 La dirección no especificada es :: La dirección de Loopback es ::1 Direcciones unicast globales Direcciones Site-local FEC0::/48 (Desaprobada en RFC3879) 58

75 La representación de las direcciones se realiza con notación decimal. La máscara de subred se representa con notación decimal con puntos o longitud del prefijo. La representación de las direcciones se la realiza con notación hexadecimal con supresión de los ceros. Los bits de red se representan solo con la longitud del prefijo Políticas de distribución y asignación En la jerarquía de las políticas de atribución, distribución y asignación de direcciones, cada RIR (Regional Internet Registry) recibe de la IANA (Internet Assigned Numbers Authority) un bloque /12 IPv6. El bloque 2800::/12 corresponde al espacio reservado para que LACNIC realice distribuciones en América Latina y el Caribe. La mínima distribución para un ISP es un bloque /32, aunque se pueden realizar distribuciones mayores si se justifica la utilización. Un aspecto importante a destacar es que, a diferencia de lo que ocurre en IPv4, en IPv6 la utilización se mide considerando el número de bloques de direcciones asignados a usuarios finales, no el número de direcciones asignadas a usuarios finales. En relación con la distribución y asignación de direcciones a usuarios finales, la RFC 3177 recomienda seguir un enfoque conocido como one size fits all, el cual tiene las siguientes características: En general se recomienda el uso de redes /48 para todos los tipos de usuarios, sin importar si son residenciales o empresas pequeñas o grandes; 59

76 Las empresas muy grandes pueden recibir un /47, prefijos un poco menores o múltiplos de un /48; Se recomienda el uso de redes /64 cuando exista la certeza de que se requiere una única subred, por ejemplo para usuarios 3G; Se puede utilizar una red /128 cuando exista la certeza absoluta de que solamente se conectará una interfaz. Por ejemplo: conexiones PPPoE (Pointto-Point Protocol over Ethernet). El enfoque one size fits all tiene algunas ventajas: Facilita la renumeración de la red en caso de cambio de proveedor (cambio de prefijo) Permite ampliar la red sin necesidad de solicitar más direcciones al proveedor Facilita el mapeo entre la dirección global y la dirección Unique Local (ULA fc00:xyzw:klmn::/48) Ya hay redes que utilizan prefijos /48 6to4; Permite mantener reglas únicas para zonas inversas de diferentes prefijos; Facilita la administración; Hay quienes creen que desperdicia demasiadas direcciones y que podría generar problemas dentro de algunas décadas. Un enfoque más conservador, opuesto a one size fits all, recomienda no delegar bloques /48 a todos los tipos de usuarios, asignando bloques /56 a los usuarios residenciales y SOHOs (Small Office/Home Office). Esto reduce el consumo total de direcciones de 6 a 7 bits. Además, un /32 permite apenas prefijos /48, que en el caso de los grandes proveedores no sería suficiente para satisfacer toda su demanda. 60

77 4.4.7 Qué están haciendo los RIR y los ISP? Los RIR aplican dos políticas diferentes en cuanto a las recomendaciones de uso para los ISP y el criterio para la distribución de bloques de direcciones adicionales. Los RIR LACNIC y AFRINIC siguen la recomendación one size fits all y sugieren que los proveedores de sus regiones también los sigan. También evalúan las solicitudes de bloques adicionales por parte de los ISP de acuerdo con ese enfoque, es decir, basándose en la cantidad de bloques /48 asignados por los ISP. En cambio los RIR APNIC, ARIN y RIPE siguen un enfoque más conservador, utilizando la cantidad de bloques /56 asignados por los proveedores como base para evaluar las solicitudes de bloques adicionales. En todos los casos la medida utilizada para la evaluación es el HD-Ratio (Host- Density ratio). El HD-Ratio es un modo de medir el uso del espacio de direccionamiento, ya que su valor está relacionado con el porcentaje de uso. Para calcular el HD-Ratio se utiliza la siguiente fórmula: Todos los RIR utilizan como valor Threshold (umbral) HD-Ratio = 0,94, solo que LACNIC y AFRINIC lo aplican a la utilización de bloques /48 mientras que APNIC, ARIN y RIPE a la utilización de bloques /56. 61

78 4.5 FUNCIONALIDADES DE IPv ICMPv6 (Internet Control Message Protocol) Definido en la RFC 4443 para ser utilizado con IPv6, ICMPv6 es una versión actualizada del ICMP (Internet Control Message Protocol) que se utiliza con IPv4. Aunque tiene las mismas funciones que ICMPv4 (como por ejemplo informar errores en el procesamiento de paquetes y reenviar mensajes sobre el estado o las características de la red), esta nueva versión del ICMP no es compatible con su predecesor y ahora presenta un mayor número de mensajes y funcionalidades. Ahora ICMPv6 es responsable de realizar las funciones del protocolo ARP (Address Resolution Protocol), que mapea direcciones IP a direcciones de capa dos en IPv4 y de IGMP (Internet Group Management Protocol), que gestiona los miembros de los grupos multicast en IPv4. El valor del campo Siguiente Encabezado (que indica la presencia del protocolo ICMPv6) es 58 y en todos los nodos se debe implementar soporte para este protocolo. En un paquete IPv6, el ICMPv6 se coloca inmediatamente después del encabezado base de IPv6 y de los encabezados de extensión (si los hubiera). ICMPv6, es un protocolo clave en la arquitectura IPv6 ya que, además de gestionar los grupos multicast, a través del protocolo MLD (Multicast Listener Discovery) y de la resolución de direcciones de capa dos, sus mensajes son esenciales para el funcionamiento del protocolo de Descubrimiento de Vecinos (Neighbor Discovery), responsable de localizar routers vecinos en la red, detectar cambios de dirección en el enlace, detectar direcciones duplicadas, etc. 62

79 El encabezado de todos los mensajes ICMPv6 tienen la misma estructura y está compuesto por cuatro campos: Tipo: Especifica el tipo de mensaje, lo que determinará el formato del cuerpo del mensaje. Su tamaño es de ocho bits; Código: Ofrece algunos datos adicionales para determinados tipos de mensajes. Su tamaño también es de ocho bits; Suma de Verificación: Se utiliza para detectar datos corruptos en el encabezado ICMPv6 y en parte del encabezado IPv6. Su tamaño es de 16 bits; Datos: Presenta información de diagnóstico y error según el tipo de mensaje. Para ayudar en la resolución de problemas, los mensajes de error incluyen en este campo el paquete que invocó el mensaje, ya que el tamaño total del paquete ICMPv6 no debe exceder la mínima MTU de IPv6, que es de 1280 bytes. Los mensajes ICMPv6 se dividen en dos clases, cada una de ellas compuesta por diferentes tipos de mensajes, de acuerdo con las tablas 4.5 y 4.6: Tabla 4.5 Mensajes de Error Tipo Nombre Descripción Indica fallas en la entrega del 1 Destination paquete (como dirección o puerto Unreachable desconocido) o problemas en la comunicación. 2 Packet Too Big Indica que el tamaño del paquete es mayor que la Indica que el tamaño del paquete es mayor que la enlace. 3 Time Exceeded Indica que el Límite de Direccionamiento o el tiempo 63

80 Indica que el Límite de Direccionamiento o el tiempo 4 Parameter Problem Indica un error en alguno de los campos encabezado IPv6 o que el tipo indicado en el campo encabezado IPv6 o que el tipo indicado en el campo Uso experimental No utilizados 127 Reservado para la expansión de mensajes de error ICMPv6 Tabla 4.6 Mensaje de información Tipo Nombre Descripción 128 Echo Request 129 Echo Reply Utilizados por el comando ping. 130 Multicast Listener Query 131 Multicast Listener Report Utilizados en la gestión de grupos multicast. 132 Multicast Listener Done 133 Router Solicitation 134 Router Advertisement Utilizados con el protocolo de 135 Neighbor Solicitation Descubrimiento de vecinos 136 Neighbor Advertisement 137 Redirect Message Utilizado en el mecanismo de Router Renumbering 138 redireccionamiento direccionamiento( 64

81 Renumbering) de routers. ICMP Node Information 139 Query ICMP Node Information Response 140 Inverse ND Solicitation 141 Message Inverse ND 142 Advertisement Message Version 2 Multicast 143 Listener Report HA Address Discovery 144 Req. Message HA Address Discovery 145 Reply Message 146 Mobile Prefix Solicitation Mobile Prefix 147 Advertisement Certification Path 148 Solicitation Message Cert. Path 149 Advertisement Message 150 Multicast Router 151 Advertisement Multicast Router 152 Solicitation Utilizados para descubrir datos sobre nombres y direcciones, actualmente están limitados a herramientas de diagnóstico, depuración y gestión de redes. Utilizados en una extensión del protocolo de Descubrimiento de Vecinos. Utilizado en la gestión de grupos multicast. Utilizados en el mecanismo de Movilidad IPv6. Utilizados por el protocolo SEND. Utilizado experimentalmente con protocolos de movilidad como Seamoby. Utilizados por el mecanismo Multicast Router Discovery 65

82 Multicast Router 153 Termination Utilizado por el protocolo de movilidad FMIPv6 Messages 154 Fast Handovers Uso experimental Reservado para la expansión de 255 mensajes de error ICMPv Descubrimiento de Vecinos (Neighbor Discovery Protocol) Definido por la RFC4861, el protocolo de Descubrimiento de Vecinos agiliza algunos procesos de configuración de red con respecto a IPv4 combinando las funciones de protocolos como ARP, ICMP Router Discovery y ICMP Redirect y además agrega nuevos métodos que no existían en la versión anterior del protocolo IP. El protocolo de Descubrimiento de Vecinos de IPv6 es utilizado por los hosts y routers para los siguientes propósitos: Determinar la dirección MAC de los nodos de la red Encontrar routers vecinos Determinar prefijos y otros datos de configuración de la red Detectar direcciones duplicadas Determinar la accesibilidad de los routers Redireccionamiento de paquetes Autoconfiguración de direcciones Los mensajes Neighbor Discovery se configuran con un Límite de Direccionamiento de 255 para asegurar que los mensajes recibidos tengan su 66

83 origen en un nodo del mismo enlace, descartando los mensajes que tengan valores diferentes. Neighbor Discovery utiliza cinco mensajes ICMPv6: Router Solicitation (ICMPv6 tipo 133): Utilizado por los hosts para solicitar a los routers mensajes de Router Advertisements inmediatamente. Normalmente se envía a la dirección multicast FF02::2 (all-routers on link) Router Advertisement (ICMPv6 tipo 134): Se envía periódicamente o en respuesta a un Router Solicitation y es utilizado por los routers para anunciar su presencia en un enlace. Los mensajes periódicos se envían a la dirección multicast FF02::1 (all nodes on link), mientras que los solicitados se envían directamente a la dirección del solicitante. Un RA (Router Advertisement) transporta información referente a la configuración de la red, por ejemplo: El valor por defecto del enlace para el campo Límite de Direccionamiento Un flag que especifica si se debe utilizar autoconfiguración stateless o stateful Otro flag que especifica si los nodos deben utilizar configuraciones stateful para obtener otros datos acerca de la red En las redes que soportan movilidad IPv6 se utiliza un tercer flag para indicar si el router es un Agente de Origen Por cuánto tiempo (en segundos) el router será considerado el router por defecto del enlace. Si no es el router por defecto este valor será cero; El tiempo que un host supone que los vecinos son alcanzables luego de recibir una confirmación de accesibilidad El intervalo entre el envío de mensajes Neighbor Solicitation. 67

84 Neighbor Solicitation (ICMPv6 tipo 135): Mensaje multicast enviado por un nodo para determinar la dirección MAC y la accesibilidad de un vecino y detectar la existencia de direcciones duplicadas. Este mensaje tiene un campo para indicar la dirección de origen del mensaje Neighbor Advertisement (ICMPv6 tipo 136): Se envía como respuesta a un Neighbor Solicitation, pero también se puede enviar para anunciar el cambio de alguna dirección dentro del enlace. Este mensaje tiene tres flags: El primero indica si quien está enviando el mensaje es un router; El segundo indica si el mensaje es una respuesta a un NS; El tercero indica si la información que transporta el mensaje es una actualización de la dirección de alguno de los nodos de la red. Redirect (ICMPv6 tipo 137): Utilizado por los routers para informar al host el mejor router para encaminar el paquete a su destino. Este mensaje contiene información como la dirección del router que se considera el mejor salto y la dirección del nodo que está siendo redireccionado. Estos mensajes pueden tener o no opciones: Source link-layer address: Contiene la dirección MAC del remitente del paquete. Se utiliza en los mensajes NS, RS y RA Target link-layer address: Contiene la dirección MAC del destino del paquete. Se utiliza en los mensajes NA y Redirect Prefix information: Proporciona a los hosts los prefijos del enlace y los prefijos para autoconfiguración de direcciones. Se utiliza en los mensajes RA Redirected header: Contiene todo el paquete que está siendo redireccionado o parte del mismo. Se utiliza en los mensajes Redirect 68

85 MTU: Indica el valor de la MTU del enlace. Se utiliza en los mensajes RA Descubrimiento de direcciones de capa de enlace Esta funcionalidad se utiliza para determinar la dirección MAC de los vecinos del mismo enlace: un host envía un mensaje NS a la dirección multicast solicited node del vecino informando su dirección MAC. Figura 4.14 Descubrimiento de direcciones Fuente: packetlife.net Al recibir el mensaje, el vecino responde enviando un mensaje NA informando su dirección MAC. En IPv6, esta característica del protocolo de Descubrimiento de Vecinos reemplaza al protocolo ARP de IPv4 y en lugar de utilizar una dirección broadcast, utiliza la dirección multicast solicited-node como dirección de destino Descubrimiento de Routers y prefijos Esta funcionalidad del protocolo de Descubrimiento de Vecinos se utiliza para localizar routers vecinos dentro del mismo enlace, así como para aprender prefijos y parámetros relacionados con la autoconfiguración de direcciones. 69

86 Esta información se envía desde un router local, a través de mensajes RA encaminados a la dirección multicast all-nodes. En IPv4 el mapeo de las direcciones de la red local se realiza a través de mensajes ARP Request. Figura 4.15: Descubrimiento de Routers Fuente: packetlife.net Detección de direcciones duplicadas La Detección de Direcciones Duplicadas es el procedimiento que utilizan los nodos para verificar la unicidad de las direcciones en un enlace y se debe realizar antes de atribuir cualquier dirección unicast a una interfaz, sin importar si éstas se obtienen mediante autoconfiguración stateless, DHCPv6 o configuración manual. Este mecanismo consiste en el envío de un mensaje NS por parte del host con su propia dirección en el campo target address. Si como respuesta se recibe un mensaje NA, esto indica que la dirección ya está siendo utilizada y que el proceso de configuración debe ser interrumpido. 70

87 En IPv4 los nodos utilizan mensajes ARP Request y el método llamado gratuitous ARP para detectar direcciones unicast duplicadas dentro del mismo enlace definiendo los campos Source Protocol Address y Target Protocol Address, del encabezado del mensaje ARP Request, con la dirección IPv4 que está siendo verificada. Este mecanismo se utiliza en comunicaciones host-a-host, host-a-router y routera-host para rastrear la accesibilidad de los nodos a lo largo del camino. Un nodo considera que un vecino es accesible si recientemente ha recibido confirmación de la entrega de algún paquete a dicho vecino. Esta confirmación se puede dar de dos maneras diferentes: una respuesta a un mensaje del protocolo de Descubrimiento de Vecinos o algún proceso de capa de transporte que indique que se estableció una conexión. Este proceso solo se ejecuta cuando se envían paquetes a una dirección unicast; no se utiliza cuando se envían paquetes a direcciones multicast. Para realizar el seguimiento de los estados de un vecino el nodo IPv6 utiliza dos tablas principales: Neighbor Cache Mantiene una lista de vecinos locales a los cuales se envió tráfico recientemente, almacenando sus direcciones IP, información sobre la dirección MAC y un flag que indica si el vecino es un router o un host. También informa si todavía hay paquetes en cola esperando ser enviados, la accesibilidad de los vecinos y la próxima vez que está programado un evento de detección de vecinos inaccesibles. Esta tabla es comparable a la tabla ARP de IPv4. 71

88 Destination Cache Mantiene información sobre destinos a los cuales se envió tráfico recientemente (tanto destinos locales como remotos) y se actualiza con información recibida a través de mensajes Redirect. El Neighbor Cache se puede considerar como un subconjunto de la información del Destination Cache Redireccionamiento Los routers envían mensajes Redirect para redireccionar un host automáticamente a un router más apropiado o informar al host qué destino se encuentra en el mismo enlace. Este mecanismo es igual al que existe en IPv Autoconfiguración de direcciones stateless El mecanismo de autoconfiguración stateless, definido en la RFC 4862, permite atribuir direcciones IPv6 a las interfaces sin necesidad de realizar configuraciones manuales y sin utilizar servidores adicionales (DHCP), apenas realizando una configuración mínima de los routers. Para generar una dirección IP un host utiliza una combinación de datos locales, como la dirección MAC de la interfaz o un valor aleatorio para generar el IID, e información recibida de los routers, como múltiples prefijos. Si no hay routers presentes, el host solo genera la dirección link local con el prefijo FE80::. Los routers solo usan este mecanismo para generar direcciones link-local. Sus direcciones globales se deben configurar de otra manera. El mecanismo de autoconfiguración de direcciones se ejecuta respetando los siguientes pasos: 72

89 Se genera una dirección link-local agregando el prefijo FE80::/64 al identificador de la interfaz Esta dirección pasa a formar parte de los grupos multicast solicited-node y allnodes Se realiza la verificación de la unicidad de la dirección link-local generada Si otro nodo del enlace ya está utilizando la misma dirección el proceso de autoconfiguración se interrumpe y es necesario realizar una configuración manual. Si la dirección se considera única y válida ésta será automáticamente inicializada para la interfaz. El host envía un mensaje Router Solicitation al grupo multicast all-routers Todos los routers del enlace responden con un mensaje Router Advertisement informando: los routers por defecto; un valor predefinido para el campo Límite de Direccionamiento; la MTU del enlace; la lista de prefijos de la red, para los cuales también se generarán direcciones automáticamente. Una dirección IPv6 puede asumir diferentes estados: Dirección en tentativa Dirección que aun no ha sido atribuida. Es el estado previo a la atribución, mientras se realiza el proceso DAD. No se puede utilizar en las comunicaciones del nodo, sino solamente para los mensajes relacionados con el Descubrimiento de Vecinos Dirección preferida Dirección atribuida a la interfaz que puede ser utilizada sin restricciones hasta que expire su tiempo de vida Dirección desaprobada Dirección cuyo tiempo de vida ha expirado. Se puede utilizar para continuar las comunicaciones abiertas por la misma, pero no para iniciar nuevas comunicaciones Dirección válida Término utilizado para designar tanto a las direcciones preferidas como a las direcciones desaprobadas 73

90 Dirección inválida Dirección que no se puede atribuir a una interfaz. Una dirección se vuelve inválida cuando expira su tiempo de vida DHCPv6 (Dynamic Host Configuration) El Dynamic Host Configuration Protocol (DHCP) es un protocolo de autoconfiguración stateful que se utiliza para distribuir dinámicamente direcciones IP en una red a partir de un servidor DHCP, permitiendo un mayor control de la atribución de direcciones a los host. Definido en la RFC 3315, el protocolo DHCPv6 es una alternativa al mecanismo de autoconfiguración stateless de IPv6 que se puede utilizar cuando no hay routers en la red o cuando su uso es indicado en los mensajes RA. Este mecanismo puede proveer direcciones IPv6 y diferentes parámetros de la red, como por ejemplo direcciones de servidores DNS (Domain Name System), NTP (Network Time Protocol), SIP (Session Initiaton Protocol), etc. En DHCPv6 el intercambio de mensajes entre cliente y servidor se realiza usando el protocolo UDP. Los clientes utilizan una dirección link-local para transmitir o recibir mensajes DHCP, mientras que los servidores utilizan una dirección multicast reservada (FF02::1:2 o FF05::1:3) para recibir mensajes de los clientes. Cuando el cliente necesita enviar un mensaje a un servidor que está fuera de su subred se utiliza un Relay DHCP. El uso de DHCPv6 permite un mayor control de la atribución de direcciones ya que además de proporcionar opciones de configuración de red, permite definir políticas para la distribución de direcciones y atribuir direcciones a los hosts que no se derivan de la dirección MAC. 74

91 En una red IPv6 se puede combinar el uso de autoconfiguración stateless con servidores DHCP. En este escenario es posible, por ejemplo, utilizar autoconfiguración stateless para atribuir direcciones a los hosts y servidores DHCPv6 para proveer información de configuración adicional, como por ejemplo la dirección de los servidores DNS. Los protocolos DHCPv6 y DHCPv4 son independientes, de modo que en una red con doble pila se debe ejecutar un servicio para cada protocolo. En el caso de DHCPv4 es necesario configurar en el cliente si éste utilizará DHCP, mientras que la utilización de DHCPv6 se indica a través de las opciones de los mensajes RA. Muchas veces el direccionamiento de una red se basa en los prefijos atribuidos por los ISP. Si se cambia de proveedor es necesario renumerar todas las direcciones de la red. En IPv6 el proceso de redireccionamiento de los host se puede realizar de manera relativamente sencilla. A través de los mecanismos del protocolo de Descubrimiento de Vecinos el router puede anunciar un nuevo prefijo a todos los hosts del enlace. También es posible utilizar servidores DHCPv6. Para tratar la configuración y reconfiguración de prefijos en los routers tan fácilmente como en los hosts, en la RFC 2894 se definió el protocolo Router Renumbering. El mecanismo Router Renumbering utiliza mensajes ICMPv6 de tipo 138, los cuales se envían a los routers a través de la dirección multicast all-routers, y contienen las instrucciones para actualizar sus prefijos. Los mensajes Router Renumbering están formados por los siguientes campos: Tipo (decimal) Código - 0 para mensajes de comando 1 para mensajes de resultado 75

92 255 para poner en cero el número secuencial - Suma de Verificación Verifica la integridad de los mensajes ICMPv6 y de parte del encabezado IPv6 Número secuencial Identifica las operaciones Número de segmento Enumera diferentes mensajes RR válidos que tienen el mismo número secuencial. Flags T: Indica si la configuración del router debe ser modificada o si se trata de una prueba R: Indica si se debe enviar un mensaje de resultado; A: Indica si el comando se debe aplicar a todas las interfaces, independientemente de su estado S: Indica que el comando se debe aplicar a todas las interfaces, independientemente de la subred a la cual pertenezcan P: Indica que el mensaje de resultado contiene el informe completo del procesamiento del mensaje de comando, o que el mensaje de comando fue tratado previamente (y no se trata de una prueba) y que el router no lo está procesando nuevamente. Retraso máximo Especifica el tiempo máximo, en milisegundos, que un router debe retrasar el envío de cualquier respuesta a un mensaje de comando. Los mensajes de comando están formados por secuencias de operaciones, Match-Prefix y Use-Prefix. Match-Prefix indica cuál prefijo debe ser modificado, mientras que Use-Prefix indica el nuevo prefijo. Las operaciones pueden ser ADD, CHANGE o SET-GLOBAL, que indican, respectivamente, que el router debe agregar los prefijos indicados en Use-Prefix al conjunto de prefijos configurados, eliminar el prefijo indicado en Match-Prefix (si es que existen) y cambiarlos por los 76

93 prefijos contenidos en Use-Prefix; o reemplazar todos los prefijos de alcance global por los prefijos de Use-Prefix. Si el conjunto Use-Prefix es un conjunto vacío, la operación ADD no realiza ninguna adición y las otras dos operaciones simplemente borran el contenido indicado. Los routers también envían mensajes de resultados que contienen un Match Report para cada prefijo igual a los enviados en el mensaje de comando Path MTU Discovery Dependiendo de los protocolos de enrutamiento cada enlace de la red puede tener un valor de MTU diferente, es decir una limitación diferente respecto del tamaño máximo de paquete que puede atravesarlo. Para poder encaminar paquetes mayores que la MTU del enlace, éstos se deben fragmentar en paquetes menores que serán ensamblados al llegar a su destino. En la transmisión de paquetes IPv4 cada router a lo largo del camino puede fragmentar los paquetes si éstos son mayores que la MTU del siguiente enlace. Dependiendo del diseño de la red, un paquete IPv4 puede ser fragmentado más de una vez durante su trayecto y ensamblado nuevamente en el destino final. En IPv6 la fragmentación de los paquetes se realiza solamente en el origen, no estando permitida en los routers intermedios. Este proceso tiene por objeto reducir el overhead del cálculo de los encabezados modificados en los routers intermedios. Para ello en el inicio del proceso de fragmentación se utiliza el protocolo Path MTU Discovery, descrito en la RFC 1981, que descubre de forma dinámica cuál es el tamaño máximo de paquete permitido, identificando previamente las MTU de cada enlace en el camino hasta el destino. Todos los nodos IPv6 deben soportar el 77

94 protocolo PMTUD (Path MTU Discovery). No obstante, las implementaciones mínimas de IPv6 pueden omitir este soporte, utilizando 1280 bytes como máximo tamaño de paquete. El proceso Path MTU Discovery comienza suponiendo que la MTU de todo el camino es igual a la MTU del primer salto. Si el tamaño de los paquetes enviados es mayor que el que soporta alguno de los routers a lo largo del camino, éste lo descartará y devolverá un mensaje ICMPv6 packet too big, que junto con el mensaje de error devuelve el valor de la MTU del enlace siguiente. Luego de recibir este mensaje el nodo de origen reduce el tamaño de los paquetes de acuerdo con la MTU indicada en el mensaje packet too big. Este procedimiento finaliza cuando el tamaño del paquete es igual o menor que la MTU del camino, por lo que estas iteraciones (intercambio de mensajes y reducción del tamaño de los paquetes) pueden ocurrir varias veces hasta encontrar la menor MTU. Si el paquete es enviado a un grupo multicast el tamaño será la menor PMTU (Path MTU) de todo el conjunto de destinos. PMTUD puede parecer imperfecto desde un punto de vista teórico, ya que el enrutamiento de los paquetes es dinámico y cada paquete puede ser entregado a través de una ruta diferente. Sin embargo, estos cambios no son tan frecuentes y si el valor de la MTU disminuye debido a un cambio de ruta el origen recibirá el mensaje de error y reducirá el valor de la Path MTU Jumbograms La RFC 2675 define una opción de encabezado de extensión Hop-By-Hop llamada Jumbo Payload. Esta opción permite enviar paquetes IPv6 con cargas útiles con una longitud comprendida entre y bytes, conocidos como jumbograms. 78

95 Al enviar jumbograms, el encabezado IPv6 indicará un valor nulo (cero) en los campos Tamaño de Datos y Siguiente Encabezado. Este último indicará que las opciones del encabezado de extensión Hop-By-Hop deben ser procesadas por los nodos, donde se indican los tamaños de los paquetes jumbograms. El encabezado UDP tiene un campo de 16 bits llamado Tamaño que indica el tamaño del encabezado UDP más el tamaño de los datos y no permite el envío de paquetes de más de bytes. No obstante, es posible enviar jumbograms definiendo el campo Tamaño como cero y permitiendo que el receptor determine el tamaño real del paquete UDP a partir del tamaño del paquete IPv6. En los paquetes TCP las opciones Maximum Segment Size (MSS), que al iniciar la conexión negocia el tamaño máximo de paquete TCP a ser enviado, y Urgent Pointer, que indica el desplazamiento (offset) de bytes a partir del número de secuencia en que se encuentran los datos de alta prioridad, tampoco pueden referenciar paquetes mayores que bytes. Así que para enviar jumbograms es necesario establecer el valor de MSS igual a , valor que el receptor del paquete tratará como infinito. La solución es similar para Urgent Pointer: se puede establecer un valor de Urgent Pointer igual a , indicando que apunta más allá del final de este paquete Gestión del grupo Muticast Como se dijo antes, multicast es una técnica que permite direccionar múltiples nodos como un grupo, posibilitando el envío de paquetes a todos los nodos que lo componen a partir de una única dirección que los identifica. Los miembros de un grupo multicast son dinámicos y los nodos pueden entrar y salir de un grupo en cualquier momento. No existen limitaciones respecto del tamaño de un grupo multicast. 79

96 La gestión de los grupos multicast en IPv6 es realizada por el Multicast Listener Discovery (MLD) definido en la RFC Este protocolo es responsable de informar a los routers multicast locales el interés de los nodos en formar parte o salir de un determinado grupo multicast. En IPv4 este trabajo es realizado por el protocolo Internet Group Management Protocol (IGMPv2). MLD utiliza tres tipos de mensajes ICMPv6: Multicast Listener Query (Tipo 130) Hay dos subtipos de mensajes Query. Los mensajes General Query son utilizados por los routers para verificar periódicamente los miembros del grupo, solicitando a todos los nodos multicast que informen todos los grupos de los cuales forman parte. Los mensajes Multicast-Address-Specific Query son utilizados por los routers para descubrir si existen nodos que forman parte de determinado grupo. Multicast Listener Report (Tipo 131) Un nodo envía mensajes Report no solicitados cuando éste comienza a formar parte de un grupo multicast. También son generados en respuesta a mensajes Query. Multicast Listener Done (Tipo 132) Enviados por los nodos cuando abandonan determinado grupo. Estos mensajes son enviados con una dirección de origen link-local y con valor 1 en el campo Límite de Direccionamiento, garantizando que permanezcan en la red local. Si el paquete tiene un encabezado Hop-by-Hop, el flag Router Alert estará marcado; de este modo los routers no descartarán el paquete aunque la dirección del grupo multicast en cuestión no esté siendo escuchada por los mismos. En la RFC3810 se definió una nueva versión del protocolo MLD, denominada MLDv2. Equivalente a IGMPv3, además de incorporar las funcionalidades de 80

97 gestión de grupos de MLD, esta nueva versión introduce el soporte para filtrado de origen, lo que permite que un nodo especifique si no desea recibir paquetes de un determinado origen o que informe su interés por recibir paquetes solo de determinadas direcciones. Por defecto, los miembros de un grupo reciben paquetes de todos los miembros de este grupo. Otro mecanismo importante para el funcionamiento de los grupos multicast es el Multicast Router Discovery (MRD). MRD fue definido en la RFC 4286 y es utilizado para descubrir routers multicast en la red. Utiliza tres mensajes ICMPv6: Multicast Router Advertisement (Tipo 151) Este mensaje es enviado por los routers para anunciar que está habilitado el enrutamiento IP multicast. Se envía desde la dirección link-local del router a la dirección multicast allsnoopers (FF02::6A) Multicast Router Solicitation (Tipo 152) Los dispositivos envían este mensaje a los routers multicast para solicitar mensajes Multicast Router Advertisement. Se envía desde la dirección link-local del dispositivo a la dirección multicast allrouters (FF02::2) Multicast Router Termination (Tipo 153) Los routers envían este mensaje para anunciar que sus interfaces ya no están encaminando paquetes IP multicast. Se envía desde la dirección link-local del router a la dirección multicast all-snoopers (FF02::6A). Todos los mensajes MRD también se envían con un Límite de Direccionamiento igual a 1 y con la opción Router Alert DNS (Domain Name System) El protocolo Domain Name System (DNS) es una inmensa base de datos distribuida que se utiliza para resolver nombres de dominio en direcciones IP y 81

98 viceversa. Posee una arquitectura jerárquica en la cual los datos están dispuestos en forma de árbol invertido, distribuidos eficientemente en un sistema descentralizado y con caché. En la RFC 3596 se definieron algunos cambios para permitir que el DNS trabaje con la versión 6 del protocolo IP. Se creó un nuevo registro para almacenar las direcciones IPv6 de 128 bits, el AAAA o quad-a. Su función es traducir nombres a direcciones IPv6, equivalente al registro A que se utiliza en IPv4. Si un host tiene más de una dirección IPv6, éste tendrá un quad-a para cada dirección. Los registros se representan de la siguiente manera: Ejemplo: IN A IN AAAA 2001:12ff:0:4::22 Para la resolución inversa se agregó el registro PTR ip6.arpa, responsable de traducir direcciones IPv6 a nombres. En su representación no se permite omitir la secuencia de ceros y el bit menos significativo se coloca más a la izquierda, como se puede observar en el siguiente ejemplo: in-addr.arpa PTR f.f ip6.arpa PTR Los otros tipos de registro DNS no sufrieron modificaciones, salvo que fueron adaptados para soportar el nuevo tamaño de las direcciones. La RFC 2874 introdujo los registros A6 y DNAME a fin de facilitar la renumeración de redes, donde cada nameserver solamente tiene una parte de la dirección IPv6. 82

99 Inicialmente el dominio de resolución inversa, definido en la RFC 1886, era ip6.int, pero hubo manifestaciones contrarias a su utilización debido a que.int significa "internacional" y por lo tanto no debe ser empleado para fines administrativos en Internet. Los registros A6 y DNAME quedaron obsoletos por el desudo y el dominio.int fue reemplazado por el dominio.arpa, respectivamente en las RFC 3363 y Deben observarse dos aspectos del soporte para IPv6 del DNS. El primero es que un servidor DNS debe ser capaz de almacenar registros quad-a para direcciones IPv6. El segundo es que un servidor DNS es capaz de transportar consultas y respuestas a través de conexiones IPv6. Es decir, la base de datos de un servidor DNS puede almacenar tanto registros IPv6 como IPv4, independientemente de la versión de IP en que opera dicho servidor. Por lo tanto, un servidor que solamente tiene conexión IPv4 puede responder tanto consultas AAAA como A. Sin embargo, las informaciones obtenidas en la consulta vía IPv6 deben ser iguales a las obtenidas en la consulta IPv QoS (Quality Of Servise) Al principio, el protocolo IP trata todos los paquetes de la misma manera, sin ninguna preferencia a la hora de encaminarlos. Esto puede tener diferentes consecuencias para el desempeño de una aplicación, ya que en la actualidad muchas de estas aplicaciones tales como voz y video sobre IP, requieren transmisión y reproducción prácticamente en tiempo real y su calidad se puede reducir debido a la pérdida de paquetes, entrega fuera de orden, retraso o variación de la señal. Estos problemas pueden ocurrir debido a la forma en que el tráfico llega a los routers y es manipulado por los mismos, ya que como provienen 83

100 de diferentes interfaces y redes el router procesa los paquetes en el orden en que se reciben. El concepto de QoS (Quality of Service), se utiliza para los protocolos cuya función es proporcionar la transmisión de determinados tráficos con prioridad y garantía de calidad. Actualmente existen dos arquitecturas principales: Differentiated Services (DiffServ) e Integrated Services (IntServ). Ambas utilizan políticas de tráfico y se pueden combinar para permitir QoS en redes LAN o WAN. DiffServ trabaja por medio de clases, agregando y priorizando paquetes con requisitos de QoS similares. Los paquetes DiffServ se identifican por los ocho bits de los campos Tipo de Servicio en IPv4 y Clase de Tráfico en IPv6, con el fin de identificar y distinguir las diferentes clases o prioridades de paquetes que requieren QoS. Ambos campos tienen las mismas definiciones y las prioridades atribuidas a cada tipo de paquete se pueden definir tanto en el origen como en los routers y también pueden ser redefinidas por los routers intermedios a lo largo del camino. En los paquetes que no requieren QoS el campo Clase de Tráfico tiene valor 0 (cero). En comparación con IntServ, DiffServ no exige ninguna identificación ni gestión de los flujos y en general es más utilizado en las redes debido a su facilidad de implementación. El modelo IntServ se basa en la reserva de recursos por flujo y su utilización normalmente está asociada al Protocolo de Reserva de Recursos (RSVP). El protocolo RSVP se utiliza para reservar recursos a lo largo del camino de un flujo que requiere QoS desde la fuente hasta el destino. 84

101 En IPv6, para identificar los flujos que requieren QoS se utilizan los 20 bits del campo Identificador de Flujo que se completan con valores aleatorios comprendidos entre y FFFFF. Los paquetes que no pertenecen a un flujo deben completar el campo Identificador de Flujo con ceros. Los hosts y routers que no tienen soporte para las funciones de este campo deben completarlo con ceros cuando envían un paquete, no modificarlo cuando encaminan un paquete o ignorarlo cuando reciben un paquete. Los paquetes de un mismo flujo deben tener la misma dirección de origen y destino y el mismo valor en el campo Identificador de Flujo. RSVP utiliza algunos elementos del protocolo IPv6, como por ejemplo el campo Identificador de Flujo y el encabezado de extensión Hop-by-Hop. Los paquetes RSVP se envían con el mismo valor en el campo Identificador de Flujo junto con el encabezado de extensión Hop-By-Hop, usado para transportar un mensaje Router Alert que le indica a cada router en el camino del tráfico QoS que el paquete IP debe ser procesado. 4.6 MOVILIDAD IPV6 El soporte para movilidad permite que un dispositivo móvil se desplace de una red a otra sin necesidad de cambiar su dirección IP de origen, haciendo que el movimiento entre redes sea invisible para los protocolos de las capas superiores. Por lo tanto, todos los paquetes enviados a este nodo móvil continuarán siendo encaminados al mismo usando la dirección de origen. Existen algunos componentes clave para el funcionamiento del soporte para movilidad IPv6: Nodo móvil Dispositivo que puede cambiar de una red a otra sin dejar de recibir paquetes a través de su Dirección de Origen. Red de origen Red que atribuye la Dirección de Origen al Nodo Móvil. 85

102 Agente de Origen Router ubicado en la Red de Origen y que mantiene la asociación entre la Dirección de Origen y la Dirección Remota del Nodo Móvil. Dirección de origen Dirección global unicast atribuida por la Red de Origen al Nodo Móvil. Se utiliza como dirección permanente hacia la cual se encaminan los paquetes. Red remota Cualquier red diferente a la de Red de Origen en la cual se encuentra el Nodo Móvil. Dirección remota Dirección global unicast atribuida al Nodo Móvil por la Red remota. Nodo corresponsal Nodo que se comunica con un Nodo Móvil. Puede ser móvil o estacionario. El Nodo Móvil tiene una Dirección de Origen fija, que le es atribuida por su Red de Origen. Esta dirección se mantiene aunque no se desplace de su Red de Origen. Al ingresar en una Red Remota el Nodo Móvil recibe una o más Direcciones Remotas a través de los mecanismos de autoconfiguración, que consisten en un prefijo válido en la Red Remota. Para asegurar que se reciban los paquetes IPv6 destinados a su Dirección de Origen, el nodo realiza una asociación entre la Dirección de Origen y la Dirección Remota, registrando su nueva dirección en el Agente de Origen mediante el envío de un mensaje Binding Updates. Como respuesta a este mensaje el router de la Red de Origen envía un mensaje Binding Acknowledgement. Esta asociación de direcciones también se puede realizar directamente con el Nodo corresponsal a fin de optimizar la comunicación. Para detectar que regresó a su red el Nodo Móvil utiliza el proceso de Descubrimiento de Vecinos Inaccesibles para determinar si su router por defecto está activo. En caso de ubicar un nuevo router por defecto, éste generará una nueva dirección basada en el prefijo 86

103 anunciado en el mensaje RA. Sin embargo, el hecho de encontrar un nuevo router por defecto no necesariamente significa que se encuentra en una nueva red; puede que simplemente se trate de una renumeración de la red o del agregado de un nuevo router. Por lo tanto, antes de asociar las direcciones con el Agente de Origen y con los Nodos Corresponsales, el Nodo Móvil intentará ubicar nuevamente su router por defecto y comparará si el intervalo entre el envío de mensajes RA no solicitados es el mismo que está configurado en su Red Original. Cuando el Nodo Móvil regresa a su Red de Origen envía un mensaje Binding Updates para informarle su retorno al Agente de Origen y avisarle que ya no es necesario que reencamine los paquetes. (Ver Figura 4.16) Figura 4.16 Mensajes Binding Fuente: ipreference.com Las comunicaciones entre los nodos móviles y los nodos corresponsales pueden producirse de dos maneras diferentes: túneles bidireccionales y optimización de ruta. En el caso de los túneles bidireccionales, los paquetes que el Nodo Corresponsal envía a la Dirección Original del Nodo Móvil son interceptados por el Agente de Origen, que los encamina, a través de un túnel hacia el Nodo Móvil utilizando la Dirección Remota. Luego el Nodo Móvil responde al Agente de Origen, a través del túnel, que reenvía el paquete al Nodo Corresponsal. En este caso no es 87

104 necesario que el Nodo Corresponsal tenga soporte para movilidad IPv6 ni que el Nodo Móvil esté registrado en el Nodo Corresponsal. En el modo Optimización de Ruta la comunicación entre el Nodo Móvil y el Nodo Corresponsal ocurre de manera directa, sin necesitad de utilizar el Agente de Origen. Para que esta comunicación ocurra el Nodo Móvil registra su Dirección Remota en el Nodo Corresponsal que asocia las Direcciones de Origen y Remota del Nodo Móvil. El intercambio de mensajes entre ambos nodos funciona de la siguiente manera: El Nodo Corresponsal envía paquetes con el campo Dirección de Destino del encabezado base, completado con la Dirección Remota del Nodo Móvil. El encabezado base es seguido por el encabezado de extensión Routing Tipo 2, que transporta la Dirección de Origen del Nodo Móvil Al recibir el paquete el Nodo Móvil procesa el encabezado Routing e inserta la Dirección de Origen del encabezado Routing en el campo Dirección de Destino del encabezado base. Las capas superiores continúan procesando el paquete normalmente Los paquetes enviados por el Nodo Móvil tienen el campo Dirección de Origen del encabezado base completado con la Dirección Remota. El encabezado base está seguido por el encabezado de extensión Destination Options, que transporta en la opción Home Address la Dirección de Origen del Nodo Móvil. Al recibir el paquete el Nodo Corresponsal inserta la Dirección de Origen del encabezado Destination Options en el campo Dirección de Origen del encabezado base. Las capas superiores continúan procesando el paquete normalmente. Para optimizar el funcionamiento de este servicio, a la especificación de IPv6 se agregó un nuevo encabezado de extensión, el encabezado Mobility. 88

105 El encabezado de extensión Mobility se identifica por el valor 135 en el campo Siguiente Encabezado. Es utilizado por el Nodo Móvil, por el Agente Remoto y por el Nodo Corresponsal en el intercambio de mensajes relacionados con la creación y gestión de asociaciones de direcciones. Este encabezado tiene los siguientes campos: Protocolo de datos Corresponde al campo Siguiente Encabezado. En la actualidad solo se utiliza el valor 59, en formato decimal, lo que indica que no hay encabezado siguiente Tamaño del encabezado de extensión Contiene el tamaño del encabezado Mobility en unidades de 8 bytes. El tamaño de este encabezado debe ser siempre múltiplo de 8 Tipo de Mensaje Mobility Indica el tipo de mensaje enviado Suma de Verificación Verifica la integridad del encabezado Mobility Datos Su formato y tamaño dependen del tipo de mensaje Mobility que está siendo enviado. Los siguientes son los tipos de mensajes Mobility más utilizados: Binding Refresh Request (Tipo 0) Enviado por el Nodo Corresponsal para solicitarle al Nodo Móvil la actualización de la asociación de direcciones. Binding Update (Tipo 5) Enviado por el Nodo Móvil para notificar una nueva Dirección Remota al Agente de Origen o al Nodo Corresponsal. Binding Ack (Tipo 6) Enviado para confirmar la recepción de un mensaje Binding Update Binding Error (Tipo 7) Enviado por el Nodo Corresponsal para informar errores. 89

106 También se crearon cuatro nuevos mensajes ICMPv6 que se utilizan en la configuración de prefijos en la Red de Origen y en el descubrimiento de Agentes de Origen. El par de mensajes Home Agent Address Discovery Request y Home Agent Address Discovery Reply se utilizan para descubrir dinámicamente un Agente de Origen en su red. Esto evita la necesidad de realizar configuraciones manuales y problemas en caso de renumeración del Agente de Origen. El Nodo Móvil envía un mensaje Discovery Request a la dirección anycast del Agente de Origen en su red. El campo Dirección de Origen del encabezado base lleva la Dirección Remota del Nodo Móvil. El Agente de Origen responde enviando un mensaje Discovery Reply. Los mensajes Discovery Request y Reply se identifican por los valores 150 y 151, respectivamente, en el campo Siguiente Encabezado. Ya el mensaje Mobile Prefix Solicitation es enviado por el Nodo Móvil al Agente de Origen para determinar cambios en la configuración del prefijo en la red. El Agente Remoto responde enviando un mensaje Mobile Prefix Advertisement. En base a esta respuesta el Nodo Móvil puede configurar su Dirección de Origen. Los mensajes Mobile Prefix Solicitation y Advertisement se identifican, respectivamente, en el campo Siguiente Encabezado por los valores 152 y 153. También se introdujeron algunas modificaciones en el Protocolo de Descubrimiento de Vecinos. A los mensajes RA se agregó el flag H, que permite que un router anuncie si actúa como Agente de Origen en la red. Basándose en este anuncio, un Nodo Móvil crea una lista de Agentes de Origen de su red. 90

107 Así y todo, para mantener esta lista actualizada el Nodo Móvil debe conocer las direcciones global unicast de los routers, pero los mensajes RA traen solamente la dirección link-local. Para resolver este problema se agregó un nuevo flag a la opción Prefix Information, el flag R. Cuando este flag está marcada indica que la opción Prefix Information no contiene un prefijo pero sí la dirección global unicast del router. También se crearon dos nuevas opciones para el protocolo, Advertisement Interval y Home Agent Information. La primera indica el intervalo entre mensajes RA no solicitados, información que es utilizada por el algoritmo de detección de cambio de red. De acuerdo con las especificaciones del Protocolo de Descubrimiento de Vecinos el intervalo mínimo entre el envío de estos mensajes debe ser de tres segundos. Sin embargo, para asegurar que el Nodo Móvil detecte el cambio de red y aprenda la información sobre la nueva red lo más rápidamente posible, los routers con soporte para movilidad IPv6 se pueden configurar con un intervalo de tiempo menor para el anuncio de mensajes RA. La opción Home Agent Information se utiliza para indicar el nivel de preferencia de asociación de cada Agente de Origen. Las principales diferencias entre el soporte para movilidad de IPv6 y de IPv4 se pueden resumir en los siguientes puntos: Ya no es necesario implementar routers especiales que actúen como agentes remotos En lugar de formar parte de un conjunto de extensiones opcionales, la optimización de la ruta está incorporada en el protocolo La autoconfiguración stateless facilita la atribución de Direcciones Remotas 91

108 Aprovecha los beneficios del protocolo IPv6 tales como el protocolo de Descubrimiento de Vecinos, los mensajes ICMPv6 y los encabezados de extensión. El uso del protocolo de Descubrimiento de Vecinos en lugar de ARP permite que el proceso de intercepción de los paquetes destinados al nodo móvil no dependa de la capa de enlace, lo que simplifica el protocolo y aumenta su eficiencia La búsqueda por agentes de origen que realizaba el nodo móvil pasó a ser realizada utilizando anycast. De esta forma el nodo móvil solo recibirá la respuesta de un único agente de origen. Con IPv4 se utiliza broadcast, lo que implica una respuesta separada para cada agente de origen existente. 4.7 SEGURIDAD EN IPv6 Destinado principalmente a interconectar redes de investigación académicas, el proyecto original de IPv4 no presentaba ninguna gran preocupación con respecto a la seguridad de la información transmitida. Sin embargo, la creciente importancia de Internet para las transacciones entre empresas y consumidores llevó a exigir mayores niveles de seguridad, como por ejemplo identificación de usuarios y encriptación de los datos, haciendo que fuera necesario agregar al protocolo original nuevos mecanismos que garantizaran estos servicios. No obstante, las soluciones adoptadas son habitualmente específicas para cada aplicación. Este hecho es bastante claro en la Internet actual. Hay quienes sostienen que para resolver este problema debería haber una nueva Internet, proyectada desde cero (enfoque clean slate). Al proyectar IPv6 se abordaron algunos aspectos de la seguridad, pero sus implementaciones aun no están maduras. A pesar de tener más de diez años, no 92

109 hay buena experiencia en su uso. Las mejores prácticas continúan siendo tomadas de IPv4, por lo que no siempre funcionan bien. En IPv6 la seguridad fue una preocupación desde el inicio, por lo que en el protocolo se implementaron varias herramientas de seguridad Antes de entrar en detalle sobre las herramientas vamos a pensar un poco acerca de la estrategia de despliegue de IPv6. Podemos pensar en varios ejemplos históricos de despliegues de nuevas tecnologías en que no se tuvieron en cuenta desde el inicio los aspectos de seguridad, como cuando surgieron los routers inalámbricos. Podemos mencionar varios ejemplos de la vida diaria de proyectos de última hora, demostraciones para clientes, que terminan por convertirse en sistemas en producción y presentan diferentes vulnerabilidades. Lo ideal es que el despliegue de IPv6 se realice de una manera planificada y organizada, tomando en cuenta la seguridad desde el primer momento. Es interesante observar cuántos sistemas son capaces de ejecutar IPv6 y que muchos de ellos vienen con el protocolo habilitado por defecto. La lista incluye sistemas operativos, teléfonos celulares y equipos de red, entre otros. IPv6 ofrece diferentes herramientas tanto para defensa como para ataque: Defensa: IPsec SEND Crypto-Generated Address Unique Local Addresses 93

110 Privacy Addresses Ataque: Túnel automático Descubrimiento de vecinos y autoconfiguración Modelo end-to-end Novedad / Complejidad Falta de políticas, capacitación y herramientas. Es necesario: Preocuparse por la seguridad y considerar la seguridad de los equipos desde el inicio. Obtener equipos certificados Educación / Capacitación Actualizar las herramientas y procesos de seguridad Desarrollar prácticas de programación adecuadas (y seguras) para IPv6 Buscar auditores / equipos de prueba que conozcan IPv6 IPSec fue desarrollado para IPv4 y es poco lo que cambia con IPv6. No obstante, el soporte pasa a ser obligatorio y no hay NAT para entorpecer el funcionamiento. IPSec se puede utilizar de dos maneras diferentes: modo transporte o modo túnel. En modo transporte, ambos extremos de la comunicación requieren soporte IPSec para que entre ellos la comunicación sea segura. A diferencia de lo que ocurre en modo transporte, en modo túnel (también conocido como VPN) IPSec se implementa en dispositivos propios (por ejemplo, concentradores VPN) entre los que la comunicación IPSec se realiza encapsulando todos los paquetes IP de los respectivos extremos. 94

111 Cabe destacar que en el caso de una comunicación en modo transporte se mantiene el encabezado del paquete IP original. En modo túnel éste se codifica y se crea un nuevo encabezado que hace posible la comunicación entre el dispositivo emisor y el dispositivo receptor (del túnel). Transporte - Protege solo los protocolos de las capas superiores, ya que el encabezado de seguridad aparece inmediatamente después del encabezado IP y antes de los encabezados de los protocolos de las capas superiores Túnel - Protege todo el paquete IP, encapsulándolo dentro de otro paquete IP y dejando visible solo el encabezado IP externo. Muchas implementaciones de pila IPv6 todavía no soportan IPSec en forma integral. Por lo tanto, éste se está usando sin soporte criptográfico. Pero aunque se esté utilizando, en las redes IP todavía preocupan varios temas de seguridad. No obstante lo anterior, IPv6 potencialmente puede mejorar la seguridad en Internet. DoS: En IPv6 no existen direcciones broadcast broadcast. Evita ataques mediante el envío de paquetes ICMP a la dirección Las especificaciones de IPv6 prohíben la generación de paquetes ICMPv6 en respuesta a mensajes enviados a direcciones globales multicast (excepto mensajes packet too big). Muchos sistemas operativos siguen la especificación Todavía hay cierta incertidumbre sobre el riesgo que pueden crear los paquetes ICMPv6 que se originan en direcciones multicast globales. A continuación se nombraran algunas recomendaciones para mejorar la seguridad en IPv6: 95

112 Implementar extensiones de privacidad solo en las comunicaciones externas. Cuidado con el uso indiscriminado, puede dificultar las auditorías internas. Las direcciones de uso interno se deben filtrar en los routers de borde. Las direcciones multicast como FF02::1 (all-nodes on link), FF05::2 (all-routers on link) y FF05::5 (all DHCPv6 servers) se pueden transformar en nuevos vectores de ataque. Filtrar el ingreso de paquetes con direcciones de origen multicast. No usar direcciones obvias Filtrar servicios innecesarios en el firewall. Filtrar mensajes ICMPv6 no esenciales Filtrar direcciones bogon. En IPv6 este filtrado es diferente al que se realiza en IPv4. En IPv4 se bloquean los rangos no asignados (son pocos). En IPv6 es al revés. Es más fácil liberar solo los rangos asignados. Bloquear fragmentos de paquetes IPv6 con destino a equipos de red. Descartar paquetes de tamaño menor a 1280 bytes (excepto el último). Los mecanismos de seguridad de BGP y de IS-IS no cambian. Con OSPFv3 y RIPng se debe utilizar IPSec. Limitar el número de saltos para proteger dispositivos de red. Utilizar IPSec siempre que sea necesario. 96

113 5. DESARROLLO INGENIERIL 5.1 INSTALACIÓN DE IPV6 La mayor parte de los sistemas operativos, desde el año 2001 aproximadamente, tienen algún tipo de soporte de IPv6. En algunos casos, inicialmente no se trataba de un soporte comercial, sino de versiones de prueba, aunque se incorporaban a sistemas operativos de producción. Tal es el caso del soporte de IPv6 en Windows 2000, e incluso en la primera versión de Windows XP antes del lanzamiento del denominado Service Pack 1 (SP1). Cada vez es más frecuente que diversas plataformas o sistemas operativos, no solo incorporen IPv6, sino que además éste sea activado por defecto por el fabricante, sin requerir intervención alguna por parte del usuario. Lo expuesto es válido no solo para sistemas operativos de computadores de sobremesa y portátiles, sino también para otros dispositivos que utilizan los mismos sistemas operativos, o versiones reducidas de los mismos, por ejemplo teléfonos celulares, agendas electrónicas, plataformas de juegos, etc. Es cierto, lógicamente, que en algunos casos, dichas versiones reducidas de los sistemas operativos, no incorporan todas las funcionalidades del sistema operativo original, y por tanto, se podría dar el caso de no poder acceder a todos las funciones que se mostrarán para la configuración y prueba de IPv Instalación de IPv6 en Windows XP/2003 En realidad se podría decir que IPv6 ya está instalado tanto en Windows XP como en Windows Server 2003 y por tanto, más que de instalación, se habla de activación. 97

114 Existen dos procedimientos para habilitar IPv6 en estas dos plataformas: En una ventana DOS ejecutar: ipv6 install. Tras unos segundos, un mensaje de confirmación indicara la correcta instalación. A través del entorno gráfico o panel de control, llegar hasta Conexiones de red, seleccionar la red de área local o red inalámbrica, Propiedades con el pulsador derecho del ratón y a continuación pulsar sobre instalar, protocolo y seleccionar Microsoft TCP/IP version 6. (Ver Figura 5.1). Figura 5.1: Instalación de IPv6 en Windows XP Instalación IPv6 en Vista Desde el lanzamiento de Windows Vista, este sistema operativo incluye soporte de IPv6 instalado y habilitado por defecto. Por lo tanto, no es necesario hacer ninguna configuración adicional. En caso de que se hubiera desactivado, se podría utilizar 98

115 el procedimiento con netsh o entorno gráfico indicado para Windows XP/2003.(Ver Figura 5.2). Téngase en cuenta que para usar netsh, se requiere una ventana de DOS explícitamente abierta con permisos de administración. Figura 5.2: Instalación en Windows Vista En comparación con XP/2003, IPv6 en Vista tiene funcionalidades adicionales, como por ejemplo: Soporte completo IPsec MLDv2 (Multicast Listener Discovery Version 2) LLMNR (Link-Local Multicast Name Resolution) No requiere un servidor DNS. Los nodos IPv6 en un segmento piden el nombre a una dirección IPv6 multicast en forma similar al funcionamiento de NetBIOS. Soporte de direcciones IPv6 en URLs IPv6 Control Protocol (IPV6CP - RFC5072) IPv6 sobre PPP DHCPv6, en el cliente y el servidor 99

116 Identificador de Interfaz aleatorio por defecto (RFC3041) Teredo soporta NATs simétricos Activo por defecto. Solo se utiliza si la aplicación requiere soporte IPv6 y no está disponible de forma nativa. Se puede comprobar que está instalado por medio de comandos, o con el entorno gráfico de forma similar a lo indicado para el caso de XP: Instalación IPv6 en Windows 7 Igual que en el caso de Vista/2008, Windows 7 incorpora IPv6 instalado y habilitado por defecto. Igualmente, en caso de que se hubiera desactivado, se podría utilizar el procedimiento con netsh o entorno gráfico indicado para Windows XP/2003. En este caso también se debe tener en cuenta que para usar netsh, se requiere una ventana de DOS explícitamente abierta con permisos de administración. Las características de esta versión se pueden resumir en: Soporte IPv6 similar al de Vista y Server 2008 IPsec, MLDv2, LLMNR, IPv6 en URLs, IPV6CP, IPv6 sobre PPP, DHCPv6, Teredo. Cambia: Identificador de Interfaz aleatorio por defecto (RFC3041) No usa EUI-64 por defecto para el identificador de interfaz en las direcciones autoconfiguradas. Nuevas mejoras IP-HTTPS (IP over Secure HTTP) Permite a los hosts atravesar un servidor proxy o firewall y conectarse a redes privadas por medio de IPv6 dentro de un túnel 100

117 HTTPS. HTTPS no provee seguridad a los datos, es necesario usar IPsec para dar seguridad a una conexión IP-HTTPS. DirectAcces Permite a los usuarios conectarse de manera transparente a la red corporativa sin establecer específicamente una conexión VPN. También permite al administrador de red seguir en contacto con los host móviles fuera de la oficina y poder hacer actualizaciones y dar soporte a dichos equipos. Es una arquitectura en la que un cliente IPv6 se comunica con un servidor IPv6 en la red corporativa. También se puede usar conexiones desde Internet IPv4 empleando 6to4, Teredo e ISATAP. También se puede usar IP-HTTPS. DirectAccess usa túneles IPsec para proveer seguridad a la autenticación y al acceso a recursos. El cliente puede ser un Windows 7 o Server El servidor puede ser un Server 2008 Igual que en el caso de Vista, se puede comprobar que está instalado, mediante el entorno gráfico (Ver figura 5.3): Figura 5.3 Instalación Windows 7 101

118 5.1.4 Instalación de IPv6 en Windows 2000 El método más fiable para la instalación de la pila IPv6 para Windows 2000, requiere primero descargar el código correspondiente a la pila IPv6, dado que a diferencia de los sistemas operativos hasta ahora mencionados, en este caso no está preinstalado por el fabricante. Como se ha indicado antes, Windows 2000 IPv6 no está soportado por Microsoft, dado que se trataba de una versión de desarrollo. Por lo tanto, en primer lugar, se debe descargar Microsoft IPv6 Technology Preview for Windows 2000 : tpipv sp2-ie6 para SP1 y SP2 tpipv sp3-ie6 para SP3 tpipv sp4-ie6 para SP4 Una vez realizada la descarga, el procedimiento de instalación es el siguiente: Entrar en el sistema como usuario con privilegios locales de administrador Extraer los ficheros de IPv6 Technology Preview, por ejemplo en C:\IPv6Kit. Seguir el procedimiento de SPn & IE6 fixed.txt para cambiar el fichero/setup/hotfix.ini. Ejecutar Setup.exe o hotfix.exe. Desde el escritorio de Windows 2000, clic en Inicio, luego Configuración y luego Conexiones de Red. Alternativamente, hacer clic con el botón derecho en Mis Sitios de Red, luego clic en Propiedades, hacer clic con el botón derecho en conexiones basadas en Ethernet para las que se desea añadir el protocolo IPv6 y luego clic en Propiedades. Normalmente, esta conexión se denomina Conexión de Área Local. Clic en Install. 102

119 En el cuadro de diálogo Seleccionar Tipo de Componente de Red, hacer clic en Protocolo y luego clic en Añadir. En el cuadro de diálogo Seleccionar Protocolo de Red, hacer clic en Microsoft IPv6 Protocol y luego clic en Aceptar Clic en Cerrar para cerrar el cuadro de diálogo de las Propiedades de la Conexión de Área Local Comprobación de IPv6 Windows Una vez se ha instalado IPv6, en función de las diferentes plataformas, se tiene una o varias opciones para verificar que dicha instalación ha sido realizada correctamente e incluso si se tiene conectividad tanto en la red local como con otras redes IPv6. Además de visualizar si la pila IPv6 ha sido instalada a través del entorno gráfico, como se ha indicado anteriormente, se puede utilizar el comando ipconfig o ipv6 if ( Ipv6 if no está disponible en las últimas versiones de Windows). El comando ipconfig facilitará la información de configuración IPv6 de las diferentes interfaces al igual que de IPv4, mientras que ipv6 if sólo muestra información relativa a IPv6. Una prueba adicional es comprobar que se puede alcanzar la propia interfaz, mediante el comando ping/ping6 a la dirección Loopback ::1 (ping6 puede estar disponible dependiendo de la versión específica de cada sistema operativo). El paso siguiente sería, comprobar que hay conectividad con la red local. Esto sólo es posible si hay otras máquinas con IPv6 correctamente configurada en dicha red local (y la configuración de los cortafuegos permite usar el comando ping). El uso 103

120 sería equivalente al ejemplo anterior, pero utilizando la dirección de enlace local (o una dirección global, si existiera), de la máquina a la que se desea hacer ping. Un paso adicional, sería el uso de una herramienta que muestre los saltos entre los diferentes puntos de la red, desde la maquina propia hasta la máquina destino, lo que se denomina un traceroute (traza de la ruta). Para ello se usa el comando tracert o tracert6 (según la versión/plataforma) Configuración de IPv6 Windows Antes de realizar cualquier configuración es necesario saber qué índice le corresponde a la interfaz en donde se va a realizar la configuración. Para lograr esto se escribe el siguiente comando: netsh interface ipv6 show interface El índice asignado a la interfaz es visible al costado izquierdo. (Ver figura 5.4). Figura 5.4 Índice correspondiente a cada Interfaz Por diversos motivos, puede requerirse configurar manualmente una dirección IPv6. Para ello se usa el comando netsh con el formato siguiente: 104

121 netsh interface ipv6 add address [interface=]<cadena (nombre de interfaz o índice)> [address=]<dirección IPv6>[/<entero>] [[type=]unicast anycast] [[validlifetime=]<entero > infinite] [[preferredlifetime=]<entero> infinite] [[store=]active persistent] Ejemplo: netsh interface ipv6 add address :db8::2 type=unicast validlifetime=infinite preferredlifetime=10m store=active Igualmente, se puede revisar la configuración con netsh (asumiendo que es la interfaz numero 5) netsh interface ipv6 show address 5 Una vez configurada una dirección manualmente, se puede modificar con: netsh interface ipv6 set address [interface=]<cadena> [address=]<dirección IPv6>[[type=]unicast anycast] [[validlifetime=]<entero> infinite] [[preferredlifetime=]<entero > infinite] [[store=]active persistent] Ejemplo: netsh interface ipv6 set address :db8::2 preferredlifetime=infinite Y finalmente, dicha dirección puede ser eliminada con: netsh interface ipv6 delete address [interface=]<cadena> [address=]<dirección IPv6>[[store=]active persistent] 105

122 Ejemplo: netsh interface ipv6 delete address :db8::2 store=persistent Igualmente, se puede dar el caso en que sea necesario agregar una ruta estática, y de forma similar, se utiliza: netsh interface ipv6 add route add route [prefix=]<dirección IPv6>/<entero> [interface=]<cadena> [[nexthop=]<dirección IPv6>] [[siteprefixlength=]<entero>] [[metric=]<entero>] [[publish=]no yes immortal] [[validlifetime=]<entero> infinite] [[pre ferredlifetime=]<entero> infinite] [[store=]active persistent] Ejemplo: netsh interface ipv6 add route 2002::/16 5 fe80::200:87ff:fe28:a0e0 store=persistent Donde, fe80::200:87ff:fe28:a0e0 es la puerta de enlace que se desea configurar para la ruta 2002::/16. Para borrar dicha ruta puede emplearse: netsh interface ipv6 delete route [prefix=]<dirección IPv6>/<entero> [interface=]<cadena> [[nexthop=]<dirección IPv6>] [[store=]active persistent] Ejemplo: netsh interface ipv6 delete route 2002::/16 5 fe80::200:87ff:fe28:a0e0 store=persistent Además se pueden visualizar las rutas con el siguiente comando (Ver figura 5.5): netsh interface ipv6 show route [[level=]normal verbose] [[store=]active persistent] 106

123 Figura 5.5 Rutas configuradas en cada interfaz 5.2 SIMULADOR GNS3 Durante el desarrollo de este proyecto se realizarán varias configuraciones tanto en router como en host, por lo que se hace necesario el uso de simuladores para tener la posibilidad de realizar las prácticas propuestas sin el requerimiento de contar con un Laboratorio de Redes especializado. Actualmente existen diversos simuladores de red como: OMNeT++, Packet Tracer, Boson Net Simulator y GNS3 solo por nombrar algunos. Sin embargo el objetivo es utilizar un simulador que proporcione la robustez necesaria y que dé soporte al protocolo IPv6. Realizando diferentes pruebas con distintos simuladores, se ha encontrado que el simulador que más se ajusta a las necesidades de este proyecto es GNS3. GNS3 es un simulador grafico de redes que permite diseñar fácilmente topologías de red y luego ejecutar simulaciones en él. Hasta este momento GNS3 soporta el IOS de routers, ATM/Frame Relay/switchs Ethernet y PIX firewalls. 107

124 Además este simulador permite extender una red propia, conectándola a la topología virtual. Para realizar esto, GNS3 está basado en Dynamips, PEMU (incluyendo el encapsulador) y en parte en Dynagen. Fue desarrollado en python a través de PyQt la interfaz grafica (GUI) confeccionada con la poderosa librería Qt, famosa por su uso en el proyecto KDE. GNS3 también utiliza la tecnología SVG (Scalable Vector Graphics) para proveer símbolos de alta calidad para el diseño de las topologías de red. Las capacidades más importantes que se pueden resaltar de GNS3 y que han servido como punto de partida para tomar la decisión de estudiar más a fondo este simulador son las siguientes: Se encuentra disponible de forma gratuita en la red. Es fácil de instalar ya que todos los programas que necesita para funcionar se encuentran en un solo paquete de instalación. Está en constante actualización y periódicamente se puede encontrar versiones de la aplicación más robustas y con nuevas funcionalidades. Permite la conexión Telnet a la consola de un router virtual, de forma fácil directamente desde la interfaz gráfica. Alternativamente también permite trabajar directamente desde consola de gestión de Dynagen. Permite la comunicación entre redes virtuales y redes del mundo real. Es apropiado para simular redes de grandes tamaños ya que permite que un cliente GNS3 pueda correr en una máquina diferente a la que contiene al emulador Dynamips, repartiendo el procesamiento entre diferentes PCs. Puede capturar los paquetes que pasan por enlaces virtuales y escribir los resultados de la captura en archivos que pueden ser interpretados por aplicaciones como Wireshark o tcpdumps. Los foros de Internet evidencian que es una aplicación ampliamente utilizada. 108

125 A continuación se encuentra una tabla comparativa con los distintos simuladores con los que se experimentaron previamente a la elección del simulador GNS3. Tabla 5.1 Tabla comparativa entre los simuladores usados Static Routing RIPng OSPF v3 IS-IS IPv6 M- BGP DUALS TACK 6to4 ISATAP GRE (IPv6) Facilidad de uso PACKET TRACER x x x x ROUTER SIM x x x x BOSON NET SIMULATOR x x x x x OMNET++ x x x x x x x x x GNS3 x x x x x x x x x x Omnet++ es una potente herramienta, eficiente, enfocada al area académica, desarrollada para modelar y simular eventos discretos en redes de comunicaciones. Sin embargo, un modelo de simulación en OMNET++ consiste de una serie de modulos que se comunican a través del paso de mensajes y en el que los modulos activos son módulos simples y cuya implementación es através de la programación en C++ empleando la librería de simulación dificultando la implementación de los protocolos de enrutamiento y técnicas de transición. Por el contrario, GNS3 permite centralizar su uso, en el sistema operativo de los routers en los cuales se trabaja, en este caso CISCO lo cual simplifica y reduce el trabajo necesario para implementar cada simulación Uso de GNS3 A continuación se tratará de explicar claramente cómo hacer uso de GNS3, detallando los pasos que hay que seguir para la emulación de las diferentes plataformas CISCO soportadas. Así mismo se describirán los diferentes métodos existentes para la simulación de PCs y se explicará cómo usar los switches 109

126 Ethernet. De igual manera se mostrará cómo realizar los procesos básicos de GNS3, como por ejemplo la creación de enlaces, la interconexión de redes reales con virtuales, la captura de datos, la operación en modo hipervisor o el almacenamiento de la topología Emulación Router CISCO Como ya se ha indicado anteriormente, para emular routers CISCO reales se necesita una imagen del IOS CISCO perteneciente al router que contiene las características que se desea clonar. La imagen del IOS CISCO debe ser buscada por cuenta de cada persona o puede ser solicitada directamente a CISCO si se es cliente. La imagen debe soportar el protocolo IPv6. En este sentido, el emulador habilitará un número de ranuras o slots dependiendo del tipo de plataforma que se emula y en cada una de esas ranuras se podrán colocar solo ciertos tipos de adaptadores de interfaces. Por lo tanto, si se quiere añadir capacidades de hardware en el router virtual, se debe seleccionar el tipo de adaptador de red que éste puede soportar en la configuración del router virtual. Ver Tabla 5.1 para más detalle. Tabla 5.2 Lista de adaptadores correspondientes a cada tipo de plataforma Adaptadores de Interfaces Disponibles Routers Nombre Descripción 1700s WIC-1T 1 puerto serie WIC-2T 2 puertos serie WIC-1ENET 1 puerto Ethernet 2600s NM-1E 1 puerto Ethernet NM-4E 4 puertos Ethernet NM-1FE-TX 1 puerto FastEthernet 110

127 Módulo de switch Ethernet (16 NM-16ESW puertos) Conecta el router virtual a un PC NM-NAM virtual Conecta el router virtual a un PC NM-IDS virtual WIC-1T 1 puerto serie WIC-2T 2 puertos serie 3600s NM-1E 1 puerto Ethernet NM-4E 4 puertos Ethernet NM-1FE-TX 4 puertos Ethernet NM-16ESW Módulo de switch Ethernet (16 puertos) NM-4T 4 puertos serie Leopard-2FE Puerto automático FastEthernet en slot s NM-1FE-TX (FastEthernet, 1 port) 1 puerto FastEthernet NM-4T 4 puertos serie NM-16ESW Módulo de switch Ethernet (16 puertos) GT96100-FE 2 puertos integrados NM-NAM Conecta el router virtual a un PC virtual NM-IDS Conecta el router virtual a un PC virtual WIC-1T 1 puerto serie WIC-2T 2 puertos serie 7200s C7200-IO-FE Solo puerto FastEthernet en slot 111

128 0 C7200-IO-2FE 2 puertos FastEthernet en slot 0 Sólo Puerto GigabitEthernet en C7200-IO-GE-E slot 0 PA-FE-TX 1 puerto FastEthernet PA-2FE-TX 2 puertos FastEthernet PA-4E 4 puertos Ethernet PA-8E 8 puertos Ethernet PA-4T+ 4 puertos serie PA-8T 8 puertos serie PA-A1 Puerto ATM PA-POS-OC3 Puerto POS PA-GE 1 puerto GigabitEthernet Los pasos a seguir para la emulación y configuración de un router en GNS3 son los siguientes: 1) En el grupo de plataformas hacer clic sobre el router que se quiere emular y arrastrar hasta el área de construcción de topologías. Ver figura 5.6. Figura: 5.6 ventana principal GNS3 112

129 2) Hacer clic derecho sobre el router y después elegir configure, tal como se muestra en la Figura 5.7. Figura 5.7 Menú de opciones de un router 3) Hacer clic en el nombre del router, después en la pestaña slots y finalmente elegir las interfaces que se desea instalae en el dispositivo haciendo clic en de cada slot. Guardar los cambios cliqueando en OK. Ver figura 5.8 Figura 5.8 Ventana de configuración del nodo 113

130 4) Encender el router con un clic derecho y eligiendo start, como se muesra en la Figura 5.9. Notar que ahora en el resumen de la topología ubicado a la derecha de la pantalla, el indicador del router se encuentra de color verde. Figura 5.9 Encendido del router mediante la opción Start 5) Calcular el valor de IDLEPC para la imagen de IOS utilizada con un clic derecho en el router y eligiendo Idle PC del menú desplegado (ver Figura 5.10). Figura 5.10 Cálculo de IDLEPC para la imagen del IOS 6) Tras unos instantes se apreciará una ventana como la de la Figura 5.11, hacer clic en para ver todos los posibles valores de IDLE PC calculados, los mejores son los que tiene un * a la izquierda, elegir uno de ellos y hacer clic en apply. Figura 5.11 Selección de IDLE PC para la imagen del router 114

131 7) Finamente hacer clic derecho sobre el router y elegir console para obtener una ventana de Telnet con la consola del router que se está emulando (ver Figura 5.12). Figura 5.12 Selección de la opción de consola para administración del router Emulación de Switches Ethernet GNS3 posee integrada la capacidad de emulación de switches simples Ethernet con funcionalidades básicas como la creación de VLANs o el funcionamiento del trunking 802.1q. Por defecto, un switch emulado con GNS3 tiene 8 puertos Access configurados en la VLAN1 pero se puede añadir hasta puertos, pudiendo ser cada uno de ellos un puerto de acceso o uno troncal. 115

132 En este sentido, si se desea trabajar con switches que poseen más funcionalidades, GNS3 puede emular una tarjeta EtherSwitch que puede ser soportada sólo por determinadas plataformas CISCO. La tarjeta EtherSwitch que emula Dynamips es NM-16ESW además puede ser incluida en casi todas las plataformas disponibles en GNS3. Las principales capacidades de esta tarjeta son: Interfaces Ethernet Layer 2 Interfaces Switch Virtual (SVI) Protocolo VLAN Trunk EtherChannel Protocolo Spanning Tree Protocolo Cisco Discovery Switched Port Analyzer (SPAN) Calidad de Servicio IP Multicast Storm-Control Seguridad de Puertos Stacking Control de flujo. Cabe resaltar que una tarjeta NM-16ESW no puede soportar todos los comandos existentes en un switch Ethernet, por lo que para su uso se recomienda consultar los manuales existentes en CISCO. La emulación y configuración de un switch Ethernet usando GNS3 se hace de la siguiente manera: 116

133 1) Hacer clic en el Ethernet Switch situado en la parte izquierda de la ventana principal y arrastrar hasta el área de construcción de topologías (ver Figura 5.13). Figura 5.13 Ventana principal GNS3 2) Hacer clic derecho sobre el ícono del switch y elegir configure, como se muestra en la Figura Figura 5.14 Selección de la opción configure de un switch 3) En ventana de la figura 5.15, hacer clic sobre el nombre del dispositivo y borrar la configuración inicial del switch Ethernet seleccionando cada puerto y haciendo clic en Delete. Figura 5.15 Ventana de configuración del switch 117

134 4) Configurar los nuevos puertos ingresando los parámetros de la sección Settings y hacer clic en Add (Ver Figura 5.16). Finalmente guardar los cambios haciendo clic en OK. Figura 5.16 Sección settings de la ventana de configuración del switch 5) Crear enlaces entre los diferentes dispositivos disponibles y cualquiera de las interfaces del switch que se acaban de añadir Simulación de PC s 118

135 GNS3 permite, además de los equipos de red, la incorporación de PCs en las topologías creadas, lo que facilita la comprobación y el estudio de las redes simuladas. Las formas existentes de simulación de PCs en GNS3 son las siguientes: - Usando Virtual PC Esta primera forma de simulación de PCs se realiza utilizando un programa llamado Virtual Pc Simulator ó VPC que usa puertos UDP para la comunicación entre el simulador y cada uno de los PCs simulados. VPC es un programa que corre tanto en Windows como en Linux y que se puede descargar desde Internet de forma gratuita. Las ventajas de usar VPC es que su uso es simple y que no usa grandes cantidades de memoria ni ciclos de CPU para su funcionamiento; por otro lado, tiene la desventaja de que tiene funcionalidad limitada, ya que solo permite el uso de comandos como ping y traceroute ; además sólo soporta un máximo de nueve (09) PCs simulados simultáneamente. Los pasos a seguir para la simulación de PCs utilizando este método son: 1) Descargar e instalar el programa Virtual Pc Simulator desde 2) Escribir el carácter? para observar los comandos disponibles, como puede verse en la Figura 5.17 y show para ver la configuración de red actual de los PCs simulados. Para introducir comandos en un detreminado PC, este se puede seleccionar escribiendo su número de identificación correspondiente (del 1 al 9) como se muestra en la Figura

136 Figura 5.17 Comandos disponibles en VPC s 3) Se puede configurar los datos de cada PC IPv4 ingresando el comando ip seguido de la dirección IP ( ), la puerta de enlace por defecto del PC ( ), la máscara de subred (24) y Enter. En el caso de IPv6 se asigna de igual forma, sin embargo no es necesario introducir la puerta de enlace por defecto. Si se desea configurar otro PC se debe escribir el número correspondiente al PC y luego presionar Enter. Figura 5.18 Configuración de los PC s virtuales 4) Para incluir los PCs en la topología se debe seleccionar el ícono correspondiente a una nube (cloud) y arrastrarlo al área de construcción de topologías. Luego dando clic derecho sobre la nube se puede seleccionar la 120

137 opción de cambiar el símbolo (Change symbol) seleccionar Computer, dar clic en Apply y luego en OK. Se puede arrastrar tantas nubes como PCs se quiera integrar al simulador. 5) Para configurar los PCs, hacer clic derecho en cada uno de ellos y elegir configure. Hacer clic en C0 debajo de clouds y elegir la pestaña llamada NIO UDP. Ver figura Figura 5.19 Selección de la pestaña NIO UDP para la configuración del PC 6) Configurar los parámetros Local port, Remote host y Remote port debajo de Settings con los datos mostrados en la figura 5.21 que corresponden a los puertos asignados por VPC para un PC virtual. Hacer clic en Add y finalmente en OK. Figura 5.20 Ventana para la configuración de PCs virtuales 121

138 6) Repetir los pasos 5 y 6 en cada una de las otras nubes añadidas pero asignar valores correlativos a los mostrados anteriormente, tanto para el puerto local como para el remoto. Figura 5.21 Configuración de PC s virtuales - Creación de Enlaces En GNS3 los enlaces son usados para unir dos dispositivos de red de la topología creada. Estos pueden ser GigaEthernet, ATM, POS, FastEthernet, Ethernet o Serie y su tipo depende de los adaptadores de interfaz que tengan los dos dispositivos a los que une. Para simular un enlace se siguen los siguientes pasos: 1) Hacer clic en el ícono situado en la parte superior de la ventana principal de GNS3 y elegir Manual para que se asigne el tipo de enlace automáticamente. Las diferentes opciones de enlaces disponibles se pueden ver en la Figura Figura 5.22 Tipos de enlaces disponibles para interconectar dispositivos 122

139 2) Hacer clic sobre el dispositivo que se va a conectar. Como ajemplo, asumiendo que los dispositivos a interconectar son dos routers, al hacer clic sobre el ícono correspondiente a uno de ellos, aparecerá un cuadro con todas las interfaces disponibles (indicador en rojo). Se elige una de ellas y se repite el proceso para el router del otro extremo del enlace. Ver figura Este proceso se puede repetir para todas las conexiones que se desee realizar. Figura 5.23 Interfaces disponibles en router 3) Cuando el enlace ha sido establecido, se debe hacer clic sobre el ícono para deshabilitar el proceso de creación de enlaces. - Usando un PC real En este caso usaremos la capacidad que tiene el simulador de poder conectar dispositivos reales a una topología simulada. Se debe arrastrar una nube hacia el área de construcción de topologías, asignarle a ésta cualquier adaptador real de red, detectado en el PC donde se encuentra el simulador, crear un enlace virtual que la conecte con el resto de la topología y finalmente otro físico entre el simulador y el PC externo. A continuación se describe el procedimiento en forma más detallada: 1) Hacer clic en la nube y arrastrarla hasta el área de construcción de topologías, tal como se muestra en la Figura

140 Figura 5.24 Ventana principal de GNS3 2) Hacer clic derecho sobre la nube y elegir configure para abrir una ventana de configuración. Figura 5.25 Selección de la opción Configure. 3) Hacer clic sobre el nombre de la nube, elegir la pestaña NIO Ethernet y hacer clic en la caja que esta inmediatamente debajo de Generic Ethernet NIO para observar todos los adaptadores de red reconocidos por el simulador. Seleccionar el que se quiere usar para conectar el dispositivo externo y añadirlo a la topología haciendo clic en Add. Finalmente aceptar los cambios con un clic en OK. Ver figura

141 Figura 5.26 Selección del adaptador de red 4) En el otro extremo del enlace (extremo externo), se debe configurar la dirección IP necesaria para la conexión. Si el equipo externo es un PC se requiere configurar una dirección IP en su adaptador de red que se va a usar. Por otro lado, si se trata de un router, se debe configurar la dirección IP desde la consola del equipo en la interfaz que se conectará al simulador. Se debe elegir direcciones IP que mantengan concordancia con la topología que se va a simular. 5) Realizar una conexión física entre el adaptador de red que ha sido elegido anteriormente en el simulador y el correspondiente al equipo externo. 6) Crear un enlace virtual, como se explico anteriormente, entre un router virtual y la nube creada Almacenamiento de la topología 125

142 GNS3 permite el almacenamiento de la topología y de la configuración efectuada en los routers emulados, en archivos diferentes; la topología se guarda en forma de texto en un archivo.net que es interpretado por Dynagen y mostrado gráficamente por GNS3, mientras que las configuraciones de los routers emulados se guardan en archivos.cfg, los cuales al ser abiertos con un editor de texto, muestran los comandos introducidos en el router de la misma forma que se pueden encontrar en un router real. El almacenamiento se realiza de la siguiente forma: 1) Al iniciar el programa GNS3 aparecerá una ventana como la mostrada en la figura En ella se debe habilitar el almacenamiento de las NVRAMs, de los archivos adicionales (logfiles y bootfiles) y de los archivos de configuración de todos los routers; además se requiere asignar un nombre al proyecto. Luego se hace clic en OK. Figura 5.27 Habilitación del almacenamiento. 2) Para completar la habilitación del almacenamiento se debe realizar en los routers de la topología corriente, el proceso de salvar las configuraciones realizadas. Para explicar el proceso se toma como ejemplo un router que ha sido 126

143 arrastrado al área de creación de topologías. Para darle un nombre al router se da clic derecho sobre el ícono correspondiente y se elige la opción Change the hostname. A continuación se escribe el nuevo nombre del dispositivo y se selecciona OK, en la ventana que se muestra en la Figura Figura 5.28 Ventana para el cambio de nombre de host 3) Para guardar los cambios de configuración realizados en el router se emplea el comando wr, el cual salva en la NVRAM los datos que se encuentran en la RAM. En la Figura 5.29 se puede observar los comandos mencionados. Figura 5.29 Comandos para guardar la configuración de routers 4) Al hacer clic sobre el ícono de la barra principal de GNS3 aparecerá una ventana como la de la Figura Allí se debe elegir Extracting to a directory para guardar los archivos de configuración de todos los routers existentes en la topología. Luego se hace clic en Ok, se busca la ubicación de la carpeta simulación_config y se acepta el destino. Figura 5.30 Ventana de almacenamiento configuraciones 127

144 Cabe resaltar que en la figura 5.30 existe la opción Importing from a directory la cual permite recuperar las configuraciones almacenadas de los routers, así como también, importar configuraciones de routers de otras topologías a la topología corriente siempre y cuando ambos routers tengan el mismo Hostname. 6) Seguidamente se puede comprobar que en la carpeta simulación_config se ha creado un archivo llamado Barcelona.cfg (para el ejemplo), que contiene la configuración del router. No olvidar escribir el comando wr antes de volver a extraer la configuración. 7) Para guardar la topología corriente, las conexiones y el escenario se debe dar clic en File y elegir Save, tal como se ve en la figura Figura 5.31 Opciones de archivos 128

145 5.2.2 SIMULACIONES Durante el desarrollo de este proyecto se simularon los distintos protocolos de enrutamiento, así como las diversas técnicas de transición para diferentes tipos de topologías. El objetivo de la simulación en cada caso fue la verificación del funcionamiento de los protocolos y las estrategias de transición y convivencia, lo cual se realizó de la siguiente manera: 1. En primera instancia se realizó el diseño de una topología específica para cada uno de los esceneraios de acuerdo con el tipo de estrategia y de protocolo que se simulara. 2. Para cada topología se realizó un esquema de direccionamiento y enrutamiento adecuado para la simulación, usando segmentos IPv4 e IPv6 según la necesidad. 3. En cada caso se configuraron los enrutadores usando los comandos propios de los sistemas operativos de routers cisco. 4. Posteriormente se verificó la comunicación extremo a extremo por medio del envío y recepción de mensajes ICMP usando la herramienta PING (Packet Internet Groper), la cual va a permitir diagnosticar el estado, velocidad y calidad de una red. 5. Finalmente se realizaron pruebas usando la herramienta TRACERT para verificar los saltos que realiza cada paquete de un extremo a otro. Para cada escenario se explica, en los numerales a continuación, el protocolo de enrutamiento y cada técnica de transición expresando sus características y su completo funcionamiento, luego se expone la topología de red para su simulación e implementación a nivel de laboratorio. A continuación de este proceso se muestra la forma en que debe ser programado cada componente de red, mostrando paso a paso la configuración necesaria para 129

146 completar y llevar a cabo el protocolo de enrutamiento o la técnica de transición que se esté implementando (scripts de configuración). Como resultado de las simulaciones se constató que todas ellas fueron exitosas, lo cual significa que al enviar los paquetes ICMP mediante el uso del PING, la máquina destino envía una confirmación de la recepción de los paquetes con tiempos de respuesta y porcentajes de pérdida óptimos. Dado que todas las pruebas fueron similares, los resultados fueron exitosos, y la respuesta (tanto en el simulador como en el ambiente real) es prácticamente igual en cada caso (con excepción de las direcciones IP de la máquina origen y de la máquina destino) se obvió incluir en cada caso la impresión de la pantalla del resultado. No obstante se presenta a continuación el resultado de una de ellas. La sintaxis utilizada para el comando Ping es la siguiente: En Windows: C:\> ping <dirección IP> En un router Cisco llamado R1: R1# ping <dirección IP> 130

147 Cuando es exitosa una prueba la cantidad de paquetes enviados es la misma cantidad que los recibidos. Esta prueba certifica que existe comunicacion entre los nodos examinados. En cuanto a las pruebas realizadas con el TRACERT los resultados obtenidos fueron igualmente exitosos. En cada caso se observaron los saltos realizados por los paquetes entre los dos extremos. A continuación se muestra el comando usado y el resultado logrado. En un router Cisco llamado R1: R1# traceroute <dirección IP > TRACERT es una herramienta que permite visualizar el número de saltos que debe realizar un paquete, hasta llegar a su destino final. Cada salto representa un router por el cual se pasa para acceder al destino final. 131

148 5.3 ENRUTAMIENTO IPv Consideraciones generales IPv4 e IPv6 son protocolos de la Capa de Red, de manera que ésta es la única capa directamente afectada por la implementación de IPv6 y por lo tanto no se tendría necesidad de modificar el funcionamiento de las demás. Sin embargo, es necesario comprender que se trata de dos Capas de Red distintas e independientes. Esto implica algunas consideraciones importantes: Cómo actuar en lo relacionado con la planificación y la estructuración de las redes: Migrar toda la estructura a doble pila; migrar solo las áreas críticas; mantener dos estructuras diferentes, una IPv4 y otra IPv6; etc. En las redes con doble pila, algunas configuraciones deben ser duplicadas, como por ejemplo la correspondiente al DNS, al firewall y a los protocolos de enrutamiento. Para el soporte y resolución de problemas será necesario determinar si las fallas se encuentran en la conexión de la red IPv4 o de la red IPv6; Los nuevos equipos y aplicaciones deben soportar las funcionalidades de los dos protocolos. La Capa de Red está asociada principalmente a dos características: Identificación Debe garantizar que cada dispositivo de la red sea identificado de manera unívoca, sin posibilidad de error. En otras palabras, la 132

149 dirección IP debe ser única a nivel mundial. Utilizando el comando host en las plataformas UNIX, o nslookup en las plataformas Windows, se puede por ejemplo, verificar la identificación de un servicio. En las redes con doble pila los nodos se identifican por las dos direcciones. Localización Indica cómo llegar al destino, decidiendo el encaminamiento de los paquetes con base en el direccionamiento; ocurre de la misma manera tanto en IPv4 como en IPv6. Podemos verificar esta funcionalidad utilizando comandos como mtr -4 y -6, o traceroute (traceroute6), o tracert (tracert6). Estos comandos muestran la identificación y la localización de un nodo. La unión de estas dos características en la Capa de Red resulta en una semántica sobrecargada. Esto se evidencia en aspectos tales como la agregación de rutas, agravando el problema del crecimiento de la tabla de enrutamiento global. Una forma de impedir esto consiste en separar las funciones de localización e identificación. Existe un grupo de trabajo en la IETF que está discutiendo una forma de separar esas dos funciones (identificación y localización). LISP (Locator/Identifier Separation Protocol) es un protocolo sencillo que busca separar las direcciones IP en Endpoint Identifiers (EIDs) y Routing Locators (RLOCs). Esto no exige ningún cambio en las pilas de los host ni grandes cambios en la infraestructura existente, pudiendo ser implementado en un número relativamente pequeño de routers. Sus principales elementos son los siguientes: Endpoint ID (EID): Un identificador de 32 bits (para IPv4) o 128 bits (para IPv6) que se utiliza en los campos de dirección de origen y de destino del primer encabezado (más interno) de un paquete. El host obtiene un EID de destino de la misma manera en que hoy obtiene una dirección de destino, por ejemplo a 133

150 través de una consulta de DNS. El EID de origen también se obtiene a través de los mecanismos ya existentes usados para definir la dirección local de un host. Routing Locator (RLOC): Dirección IPv4 o IPv6 de un ETR (Egress Tunnel Router). Los RLOC se numeran a partir de un bloque topológicamente agregado y son atribuidos a una red en cada punto en que hay conexión a la Internet global Ingress Tunnel Router (ITR): Router de entrada del túnel que recibe un paquete IP (más precisamente, un paquete IP que no contiene un encabezado LISP). Este trata la dirección de destino de ese paquete como un EID y realiza un mapeo entre el EID y el RLOC. A continuación el ITR agrega un encabezado IP externa que contiene uno de sus RLOC globalmente enrutables en el campo de dirección de origen y un RLOC resultado del mapeo en el campo de dirección de destino. Egress Tunnel Router (ETR): Router de salida del túnel que recibe un paquete IP donde la dirección de destino del encabezado, IP externa, es uno de sus RLOC. El router retira el encabezado externo y encamina el paquete con base en el siguiente encabezado IP encontrado. La definición del prefijo IP es una definición importante. El recurso que asigna el Registro.co a los AS es un bloque IP que representa un grupo de direcciones IP. Un bloque no es un elemento enrutable; lo que es enrutable es el prefijo. Lo que sí es posible, por ejemplo, es crear un prefijo IPv6 /32 igual al bloque /32 recibido del Registro.co y anunciar dicho prefijo en la tabla de rutas. Pero a partir del bloque recibido también se pueden crear prefijos /33, /34, /48 etc. El prefijo representa el número de bits de una dirección que identifica la red. A pesar de ser solo una nomenclatura, esta definición es importante a la hora de 134

151 enviar información para activar sesiones de tránsito con otros operadores y en la detección de problemas de conectividad Cómo funciona el router? También es importante comprender el funcionamiento básico de un router y saber de qué manera procesa los paquetes recibidos y toma las decisiones de encaminamiento. Consideremos el siguiente ejemplo: El router recibe una trama Ethernet a través de su interfaz de red y verifica la información del Ethertype que indica que el protocolo de capa superior transportado es IPv6. Se procesa el encabezado IPv6 y se analiza la dirección de destino. El router busca en la tabla de enrutamiento unicast (RIB - Router Information Base) si existe alguna entrada para la red de destino. Visualización de la RIB IPv6: Cisco/Quagga show ipv6 route Juniper show route table inet6 Visualización de la RIB IPv4: Cisco/Quagga show ip route Juniper show route Longest Match - Busca la entrada más específica. Ejemplo: La IP de destino es 2001:0DB8:0010:0010::0010 y el router tiene la siguiente información en su tabla de rutas: o 2001:DB8::/32 vía interfaz A o 2001:DB8::/40 vía interfaz B o 2001:DB8:10::/48 vía interfaz C Los tres prefijos engloban la dirección de destino, pero el router siempre preferirá el más específico, en este caso el /

152 Una vez identificado el prefijo más específico, el router decrementa el Hop- Limit, arma la trama Ethernet de acuerdo con la interfaz y envía el paquete. Los valores de esta tabla son números enteros comprendidos entre 0 y 255 asociados a cada ruta; cuanto menor es su valor más confiable es la ruta; Los valores se asignan evaluando si la ruta está conectada directamente, si fue aprendida a través del protocolo de enrutamiento externo o interno, etc. Estos valores solo tienen significado local, no pueden ser anunciados por los protocolos de enrutamiento y, si fuera necesario, pueden ser modificados para priorizar un determinado protocolo. En caso que en la tabla de preferencias también se encuentre el mismo valor, hay equipos e implementaciones que por defecto realizan el balanceo de carga Tabla de enrutamiento El proceso de selección de rutas es idéntico en IPv4 e IPv6, pero las tablas de rutas son independientes. Por lo tanto existe una RIB (Router Information Base) para IPv4 y otra para IPv6. Para optimizar el envío de paquetes hay mecanismos que agregan solo las mejoras rutas a otra tabla, la tabla de encaminamiento (FIB - Forwarding Information Base). Un ejemplo de este mecanismo es el CEF (Cisco Express Forwarding) de Cisco. La FIB se crea a partir de la RIB y al igual que la RIB también está duplicada si la red está configurada con doble pila. Es así que hay más información para almacenar y procesar. En los routers que tienen arquitectura distribuida el proceso de selección de rutas y el encaminamiento de los paquetes son funciones diferentes. 136

153 Ejemplo: Routers 7600 de Cisco: La RIB reside en el módulo de enrutamiento central y la FIB en las placas de las interfaces. Routers Juniper de la serie M: El Router Engine es responsable por la RIB, mientras que la FIB también reside en las placas de las interfaces (Packet Forwarding Engine - PFE). El mecanismo de enrutamiento es el que permite el encaminamiento de paquetes de datos entre dos dispositivos cualquiera conectados a Internet. Para actualizar la información que utilizan los routers para encontrar el mejor camino disponible en el encaminamiento de los paquetes hasta su destino, se utilizan los protocolos de enrutamiento. Son las informaciones recibidas por los protocolos de enrutamiento las que "alimentan" la RIB, la cual a su vez "alimenta la FIB. Estos protocolos se dividen en dos grupos: Protocolos de Gateway Interno (IGP: Interior Gateway Protocol) - Protocolos que distribuyen la información de los routers dentro de los Sistemas Autónomos. Dentro de estos protocolos se puede mencionar como ejemplo: OSPF, IS-IS y RIP. Protocolos de Gateway Externo (EGP: Exterior Gateway Protocol) - Protocolos que distribuyen la información entre Sistemas Autónomos. Como ejemplo se puede mencionar el protocolo BGP-4. Si el router recibe un paquete cuya dirección de destino no esté explícitamente listada en la tabla de rutas, éste utilizará su ruta por defecto. 137

154 Naturalmente, los servidores y estaciones de trabajo necesitan una ruta por defecto. Estos dispositivos no son equipos de red; solo conocen las redes directamente conectadas a sus interfaces. Para llegar a un destino que no esté directamente conectado deberán usar la ruta por defecto Ruta por defecto Entre los operadores existe un concepto que delimita una región de Internet sin ruta por defecto, la DFZ (Default Free Zone). Un AS (Sistema Autónomo) que tiene la tabla completa no necesita tener ruta por defecto, ya que la tabla completa muestra las entradas de red de todo el mundo. Este modelo es bueno y funcional, pero puede acarrear algunos problemas. Los routers deben procesar información del mundo entero en tiempo real; también pueden surgir problemas de escalabilidad futura. El uso de una ruta por defecto por parte de los routers que tienen tabla completa puede ocasionar algunos problemas. Como ejemplo, imagine la siguiente situación: una red ha sido comprometida por un malware. La máquina contaminada barrerá Internet intentando contaminar otras máquinas, incluso IPs que no están asignadas y que no están en la tabla completa; Si hay ruta por defecto, su router va a encaminar ese tráfico no válido hacia adelante; Este es uno de los motivos para utilizar DFZ. Una sugerencia para solucionar este problema es crear una ruta por defecto y apuntar hacia Null0 o DevNull. También hay que deshabilitar el envío de mensajes 'ICMP unreachable': ya que cuando un router descarta un paquete envía un mensaje 'ICMP unreachable' pero si el destino no es válido no es necesario avisar al origen, esto solo consumirá CPU innecesariamente. 138

155 La ruta por defecto en IPv4 es /0 y en IPv6 es ::/ Enrutamiento Estático El enrutamiento estático parte de una configuración manual realizada por el administrador, siendo éste el que decide cuál va a ser la ruta más adecuada para los paquetes de datos de acuerdo con la topología y con las características de la red. Esta ruta va a permanecer inalterable durante el proceso de enrutamiento hasta que el administrador la vuelva a cambiar de una manera manual. Generalmente se utiliza este tipo de enrutamiento cuando se tiene un alto conocimiento de la red y cuando la misma no es muy compleja. El administrador de la red debe llenar manualmente la tabla de enrutamiento del enrutador, siendo ésta la base del enrutamiento estático. Hay que destacar que si hay cambios en la red, es el administrador quien debe hacer los cambios en las rutas, ya que en este caso los enrutadores no toman decisiones, también hay que destacar que mientras más grande y compleja sea la red, más tiempo de administración va a requerir Configuración de enrutamiento estático IPv6 Antes de configurar el router con una ruta IPv6 estática es necesario habilitar el reenvió de paquetes IPv6 utilizando el comando IPv6 unicast-routing en el router desde la configuración global. Router> enable Router# Conmfigure terminal Router(config)# ipv6 unicast-routing 139

156 Existen diferentes formas de configurar una ruta estática, entre las cuales se encuentran: - Rutas estáticas directamente conectadas En las rutas directamente conectadas, solo se especifica la interfaz de salida. El destino se supone que es conectado directamente a esta interfaz, por lo que el destino del paquete se utiliza como la dirección del siguiente salto. Ejemplo: Ipv6 route 2001:db8::/32 ethernet1/0 En el ejemplo se especifica que todos los destinos con prefijo de la dirección 2001:db8::/32 son directamente accesibles a través de la interfaz Ethernet 1/0. - Rutas estáticas recursivas En la ruta estática recursiva, solo se especifica el siguiente salto. La interfaz de salida se deriva del siguiente salto. Ejemplo: Ipv6 route 2001:db8::/ :db8:3000:1 Este ejemplo especifica que todos los destinos con prefijo 2001:DB8::/32 son accesibles a través del host con dirección 200:DB8:3000:1. Una ruta estática recursiva es válida sólo cuando se resuelve el siguiente salto especificado, ya sea directa o indirectamente, a una interfaz de salida de IPv6 válida, siempre que la ruta no se auto-redirija. - Rutas estáticas completamente especificadas 140

157 En una ruta estática completamente especificada, se define tanto la interfaz de salida como el siguiente salto. Esta forma de ruta estática se utiliza cuando la interfaz es un acceso multi-uno y es necesario identificar explícitamente el siguiente salto. El siguiente salto debe estar directamente conectado a la interfaz de salida especificada. Ejemplo: Ipv6 route 2001:db8::/32 ethernet 1/0 2001:db8:3000::1 - Rutas estáticas flotantes Son rutas estáticas que se utilizan para copias de seguridad de las rutas dinámicas a través de los protocolos de enrutamiento. Una ruta estática flotante se configura con una mayor distancia administrativa que el enrutamiento dinámico. Como resultado, las rutas dinámicas aprendidas a través del protocolo de enrutamiento siempre tienen preferencia. Por lo tanto las rutas flotantes son utilizadas únicamente cuando las rutas dinámicas se pierdan. Ejemplo: Ipv6 route 2001:db8:/32 ethernet 1/0 2001:db8:3000:1 210 Topología básica para Enrutamiento Estático En la Figura 5.32 se presenta la topología propuesta para la simulación de este esrutamiento y a continuación se describe la configuración de cada router. 141

158 Figura 5.32 Enrutamiento estático IPv4 Ipv6 ENRUTAMIENTO ESTATICO IPV4 - IPV6 ROUTER 1 Router>enable!Ingresa al modo EXEC Privilegiado Router#configure terminal!configura la terminal manualmente desde la terminal de consola Router(config)#ipv6 unicast-routing!habilita el ruteo para IPv6 Router(config)#interface fastethernet0/0!entra al modo de configuración de la interfaz 142

159 Router(config-if)#ip address !Asigna una dirección y una mascara de subred IPv4 Router(config-if)#ipv6 enable!habilita IPv6 en la interfaz y genera automaticamente la direccion link-local con EUI-64 Router(config-if)#ipv6 address 2001:db8:1::1/64!Asigna una dirección IPv6 a la interfaz. Router(config-if)#no shutdown Router(config-if)#exit!Inicia la interfaz desactivada!regresa al modo anterior Router(config)#interface fastethernet0/1!entra al modo de configuración de la interfaz Router(config-if)#ip address !Asigna una dirección y una mascara de sub-red IPv4 Router(config-if)#ipv6 enable!habilita IPv6 en la interfaz y genera 143

160 automaticamnte la direccion link-local con EUI-64 Router(config-if)#ipv6 address 2001:db8:2::1/64!Asigna una dirección IPv6 a la interfaz Router(config-if)#no shutdown Router(config-if)#exit!Inicia la interfaz desactivada!regresa al modo anterior Router(config)#ip route !Se configura la ruta y el siguiente salto Router(config)#ip route Router(config)#ipv6 route 2001:db8:3::/ :db8:2::2!Se configura la ruta y el siguiente salto Router(config)#ipv6 route 2001:db8:4::/ :db8:2::2!Se configura la ruta y el siguiente salto 144

161 ROUTER 2 Router>enable Router#configure terminal Router(config)#ipv6 unicast-routing Router(config)#interface fastethernet0/0 Router(config-if)#ip address Router(config-if)#ipv6 enable Router(config-if)#ipv6 address 2001:db8:2::2/64 Router(config-if)#no shutdown Router(config-if)#exit Router(config)#interface fastethernet0/1 Router(config-if)#ip address Router(config-if)#ipv6 enable Router(config-if)#ipv6 address 2001:db8:3::1/64 Router(config-if)#no shutdown Router(config-if)#exit Router(config)#ip route Router(config)#ip route Router(config)#ipv6 route 2001:db8:1::/ :db8:2::1 Router(config)#ipv6 route 2001:db8:4::/ :db8:3::2 ROUTER 3 145

162 Router>enable Router#configure terminal Router(config)#ipv6 unicast-routing Router(config)#interface fastethernet0/0 Router(config-if)#ip address Router(config-if)#ipv6 enable Router(config-if)#ipv6 address 2001:db8:4::1/64 Router(config-if)#no shutdown Router(config-if)#exit Router(config)#interface fastethernet0/1 Router(config-if)#ip address Router(config-if)#ipv6 enable Router(config-if)#ipv6 address 2001:db8:3::2/64 Router(config-if)#no shutdown Router(config-if)#exit Router(config)#ip route Router(config)#ip route Router(config)#ipv6 route 2001:db8:1::/ :db8:3::1 Router(config)#ipv6 route 2001:db8:4::/ :db8:3::1 Para la verificación de las rutas estáticas y su operación se utiliza el siguiente comando: Router# show ipv6 static 146

163 5.3.6 Protocolos de Enrutamiento Interno Hoy en día hay dos opciones principales para trabajar con enrutamiento interno, OSPF (Open Shortest Path First) e IS-IS (Intermediate System To Intermediate System). Estos dos protocolos son de tipo Link-State, es decir, consideran la información de estado del enlace y envían actualizaciones en forma optimizada solo cuando se producen cambios de estado en los enlaces. También permiten trabajar con estructura jerárquica separando la red por regiones. Esto es un punto fundamental para IPv6. Otra opción es el protocolo RIP (Routing Information Protocol). Éste es un protocolo de tipo Vector de Distancia (Bellman-Ford), de fácil implementación y de funcionamiento sencillo, pero presenta algunas limitaciones como el hecho de enviar su tabla de estados periódicamente sin importar si hay o no cambios en la red. Es importante que el protocolo de enrutamiento interno se habilite solamente en las interfaces donde sea necesario. Aunque parezca obvio, hay quienes lo configuran equivocadamente haciendo que los routers queden intentando establecer relaciones de vecindad con otros AS (Autonomous System) RIPng Para tratar el enrutamiento interno IPv6 se definió una nueva versión del protocolo RIP, el Routing Information Protocol next generation (RIPng). Esta versión se basa en el protocolo RIPv2 que se utiliza en las redes IPv4, pero es específica para redes IPv6. Entre los principales cambios se destacan los siguientes: Soporte para el nuevo formato de direcciones; Utiliza la dirección multicast FF02::9 (All RIP Routers) como destino; 147

164 La dirección del salto siguiente debe ser una dirección link local. En un ambiente con doble pila (IPv4+IPv6) es necesario utilizar una instancia de RIP para IPv4 y una de RIPng para el enrutamiento IPv6. A pesar de ser nuevo, el protocolo RIPng todavía tiene las mismas limitaciones que las versiones anteriores utilizadas con IPv4, entre ellas: El diámetro máximo de la red es de 15 saltos; Para determinar el mejor camino utiliza solamente la distancia; Loops de enrutamiento y conteo al infinito. La tabla de rutas contiene la siguiente información: Prefijo de destino Métrica Siguiente salto Identificación de la ruta (route tag) Cambio de ruta Tiempo hasta que la ruta expira (por defecto 180 segundos) Tiempo hasta el garbage collection (por defecto 120 segundos) Las tablas de rutas se pueden actualizar de tres maneras diferentes: a través del envío automático de datos cada 30 segundos, cuando se detecta algún cambio en la topología de la red enviando solo la línea afectada por el cambio y cuando se recibe un mensaje de tipo Request (solicitud). El encabezado de los mensajes RIPng es muy sencillo (Ver Figura 5.33) y está formado por los siguientes campos: 148

165 Figura 5.33 Cabecera RIPng Fuente: h2c.com Comando (command) Indica si el mensaje es de tipo Request o Response; Versión (version) Indica la versión del protocolo que actualmente es 1. Estos campos van seguidos por las entradas de la tabla de rutas (Route Table Entry RTE) que contienen la siguiente información: Prefijo IPv6 (128 bits); Identificación de la ruta (16 bits); Tamaño del prefijo (8 bits); Métrica (8 bits). A diferencia de lo que ocurre en RIPv2, la dirección del siguiente salto aparece solo una vez, seguida por todas las entradas que deben utilizarla Configuración RIPng Antes de configurar el router para ejecutar RIP IPv6, es necesario habilitar el enrutamiento IPv6 con el comando ipv6 unicast-routing en el modo de 149

166 configuración global y habilitar el proceso en cada router como se muestra a continuación: Router>enable Router#configure terminal Router(config)# ipv6 unicast-routing Router(config)# ipv6 router rip nombredeproceso Para permitir un proceso de enrutamiento RIP IPv6 en una interfaz es necesario introducir el siguiente comando en la interfaz donde será habilitado el proceso: Router(config-if)# ipv6 rip nombredeproceso enable Donde Proceso puede ser cualquier nombre que se le quiera dar. En la figura 5.34 se muestra la topología propuesta para la simulación del enrutameinto con el protocolo RIP. A continuación se incluye la correspondiente configuración de cada router. Figura: 5.34 RIPng 150

167 CONFIGURACION RIPng ROUTER 1 Router>enable Router#configure terminal Router(config)#ipv6 unicast-routing Router(config)#ipv6 router rip RIC Router(config-rtr)#exit Router(config)#interface fastethernet0/0 Router(config-if)#ipv6 enable Router(config-if)#ipv6 rip RIC enable Router(config-if)#ipv6 address 2001:1:1:1::1/64 Router(config-if)#no shutdown Router(config-if)#exit Router(config)#interface serial1/0 Router(config-if)#ipv6 enable Router(config-if)#ipv6 rip RIC enable Router(config-if)#ipv6 address 2001:4:4:4::1/64 Router(config-if)#clock rate Router(config-if)#no shutdown Router(config-if)#exit 151

168 ROUTER 2 Router>enable Router#configure terminal Router(config)#ipv6 unicast-routing Router(config)#ipv6 router rip RIC Router(config)#exit Router(config)#interface fastethernet0/0 Router(config-if)#ipv6 enable Router(config-if)#ipv6 rip RIC enable Router(config-if)#ipv6 address 2001:300:300:300::1/64 Router(config-if)#no shutdown Router(config-if)#exit Router(config)#interface serial1/0 Router(config-if)#ipv6 enable Router(config-if)#ipv6 rip RIC enable Router(config-if)#ipv6 address 2001:4:4:4::2/64 Router(config-if)#clock rate Router(config-if)#no shutdown Router(config-if)#exit Para verificar la configuración y operación de RIP para IPv6, se utilizan los siguientes comandos: Para ver la información sobre los actuales procesos de RIP IPv6: 152

169 Router#show ipv6 rip nombredeproceso database Para mostrar el contenido actual de la tabla de enrutamiento: Router#show ipv6 route rip OSPFv3 (Open Shortest Path First Version 3) OSPF es un protocolo de tipo link-state mediante el cual, a través del proceso de flooding (inundación), los routers envían anuncios de estado del enlace (LSA: Link State Advertisements) describiendo su estado actual a lo largo del AS (Sistema Autónomo). El flooding consiste en el envío de un LSA por todas las interfaces de salida del router, de modo que todos los routers que reciben un LSA también lo envían por todas sus interfaces. De este modo, el conjunto de los LSAs de todos los routers forma una base de datos del estado de los enlaces. Cada router que participa del AS tiene una base de datos idéntica. Con la información de esta base de datos, el router, a través del protocolo OSPF, construye un mapa de la red que será utilizado para determinar un árbol de caminos más cortos dentro de toda la subred, teniendo al propio nodo como raíz. Utiliza el algoritmo de Dijkstra para escoger el mejor camino y permite agrupar los routers en áreas. OSPF se puede configurar para trabajar de forma jerárquica, dividiendo los routers de un AS en diferentes áreas (ver Figura 5.35). A cada una de estas áreas se atribuye un identificador único (Área-ID) de 32 bits y todos los routers de una misma área mantienen una base de datos de estado separada, de modo que la topología de un área se desconoce fuera de la misma, reduciendo así la cantidad de tráfico de enrutamiento entre las partes del AS. El área backbone es la responsable de distribuir la información de enrutamiento entre las áreas nonbackbone y se identifica mediante el ID 0 (ó ). En los AS en los cuales no hay esta división, generalmente el área backbone es la única que se configura. 153

170 A pesar de que está basado en la versión de OSPFv2 que se utiliza en las redes IPv4, OSPFv3 es un protocolo específico para IPv6. Por lo tanto, en las redes con doble pila es necesario utilizar OSPFv2 para realizar el enrutamiento IPv4 y OSPFv3 para realizar el enrutamiento IPv6. Figura 5.35 Diagrama OPSFv3 Fuente: ipv6.br Los routers OSPF se pueden clasificar de la siguiente manera: Internal Router (IR) Routers que solo se relacionan con vecinos OSPF de una misma área. Area Border Router (ABR) Routers que conectan una o más áreas al backbone. Estos poseen múltiples copias de las bases de datos de estado, una para cada área y son responsables de condensar la información de estas áreas y enviarla al backbone. Backbone Router (BR) Routers que pertenecen al área backbone. Un ABR es siempre un BR, ya que todas sus áreas están directamente conectadas al 154

171 backbone o conectadas vía un virtual link - túnel que conecta un área al backbone pasando a través de otra área Autonomous System Border Router (ASBR) Routers que intercambian información de enrutamiento con routers de otro AS y distribuyen las rutas recibidas dentro su propio AS. OSPFv3 todavía incluye algunas características de OSPFv2 como las siguientes: Tipos básicos de paquetes: Hello, DBD, LSR, LSU, LSA. Mecanismos para descubrimiento de vecinos y formación de adyacencias. Tipos de interfaces: point-to-point, broadcast, NBMA, point-to-multipoint y enlaces virtuales. Lista de estados y eventos de las interfaces. Algoritmo de selección del Designated Router y del Backup Designated Router. Envío y edad de las LSAs. AREA_ID y ROUTER_ID continúan siendo de 32 bits. Entre las principales diferencias entre OSPFv2 y OSPFv3 se destacan las siguientes: OSPFv3 funciona por enlace y no por subred. Se eliminó la información de direccionamiento Se agregó limitación de alcance para flooding Soporte explícito para múltiples instancias en cada enlace Uso de direcciones link-local Cambios en la autenticación Cambios en el formato del paquete Cambios en el formato del encabezado LSA Tratamiento de tipos de LSA desconocidos 155

172 Soporte para áreas Stub/NSSA Identificación de vecinos mediante Router IDs Utiliza direcciones multicast (AllSPFRouters FF02::5 y AllDRouters FF02::6) Configuración OSPFV3 Antes de empezar a configurar OSPFv3 es necesario: Planificar y crear una estrategia de red para OSPFv3, definiendo la cantidad de áreas y backbone. Habilitar ipv6 unicast-routing Habilitar IPv6 en cada interfaz Figura 5.36 Topología para la simulación de OSPFv3 La figura 5.36 muestra la topología usada para la simulación del enrutamiento utilizando el protocolo OSPFv3. 156

173 El primer paso en la configuración básica es permitir el enrutamiento IPv6 unicast: R1(config)# ipv6 unicast-routing R1(config)# ipv6 cef R2(config)# ipv6 unicast-routing R2(config)# ipv6 cef R3(config)# ipv6 unicast-routing R3(config)# ipv6 cef A continuación se debe asignar direcciones IPv6 a las interfaces necesarias en cada router. R1(config-if)# interface serial 1/1 R1(config-if)# ipv6 address FEC0::13:1/112 R1(config-if)# no shutdown R1(config)# interface serial 1/0 R1(config-if)# ipv6 address FEC0::12:1/112 R1(config-if)# clockrate R1(config-if)# no shutdown R2(config)# interface serial 1/0 R2(config-if)# ipv6 address FEC0::12:2/112 R2(config-if)# no shutdown R2(config)# interface serial 1/1 R2(config-if)# ipv6 address FEC0::23:2/112 R2(config-if)# no shutdown R3(config)# interface serial 1/0 157

174 R3(config-if)# ipv6 address FEC0::13:3/112 R3(config-if)# clockrate R3(config-if)# no shutdown R3(config)# interface serial 1/1 R3(config-if)# ipv6 address FEC0::23:3/112 R3(config-if)# clockrate R3(config-if)# no shutdown Se deben crear las interfaces loopback necesarias, pues éstas simularán una red conectada directamente. R1(config)# interface loopback0 R1(config-if)# ipv6 address FEC0::1:1/112 R2(config)# interface loopback0 R2(config-if)# ipv6 address FEC0::2:1/112 R3(config)# interface loopback0 R3(config-if)# ipv6 address FEC0::3:1/112 Aunque OSPFv3 utiliza exclusivamente direcciones IPv6, todavía utiliza 32 bits para el ID del proceso para el router. Puesto que no existe ninguna dirección IPv4 en las interfaces, se definirá manualmente el ID del router. R1(config)# ipv6 router ospf 1 R1(config-rtr)# router id R2(config)# ipv6 router ospf 1 R2(config-rtr)# router id

175 R3(config)# ipv6 router ospf 1 R3(config-rtr)# router id A continuación se debe asignar las interfaces a las áreas de OSPF. R1(config)# interface loopback0 R1(config-if)# ipv6 ospf 1 area 1 R1(config-if)# interface serial0/0 R1(config-if)# ipv6 ospf 1 area 4 R1(config-if)# interface serial0/1 R1(config-if)# ipv6 ospf 1 area 4 R2(config)# interface loopback0 R2(config-if)# ipv6 ospf 1 area 2 R2(config-if)# interface serial0/0 R2(config-if)# ipv6 ospf 1 area 4 R2(config-if)# interface fastethernet 0/0 R2(config-if)# ipv6 ospf 1 area 4 R3(config)# interface loopback0 R3(config-if)# ipv6 ospf 1 area 3 R3(config-if)# interface serial0/0 R3(config-if)# ipv6 ospf 1 area 4 R3(config-if)# interface fastethernet 0/0 R3(config-if)# ipv6 ospf 1 area 4 159

176 Si todo está configurado correctamente, todos los routers deben tener accesibilidad completa a través de IPv6. Se puede inspeccionar la información de cada vecino con el siguiente comando: Router# ipv6 show ospf neighbor Del mismo modo, se puede inspeccionar la tabla de enrutamiento IPv6 para verificar que se han recibido todas las rutas OSPF: Router# route show ipv6 Para mostrar la información de enrutamiento OSPF en cada interface se usa el siguiente comando: Router# show ipv6 ospf interface Por último para obtener la información general sobre el proceso de enrutamiento OPSFv3 se utiliza: Router# show ipv6 ospf IS-IS (Intermediate System to Intermediate System) Al igual que OSFP, Intermediate System to Intermediate System (IS-IS) es un protocolo IGP de tipo link-state, que utiliza el algoritmo de Dijkistra para calcular las rutas. IS-IS fue originalmente desarrollado para funcionar sobre protocolos CLNS (Servicio No Orientado a Conexión), pero la versión Integrated IS-IS permite enrutar tanto paquetes de red IP como OSI. Para ello se utiliza un identificador de protocolo, el NLPID (Network Level Protocol ID) para informar qué protocolo de red está siendo utilizado. 160

177 Al igual que OSPF, IS-IS también permite trabajar la red de manera jerárquica, actuando con los routers en dos niveles, L1 (Stub) y L2 (Backbone), además de los routers que integran esas áreas, L2/L1. Para tratar el enrutamiento IPv6 no se definió una nueva versión del IS-IS sino que solo se agregaron nuevas funcionalidades a la versión ya existente. Se agregaron dos nuevas TLVs (Type-Length-Values): IPv6 Reachability (type 236) Transporta información de las redes accesibles IPv6 Interface Address (type 232) Indica las direcciones IP de la interfaz que está transmitiendo el paquete. También se agregó un nuevo identificador de la capa de red. IPv6 NLPID Su valor es 142. El proceso de establecimiento de vecindades no cambia Protocolo de enrutamiento externo En la actualidad el protocolo de enrutamiento externo por defecto es Border Gateway Protocol versión 4 (BGP-4). Se trata de un protocolo de tipo path vector, en el cual los routers BGP intercambian información de enrutamiento entre AS s vecinos diseñando un grafico de conectividad entre los mismos. 161

178 BGP (Border Gateway Protocol) BGP es un protocolo extremamente simple basado en sesiones TCP escuchando en el puerto 179. Para intercambiar información y mantener el estado de la conexión TCP se utilizan cuatro tipos de mensajes BGP: Open Enviado por los dos vecinos luego del establecimiento de la conexión TCP. Lleva la información necesaria para el establecimiento de la sesión BGP (ASN, versión de BGP, etc.) Update Usado para transferir la información de enrutamiento entre los vecinos BGP, la cual se utilizará para construir el grafo que describe la relación entre varios ASs Keepalive Se envían frecuentemente para evitar que la conexión TCP expire; Notification Se envía cuando se detecta un error, cerrando la conexión BGP inmediatamente después de su envío. Se puede establecer dos tipos de conexión BGP (ver Figura 5.37): externa (ebgp) conexión entre dos AS vecinos; interna (ibgp) conexión entre routers dentro de un mismo AS. Establecer el ibgp es muy importante para mantener una visión consistente de las rutas externas en todos los routers de un AS. 162

179 Figura 5.37 Ejemplo de topología BGP Fuente: ipv6.br El funcionamiento de BGP se puede representar mediante una Máquina de Estados Finitos. Para quienes no están familiarizados con el protocolo BGP, al verificarse que el estado de una conexión está Active o Established, se puede tener la falsa impresión de que la conexión está activa o establecida, pero en general, en BGP, cuando hay palabras representando el estado, significa que la sesión BGP todavía no está bien. La sesión estará efectivamente establecida cuando se observe el número de prefijos que se está recibiendo del vecino. Esos nombres representan estados intermedios de la sesión BGP. Identificar esos estados ayuda en el análisis y resolución de problemas. A pesar de que la RFC sobre BGP recomienda algunos puntos, el criterio de selección entre diferentes atributos BGP puede variar de implementación a implementación. Sin embargo, la mayor parte de las implementaciones sigue los mismos estándares. Los atributos BGP se pueden dividir en dos grandes categorías: 163

180 Bien conocidos (Well-known) Son atributos definidos en la especificación original del protocolo BGP. Estos se subdividen en otras dos categorías: Obligatorios (Mandatory) Siempre deben estar presentes en los mensajes tipo UPDATE y deben ser obligatoriamente reconocidos por todas las implementaciones del protocolo Discrecional (Discretionary) No deben obligatoriamente estar presentes en todos los mensajes UPDATE. Opcionales (Optional) No son obligatoriamente soportados por todas las implementaciones de BGP. Estos se subdividen en otras dos categorías: Transitivos (Transitive) Deben ser retransmitidos en los mensajes UPDATE No Transitivos (Non-transitive) No deben ser retransmitidos. La RFC sobre BGP contiene los siguientes atributos: ORIGIN Es bien conocido y obligatorio, Indica si el camino fue aprendido vía IGP o EGP AS_PATH - Es bien conocido y obligatorio. Indica el camino para llegar a un destino, listando los ASN por los cuales se debe pasar NEXT_HOP Es bien conocido y obligatorio. Indica la dirección IP de la interfaz del siguiente router MULTI_EXIT_DISC Es opcional y no transitivo. Indica a los vecinos BGP externos cuál es el mejor camino para una determinada ruta del propio AS, 164

181 influenciándolos, así como cuál camino se debe seguir en caso de que el AS posea diferentes puntos de entrada. LOCAL_PREF Es bien conocido y discrecional. Indica un camino de salida preferencial para una determinada ruta destinada a una red externa al AS. ATOMIC_AGGREGATE Es bien conocido y discrecional. Indica si caminos más específicos se agregaron en menos específicos. AGGREGATOR - Es opcional y transitivo. Indica el ASN del último router que formó una ruta agregada, seguido por su propio ASN y dirección IP. Al decidir la mejor ruta, los atributos se consideran si se conoce el camino, si hay conectividad, si es accesible o si está disponible el next hop (siguiente salto). Pero la forma de selección puede variar dependiendo de la implementación. Un atributo que vale la pena destacar es el atributo LOCAL_PREFERENCE. Éste es un atributo extremadamente poderoso para influenciar el tráfico de salida. Su valor es válido para todo el AS, siendo retransmitido solamente en las sesiones ibgp BGP Multiprotocolo Se definieron extensiones para BGP-4 con la intención de habilitarlo para que transporte información de enrutamiento de múltiples protocolos de Capa de Red tales como IPv6, IPX, L3VPN, etc. Para realizar el enrutamiento externo IPv6, es fundamental el soporte para MP-BGP, ya que no existe una versión específica de BGP para tratar esta tarea. 165

182 Para que BGP pueda trabajar con la información de enrutamiento de diversos protocolos se introdujeron dos nuevos atributos: Multiprotocol Reachable NLRI (MP_REACH_NLRI): Transporta el conjunto de destinos alcanzables junto con la información del next-hop Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI): Transporta el conjunto de destinos inalcanzables. Estos atributos son opcionales y no transitivos; en caso que un router BGP no soporte MBGP, debe ignorar esta información y no transferirla a sus vecinos. Estos atributos llevan la siguiente información: MP_REACH_NLRI Address Family Identifier (2 bytes) Identifica el protocolo de red a ser soportado Subsequent Address Family Identifier (1 byte) Identifica el protocolo de red a ser soportado Length of Next Hop Network Address (1 byte) Valor que expresa la longitud del campo Network Address of Next Hop, medida en bytes Network Address of Next Hop (variable) Contiene la dirección del siguiente salto Reserved (1 byte) Reservado Network Layer Reachability Information (variable) Lista la información de las rutas accesibles. MP_UNREACH_NLRI Address Family Identifier (2 bytes) Identifica el protocolo de red a ser soportado 166

183 Subsequent Address Family Identifier (1 byte) Identifica el protocolo de red a ser soportado Withdrawn Routes (variable) Lista la información de las rutas inaccesibles Tabla BGP La información sobre las rutas de Internet se encuentra en la tabla BGP. En los routers de borde, los cuales se ocupan de la comunicación entre ASs. Esta información se replica hacia la RIB y la FIB, IPv4 e IPv6. La tabla global IPv4 hoy tiene aproximadamente entradas. La tabla IPv6 tiene aproximadamente entradas. La duplicidad de esta información en las arquitecturas distribuidas implica la necesidad de contar con más espacio para almacenamiento, más memoria y más capacidad de procesamiento, tanto en el módulo central como en las placas de las interfaces. Esto también implica otro aspecto importante, la necesidad de establecer un plan de direccionamiento jerárquico para minimizar la tabla de rutas y optimizar el enrutamiento, evitando el anuncio de rutas innecesarias y desagregadas. Los AS también pueden controlar los anuncios que reciben de sus vecinos BGP. Por ejemplo, es posible limitar el tamaño de los prefijos recibidos entre /20 y /24 IPv4, y entre /32 y /48 IPv6. Sin embargo, se pueden anunciar hasta 31 prefijos IPv4 (considerando anuncios entre un /20 y un /24) y prefijos IPv6 (considerando anuncios entre un /32 y un /48), de este modo hay quienes también controlan la cantidad de prefijos que reciben de sus vecinos BGP a través de comandos como maximum-prefix (Cisco) 167

184 y maximumprefixes (Juniper). Prestar atención a este tema es muy importante en las redes IPv4, pero en las redes IPv6 es fundamental Configuración BGP BGP utiliza un ID (Identificador) para cada router BGP, permitiendo identificar a sus vecinos. El ID de cada router BGP tiene un valor de 32-bits que a menudo es representado por una dirección IPv4. Por defecto, el software IOS de Cisco establece el ID de router igual a la dirección IPv4 de la interfaz loopback en el router. Si no hay interfaz de bucle configurado en el router, el software elige la dirección IPv4 más alta configurada para una interfaz física del router. Al configurar BGP en un router que sólo está habilitado para IPv6 (el router no tiene una dirección IPv4), es necesario configurar manualmente el ID de router BGP. El ID de router BGP utiliza una sintaxis de la dirección IPv4 este debe ser único en el BGP del router. Para configurar un proceso de enrutamiento BGP y entrar en modo de configuración del router se utiliza el siguiente comando en el modo de congiguración global: Router(config)# router bgp numerodeproceso Después es necesario desactivar las direcciones IPv4 para el proceso de enrutamiento BGP definido en el paso anterior. Router(config-router)#no bgp default ipv4-unicast Para definir el ID del router se utiliza: Router(config-router)#bgp router-id direccion32bits 168

185 Por defecto, los vecinos que se definen mediante el comando remote-as solo pueden ser prefijos IPv4. Para el intercambio de otros tipos de prefijos como los prefijos IPv6, los vecinos deben ser activados en el modo de configuración address-family ipv6, como se muestra a continuación. Router(config-router)# neighbor direccionipv6 remote-as procesobgp Router(config-router)# address-family ipv6 Router(config-router-af)# neighbor direccionipv6 activate Figura 5.38: BGP Multiprotocolo En la Figura 5.38 puede verse la topología empleada para la simulación del enrutamiento con el protocolo BGP. A continuación se relacionan las configuraciones realizadas en cada router. Router 1 R1#ipv6 unicast-routing 169

186 R1#ipv6 cef R1(config)#interface Loopback0 R1(config-if)# ipv6 address FEC0::1:1/112 R1(config-if)# ipv6 ospf 1 area 0 R1(config)#interface Serial1/0 R1(config-if)# ipv6 enable R1(config-if)# ipv6 address FEC0::12:1/112 R1(config-if)# ipv6 ospf 1 area 0 R1(config-if)# clock rate R1(config-if)# no shutdown R1(config)#interface Serial1/1 R1(config-if)# ipv6 enable R1(config-if)# ipv6 address FEC0::13:1/112 R1(config-if)# ipv6 ospf 1 area 0 R1(config-if)# no shutdown R1(config)#router bgp 1 R1(config-router)# bgp router-id R1(config-router)# bgp log-neighbor-changes R1(config-router)# neighbor FEC0::2:1 remote-as 1 R1(config-router)# neighbor FEC0::2:1 update-source Loopback0 R1(config-router)# neighbor FEC0::3:1 remote-as 1 R1(config-router)# neighbor FEC0::3:1 update-source Loopback0 R1(config-router)# address-family ipv6 R1(config-router)# neighbor FEC0::2:1 activate R1(config-router)# neighbor FEC0::3:1 activate R1(config-router)# exit-address-family 170

187 R1(config)# ipv6 router ospf 1 R1(config-rtr)# router-id Router 2 R2#ipv6 unicast-routing R2#ipv6 cef R2(config)#interface Loopback0 R2(config-if)# ipv6 address FEC0::2:1/112 R2(config-if)# ipv6 ospf 1 area 0 R2(config)#interface Serial1/0 R2(config-if)# ipv6 enable R2(config-if)# ipv6 address FEC0::12:2/112 R2(config-if)# ipv6 ospf 1 area 0 R2(config-if)# no shutdown R2(config)#interface Serial1/1 R2(config-if)# ipv6 enable R2(config-if)# ipv6 address FEC0::23:2/112 R2(config-if)# ipv6 ospf 1 area 0 R2(config-if)# no shutdown R2(config)#router bgp 1 R2(config-router)# bgp router-id R2(config-router)# bgp log-neighbor-changes R2(config-router)# neighbor FEC0::1:1 remote-as 1 171

188 R2(config-router)# neighbor FEC0::1:1 update-source Loopback0 R2(config-router)# neighbor FEC0::3:1 remote-as 1 R2(config-router)# neighbor FEC0::3:1 update-source Loopback0 R2(config-router)# address-family ipv6 R2(config-router)# neighbor FEC0::1:1 activate R2(config-router)# neighbor FEC0::3:1 activate R2(config-router)# exit-address-family R2(config)# ipv6 router ospf 1 R2(config-rtr)# router-id Router 3 R3(config)# ipv6 unicast-routing R3(config)# ipv6 cef R3(config)# interface Loopback0 R3(config-if)# ipv6 address FEC0::3:1/112 R3(config-if)# ipv6 ospf 1 area 0 R3(config)# interface Serial1/0 R3(config-if)# ipv6 enable R3(config-if)# ipv6 address FEC0::13:3/112 R3(config-if)# ipv6 ospf 1 area 0 R3(config-if)# clock rate R3(config-if)# no shutdown R3(config)# interface Serial1/1 R3(config-if)# ipv6 enable R3(config-if)# ipv6 address FEC0::23:3/112 R3(config-if)# ipv6 ospf 1 area 0 172

189 R3(config-if)# clock rate R3(config-if)# no shutdown R3(config)# interface Serial1/2 R3(config-if)# ipv6 enable R3(config-if)# ipv6 address 2001:DB8:1:1::1/64 R3(config-if)# no shutdown R3(config)#router bgp 1 R3(config-router)# bgp router-id R3(config-router)# no bgp default ipv4-unicast R3(config-router)# bgp log-neighbor-changes R3(config-router)# neighbor 2001:DB8:1:1::2 remote-as 2 R3(config-router)# neighbor 2001:DB8:1:1::2 ebgp-multihop 8 R3(config-router)# neighbor FEC0::1:1 remote-as 1 R3(config-router)# neighbor FEC0::1:1 update-source Loopback0 R3(config-router)# neighbor FEC0::2:1 remote-as 1 R3(config-router)# neighbor FEC0::2:1 update-source Loopback0 R3(config-router)# address-family ipv6 R3(config-router)# neighbor 2001:DB8:1:1::2 activate R3(config-router)# neighbor FEC0::1:1 activate R3(config-router)# neighbor FEC0::1:1 next-hop-self R3(config-router)# neighbor FEC0::2:1 activate R3(config-router)# neighbor FEC0::2:1 next-hop-self R3(config-router)# exit-address-family R3(config)# ipv6 router ospf 1 R3(config-rtr)# router-id

190 Router4 R4(config)# ipv6 unicast-routing R4(config)# ipv6 cef R4(config)# interface Loopback2000 R4(config-if)# ipv6 address EFFE:DB8:1:1::1/64 R4(config)# interface Serial1/0 R4(config-if)# ipv6 enable R4(config-if)# ipv6 address 2001:DB8:1:1::2/64 R4(config-if)# ipv6 ospf 1 area 0 R4(config-if)# clock rate R4(config-if)# no shutdown R4(config)#router bgp 2 R4(config-router)# bgp router-id R4(config-router)# no bgp default ipv4-unicast R4(config-router)# bgp log-neighbor-changes R4(config-router)# neighbor 2001:DB8:1:1::1 remote-as 1 R4(config-router)# neighbor 2001:DB8:1:1::1 ebgp-multihop 8 R4(config-router)# address-family ipv6 R4(config-router)# neighbor 2001:DB8:1:1::1 activate R4(config-router)# network EFFE:DB8:1:1::/64 R4(config-router)# exit-address-family R4(config)#ipv6 route ::/0 serial 1/0 174

191 5.4 TRANSICIÓN Y COEXISTENCIA Para que la transición entre ambos protocolos se produzca de forma gradual y sin mayores impactos sobre el funcionamiento de las redes es necesario que exista un período de coexistencia entre los protocolos IPv4 e IPv6. Con el objetivo de facilitar el proceso de transición entre las dos versiones del Protocolo de Internet se han desarrollado algunas técnicas para que toda la base de redes instaladas sobre IPv4 se mantenga compatible con IPv6, ya que en este primer momento de coexistencia de los dos protocolos la compatibilidad es fundamental para el éxito de la transición a IPv6. Cada una de estas técnicas tiene características específicas y se puede utilizar individualmente o junto con otras técnicas para adecuarse a las necesidades de cada situación, ya sea una migración a IPv6 que se realiza paso a paso, comenzando por un único host o subred, o incluso toda una red corporativa. Estos mecanismos de transición se pueden clasificar en las siguientes categorías: Doble pila: Provee soporte a ambos protocolos en el mismo dispositivo; Tunelización: Permite el tráfico de paquetes IPv6 sobre estructuras de red IPv4; y Traducción: Permite la comunicación entre nodos que solo soportan IPv6 y nodos que solo soportan IPv4. Como el período de coexistencia de los dos protocolos puede durar indefinidamente, la implementación de métodos que permitan la interoperabilidad entre IPv4 e IPv6 garantizará una migración segura hacia el nuevo protocolo a través de la realización de pruebas que permitan conocer las opciones que ofrecen dichos mecanismos y además podrían evitar que en el futuro surjan "islas" de comunicación aisladas. 175

192 5.4.1 Doble Pila En esta fase inicial de implementación de IPv6 todavía no es aconsejable tener nodos que solamente soporten esta versión del protocolo IP, ya que muchos servicios y dispositivos de red continúan trabajando solamente sobre IPv4. Por este motivo, una posibilidad consiste en implementar el método conocido como doble pila. El uso de este método permite que los hosts y routers estén equipados con pilas para ambos protocolos y tengan la capacidad de enviar y recibir ambos tipos de paquetes, IPv4 e IPv6. Así, en la comunicación con un nodo IPv6 un nodo doble pila (o nodo IPv6/IPv4) se comportará como un nodo solo IPv6, mientras que en la comunicación con un nodo IPv4 se comportará como un nodo solo IPv4. La Figura 5.39 representa el concepto de doble pila. Figura 5.39 Concepto de la doble pila Fuente:lacnic.com Cada nodo IPv6/IPv4 se configura con ambas direcciones, utilizando mecanismos IPv4 (por ejemplo DHCP) para adquirir su dirección IPv4 y mecanismos del protocolo IPv6 (por ejemplo autoconfiguración y/o DHCPv6) para adquirir su dirección IPv6. 176

193 Este método de transición puede facilitar la gestión de la implementación de IPv6, ya que permite implementar IPv6 en forma gradual, configurando pequeñas secciones del entorno de red cada vez. Además, si en el futuro se dejara de utilizar IPv4, bastaría con deshabilitar la pila IPv4 de cada nodo. Al implementar la técnica de doble pila es necesario considerar algunos aspectos. Se debe analizar la necesidad de realizar cambios en la infraestructura de red, como por ejemplo la estructuración del servicio de DNS y la configuración de los protocolos de enrutamiento y los firewalls. Con respecto al DNS, es necesario que éste esté habilitado para resolver nombres y direcciones de ambos protocolos. En el caso de IPv6, es necesario que responda a consultas de registros tipo AAAA (quad-a), que almacenan direcciones en formato IPv6. En una red IPv6/IPv4 la configuración del enrutamiento IPv6 normalmente es independiente de la configuración del enrutamiento IPv4. Esto implica que si antes de la implementación de la pila doble la red solo utilizaba el protocolo de enrutamiento interno OSPFv2 (que solo soporta IPv4), será necesario migrar a un protocolo de enrutamiento que soporte tanto IPv6 como IPv4, como por ejemplo IS-IS, o forzar la ejecución de un IS-IS o OSPFv3 en paralelo con el OSPFv2. La forma en que se realiza el filtrado de paquetes que atraviesan la red puede depender de la plataforma que se esté usando Configuración Dual-Stack (Doble Pila) La Figura 5.40 muestra la topología usada para la simulación de la doble pila. 177

194 Figura 5.40 Topología Doble Pila (Dual Stack) A continuación se relacionan los comandos necesarios en cada uno de los routers de la topología propuesta: ROUTER 1 Router>enable Router#configure terminal Router(config)#router rip Router(config-router)#version 2 Router(config-router)#network Router(config-router)#exit Router(config)#ipv6 unicast-routing Router(config)#ipv6 router rip RIC Router(config)#exit Router(config)#interface fastethernet0/0 Router(config-if)#ip address

195 Router(config-if)#duplex auto Router(config-if)#speed auto Router(config-if)#ipv6 enable Router(config-if)#ipv6 rip RIC enable Router(config-if)#no shutdown Router(config-if)#exit Router(config)#interface fastethernet0/1 Router(config-if)#ip address Router(config-if)#duplex auto Router(config-if)#speed auto Router(config-if)#ipv6 enable Router(config-if)#ipv6 rip RIC enable Router(config-if)#ipv6 address 2001:1:1:1::1/64 Router(config-if)#no shutdown Router(config-if)#exit Router(config)#interface serial1/0 Router(config-if)#ip address Router(config-if)#ipv6 enable Router(config-if)#ipv6 rip RIC enable Router(config-if)#ipv6 address 2001:4:4:4::1/64 Router(config-if)#clock rate Router(config-if)#no shutdown Router(config-if)#exit 179

196 ROUTER 2 Router>enable Router#configure terminal Router(config)#router rip Router(config-router)#version 2 Router(config-router)#network Router(config-router)#exit Router(config)#ipv6 unicast-routing Router(config)#ipv6 router rip RIC Router(config)#exit Router(config)#interface fastethernet0/0 Router(config-if)#duplex auto Router(config-if)#speed auto Router(config-if)#ipv6 enable Router(config-if)#ipv6 rip RIC enable Router(config-if)#ipv6 address 2001:300:300:300::1/64 Router(config-if)#no shutdown Router(config-if)#exit Router(config)#interface fastethernet0/1 Router(config-if)#ip address Router(config-if)#duplex auto Router(config-if)#speed auto Router(config-if)#ipv6 enable Router(config-if)#ipv6 rip RIC enable Router(config-if)#ipv6 address 2001:2:2:2::1/64 180

197 Router(config-if)#no shutdown Router(config-if)#exit Router(config)#interface serial1/0 Router(config-if)#ip address Router(config-if)#ipv6 enable Router(config-if)#ipv6 rip RIC enable Router(config-if)#ipv6 address 2001:4:4:4::2/64 Router(config-if)#clock rate Router(config-if)#no shutdown Router(config-if)#exit Técnicas de tunelización La técnica de creación de túneles tunelización permite transmitir paquetes IPv6 a través de la infraestructura IPv4 existente sin necesidad de realizar ningún cambio en los mecanismos de enrutamiento, encapsulando el contenido del paquete IPv6 en un paquete IPv4. Estas técnicas, descritas en la RFC 4213, han sido las más utilizadas en la fase inicial del despliegue de IPv6 por ser fáciles de aplicar en entornos de prueba en los cuales las redes no están estructuradas para ofrecer tráfico IPv6 nativo. Hay diferentes técnicas de tunelización disponibles: Los escenarios en los que se pueden aplicar, las dificultades de implementación y la diferencia de rendimiento varían significativamente entre los diferentes modelos, por lo que es necesario realizar un análisis detallado de cada uno de ellos. Las principales técnicas de tunelización son las siguientes: 181

198 Túneles Estáticos Tunnel Broker 6to4 ISATAP Teredo GRE Tunnel Broker Descrita en la RFC 3053, esta técnica permite que hosts IPv6/IPv4 aislados en una red IPv4 accedan a redes IPv6. Su funcionamiento es bastante sencillo. Primero es necesario registrarse en un proveedor de acceso Tunnel Broker y descargar un software o script de configuración. La conexión del túnel se establece solicitando el servicio al Servidor Web del proveedor, quien luego de una autenticación verifica qué tipo de conexión está utilizando el cliente (IPv4 pública o NAT) y le asigna una dirección IPv6. A partir de ese momento el cliente puede acceder a cualquier host IPv6 en Internet Túnel Broker con Hurricane Electric Hurricane Electric es un proveedor de conectividad estructurante (backbone) a escala global, especializado en IPv6 que opera actualmente el backbone más grande de IPv6 en el mundo, medido por el número de redes conectadas. Procedimiento 1. Dirigirse al sitio de Hurricane Electric La figura 5.41 muestra la interfaz presentada por esta página web. Para crear un túnel es necesario registrarse (Click en "Register" para ir a la página de registro). 182

199 Figura 5.41 Pagina Hurricane Electric 2. En el formulario de registro, es necesario llenar los datos y selecciona el botón de "Register" como muestra la figura Figura 5.42 Registro en Hurricane Electric 3. Una vez se complete el registro se regresa a la página principal, donde aparecerá la opción de "Create Regular Tunnel" en el menú del lado izquierdo. Se debe seleccionar esta opción (ver registro completo y opción para crear el túnel en la figura 5.43). 183

200 Figura 5.43 Registro completado En la página de creación de un nuevo túnel, es necesario colocar la dirección IPv4 en el cuadro de texto disponible. Esta IP debe ser pública (En caso de que se quiera saber la dirección IP, la página la muestra en "You are viewing from"). En la misma página se debe selecciona el servidor de destino, el de Miami es una buena opción para alguien que está en Colombia (todos funcionan). La Figura 5.44 muestra esta selección. Para finalizar se hace clic en el botón de "Create Tunnel" que se encuentra al final de la página. Figura 5.44 Creación del Túnel 184

201 5. Ahora el nuevo túnel aparece en la página principal (en la figura 5.45 es el segundo túnel abajo). Se puede seleccionar para ver los detalles. Figura 5.45 Descripción del nuevo túnel creado 6. En la página de detalles se puede ver toda la información relacionada con el túnel para su configuración (Figura 5.46). Para saber específicamente como configurar el computador es necesario seleccionar la pestaña de "Example Configurations" Figura 5.46 Detalles del túnel creado 185

202 7. En "Example Configurations" se selecciona el sistema operativo para que se muestren los comandos necesarios para la configuración en el host. La imagen de la Figura 5.47 muestra la configuración para un equipo con Windows 7. Figura 5.47 Configuración del túnel en el Host Los comandos son los siguientes (Las direcciones depende de cada host): netsh interface teredo set state disabled netsh interface ipv6 add v6v4tunnel IP6Tunnel netsh interface ipv6 add address IP6Tunnel 2001:470:4:87f::2 netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:4:87f::1 Una vez realizada la configuración del túnel, puede empezarse a hacer uso de él realizando conexiones con páginas web IPv6. Problemas que pueden presentarse: Si el túnel no funciona puede ser por una de las siguientes razones: 186

203 1.- Uso de una dirección IP privada. El host configurado debe ser alcanzable desde Internet. Si se está detrás de un router casero lo más probable es que no se esté utilizando una dirección pública y esto puede ser el problema. 2.- Existencia de firewalls en la red. El tunnel broker encapsula paquetes IPv6 dentro de paquetes IPv4. Este tipo de paquetes podrían ser bloqueados por algunos firewalls de computadores personales. Es necesario permitir que el protocolo 41 pase por el firewall; una solución puede ser desactivar el firewall de Windows, temporalmente Tunel Broker con GoGo6 Este proveedor proporciona uno de los métodos más fáciles para implementar IPv6. Proceso: 1. Ir a la página gogonet.gogo6.com e ingresar en Sing Up si aun no se tiene una cuenta de usuario (ver figura 5.48). Figura 5.48: Pagina gogo6 2. Ingresar los datos solicitados y dar clic en Sing UP (Figura 5.49). 187

204 Figura 5.49: Registro Gogo6 3. El sistema envía un correo electrónico a quien se está registrando. Se debe verificar y seguir los pasos especificados en el (Figura 5.50). Figura 5.50: Invitación a verificar el mail 4. Con los datos del se debe crear el perfil con la información solicitada, como lo muestra la Figura

205 Figura 5.51: Creación del perfil 5. Descargar el archivo de setup como se muestra en la Figura Figura: 5.52 Descarga de archivo setup 6. Se debe descargar la aplicación que se ajuste al sistema operativo en el cual se va a instalar según se ve en la Figura

206 Figura: 5.53 Selección del sistema operativo 7. Instalar y abrir el acceso gogoc-gui, en el cual se debe dar click en conectar en cómo se muestra en la figura Figura: 5.54 Conexión al servidor Gogo6 190

207 Para saber si se está conectado con soporte IPv6 se recomienda entrar en la siguiente página: y comprobar la conexión como se muestra en la Figura Figura: 5.55 Prueba de conexión IPv Túnel 6to4 Definida en la RFC 3056, la técnica de tunelización automática 6to4 permite la interconexión punto-a-punto entre routers, subredes o computadoras IPv6 a través de la red IPv4, proporcionando una dirección IPv6 única que se forma a partir de direcciones IPv4 públicas. Este direccionamiento 6to4 utiliza el prefijo de dirección global 2002:wwxx:yyzz::/48, donde wwxx:yyzz es la dirección IPv4 pública del cliente convertida a formato hexadecimal (ver formato en la Figura 5.56). Cliente/Router 6to4: Cliente que tiene una dirección IPv4 pública y conectividad directa 6to4, es decir, que tiene una interfaz virtual 6to4 por la cual accede directamente a la Internet IPv6 sin necesidad de utilizar un router 6to4. Solo requiere de un Relay 6to4. Router 6to4: Router que soporta 6to4, permitiendo que los clientes que no soportan este tipo de direcciones accedan a otros hosts 6to4 IPv6 a través del 191

208 mismo. En el caso de los accesos a la Internet IPv6, éste direcciona el tráfico hasta el Relay Router más cercano, el cual encaminará el paquete hacia la red IPv6. Relay 6to4: Router con soporte para 6to4 y que también tiene conexión nativa a la Internet IPv6. De este modo puede enrutar y comunicarse con la red IPv6 nativa, con la red IPv4 y con la red 6to4. Cliente 6to4: Equipo de red o computadora que solo tiene dirección IPv6 en formato 6to4, pero que no tiene una interfaz virtual 6to4. Por lo tanto, necesita de un router 6to4 para realizar la comunicación con otras redes IPv6 y 6to4. Figura 5.56: Formato de una dirección 6to4 Fuente: Migrating to IPv6 El formato de la dirección 6to4 consta de los siguientes campos: - El prefijo 6to4 siempre es 2002, de acuerdo con la definición de la IANA. - El siguiente campo es la dirección IPv4 pública del cliente. Se crea de acuerdo con el siguiente ejemplo: Dirección IPv4: Primero se convierte cada número decimal a formato hexadecimal: 200=C8 192=C0 180=B4 002=02 Así la dirección se convierte en C8C0:B

209 - El ID de la subred se puede usar para segmentar la red 6to4 asociada a la dirección IPv4 pública en varias subredes (2 16 subredes con 2 64 direcciones cada una); puede utilizar, por ejemplo, 0, 1, 2, 3, El ID de la interfaz puede ser igual al segundo campo (IPv4 convertido a formato hexadecimal) en el caso de la configuración automática de Windows Vista y Server 2008, o bien 1, 2, 3, 4.., en el caso de configuración manual o de Linux y BSD. Como la longitud de este campo es de 64 bits se puede tener hasta 2 64 direcciones por cada subred. Acontinuacion se presentaran las diferentes situaciones posibles en las redes 6to4, explicando paso a paso la ruta de inicio a fin. - COMUNICACIÓN ENTRE CLIENTES 6TO4 QUE ESTAN EN REDES DIFERENTES Figura 5.57: Comunicación entre clientes 6to4 que están en redes diferentes Fuente: ipv6.br 193

210 Equipo Ruta C1 ::/0 a través de R1 2002:0102:0304:1::/64 a través de la interfaz LAN R1 ::/0 a través del Relay 6to4 utilizando la interfaz virtual 6to4 2002::/16 a través de la interfaz virtual 6to4 2002:0102:0304:1/64 hacia la red local a través de la interfaz LAN R2 ::/0 a través de R2 2002:0102:0305:1:/64 hacia la red local a través de la interfaz LAN C2 ::/0 a través del Relay 6to4 utilizando la interfaz virtual 6to4 2002::/16 a través de la interfaz virtual 6to4 2002:0102:0305:1:/64 hacia la red local a través de la interfaz LAN 1- Analizando la tabla de enrutamiento se observa que el paquete se envía a través de la red local IPv6 hacia el router R1 utilizando la ruta ::/0 2- El paquete IPv6 es recibido por R1 a través de la interfaz LAN. R1 verifica su tabla de enrutamiento y descubre que debe enviar el paquete hacia su interfaz virtual 6to4 (ruta a la red 2002::/16). En esta interfaz el paquete IPv6 se encapsula en un paquete IPv4 (protocolo tipo 41) que se direcciona hacia el router R2 (dirección extraída de la dirección IPv6 del destinatario del paquete original) 3- El paquete IPv6 encapsulado en IPv4 es recibido por R2 a través de su interfaz IPv4 o WAN. Como el paquete es de tipo 41, éste es encaminado a la interfaz 6to4, que lo desencapsula. Al consultar su tabla de enrutamiento R2 descubre que el paquete 194

211 está destinado a su red local 2002:0102:0305:1::/64, por lo que encamina el paquete IPv6 a la computadora C2 a través de su red local. En los pasos siguientes (4, 5 y 6), el sistema de comunicación es el mismo, ya que lo único que cambia es la dirección de encaminamiento del paquete. - COMUNICACIÓN CLENTE/ROUTER 6TO4 CON UN SERVIDOR IPV6 Figura 5.58: Comunicación cliente/router 6to4 con un servidor ipv6 Fuente: ipv6.br Equipo Ruta HR1 ::/0 a través de la interfaz virtual 6to4 2002::/16 a través de la interfaz virtual 6to4 RL1 ::/0 red IPv6 a través de la interfaz LAN 195

212 2002::/16 a través de la interfaz virtual 6to4 S1 Ruta por defecto a través de R1 R1 anuncio vía BGP) 2002::/16 a través del Relay RL1 (ruta descubierta a través del 1- HR1 envía un paquete IPv6 al servidor S1. A través de la tabla de enrutamiento el paquete es direccionado a la interfaz virtual 6to4. Ésta encapsula el paquete IPv6 en un paquete IPv4 (protocolo 41) y coloca como destino la dirección del Relay, la cual se puede especificar manualmente o descubrir automáticamente encaminando el paquete a la dirección anycast El Relay RL1 recibe el paquete encapsulado a través de su dirección IPv4 o anycast; como el protocolo del paquete es 41, RL1 desencapsula el paquete IPv6 y, a través de su tabla de enrutamiento descubre que el paquete debe ser enviado a S1 a través de su interfaz LAN en la red IPv6. 3- Una vez recibido el paquete, S1 responde utilizando su ruta por defecto a través del router 1 de su red. El router R1 recibe vía BGP la ruta hacia la red 2002::/16 y encamina el paquete al Relay RL1 4- RL1 recibe el paquete y observa que está destinado a la red 6to4, por lo que encamina el paquete a la interfaz virtual 6to4, que lo encapsula en un paquete IPv4 (protocolo 41) y, a través de la dirección IPv4 implícita en la dirección IPv6 del destinatario, el paquete es encaminado a HR1. HR1 recibe el paquete en su interfaz IPv4, ve que se está utilizando el protocolo 41 y desencapsula el paquete IPv6 a través de la interfaz virtual 6to4. 196

213 - COMUNICACÓN CLIENTE 6TO4 CON UN SERVIDOR IPV6 UTILIZANDO SOLO UN RELAY 6TO4 (RUTAS DE IDA Y VUELTA IGUALES). Figura 5.59: Comunicación cliente 6to4 con un servidor ipv6 utilizando solo un relay 6to4 (rutas de ida y vuelta iguales) Fuente: ipv6.br Equipo Ruta RL1 ::/0 red IPv6 a través de la interfaz LAN / 2002::/16 a través de la interfaz virtual 6to4 RL2 ::/0 red IPv6 a través de la interfaz LAN / 2002::/16 a través de la interfaz virtual 6to4 S1 Ruta por defecto a través de R2 197

214 R2 R1 6to4 2002::/16 a través del Relay RL1 (ruta descubierta a través del anuncio vía BGP) ::/0 a través del Relay 6to4 RL1 o RL2 utilizando la interfaz virtual 2002::/16 a través de la interfaz virtual 6to4 2002:0102:0304:1/64 hacia la red local a través de la interfaz LAN C1 LAN ::/0 a través de R1 / 2002:0102:0304:1::/64 a través de la interfaz C2 LAN ::/0 a través de R1 / 2002:0102:0304:1::/64 a través de la interfaz 1- De acuerdo con la tabla de enrutamiento, el paquete se envía a través de la red local IPv6 hacia el router R1 utilizando la ruta ::/0 2- El paquete IPv6 es recibido por R1 a través de la interfaz LAN que verifica su tabla de enrutamiento y descubre que el paquete debe ser encaminado a la interfaz virtual 6to4 (ruta para la red 2002::/16). En esta interfaz el paquete IPv6 se encapsula en un paquete IPv4 (protocolo tipo 41) y se envía al Relay RL1 o RL2 (el Relay 6to4 puede ser definido manualmente en el router 6to4 o automáticamente utilizando la dirección anycast ). Supongamos que el paquete se envía al Relay RL1 3- RL1 recibe el paquete 6to4 a través de su interfaz IPv4 y, como el paquete utiliza el protocolo 41, lo encamina a la interfaz virtual, la cual desencapsula el paquete IPv6 y verifica en la tabla de enrutamiento que debe enviarlo por la interfaz LAN a través del router R2, que simplemente reenvía el paquete IPv6 al servidor S1. 198

215 4- S1 responde enviando otro paquete IPv6 con destino al Cliente C1 utilizando su ruta por defecto que apunta hacia el router R2. R2 recibe el paquete a través de la ruta recibida vía BGP y sabe que debe enviarlo al relay más próximo, que en este caso es RL1. 5- RL1 recibe el paquete IPv6 y verifica que el destino es la red 6to4 (2002::/16). Siendo así, de acuerdo con su tabla de enrutamiento el paquete es encaminado a la interfaz virtual 6to4, que lo empaqueta en un paquete IPv4 (protocolo 41) y lo envía a la dirección IPv4 implícita en la dirección IPv6 del destinatario del paquete 6- El router R1 recibe el paquete a través de su dirección IPv4 y, como el paquete está utilizando el protocolo 41, éste es encaminado a la interfaz virtual 6to4, que lo desencapsula y verifica la dirección de destino. De acuerdo con su tabla de enrutamiento ésta envía el paquete IPv6 a través de su interfaz LAN al Cliente 6to4 C1. - COMUNICACIÓN CLIENTE 6TO4 CON UN SERVIDOR IPV6 UTILIZANDO DOS RELAYS 6TO4 DIFERENTES (RUTAS DE IDA Y VUELTAS DIFERENTES). 199

216 Figura 5.60: Comunicación cliente 6to4 con un servidor ipv6 utilizando dos relays 6to4 diferentes (rutas de ida y vueltas diferentes) Fuente: ipv6.br Equipo Ruta RL1 ::/0 red IPv6 a través de la interfaz LAN / 2002::/16 a través de la interfaz virtual 6to4 RL2 ::/0 red IPv6 a través de la interfaz LAN / 2002::/16 a través de la interfaz virtual 6to4 S2 Ruta por defecto a través de R3 R3 2002::/16 a través del Relay RL2 (ruta descubierta a través del anuncio vía BGP) R1 6to4 ::/0 a través del Relay 6to4 RL1 o RL2 utilizando la interfaz virtual 200

217 2002::/16 a través de la interfaz virtual 6to4 2002:0102:0304:1/64 hacia la red local a través de la interfaz LAN C1 LAN ::/0 a través de R1 / 2002:0102:0304:1::/64 a través de la interfaz C2 LAN ::/0 a través de R1 / 2002:0102:0304:1::/64 a través de la interfaz 1- De acuerdo con la tabla de enrutamiento, el paquete se envía a través de la red local IPv6 hacia el router R1 utilizando la ruta ::/0. 2- El paquete IPv6 es recibido por R1 a través de la interfaz LAN, que verifica su tabla de enrutamiento y descubre que el paquete debe ser enviado a la interfaz virtual 6to4 (ruta para la red 2002::/16). En esta interfaz el paquete IPv6 se encapsula en un paquete IPv4 (protocolo tipo 41) y se envía al Relay RL1 o RL2 (el Relay 6to4 puede ser definido manualmente en el router 6to4 o automáticamente utilizando la dirección anycast ). Supongamos que el paquete se envía al Relay RL1. 3- RL1 recibe el paquete 6to4 a través de su interfaz IPv4, ve que el paquete utiliza el protocolo 41 y lo encamina a la interfaz virtual. Ésta desencapsula el paquete IPv6 y verifica en su tabla de enrutamiento que debe enviarlo por la interfaz LAN a través del router R3, que simplemente reenvía el paquete IPv6 al servidor S2. 4- S2 responde enviando otro paquete IPv6 con destino al Cliente C2 utilizando su ruta por defecto que apunta hacia el router R3. R3 recibe el paquete a través de la ruta recibida vía BGP, y sabe que debe enviarlo al relay más próximo, que es RL2. 201

218 5- RL2 recibe el paquete IPv6 y verifica que el destino es la red 6to4 (2002::/16). Siendo así, de acuerdo con su tabla de enrutamiento encamina el paquete a la interfaz virtual 6to4, que lo empaqueta en un paquete IPv4 (protocolo 41) y lo envía a la dirección IPv4 implícita en la dirección IPv6 del destinatario del paquete 6- El router R1 recibe el paquete a través de su dirección IPv4, verifica que el paquete está utilizando el protocolo 41 y lo encamina a la interfaz virtual 6to4. Ésta lo desencapsula y verifica la dirección de destino. De acuerdo con su tabla de enrutamiento y la dirección de destino, el paquete IPv6 es enviado a través de su interfaz LAN al Cliente 6to4 C Configuración de un Tunel 6to4 La Figura 5.61 muestra la topología utilizada para la implementación del túnel 6to4. A continuación se incluyen los comandos que se deben introducir en cada router para lograr la simulación de este túnel. Figura 5.61: Topología 6to4 202

219 ROUTER 1 Router>enable Router#configure terminal Router(config)# ipv6 unicast-routing Router(config)# interface fastethernet0/0 Router(config-if)# ipv6 enable Router(config-if)# ipv6 address 2001:db8:1::1/64 Router(config-if)# no shutdown Router(config-if)# exit Router(config)# interface serial1/0 Router(config-if)# ip address Router(config-if)# no shutdown Router(config-if)# exit Router(config)#router rip Router(config-router)#version 2 Router(config-router)#network Router(config-router)#exit Router(config)#interface tunnel0 Router(config-if)#tunnel mode ipv6ip 6to4 Router(config-if)#tunnel source Router(config-if)#ipv6 address 2002:0a01:0101::/128 Router(config-if)# exit Router(config)#ipv6 route 2002::/16 tunnel0 203

220 Router(config)#ipv6 route 2001:db8:2::/ :0a02:0202:: Router(config)#exit ROUTER 2 Router>enable Router#configure terminal Router(config)# interface serial1/0 Router(config-if)# ip address Router(config-if)# no shutdown Router(config-if)# exit Router(config)# interface serial1/1 Router(config-if)# ip address Router(config-if)# clock rate Router(config-if)# no shutdown Router(config-if)# exit Router(config)#router rip Router(config-router)#version 2 Router(config-router)#network Router(config-router)#network Router(config-router)#exit 204

221 ROUTER 3 Router>enable Router#configure terminal Router(config)# ipv6 unicast-routing Router(config)# interface fastethernet0/0 Router(config-if)# ipv6 enable Router(config-if)# ipv6 address 2001:db8:2::1 Router(config-if)# no shutdown Router(config-if)# exit Router(config)# interface serial1/0 Router(config-if)# ip address Router(config-if)# no shutdown Router(config-if)# exit Router(config)#router rip Router(config-router)#version 2 Router(config-router)#network Router(config-router)#exit Router(config)#interface tunnel0 Router(config-if)#tunnel mode ipv6ip 6to4 Router(config-if)#tunnel source Router(config-if)#ipv6 address 2002:0a02:0202::/128 Router(config-if)#exit Router(config)#ipv6 route 2002::/16 tunnel0 205

222 Router(config)#ipv6 route 2001:db8:1::/ :0a01:0101:: Router(config)#exit ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) La técnica de transición Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), definida en la RFC 5214 se basa en túneles IPv6 creados automáticamente dentro de la red IPv4 y en direcciones IPv6 asociadas a esos clientes de acuerdo con el prefijo especificado en el router ISATAP y la dirección IPv4 del cliente. Para crear estos túneles se utilizan las especificaciones de la sección 3 de la RFC 4213, que trata la tunelización a través del protocolo IPv4 tipo 41 o 6in4. A continuación se muestra un emjemplo de equivalencia entre direcciones IPv4/IPv6. Dirección IPv4 Dirección IPv6/ISATAP :10fe:0:8003:200:5efe: fe80::200:5efe: :10fe:0:8003:0:5efe: fe80:0:5efe:

223 Figura 5.62: Inicio ISATAP Fuente: ipv6.br - INICIO. 1- En este paso el cliente intenta determinar la dirección IPv4 del router, si la dirección IPv4 todavía no está determinada en su configuración. En el caso de Windows, por defecto intenta resolver el nombre ISATAP. 2- El servidor de DNS regresa la IPv4 del router ISATAP (si corresponde). 3- El cliente envía un mensaje Router Solicitation (RS) encapsulado en IPv4 al router ISATAP. 4- El router ISATAP responde con un mensaje Router Advertisement (RA) encapsulado en IPv4, con eso el cliente ya puede configurar sus direcciones IPv6/ISATAP. 207

224 - COMUNICACIÓN ENTRE CLIENTES ISATAP EN LA MISMA RED Figura 5.63: Comunicación entre clientes ISATAP en la misma red Fuente: ipv6.br 1- C2 solicita la resolución DNS del nombre del router ISATAP (si fuera necesario). 2- C2 recibe IPv4 del router ISATAP (si fuera necesario). 3- El cliente envía un mensaje Router Solicitation (RS) encapsulado en IPv4 al router ISATAP. 4- El router ISATAP responde con un mensaje Router Advertisement (RA) encapsulado en IPv4, con eso el cliente ya puede configurar sus direcciones Ipv6/ISATAP. Los procesos 1 a 4 también son ejecutados por C1; 5- El cliente ISATAP C2 envía un paquete IPv6 encapsulado en IPv4 utilizando el protocolo 41 a través de la red IPv4 con destino a la dirección IPv4 de C1. 208

225 6- El cliente ISATAP C1 recibe el paquete IPv4 y desencapsula el paquete IPv6, luego de lo cual éste responde con otro paquete IPv6 encapsulado en IPv4 utilizando el protocolo 41 a través de la red IPv4 con destino a la dirección IPv4 del cliente C2. - COMUNICACIÓN ENTRE CLIENTES ISATAP EN REDES DIFERENTES Figura 5.64: Comunicación entre clientes en redes diferentes Fuente: ipv6.br 1. El cliente ISATAP C1 desea enviar un paquete IPv6 al cliente C2. A través de su tabla de enrutamiento descubre que debe enviarlo utilizando la interfaz virtual ISATAP, por lo que el paquete se encapsula en IPv4 (protocolo 41) y se envía a la dirección IPv4 del router R1. 2. El router R1 recibe el paquete a través de su interfaz IPv4 pero, como el paquete IPv6 está encapsulado utilizando el protocolo 41, éste lo desencapsula (utilizando la interfaz virtual ISATAP) y verifica la dirección IPv6 del destino. Después de esto descubre que la ruta hacia el destino es a través de la red IPv6, por lo que el paquete desencapsulado (IPv6 nativo) se encamina al router R2. 209

226 3. El router R2 recibe el paquete IPv6 en su interfaz IPv6 pero al verificar la dirección de destino descubre que es para el cliente C2 que está en su subred ISATAP, por lo que envía el paquete a través de esta interfaz, que encapsula nuevamente el paquete IPv6 en un paquete IPv4 y lo envía a C2 (con base en la dirección IPv4 implícita en IPv6). El cliente ISATAP C1 recibe el paquete IPv4 y desencapsula el paquete IPv6 (a través de la interfaz virtual ISATAP). 4. El cliente ISATAP C2 desea responder al cliente C1, por lo que verifica su tabla de rutas y concluye que debe enviar el paquete a través de la interfaz virtual ISATAP, por lo que el paquete IPv6 es encapsulado en IPv4 y encaminado al router R2. 5. El router R2 recibe el paquete a través de su interfaz IPv4 pero, como el paquete está utilizando el protocolo 41, éste desencapsula el paquete IPv6 y luego de verificar en su tabla de enrutamiento lo encamina a través de su interfaz IPv6. 6. El router R1 recibe el paquete IPv6 pero verificando en su tabla de enrutamiento descubre que el paquete debe ser enviado a través de su interfaz virtual ISATAP, la cual encapsula el paquete IPv6 en IPv4 utilizando el protocolo 41 y lo encamina a la dirección IPv4 de C1. C1 recibe el paquete pero, como el paquete fue encapsulado utilizando el protocolo 41, éste extrae el paquete IPv6 enviado por C2 y lo recibe. 210

227 - COMUNICACIÓN ENTRE CLIENTES ISATAP Y COMPUTADORAS IPV6 Figura 5.65: Comunicación entre clientes ISATAP y computadoras IPv6 Fuente: ipv6.br 1. El cliente ISATAP desea enviar un paquete IPv6 al servidor IPv6. A través de su tabla de enrutamiento descubre que debe enviarlo utilizando la interfaz virtual ISATAP, por lo que el paquete se encapsula en IPv4 (protocolo 41) y se envía a la dirección IPv4 del router ISATAP. 2. El router ISATAP recibe el paquete a través de su interfaz IPv4 pero, como el paquete IPv6 está encapsulado utilizando el protocolo 41, éste lo desencapsula (utilizando la interfaz virtual ISATAP) y verifica la dirección IPv6 del destino. Después de esto descubre que la ruta hacia el destino es a través de la red IPv6, por lo que el paquete desencapsulado (IPv6 nativo) se encamina al router IPv6. El servidor recibe el paquete IPv6 destinado al mismo. 3- El servidor IPv6 desea responder al cliente ISATAP, por lo que verificando su tabla de enrutamiento descubre que debe enviarlo a través de su ruta por defecto, que es a través de la red IPv6. 211

228 4- Como la ruta para la red del cliente ISATAP es a través del router ISATAP, el paquete es encaminado al mismo a través de su interfaz IPv6. Verificando en su tabla de enrutamiento el router descubre que debe enviar el paquete a través de su interfaz virtual ISATAP, por lo que el paquete es encapsulado en IPv4 y encaminado al cliente ISATAP a través de la red IPv4. El cliente recibe el paquete IPv4 pero, como está utilizando protocolo 41, desencapsula y recibe el paquete IPv Configuración ISATAP La Figura 5.66 muestra la topología para la implementación del túnel ISATAP. Figura 5.66: Topología básica ISATAP La siguiente es la relación de comandos que deben ser introducidos en los routers de la topología de la Figura 5.66 para la implementación del túnel ISATAP. 212

229 ROUTER 1 Router>enable Router#configure terminal Router(config)# interface fastethernet 0/0 Router(config-if)# ip address Router(config-if)# no shutdown Router(config-if)# exit Router(config)# interface fastethernet 0/1 Router(config-if)# ip address Router(config-if)# no shutdown Router(config-if)# exit Router(config)#router rip Router(config-router)#version 2 Router(config-router)#network Router(config-router)#network Router(config-router)#exit ROUTER 2 Router>enable Router#configure terminal Router(config)# ipv6 unicast-routing Router(config)# interface fastethernet 0/0 Router(config-if)# ip address

230 Router(config-if)# no shutdown Router(config-if)# exit Router(config)# interface fastethernet 0/1 Router(config)# ipv6 enable Router(config-if)# ipv6 address 3ffe:b00:1:2::2/64 Router(config-if)# ipv6 rip RIC enable Router(config-if)# no shutdown Router(config-if)# exit Router(config)#router rip Router(config-router)#version 2 Router(config-router)#network Router(config-router)#exit Router(config)#interface tunnel0 Router(config-if)#ipv6 address 3ffe:b00:1:3::/64 eui-64 Router(config-if)#no ipv6 nd suppress-ra Router(config-if)#tunnel source Router(config-if)#tunnel mode ipv6ip isatap Router(config-if)# exit Router(config)#ipv6 route 3ffe:b00:1:3::/64 3ffe:b00:1:2::1 Router(config)#ipv6 router rip RIC Router(config-rtr)#exit ROUTER 3 Router>enable Router#configure terminal 214

231 Router(config)# ipv6 unicast-routing Router(config)# interface fastethernet 0/0 Router(config)# ipv6 enable Router(config-if)# ipv6 address 3ffe:b00:1:1::2/64 Router(config-if)# ipv6 rip RIC enable Router(config-if)# no shutdown Router(config-if)# exit Router(config)# interface fastethernet 0/1 Router(config)# ipv6 enable Router(config-if)# ipv6 address 3ffe:b00:1:2::1/64 Router(config-if)# ipv6 rip RIC enable Router(config-if)# no shutdown Router(config-if)# exit Router(config)#ipv6 router rip RIC Router(config-rtr)#exit Router(config)#ipv6 route 3ffe:b00:1:3::/64 3ffe:b00:1:2::2 EN WINDOWS c> netsh interface ipv6 isatap set router c> netsh interface ipv6 set interface 2 forwarding=enabled advertise=enabled c> netsh interface ipv6 set route 3ffe:b00:1:3::/64 2 publish=yes 215

232 5.4.6 Túnel Teredo La técnica de tunelización automática Teredo, definida en la RFC 4380, permite que los nodos ubicados detrás de NAT (Network Address Translation) obtengan conectividad IPv6 utilizando el protocolo UDP. La conexión se realiza a través de un Servidor Teredo que la inicializa y determina el tipo de NAT usado por el cliente. Luego, si el host de destino tiene IPv6 nativo, se utiliza un Relay Teredo para crear una interfaz entre el Cliente y el host de destino. El Relay utilizado será siempre el que esté más próximo al host de destino, no el más próximo al cliente. Esta técnica no es demasiado eficiente debido al overhead y la complejidad de su funcionamiento, pero cuando el host está detrás de NAT es una de las únicas opciones disponibles. Por defecto, Windows Vista ya viene con Teredo instalado y activado, mientras que en Windows XP, 2003 y 2008 solo vienen instalados. En FreeBSD y Linux ni siquiera viene instalado. Para facilitar la comprensión del funcionamiento de este tipo de túnel, en el siguiente cuadro presentamos un resumen de los cuatro tipos de NAT existentes: NAT de Cono - Todas las solicitudes originadas en una misma dirección y puerto internos son mapeadas a un mismo puerto de NAT. Por lo tanto solo es necesario conocer la dirección pública del NAT y el puerto asociado a un nodo interno para que un nodo externo establezca una comunicación sin importar su dirección o puerto, pudiendo así enviar arbitrariamente paquetes al nodo interno. También se conoce como NAT Estático. 216

233 NAT de Cono Restringido - Todas las solicitudes originadas en una misma dirección y puerto internos son mapeadas a un mismo puerto de NAT. Sin embargo, el acceso externo solo se permite en respuesta a solicitudes realizadas previamente, porque la dirección del nodo externo, que está respondiendo a la solicitud, debe ser la misma utilizada como dirección de destino de la solicitud. También se conoce como NAT Dinámico. NAT de Cono Restringido por Puerto - Tiene las mismas características de mapeo que el NAT de Cono restringido, pero la restricción para la comunicación también considera el puerto del nodo externo. Así, un nodo externo solo podrá establecer una comunicación con un nodo interno si éste último le ha enviado previamente un paquete a través del mismo puerto y dirección. NAT Simétrico - Además de tener las mismas restricciones que el NAT tipo Cono Restringido por Puerto, cada solicitud realizada desde una dirección y puerto internos a una dirección y puerto externos es mapeada únicamente en el NAT. Es decir, si la misma dirección interna envía una solicitud, con el mismo puerto, pero para una dirección de destino diferente, en el NAT se creará un mapeo diferente. Este tipo de NAT también se conoce como NAT Masquerade o NAT Stateful. Figura 5.67: Formato de dirección teredo Fuente: Migrating to IPv6 Con base en los mensajes RA recibidos de los Servidores, el cliente construye su dirección IPv6 (ver formato de esta dirección en la Figura 5.67), utilizando el siguiente estándar: 217

234 Los bits 0 a 31 son el prefijo de Teredo recibido del Servidor a través de los mensajes RA. Por defecto es 2001:0000 Los bits 32 a 63 son la dirección IPv4 primaria del Servidor Teredo que envió el primer mensaje RA Los bits 64 a 79 se utilizan para definir algunos flags. Generalmente solo se utiliza el bit más significativo, y éste se marca como 1 si el Cliente está detrás de NAT tipo Cono. En caso contrario se marca como 0. Solo Windows Vista y Windows Server 2008 utilizan los 16 bits que siguen el formato "CRAAAAUG AAAAAAAA", donde "C" sigue siendo el flag Cono; el bit R está reservado para uso futuro; el bit U define el flag Universal/Local (el valor por defecto es 0); el bit G define el flag Individual/Group (el valor por defecto 0); y los 12 bits A son determinados aleatoriamente por el Cliente para introducir una protección adicional contra los ataques de barrido. Los bits 80 a 95 son el puerto UDP de salida del NAT recibido en los mensajes RA y enmascarado mediante la inversión de todos sus bits. Este enmascaramiento es necesario porque algunos NAT buscan puertos locales dentro de los paquetes y los reemplazan por el puerto público o viceversa. Los bits 96 a 127 son la dirección IPv4 pública del Servidor NAT, enmascarado a través de la inversión de todos sus bits. Este enmascaramiento es necesario porque algunos NAT buscan direcciones IP locales dentro de los paquetes y las reemplazan por la dirección pública o viceversa. 218

235 Figura 5.68: Túnel Teredo Fuente: ipv6.br 1- Se envía un mensaje Router Solicitation (RS) al servidor Teredo 1 (servidor primario) con el flag de NAT tipo Cono activado; el servidor Teredo 1 responde con un mensaje Router Advertisement (RA). Como el mensaje RS tenía activado el flag Cono, el servidor Teredo 1 envía el mensaje RA utilizando una dirección IPv4 alternativa. Con eso el cliente podrá determinar si el NAT que está utilizando es tipo Cono, si recibe el mensaje RA. 2- Si no se recibe el mensaje RA del paso anterior, el cliente Teredo envía otro mensaje RS, pero ahora con el flag Cono desactivado. El servidor Teredo 1 responde nuevamente con un mensaje RA pero, como el flag Cono del mensaje RS está desactivado, responde utilizando la misma dirección IPv4 que recibió en el mensaje RS. Si ahora el cliente recibe el mensaje RA, entonces concluye que está usando NAT tipo restringido. 3- Para tener la certeza de que el cliente Teredo no está utilizando un NAT de tipo simétrico, éste envía otro mensaje RS, esta vez al servidor secundario Teredo 2, que responde con un mensaje tipo RA. Cuando el cliente recibe el mensaje RA del servidor Teredo 2 compara la dirección y el puerto UDP de origen contenidos en el mensaje RA recibido de los dos servidores; si son diferentes el cliente concluye que está utilizando NAT tipo simétrico, el cual no es compatible con Teredo. 219

236 - COMUNICACIÓN A TRAVÉS DE NAT TIPO CONO La figura 5.69 muestra los pasos que se siguen para lograr la comunicación a través de un túnel Teredo cuando se debe atravesar un NAT tipo Cono. A continuación se describen dichos pasos: Figura 5.69: Comunicaciones a través de NAT tipo Cono Fuente: ipv6.br 1- Para iniciar la comunicación el cliente Teredo primero debe determinar la dirección IPv4 y el puerto UDP del Relay Teredo que esté más próximo al host IPv6; para ello envía un mensaje ICMPv6 echo request al host IPv6 a través de su servidor Teredo. 2- El servidor Teredo recibe el mensaje ICMPv6 echo request y lo encamina al host IPv6 a través de la red IPv6. 3- El host IPv6 responde al cliente Teredo con un mensaje ICMPv6 Echo Reply que es enrutado a través del Relay Teredo más próximo al mismo. 220

237 4- Luego el Relay Teredo encapsula el mensaje ICMPv6 Echo Reply y lo envía directamente al cliente Teredo. Como el NAT utilizado por el cliente es tipo Cono, el paquete enviado por el Relay Teredo es encaminado al cliente Teredo. 5- Como el paquete que devuelve el Relay Teredo contiene una dirección IPv4 y el número de puerto UDP utilizado por el mismo, el cliente Teredo extrae esta información del paquete. Después un paquete inicial es encapsulado y enviado directamente por el cliente Teredo a la dirección IPv4 y puerto UDP del Relay Teredo. 6- El Relay Teredo recibe este paquete, elimina el encabezado IPv4 y UDP y lo encamina al host IPv6. Luego toda la comunicación entre el cliente Teredo y el host IPv6 se realiza a través del relay Teredo con este mismo método. - COMUNICACIONES A TRAVES DE NAT RESTRINGIDO La figura 5.70 muestra los pasos que se siguen para lograr la comunicación a través de un túnel Teredo cuando se debe atravesar un NAT restringido. A continuación se describen los pasos correspondientes: 221

238 Figura 5.70: Comunicaciones a través de NAT restringido Fuente: ipv6.br 1- Para iniciar la comunicación primero el cliente Teredo debe determinar la dirección IPv4 y el puerto UDP del Relay Teredo que esté más próximo al host IPv6; para ello envía un mensaje ICMPv6 echo request al host IPv6 a través de su servidor Teredo 2- El servidor Teredo recibe el mensaje ICMPv6 echo request y lo encamina al host IPv6 a través de la red IPv6 3- El host IPv6 responde al cliente Teredo con un mensaje ICMPv6 Echo Reply que es enrutado a través del Relay Teredo más próximo al mismo 4- A través del paquete recibido el Relay Teredo descubre que el cliente Teredo está utilizando un NAT tipo restringido, por lo que, si el Relay Teredo envía el paquete ICMPv6 directamente al cliente Teredo, éste será descartado por el NAT debido a que no hay mapeo predefinido para el tráfico entre el cliente y el Relay Teredo; por lo tanto, el Relay Teredo envía un paquete bubble al cliente Teredo a través del Servidor Teredo utilizando la red IPv4 222

239 5- El servidor Teredo recibe el paquete bubble del Relay Teredo y lo encamina al cliente Teredo, pero en el indicador de origen coloca la IPv4 y el puerto UDP del Relay Teredo. Como ya había un mapeo de tráfico entre el servidor Teredo y el Cliente Teredo, el paquete pasa por el NAT y es entregado al Cliente Teredo 6- El Cliente Teredo extrae del paquete bubble recibido la IPv4 y el puerto UDP del Relay Teredo más próximo al host IPv6, y el Cliente Teredo envía un paquete Bubble al Relay Teredo para que se cree un mapeo de conexión entre ellos en el NAT 7- En base al contenido del paquete bubble recibido, el Relay Teredo puede determinar que éste corresponde al paquete ICMPv6 Echo Reply que está en la cola a transmitir y que el paso a través del NAT restringido ya está abierto, por lo que encamina el paquete ICMPv6 Echo Reply al cliente Teredo 8- Una vez recibido el paquete ICMPv6, se envía un paquete inicial del Cliente Teredo al host IPv6 a través del Relay Teredo más próximo al mismo 9- El relay Teredo quita los encabezados IPv4 y UDP del paquete y lo encamina a través de la red IPv6 al host IPv6. Después de esto los paquetes subsiguientes se envían a través del Relay Teredo GRE (Generic Routing Encapsulation) GRE (Generic Routing Encapsulation) es un túnel estático entre dos hosts desarrollado originalmente por Cisco con el objetivo de encapsular diferentes tipos de protocolos, como por ejemplo IPv6 e IS-IS (ver la lista completa de protocolos soportados en Este tipo de encapsulamiento es soportado por la mayoría de los sistemas operativos y routers 223

240 y consiste en un enlace punto-a-punto. La principal desventaja del túnel GRE es la configuración manual que, dependiendo de la cantidad de túneles, implicará un gran esfuerzo en términos de su mantenimiento y administración. El funcionamiento de este tipo de túnel es muy simple y consiste en tomar los paquetes originales, agregar el encabezado GRE y enviarlos a la IP de destino (la dirección de destino está especificada en el encabezado GRE); cuando el paquete encapsulado llega al otro extremo del túnel (IP de destino) se quita el encabezado GRE y queda solo el paquete original, el cual se encamina normalmente a su destinatario. Los campos más importantes del encabezado GRE son los siguientes: - C (Checksum): Si es 1, indica que el campo Checksum existe y que hay información válida en el mismo y en el campo Offset - R (Routing): Si es 1, indica que el campo Enrutamiento existe y que hay información de enrutamiento válida en el mismo y en el campo Offset - K (Key): Si es 1, indica que el campo Clave existe y está siendo utilizado - S (Sequence): Si es 1, indica que el campo Número de Secuencia existe y está siendo utilizado - Versión Generalmente se completa con 0 - Protocolo: Se completa con el código del protocolo que está siendo transportado, de acuerdo con los tipos de paquetes ethernet ( 224

241 - Offset: Indica la posición donde inicia el campo de enrutamiento; - Checksum: Contiene el checksum IP (complemento a 1) del encabezado GRE y del paquete que está siendo transportado - Clave (Key): Contiene un número de 32 bits que es introducido por el encapsulador. Es utilizado por el destinatario para identificar el remitente del paquete - Número de secuencia (Sequence number): Contiene un número entero de 32 bits que es introducido por el remitente del paquete. Es utilizado por el destinatario para secuenciar los paquetes recibidos - Enrutamiento (Routing): Contiene una lista de entradas de enrutamiento, pero generalmente no se utiliza Implementación de un Túnel GNRE IPv6 La Figura 5.71 presenta la topología implementada para la realización de un túnel GNRE IPv6. Se incluye a continuación las configuraciones necesarias en cada router de la topología: 225

242 Figura 5.71: Topología Tunnel GNRE IPv6 ROUTER 1 Router>enable Router#configure terminal Router(config)# ipv6 unicast-routing Router(config)# interface fastethernet0/0 Router(config-if)# ipv6 enable Router(config-if)# ipv6 address 2001:db8:1:1::1/64 Router(config-if)# no shutdown Router(config-if)# exit Router(config)#interface serial 1/0 Router(config-if)# ip address Router(config-if)# no shutdown Router(config-if)# exit Router(config)#router rip 226

243 Router(config-router)#version 2 Router(config-router)#network Router(config-router)#exit Router(config)#interface tunnel0 Router(config-if)#ipv6 address 2001:db8:5:5::1/64 Router(config-if)#tunnel source Router(config-if)#tunnel destination Router(config-if)#tunnel mode gre ip Router(config-if)#no shutdown Router(config-if)# exit Router(config)#ipv6 route ::/0 2001:db8:5:5::2 ROUTER 2 Router>enable Router#configure terminal Router(config)#interface serial 1/0 Router(config-if)# ip address Router(config-if)# clock rate Router(config-if)# no shutdown Router(config-if)# exit Router(config)#interface serial1/1 Router(config-if)# ip address Router(config-if)# clock rate Router(config-if)# no shutdown 227

244 Router(config-if)# exit Router(config)#router rip Router(config-router)#version 2 Router(config-router)#network Router(config-router)#network Router(config-router)#exit ROUTER 3 Router>enable Router#configure terminal Router(config)# ipv6 unicast-routing Router(config)# interface fastethernet0/0 Router(config-if)# ipv6 enable Router(config-if)# ipv6 address 2001:db8:2:2::1/64 Router(config-if)# no shutdown Router(config-if)# exit Router(config)#interface serial 1/0 Router(config-if)# ip address Router(config-if)# no shutdown Router(config-if)# exit Router(config)#router rip Router(config-router)#version 2 Router(config-router)#network

245 Router(config-router)#exit Router(config)#interface tunnel0 Router(config-if)#ipv6 address 2001:db8:5:5::2/64 Router(config-if)#tunnel source Router(config-if)#tunnel destination Router(config-if)#tunnel mode gre ip Router(config-if)#no shutdown Router(config-if)# exit Router(config)#ipv6 route ::/0 2001:db8:5:5:: Analisis comparativo entre las estrategias de transición La solución más fácil y la más recomendable es la implementación de Dual-Stack, pues permite que cualquier topología de red trabaje con ambos protocolos. Actualmente el ruteo Dual-Stack es una estrategia muy utilizada en el desarrollo de infraestructuras de red que manejan aplicaciones que trabajan con protocolos IPv4 e IPv6. Sin embargo, existen ciertas limitaciones para el uso de esta alternativa; a más de la obvia necesidad de actualizar todos los routers de una red se suman problemas como que todos los routers requieren la definición de un doble esquema de direccionamiento, además se necesita una doble administración de los protocolos de ruteo, y por último, que los routers deben ser configurados con suficiente memoria para almacenar las tablas de ruteo de ambos protocolos. Cuando los routers no pueden implementar IPv6, se debe implementar túneles IPv6 en IPv4. 229

246 Los túneles estáticos tales como el túnel manual corriente y GRE (Generic Route Encapsulation), tiene el inconveniente de que no son prácticos cuando la cantidad de túneles a implementar es grande o cuando las direcciones IP son cambiantes. Respecto a los túneles automáticos puede concluirse lo siguiente: Túnel 6to4. Tiene la ventaja de que de forma automática asigna espacio de direcciones IPv6, pero no puede atravesar NATs. Solo se implementa en routers de borde. Se recomienda su uso en redes pequeñas o redes de hogar donde no existe NAT y no es aplicable en empresas ni para grandes redes. Túnel ISATAP. Es adecuado para redes de empresas pero no para ISPs ni para redes de hogar. Además, este mecanismo no funciona cuando existen NATs en el camino entre dos nodos ISATAP. TSP Tunnel broker. Tiene la ventaja de atravesar cualquier tipo de NAT y es la única posibilidad de acceso a la Internet IPv6 de nodos de doble pila que se encuentren tras routers que por su tecnología no pueden ser habilitados para IPv6, pero para su implementación se requiere de la presencia externa de Agentes y de servidores de túnel. Este túnel puede tener inconvenientes para su funcionamiento si las protecciones (firewalls) de las redes impiden el paso de los mensajes correspondientes a este protocolo. Túnel Teredo. Permite a los nodos establecer túneles IPv6 sobre IPv4 a través de NATs empleando encapsulamiento IPv6 en UDP-IPv4, aunque su uso está restringido cuando existen NATs simétricos en la red. Para la implementación de este túnel de requiere de un servidor Teredo (Teredo server) y de un repetidor o relé Teredo (Teredo relay), pero se sabe que hay disponibles muchos repetidores Teredo bien dispersos en la Internet IPv4 y en la Internet Ipv6. 230

247 5.4.9 Técnicas de traducción Las técnicas de traducción permiten un enrutamiento transparente en la comunicación entre nodos que solamente soportan una versión del protocolo IP o que utilizan doble pila. Estos mecanismos pueden actuar de diferentes formas y en distintas capas, traduciendo encabezados IPv4 a encabezados IPv6 y viceversa, realizando conversiones de direcciones de APIs de programación, o actuando en el intercambio de tráfico TCP o UDP SIIT SIIT (Stateless IP/ICMP Translation Algorithm) - Definido en la RFC 2765, SIIT es un mecanismo de traducción stateless de encabezados IP/ICMP que permite la comunicación entre nodos que solo soportan IPv6 y nodos que solo soportan IPv4. Utiliza un traductor ubicado en la capa de red de la pila, el cual convierte campos específicos de los encabezados de paquetes IPv6 en encabezados de paquetes IPv4 y viceversa. Para realizar este proceso el traductor necesita una dirección IPv4-mapeada en IPv6, en el formato 0::FFFF:a.b.c.d, que identifica el destino IPv4 y una dirección IPv4-traducida en formato 0::FFFF:0:a.b.c.d, para identificar el nodo IPv6. Cuando el paquete llega al SIIT, el encabezado se traduce, la dirección se convierte a IPv4 y se encamina al nodo de destino BIS BIS (Bump in the Stack) - Este método permite la comunicación de aplicaciones IPv4 con nodos IPv6. Definida en la RFC 2767, BIS funciona entre la capa de aplicación y la capa de red, agregando a la pila IPv4 tres módulos: translator, que traduce los encabezados IPv4 enviados a encabezados IPv6 y los encabezados IPv6 recibidos a encabezados IPv4; extension name resolver, que actúa en las 231

248 DNS queries realizadas por IPv4, de modo que, si el servidor de DNS devuelve un registro AAAA, el resolver pide al address mapper que asigne una dirección IPv4 correspondiente a la dirección IPv6; y address mapper, que posee una cierta cantidad de direcciones IPv4 para asociar a direcciones IPv6 cuando el translator recibe un paquete IPv6. Como las direcciones IPv4 no se transmiten en la red, éstas pueden ser direcciones privadas. Este método solo permite la comunicación de aplicaciones IPv4 con hosts IPv6 y no lo contrario y además no funciona en comunicaciones multicast BIA BIA (Bump in the API) - Similar al BIS, este mecanismo agrega una API de traducción entre el socket API y los módulos TPC/IP de los hosts de doble pila, permitiendo la comunicación entre aplicaciones IPv4 y hosts IPv6, traduciendo las funciones del socket IPv4 en funciones del socket IPv6 y viceversa. De acuerdo con los descrito en la RFC 3338, se agregaron tres módulos, extension name resolver y address mapper, que funcionan de la misma manera que en BIS, y function mapper, que detecta las llamadas de las funciones del socket IPv4 e invoca las funciones correspondientes del socket IPv6 y viceversa. BIA tiene dos ventajas respecto a BIS: no depende del driver de la interfaz de red y no introduce overhead en la traducción de los encabezados de los paquetes. Sin embargo, tampoco soporta comunicaciones multicast TRT TRT (Transport Relay Translator) - Actuando como un traductor de capa de transporte, este mecanismo permite la comunicación entre hosts solo IPv6 y hosts solo IPv4 a través de tráfico TCP/UDP. Sin necesidad de instalar ningún tipo de 232

249 software, TRT corre en equipos con doble pila que se deben insertar en un punto intermedio dentro de la red. En la comunicación de un host IPv6 con un host IPv4, de acuerdo con la definición de la RFC 3142, a la dirección IPv4 de destino se le agrega un prefijo IPv6 falso. Cuando un paquete con este falso prefijo atraviesa el TRT, dicho paquete es interceptado y enviado al host IPv4 de destino en un paquete TCP o UDP. En la traducción TCP y UDP el checksum solo se debe recalcular en el caso de las conexiones TCP, el estado del socket sobre el cual el host está conectado debe ser mantenido, retirándolo cuando la comunicación haya finalizado. Para que el mecanismo funcione de forma bidireccional es necesario agregar un bloque de direcciones IPv4 públicas y usar un servidor DNS-ALG para mapear las direcciones IPv4 a IPv6. 233

250 6. CONCLUSIONES Con base en el estudio y análisis realizado alrededor del protocolo IPv6 y en las implementaciones y simulaciones desarrolladas, se puede concluir que el protocolo IPv6 ha logrado ya un alto grado de madurez, lo cual permite su implantación sin ningún traumatismo en cualquier tipo de red y su coexistencia con el protocolo IPv4. Para iniciar la implementación de estrategias de transición, ya sea en forma simulada, implementada en laboratorio o realizada directamente en una red real, se requiere del estudio previo y completo de los fundamentos del protocolo IPv6. Esto facilita la comprensión de la documentación disponible y lleva a la implementación correcta y eficiente del proceso de transición. La solución más fácil de implementar y más completa es la estrategia de la doble pila, pues ésta permite que las redes trabajen con ambos protocolos a la vez. Sin embargo, la implementación completa de éste mecanismo solo es posible cuando todos los routers de la red poseen la capacidad necesaria para poder correr una versión del sistema operativo que incluya el protocolo IPv6. Cuando los routers no pueden implementar IPv6 se debe recurrir a la utilización de túneles. Las diversas estrategias de transición implementadas (pila dual y entunelamiento), de forma individual no proveen una solución completa al realizar la implantación del protocolo IPv6 en una red que no soporte los dos protocolos. Por lo tanto, es necesario combinarlas entre sí para lograr los objetivos en forma más eficiente. 234

251 La utilización de un tipo particular de túnel dentro de los diversos tipos que existen, depende en general del tamaño de la red, del número de túneles a implementar, de si la numeración de la red es fija, de si los nodos que se van a actualizar al protocolo IPv6 se encuentran detrás de un dispositivos NAT y del tipo de NAT a ser atravesado. Algunas estrategias de transición como los túneles automáticos Teredo y TSP tunnel broker, no pueden ser simuladas ni implementadas en el laboratorio, por cuanto se requiere de servidores, agentes y repetidores externos especiales que normalmente no están presentes en un simulador, sino que se encuentran dispersos en la Internet. En este caso se requiere de la realización de una implementación en una red real. 235

252 7. RECOMENDACIONES Incrementar la presencia de la industria y la comunidad académica colombiana en proyectos relacionados con IPv6. Incrementar las actividades de investigación en la comunidad académica. Incrementar la difusión y formación en IPv6 en la comunidad académica por medio de capacitaciones tanto teoricas como practicas. Promover la implementación de redes, sercivios y aplicaciones IPv6 en la red de la Universidad de San Buenaventura. Desarrollar futuras investigaciones en torno a protocolos como: IPsec, MobileIPv6 y QoS (calidad de servicio). 236

253 ANEXO A INSTALACION Y CONFIGURACIÓN DE GNS3 EN WINDOWS XP El primer paso para la instalación es descargar el archivo, GNS3-0.6-win32-allinone.exe (ocupa aproximadamente 8MB), que se encuentra en la página web El archivo anterior contendrá la versión binaria de los siguientes programas: Dynamips Dynagen : Ambos programas son la base para el funcionamiento de GNS3. Pemu 0.2.3: Es un emulador de firewalls PIX de Cisco basado en QEMU que no es más que una máquina emuladora y virtualizadora de código libre. WinPcap 4.0.2: Permite la comunicación de redes virtuales con redes reales, ya que se encarga de detectar las interfaces reales del PC de trabajo para que el simulador pueda asignarlas como extremo de un enlace hacia un router virtual. Instalar GNS3 En esta sección, una vez se haya dado doble clic al archivo que acaba de descargar, los sucesivos cuadros de diálogo lo guiarán durante el proceso de instalación de forma habitual. La mayoría de los valores que aparecen por defecto son los que aceptaremos en la instalación, a no ser que se desee cambiar el directorio donde se instalará el simulador GNS3. Los pasos para la instalación son: 237

254 1) Dar doble clic al archivo de instalación descargado anteriormente. Nos aparecerá una ventana como la que se muestra en la figura Anexo 1.1. Hacer clic en Next. 2) Aceptar la licencia haciendo clic en el botón I Agree como se observa en la figura Anexo 1.1 Figura Anexo A.1 Proceso de Instalación GNS3 3) Indicar el nombre del directorio de inicio de GNS3. Seguidamente hacer clic en Next. Ver figura Anexo 1.2 4) Aceptar todos los componentes que se instalarán por defecto. Hacer clic en Next. Ver figura Anexo 1.2 Figura Anexo A.2 Proceso de instalación GNS3 238

255 5) En la figura Anexo 1.3, Indicar la ubicación del directorio donde se instalará al simulador. Seguidamente hacer clic en install. 6) Antes de concluir la instalación de GNS3, aparecerá la ventana que da inicio a la instalación de WinPcap como se muestra en la figura Anexo 1.3. Hacer clic en Next. Figura Anexo A.3 Proceso de Instalación GNS3 7) Aceptar la licencia de WinPcap haciendo clic en I Agree. Ver figura Anexo ) Después de la instalación de WinPcap, se retomará la instalación de GNS3 y cuando ésta termine aparecerá una ventana como en la figura Anexo 1.3. Hacer clic en Finish para terminar la instalación. Figura Anexo A.4 Proceso de Instalación GNS3 239

256 9) Tras la finalización de la instalación, podemos ejecutar la aplicación desde Programas en el menú de Inicio o haciendo doble click en el icono correspondiente del escritorio, y aparecerá la pantalla de la Figura Anexo 1.4. Figura Anexo A.5 Ventana de GNS3 en Windows 10) Al momento de ejecutar el programa aparecerá una ventana como la que se muestra en la figura Anexo 1.5, la cual podemos obviar ya que su función es reemplazada siguiendo los pasos de los 2 siguientes apartados. Figura A.6 Complemento de instalación de GNS3 240

257 Carga de los CISCO IOS El siguiente paso es la carga de la imagen IOS que usarán los routers virtuales de nuestra topología, para lo cual realizaremos los siguientes pasos: 1) Ejecutar la aplicación y seleccionar IOS images and hypervisors en el menú Edit, como se muestra en la figura Anexo 1.6 Figura Anexo A.7 Carga de CISCO IOS en GNS3 2) En la ventana que aparece, hacer un clic sobre para buscar la ubicación de la imagen IOS en el PC. Ver la figura Anexo 1.7 Figura Anexo A.8 Ubicación de CISCO en GNS3 3) Seguidamente elegiremos la plataforma y el modelo que corresponde con la imagen IOS que usaremos para simular. 241

258 Figura Anexo A.9 Selección de CISCO en GNS3 4) Finalmente guardamos los cambios haciendo clic en Save. Notar que el valor de IDLE-PC se encuentra vacío por el momento. Figura Anexo A.10 Almacenamiento de CISCO en GNS3 Comprobar el path hacia Dynamips Una vez instalado GNS3 es importante comprobar si el simulador ha podido reconocer de forma eficaz el path donde se encuentra instalado Dynamips para que pueda usarlo correctamente. Los pasos para realizar esta tarea son los siguientes: 1) En la aplicación, seleccionar la opción Preferences del menú Edit, como se muestra en la figura Anexo

259 Figura A.11 Inicio de Comprobación de Path de Dynamips 2) En la ventana que aparece hacer un clic sobre Dynamips para obtener la pestaña donde se muestra la ubicación de Dynamips. Comprobar que el path que se muestran es correcto haciendo clic en si obtenemos algún error buscar la verdadera ubicación Dynamips haciendo clic sobre. No olvidar comprobar que se encuentren habilitadas las funciones de Ghostios, Sparsemem y MMAP. Figura Anexo A.12 Comprobación de path de Dynamips 3) Hacer clic en Apply para guardar los datos. 243