Proyecto Fin de Carrera Ingeniería de Telecomunicación. DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6

Transcripción

1 Proyecto Fin de Carrera Ingeniería de Telecomunicación DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 Autor: Miguel Miralles Cabeza Tutor: Juan Antonio Ternero Muñiz Departamento de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2014

2

3 Proyecto Fin de Carrera Ingeniería de Telecomunicación DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 Autor: Miguel Miralles Cabeza Tutor: Juan Antonio Ternero Muñiz Profesor colaborador Departamento de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2014

4

5 Proyecto Fin de Carrera: DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 Autor: Tutor: Miguel Miralles Cabeza Juan Antonio Ternero Muñiz El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2014 El Secretario del Tribunal

6

7 Agradecimientos Este proyecto no hubiera sido posible sin la ayuda de mi tutor el cual me ha facilitado el material y los medios para poder llevarlo a cabo. Además su conocimiento en la materia me ha ayudado a comprender mejor los conocimientos básicos necesarios para llevar a cabo este proyecto. Agradecer a la Escuela de Ingenieros de Sevilla por proporcionar una educación de calidad. Y también a sus profesores, por nutrir con sus conocimientos y experiencias a los alumnos. Y sobre todo quiero dedicar este proyecto a mi familia y amigos por estar siempre ahí en todo momento. Sin ellos no habría alcanzado las metas que he logrado en mis días. Sin ellos no sería la persona que soy. Sin ellos mi vida no tendría sentido. Muchas gracias a todos. Miguel Miralles Cabeza Sevilla, 2014 i

8

9 Resumen Hoy en día, son cada vez más frecuentes pequeños dispositivos portátiles, que gracias a las tecnologías inalámbricas, nos permiten acceder a Internet desde cualquier lugar. Aunque tenemos conectividad en todo instante, sería interesante mantener en todo momento la misma dirección IP, sin embargo, el protocolo IP no se diseñó para esta funcionalidad. Es por ello que se elaboró el protocolo de movilidad pensado en solventar ese problema. No obstante, a pesar de las ventajas que ofrece, IP móvil aún no se ha extendido por problemas de implementación a gran escala, por lo que su uso se está limitando a escenarios de prueba. Sin embargo, es difícil encontrar proyectos donde expliquen cómo implementar la movilidad y hagan un estudio exhaustivo de este protocolo. Este proyecto explica cómo crear un escenario de movilidad en IPv6 desde cero. Para ello se usan equipos de bajo coste donde se instalan el software de código abierto UMIP diseñado para implementar la movilidad. Usando este escenario se realizarán una serie de pruebas para entender el funcionamiento de IP móvil e intentar medir su rendimiento. iii

10

11 Abstract Nowadays, small portable devices are used more frequently. Thanks to wireless technologies, it allows us to connect to Internet anywhere. Although we have connectivity at any time, it would be interesting to keep also at any time the same IP address, but IP protocol was not designed for this duty. In order to resolve this problem, IP mobility was developed. In spite of the advantages that this protocol offers, it has not extended yet because of large-scale implementation problems. For this reason, it is used only in testing scenarios. However, it is difficult to find projects which explain how to implement mobility and make an exhaustive study of this protocol. This project shows how to create a scenario for mobility in IPv6 from scratch. With this in view, it will be used low-cost devices where UMIP have been installed, an open source which is designed to implement mobility. Some tests will take place through this scenario. The results will serve to understand the behavior of Mobile IPv6 and try to measure the throughput. v

12 Índice Agradecimientos i Resumen iii Abstract v Índice vi Índice de Códigos ix Índice de Figuras xi Notación xiii 1 Introducción Estado del Arte Alcance y Objetivos 2 2 Internet Protocol Version 6 (IPv6) Motivación Cabecera IPv Las direcciones en IPv Representación Subredes Tipos de direcciones Stateless Address Autoconfiguration (SLAAC) IPsec (Internet Protocol security) Internet Control Message Protocol version 6 (ICMPv6) Neighbor Discovery (ND) 12 3 Mobile IPv6 (MIPv6) Historia y motivación Funcionamiento básico Cabecera MIPv Mensajes importantes Modificación en otros protocolos Seguridad Despliegue a gran escala Proyecto UMIP 21 4 Desarrollo Del Escenario Equipos utilizados Configuración del Router Instalación Software de Movilidad Recompilar Kernel Compilar e instalar UMIP Configuración s1ipv Configuración s2ipv Configuración CN1 35

13 4.7. Esquema de conexión Arrancar servicios de Movilidad 36 5 Análisis Análisis del funcionamiento Prueba 1: Ping6 con traspaso Prueba 2: Ping6 con regreso Prueba 3: Ping6 con traspaso (ESP) Análisis del rendimiento Prueba 1: UDP del CN al MN Prueba 2: Transferencia fichero del CN al MN 54 6 Conclusiones y Trabajos Futuros 61 Anexo A: Características de equipos 63 Anexo B: Instalación Minicom 67 Anexo C: Instalación FileZilla 69 Anexo D: Script de Arranque 71 Anexo E: Script para Traspaso 75 Anexo F: Instalación Iperf y Jperf 77 Anexo G: Gráficas con Wireshark 79 Bibliografía 83 Índice de Conceptos 87 vii

14

15 Índice de Códigos Código 4-1. Configuración inicial del router. 24 Código 4-2. Crear VLAN. 26 Código 4-3. Archivo de configuración MN. 31 Código 4-4. Configuración de las SA de IPsec. 32 Código 4-5. Archivo de configuración HA. 34 Código 4-6. Configuración de radvd. 35 ix

16

17 Índice de Figuras Figura 2-1. Cabecera IPv6. 3 Figura 2-2. Bloques de direcciones para subredes IPv6 por RedIRIS. 5 Figura 2-3. Estructura dirección Unicast Global. 6 Figura 2-4. Estructura dirección de Enlace Local. 6 Figura 2-5. Estructura dirección IPv4 dentro de IPv6. 6 Figura 2-6. Estructura de direcciones Multicast. 6 Figura 2-7. Dirección Anycast para routers de una subred. 7 Figura 2-8. Algoritmo EUI Figura 2-9. Formato AH (arriba) y formato ESP (abajo). 9 Figura Requisitos de implementación de algoritmos para AH y ESP según RFC Figura ICMPv6 encapsulado dentro de paquete IPv6. 10 Figura Cabecera ICMPv6. 11 Figura Mensajes ICMPv6. 11 Figura Escenarios donde se usan ND. 12 Figura 3-1. Modo de túnel bidireccional. 15 Figura 3-2. Modo Route Optimization. 15 Figura 3-3. Cabecera MIPv6. 16 Figura 3-4. Formato Mensaje Binding Update. 17 Figura 3-5. Formato Mensaje Binding Acknowledgement. 18 Figura 3-6. Formato Mensaje Binding Error. 18 Figura 4-1. Características VLANs. 26 Figura 4-2. Esquema de conexión. 36 Figura 5-1. Escenario prueba 1 con MN en casa. 40 Figura 5-2. Escenario prueba 1 con MN en FN. 41 Figura 5-3. Mensajes a la llegada del MN a la FN. 42 Figura 5-4. Mensaje BU enviado por el MN. 43 Figura 5-5. Mensaje BA enviado por el HA. 44 Figura 5-6. Mensajes Echo request/reply cuando MN está en FN. 45 Figura 5-7. Mensajes BU cuando MN regresa a casa. 46 Figura 5-8. Mensajes directos entre CN y MN. 47 Figura 5-9. Tráfico encriptado con ESP. 48 Figura Escenario prueba UDP sin traspaso. 49 Figura Resultados de experimentos UDP sin traspaso. 50 Figura Escenario 1 prueba UDP con traspaso. 51 xi

18 Figura Escenario 2 prueba UDP con traspaso. 51 Figura Paquetes seleccionados con el filtro en Wireshark. 52 Figura Gráfico I/O prueba UDP con traspaso. 53 Figura Resultados pruebas UDP con traspaso. 53 Figura Escenario prueba TCP sin traspaso. 54 Figura Resultados pruebas TCP sin traspaso. 55 Figura Escenario 1 prueba TCP con traspaso. 55 Figura Escenario 2 prueba TCP con traspaso. 56 Figura Gráfica Stevens de los datos FTP. 57 Figura Gráfica RTT de los datos FTP. 58 Figura Gráfica RTT de los datos FTP (2). 58 Figura Resultados pruebas TCP con traspaso. 59 Figura Tabla y gráfica comparativa de tiempos de transferencia TCP sin/con traspaso. 60 Figura Tabla y gráfica comparativa de paquetes enviados TCP sin/con traspaso. 60

19 Notación AH Autentication Header BA Binding Acknowledgement BE Binding Error BU Binding Update BUL Binding Update List CIDR Classless Inter-Domain Routing CN Correspondent Node ESP Encapsulation Security Payload FN Foreign Network HA Home Agent HoA Home of Address HN Home Network ICMPv6 Internet Control Message Protocol version 6 IEEE Institute of Electrical and Electronic Engineers IKE Internet Key Exchange IPsec Internet Protocol security IPv4 Internet Protocol versión 4 IPv6 Internet Protocol version 6 MAC Media Access Control MIPv6 Mobile IP version 6 MN Mobile Node NA Neighbor Advertisement NAT Network Address Translation ND Neighbor Discovery NS Neighbor Solicitation OSI Open System Interconnection RA Router Advertisement RFC Request For Comments RS Router Solicitation RTT Round-Trip delay Time SA Security Association SLAAC Stateless Address Autoconfiguration SO Sistema Operativo TCP Transmission Control Protocol UDP User Datagram Protocol VLAN Virtual Local Area Network xiii

20

21 1 INTRODUCCIÓN Dime y lo olvidaré. Muéstrame y lo recordaré. Involúcrame y lo entenderé. Proverbio chino E ste proyecto trata sobre la movilidad en IP versión 6 (MIPv6 a partir de ahora). El texto partirá de los conceptos básicos de Internet Protocol version 6 (IPv6), y continuará su desarrollo presentado los principios básicos de la movilidad. Una vez comprendamos el funcionamiento de ésta, procederemos a abarcar el principal objetivo del proyecto: crear y configurar un escenario de pruebas. Éste nos servirá para comprender mejor cómo funciona la movilidad y hacer un análisis sobre su rendimiento Estado del Arte Aprovecharemos este apartado para hacer un repaso histórico a la movilidad IPv6 y ver en qué estado se encuentra en la actualidad. A principios de siglo, se empieza a buscar una alternativa a la movilidad en IPv4, y buscar un homólogo que corrija sus defectos y se implemente en el sucesor del protocolo de Internet (IPv6). Comienzan a redactarse los primeros textos que darán lugar, en el año 2004, al primer RFC sobre movilidad. En torno a ese año hay un aumento de artículos en Internet que hablan de los conceptos y funcionamiento básicos de MIPv6 (algunos de ellos puede encontrarlos en la bibliografía sobre el capítulo 3). Una vez que se estudia un poco más sobre este protocolo y se van encontrando deficiencias, surgen nuevos RFC que intentan solventarlas. Algunos de estos problemas van desde la seguridad, hasta uno de los más recientes que es incorporar el bootstrapping. En general, hay poca bibliografía que profundice en el tema de la movilidad IPv6. En su mayoría, como hemos dicho antes, tratan de explicar lo básico para entender la problemática de la movilidad y la solución que plantea MIPv6. También es difícil encontrar proyectos de relevancia que estudien o implementen MIPv6. A pequeña escala hallamos los proyectos KAME y USAGI, cuyo objetivo es crear escenarios controlados donde implementar MIPv6 a través de código abierto Linux creado por ellos mismos. El proyecto KAME se cerró en 2006 y el USAGI se halla abandonado desde hace años, pero su relevo lo ha cogido UMIP, que va adquiriendo importancia y cada vez son más organismos los que colaboran para incluir el código de soporte de nuevos RFC que introducen mejoras en MIPv6, como puede ser por ejemplo el uso de IKEv2. También encontramos el proyecto TAHI, que es un organismo que se encarga de hacer test sobre tecnología IPv6, entre ellas MIPv6. Este proyecto ha realizado test de rendimiento a KAME, USAGI y UMIP. En cuanto a proyectos a gran escala, solo encontramos ENABLE (Enabling efficient and operational mobility 1

22 2 Introducción in large heterogeneous IP networks). El cual se trata de un importante proyecto IST cofinanciado por la Unión Europea con un coste de casi 4 millones de euros. Se inició en 2006 y con una duración de dos años, su principal objetivo fue conseguir el despliegue a gran escala de la movilidad sobre entornos IPv6, teniendo en cuenta la transición desde IPv4. En este proyecto se colaboró con organismos de estandarización como el IETF, 3GPP, etc., ya que se abordaron temas abiertos, como por ejemplo el bootstrapping. No es de extrañar que gracias a esta colaboración, después de la finalización del proyecto se crearan RFC que solucionara tal problema (RFC 5026 y RFC 6611) Alcance y Objetivos El objetivo principal de este proyecto es crear y configurar un escenario de pruebas, compuestos por equipos que serán configurados con software de movilidad ya creados, es decir, nuestro alcance no incluye saber cómo está creado ese software ni cómo se modifica. Otro objetivo es hacer pruebas sobre ese escenario para entender el funcionamiento de la movilidad, además de valorar su rendimiento. Entendiendo éste como el retardo que sufre un paquete en alcanzar su destino y si se producen pérdidas de paquetes por culpa de la movilidad.

23 2 INTERNET PROTOCOL VERSION 6 (IPV6) C omo nuestro proyecto trata sobre la movilidad en IPv6, es necesario conocer algunos aspectos básicos de este protocolo para poder entender con mayor facilidad el desarrollo de este texto. En un primer lugar veremos la motivación que llevó a crear este protocolo que reemplaza a IPv4, y continuaremos hablando sobre sus características más relevantes Motivación Cuando se creó IPv4, en los años 70, sus creadores no predijeron en ningún momento el enorme impacto que este protocolo iba a tener en la sociedad. Gran parte de su éxito tiene que ver con la evolución de la tecnología que ha posibilitado que haya más equipos informáticos a menor precio, lo que implica que cada vez se encuentren más dispositivos usando IPv4 y más protocolos que lo usen como soporte. Todo esto ha llevado a que las 2 32 direcciones que provee IPv4 comenzaran a escasear hace años. En un principio se idearon mecanismos para alargar la vida de este protocolo, como CIDR (Classless Inter-Domain Routing) y NAT (Network Address Translation), pero era evidente que había que crear uno nuevo que solucionara este problema: Internet Protocol version 6 (IPv6) nacida en el RFC Este protocolo nos proporciona direcciones, solucionando con creces el problema de falta de direcciones. Además, aprovechando la necesidad de que se iba a crear un nuevo protocolo, se cambiaron algunos aspectos de IPv4, por ejemplo, se opta por usar una cabecera de tamaño fijo, desaparece el protocolo ARP ya que la difusión afecta a la eficiencia de la red, se adopta como uso obligatorio IPsec (que es opcional en IPv4), entre otros cambios Cabecera IPv6 En la siguiente figura se muestra la cabecera adoptada en este protocolo [2-1]: Versión Clase de Tráfico Etiqueta de Flujo Longitud de la Carga Útil Siguiente Cabecera Límite de Saltos Dirección Origen (128 bits) Dirección Destino (128 bits) Figura 2-1. Cabecera IPv6. A continuación, vamos a explicar cada uno de los campos [2-2]: Versión (Version): indica la versión del protocolo IP usado, en este caso toma siempre el valor 6. 3

24 4 Internet Protocol Version 6 (IPv6) Clase de Tráfico (Traffic Class): se usa para distinguir entre las diferentes clases o prioridades de paquetes IPv6. Etiqueta de Flujo (Flow Label): solicita un manejo especial por los enrutadores IPv6, tal como la calidad de servicio no estándar o el servicio en "tiempo real". Longitud de la Carga Útil (Payload Length): es un entero sin signo de 16 bits. Como su nombre indica, nos dice la longitud de la carga útil IPv6, es decir, el resto del paquete que sigue a la cabecera IPv6, en octetos. Las cabeceras de extensión son consideradas parte de la carga útil. Siguiente Cabecera (Next Header): identifica el tipo de cabecera que sigue inmediatamente a la cabecera IPv6. Utiliza los mismos valores que el campo protocolo de IPv4. Límite de Saltos (Hop Limit): valor máximo de saltos que puede dar un paquete. Se decrementa de uno en uno para cada nodo que reenvía el paquete, descartándose éste cuando el valor llega a cero. Dirección Origen (Source Address): dirección del que origina el paquete. Dirección Destino (Destination Address): dirección del destinatario del paquete. Cabe destacar que los campos Clase de Tráfico y Etiqueta de Flujo, nos permiten usar Calidad de Servicio (QoS) y Clase de Servicio (CoS), que son mecanismos de control de flujo y asignación de prioridades diferenciadas en función de los tipos de servicios. Como hemos comentado, el campo Siguiente Cabecera indica la cabecera de extensión que viene a continuación. Según se indique, éstas pueden ser interpretadas hop-by-hop (salto a salto) o únicamente en el nodo destinatario (que se procesarán en el mismo orden que se introdujeron en el origen). Ésta última tiene la ventaja de acelerar el paso del paquete por nodos intermedios, ya que el encaminador tendrá que examinar menos bits. También es una ventaja que la cabecera tenga un tamaño fijo (y no variable como en IPv4) porque así se consume menos tiempo de CPU en los encaminadores Las direcciones en IPv Representación El RFC 4291: Arquitectura del Direccionamiento del Protocolo de Internet versión 6, define los tres formatos para representar direcciones IPv6 [2-3]. El primero de ellos es el formato completo, el cual tiene la siguiente estructura: x:x:x:x:x:x:x:x, donde cada x representa cuatro caracteres hexadecimales, obteniendo un campo de 16 bits que puede tomar desde el valor 0000 hasta FFFF. Ejemplos de direcciones IPv6 en su formato completo es: FEDC:BA98:7654:3210:FEDC:BA98:7654: :0:0:0:8:800:200C:417A Nótese que en esta última dirección, no ha sido necesario escribir todos los ceros en un campo individual, pero sí que es importante que haya al menos un cero en cada campo. Dado que las direcciones IPv6 resultan bastante largas de escribir, y a priori más difíciles de recordar, se define un segundo formato de representación, que no es más que una simplificación del primero. Esta reducción consiste en sustituir uno o más campos con solo ceros por :: (dos puntos dobles). Por ejemplo, las siguientes direcciones: 0:0:0:0:0:0:0:0 se puede simplificar así :: 0:0:0:0:0:0:0:1 puede escribirse ::1 1080:0:0:0:8:800:200C:417A también puede ponerse como 1080::8:800:200C:417A Eso sí, los dos puntos dobles solo pueden aparecer una vez dentro de una misma dirección, por lo que 2001:720:0:0:235:0:0:0:BB10 no puede escribirse así: 2001:720::235::BB10. Sería correcto de la siguiente manera: 2001:720:0:0:235::BB10 El último formato de representación que se explica en el RFC 4291, está pensado para incrustar una dirección IPv4 en una dirección IPv6. Ésta sería: x:x:x:x:x:x:d.d.d.d, donde las x es un campo de 16 bits formado por

25 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 5 caracteres hexadecimales, y las d son campos de 8 bits formados por caracteres decimales, es decir, las cuatro d forman una dirección estándar de IPv4. A continuación se muestra una dirección IPv4 incrustada en IPv6: 0:0:0:0:0:0: , o en su forma compacta: :: Subredes En IPv6 sólo se permite representar una máscara de red mediante notación CIDR. Un ejemplo de representación sería el siguiente: 12AB:0:0:CD30::/60 La parte de la izquierda de la barra / representa la dirección de la red, y tiene que tener el formato explicado en el apartado La parte de la derecha, indica la longitud del prefijo y está en formato decimal. En cuanto a la longitud del prefijo, se recomienda que sea múltiplo de 4. Hay organismos como RedIRIS que asignan rangos a seguir como los siguientes [2-4]: Prefijo Asignado a Número de direcciones /36 Proveedores de Servicio de Internet 2 96 /48 Organizaciones 2 80 /64 Subredes de la Organización 2 64 /128 Host 1 Figura 2-2. Bloques de direcciones para subredes IPv6 por RedIRIS. Antes de dar por terminado esta sección, tenemos que tener en cuenta lo siguiente: Los bits puestos a 1 en la máscara de red define la longitud del prefijo de red y la parte restante es para el direccionamiento del host, al igual que en IPv4. En IPv4 se reservaba la primera dirección de un rango para identificar a la subred, y la última para difusión dentro de la subred. En IPv6 no existe tal reserva de direcciones Tipos de direcciones En IPv6 encontramos tres tipos de direcciones [2-5]: Unicast: se usa para identificar una sola interfaz de un nodo IPv6. Un paquete que se envía a una dirección Unicast es entregado a la interfaz identificada por esa dirección. Multicast: se utiliza para identificar un grupo de interfaces IPv6. Un paquete enviado a una dirección Multicast, es procesado por todos los miembros del grupo multicast. Anycast: esta dirección es asignada a múltiples interfaces (que usualmente se hallan en múltiples nodos). Un paquete que se envíe a una dirección Anycast se entrega a la interfaz más cercana (desde el punto de vista de latencia que determine el protocolo de encaminamiento usado). Dentro de las direcciones Unicast se agrupan los siguientes tipos de direcciones: Globales: son las utilizadas para el tráfico IPv6 genérico en Internet. Dentro de su estructura, como se puede ver en la figura que se presenta más abajo, existe un prefijo de enrutamiento global que generalmente es el que se asigna a las organizaciones, un identificador de subred, que se usa para las subredes dentro de la organización, y un identificador de interfaz, para identificar al host. El formato de la dirección fue descrito en la sección anterior.

26 6 Internet Protocol Version 6 (IPv6) n bits m bits 128-n-m bits Prefijo de enrutamiento global Identificador de subred Identificador de interfaz Figura 2-3. Estructura dirección Unicast Global. Enlace local (Link-Local): se usa en mecanismos de autoconfiguración, descubrimiento de vecinos o en situaciones donde no hayan routers. Nunca debe ser enrutada (por lo que su ámbito queda restringido a la red local) y puede ser usada sin prefijo global. La estructura usada es la siguiente: 10 bits 54 bits 64 bits Identificador de interfaz Figura 2-4. Estructura dirección de Enlace Local. Por lo que una dirección de Enlace Local se representaría así: FE80::<Id.interfaz>/10 Sitio local (Site-Local): está desaprobada. Las nuevas implementaciones deben tratarla como una dirección Unicast Global. Loopback: esta dirección tiene el mismo propósito que en IPv4. Cada dispositivo la usa para referirse a sí mismo. En formato completo, esta dirección toma la siguiente forma: 0000:0000:0000:0000:0000:0000:0000:0001, y en el formato comprimido: ::1 Sin especificar (Unspecified): se usa para indicar ausencia de dirección en una interfaz. Es representada en el formato completo así: 0000:0000:0000:0000:0000:0000:0000:0000, y en el comprimido con los dos puntos dobles. Compatible con IPv4: hay dos tipos de direcciones IPv6 definidas para llevar en su interior una dirección IPv4 de 32 bits. La primera de ellas está desaprobada, por lo que a continuación solo mostramos la segunda de ellas: 80 bits 16 bits 32 bits FFFF Dirección IPv4 Figura 2-5. Estructura dirección IPv4 dentro de IPv6. Continuemos esta sección hablando de las direcciones Multicast. Una dirección Multicast en IPv6 puede definirse como un identificador para un grupo de nodos, donde un nodo puede pertenecer a uno o varios grupos Multicast. Las direcciones Multicast tienen el siguiente formato 1 [2-2]: 8 bits 4 bits 4 bits 112 bits T Ámbito Identificador de Grupo Figura 2-6. Estructura de direcciones Multicast. El significado del bit T es el siguiente: Si T vale 0 : dirección permanente asignada por la autoridad de numeración global de Internet. 1 Hay que tener en cuenta que existen direcciones Multicast predefinidas. Para ver cuáles son, no dude en consultar la sección del RFC 4291 [2.3]

27 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 7 Si T vale 1 : dirección temporal. El campo Ámbito representa a un grupo de bits cuyos valores pueden ser los siguientes: 0- Reservado. 1- Ámbito local de nodo. 2- Ámbito local de enlace. 3- No asignado. 4- No asignado. 5- Ámbito local de sitio. 6- No asignado. 7- No asignado. 8- Ámbito local de organización. 9- No asignado. A- No asignado. B- No asignado. C- No asignado. D- No asignado. E- Ámbito global. F- Reservado. Y para terminar esta sección, explicamos un poco más en detalle en qué consiste una dirección Anycast. Como dijimos unos párrafos más arriba, una dirección Anycast identifica a un grupo de interfaces al igual que las direcciones Multicast, pero en este caso, el paquete no se entrega a todas las interfaces, sino a aquella que se encuentre más cerca dentro del grupo de direcciones Anycast, donde esa cercanía vendrá determinada según el protocolo de encaminamiento que se use. En resumen, si una dirección Multicast define una comunicación uno a muchos, una dirección Anycast define una comunicación uno a uno-entre-muchos. También hay que citar que una dirección Anycast nunca puede ser origen de un paquete. En cuanto al ámbito de representación, no cuenta con uno propio como es el caso de las Multicast, sino que usa mismo de las direcciones Unicast, por lo que a priori no podremos saber de qué tipo de dirección se trata. Hay una dirección Anycast especial, llamada Subnet-Router Anycast Address (Dirección Anycast del Router de la Subred), la cual debe ser soportada por todos los routers. Uno de sus objetivos es que un paquete enviado a esta dirección, llegue a uno de los routers de la subred (al más cercano). Su sintaxis es la siguiente: n bits 128-n bits Prefijo de subred 0 Figura 2-7. Dirección Anycast para routers de una subred Stateless Address Autoconfiguration (SLAAC) En IPv4, un host tenía varias formas de obtener una dirección IP, como por ejemplo, mediante protocolos como BOOTP o DHCP, e incluso otorgarle una dirección de manera manual. En IPv6, también podemos agregar una dirección IPv6 a un nodo de forma manual, o de forma automática a través de nuevos protocolos como DHCPv6 (RFC 3315). Además, surge un nuevo mecanismo que permite

28 8 Internet Protocol Version 6 (IPv6) que un nodo configure automáticamente su propia dirección IPv6. Estamos hablando de: Autoconfiguración de Direcciones Libres de Estado, en inglés, Stateless Address Autoconfiguration (SLAAC). El funcionamiento de este mecanismo lo resumimos en los siguientes pasos: La interfaz se conecta a la red y se asigna una dirección Link-Local. Esa interfaz envía un mensaje Router Solicitation (RS). Si obtiene respuesta a través de un mensaje Router Advertisement (RA), coge el prefijo de red que contiene. Añadiendo al prefijo la dirección que se obtiene mediante el algoritmo EUI-64, se obtiene finalmente la dirección IPv6. Por mera curiosidad, antes de continuar, presentamos esta figura [2-6] que resume el algoritmo EUI-64, teniendo en cuenta que se parte de la dirección MAC de la interfaz: Figura 2-8. Algoritmo EUI-64. Sin embargo, este procedimiento provoca problemas de privacidad, ya que una dirección IPv6 siempre está identificada a la misma interfaz. Es por ello que el RFC 4941 implementa una extensión de privacidad para obtener una dirección que parta igualmente del identificador IEEE (dirección MAC) pero que usa números aleatorios para generarla. De ahí que normalmente los equipos generen dos direcciones IPv6 mediante SLAAC, una usando el procedimiento explicado anteriormente, y otra usando esta extensión IPsec (Internet Protocol security) Este protocolo es el encargado de la seguridad en IPv6, es por ello que nos vemos obligados a dedicarle una sección dentro de nuestro proyecto. A diferencia de otros protocolos, como SSH, SSL y TSL, IPsec actúa en la capa de red (capa 3 en el modelo OSI), lo que permite dar soporte a protocolos tan comunes como UDP y TCP (de la capa 4). Además, es capaz de poder proveer los siguientes servicios [2-7]: Control de accesos. Integridad no orientada a conexión Autenticación de origen de datos. Rechazo o reenvío de paquetes.

29 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 9 Confidencialidad. Negociación de Compresión IP. IPsec está formado por una serie de componentes que trataremos de explicar de forma breve, pero con el objetivo de aprender cuáles son sus funcionalidades: Protocolos de seguridad. Como son AH (Authentication Header) y ESP (Encapsulation Security Payload). El primero de ellos [2-8] proporciona integridad, autenticación y no repudio si se eligen los algoritmos criptográficos apropiados. El segundo [2-9], confidencialidad y la opción de autenticación y protección de integridad Cabecera Siguiente Longitud de la Carga RESERVADO Índice de Parámetros de Seguridad (SPI) Número de Secuencia Datos de Autentificación (Longitud variable) Índice de Parámetros de Seguridad (SPI) Número de Secuencia Datos de Carga Útil (Variable) Relleno (0-255 bytes) Long. Relleno Sig. Cabecera Datos de Autentificación (Longitud variable) Figura 2-9. Formato AH (arriba) y formato ESP (abajo). Asociaciones de Seguridad (SA: Security Association): una SA es una clase de conexión que permite establecer los servicios de seguridad del tráfico. En cada SA se puede usar AH o ESP, pero no ambos, esto quiere decir que, si se quieren utilizar los dos, habría que establecer dos SA. Administración de claves: IPsec permite dos formas de compartir claves. La primera de ellas es administrar las claves de forma manual. La segunda, es utilizar un protocolo que lo haga de forma automática. El protocolo que propone IPsec es IKE (Internet Key Exchange), definido por primera vez en el RFC 2409, y su nueva versión IKEv2 (RFC 4306). Algoritmos de autenticación y encriptado: el nuevo RFC 7321 publicado en Agosto de 2014, establece una serie de algoritmos a usar tanto para AH como para ESP. A continuación, en la siguiente figura extraída del RFC [2-10], podemos ver cuáles son estos algoritmos. Hay que tener en cuenta lo siguiente: MAY significa que ese algoritmo puede usarse; MUST, que es de uso obligatorio; MUST NOT, que no debe usarse; SHOULD, que debería usarse y SHOULD+, que

30 10 Internet Protocol Version 6 (IPv6) debería usarse y en un futuro puede convertirse en MUST. AH Authentication Algorithms ESP Authentication Algorithms Requirement Algorithm Requirement Algorithm SHOULD+ AES-GCM with a 16 octet ICV [RFC4106] MUST HMAC-SHA1-96 [RFC2404] SHOULD+ AES-GMAC with AES-128 [RFC4543] SHOULD+ AES-GMAC with AES-128 [RFC4543] MAY TripleDES-CBC [RFC2451] SHOULD AES-XCBC-MAC-96 [RFC3566] MUST NOT SHOULD MAY DES-CBC [RFC2405] AES-XCBC-MAC-96 [RFC3566] AES-CTR [RFC3686] ESP Authenticated Encryption (Combined Mode ESP Encryption Algorithms Algorithms*) Requirement Algorithm Requirement Algorithm SHOULD+ AES-GCM with a 16 octet ICV [RFC4106] MUST AES-CBC [RFC3602] MAY AES-CCM [RFC4309] MAY AES-CTR [RFC3686] *ESP combined mode algorithms provide both confidentiality and authentication service MAY TripleDES-CBC [RFC2451] MUST NOT DES-CBC [RFC2405] Figura Requisitos de implementación de algoritmos para AH y ESP según RFC Internet Control Message Protocol version 6 (ICMPv6) El protocolo ICMPv6 es una nueva versión del que existía para IPv4. Éste aprovecha muchas características de su predecesor, pero añade nuevas funcionalidades convirtiéndolo en un protocolo más potente. Antes de comentar esas nuevas funcionalidades, veamos cómo se transmite los mensajes ICMPv6. Estos se encapsulan y se envían como carga útil dentro de los paquetes IPv6, como podemos ver en la siguiente figura [2-11]: Figura ICMPv6 encapsulado dentro de paquete IPv6. Como vemos en la anterior imagen, los mensajes ICMPv6 incluyen una cabecera 2, siendo el formato de ésta el que aparece en la siguiente figura: 2 Esto implica que el campo Sigueinte Cabecera de la cabecera IPv6 apuntará a la de ICMPv6, tomando un valor, en este caso, de 58.

31 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv Tipo Código Checksum Figura Cabecera ICMPv6. El significado de cada campo lo explicamos a continuación [2-12]: Tipo: indica el tipo de mensaje. Este valor determina el formato de la información a recibir. Código: depende del tipo de mensaje. Es usado para crear un nuevo subnivel de clasificación de los mensajes. Checksum: es usado para detectar la corrupción de los datos en los mensajes ICMPv6 y en parte de las cabeceras IPv6. Como vemos en la figura 2-11, un paquete ICMPv6 incluye un mensaje. Estos pueden ser de dos clases: de error o de información. Los primeros están identificados con un código que toma un valor comprendido entre 0 y 128. Los segundos, toman un valor entre 128 y 255. Los mensajes ICMPv6 estándar (aquellos que no están relacionados con las nuevas funcionalidades que incorpora este protocolo) los podemos ver recogidos en la siguiente figura [2-13]: Mensaje ICMPv6 Código Descripción Destination Unreachable (Destino inaccesible) Packet Too Big (Paquete demasiado grande) Time Exceeded (Tiempo agotado) 3 Parameter Problem (Problemas de parámetros) Echo Request (Solicitud de eco) 128 Echo Reply (Respuesta de eco) Mensaje de error que informa al host remitente de que un paquete no se puede entregar. Mensaje de error que informa al host remitente de que el paquete es demasiado grande para el reenvío. Mensaje de error que informa al host remitente de que el límite de saltos de un paquete IPv6 ha caducado. Mensaje de error que informa al host remitente de que se produjo un error al procesar el encabezado IPv6 o un encabezado de extensión IPv6. Mensaje informativo que se utiliza para determinar si un nodo IPv6 está disponible en la red. Mensaje informativo que se emplea para responder al mensaje de solicitud de eco ICMPv6. Figura Mensajes ICMPv6. Estos dos últimos mensajes nos serán de gran utilidad, ya que son los que usa el comando ping, herramienta que utilizaremos en nuestras pruebas. Ahora sí procedemos a comentar las nuevas funcionalidades que recoge ICMPv6. Éstas consisten en dar soporte a otros protocolos, como el de Descubrimiento de Vecino (Neighbor Discovery: ND), MIPv6, Multicast Listener Discovery (MLD), y a otros tantos, a través de mensajes ICMPv6. De los protocolos que hemos citado anteriormente, es lógico que el más importante sea MIPv6, ya que nuestro proyecto gira en torno a él. Pero también adquire cierta importancia el protocolo ND, ya que aparecerá intrínsicamente en nuestras pruebas. Puesto que para MIPv6 tenemos un apartado en el que lo explicaremos en

32 12 Internet Protocol Version 6 (IPv6) profundidad, acabaremos este capítulo hablando brevemente del protocolo ND Neighbor Discovery (ND) Este protocolo es el sustituto de ARP (Address Resolution Protocol) que funcionaba en IPv4. Su principal objetivo es permitir que un nodo que se acaba de incorporar a la red, descubra la presencia de otros nodos que están en ese mismo enlace y son sus vecinos, obteniendo también en este proceso la dirección IP de ellos. Pero además incluye otras funcionalidades que lo hacen más completo que ARP, entre ellas están: descubrir routers, prefijos y parámetros, autoconfiguración de direcciones, resolución de direcciones, determinación del siguiente salto, detección de nodos no alcanzables, detección de direcciones duplicadas o cambios, redirección, balanceo de carga entrante, direcciones anycast y anunciación de proxies. Como dijimos en la sección anterior, ICMPv6 da soporte a este protocolo por medio de una serie de paquetes que detallamos a continuación [2-14]: Solicitud de Router (RS: Router Solicitation): este mensaje es generado por una interfaz en el momento de su activación. Su finalidad es pedir a los routers que se anuncien lo más pronto posible. El Campo Tipo de la cabecera ICMPv6 toma el valor 133. Anunciación de Router (RA: Router Advertisement): este mensaje se genera periódicamente cada cierto intervalo (que es un parámetro configurable) y además también se origina en respuesta a un mensaje RS. Entre la información que aporta: prefijo de la red, puerta de enlace, tiempo de vida, límite de saltos, etc. El Campo Tipo de la cabecera ICMPv6 toma el valor 134. Solicitud de Vecino (NS: Neighbor Solicitation): estos mensajes tiene varias finalidades. Entre ellas, determinar la dirección de la capa de enlace de sus vecinos, detectar si hay direcciones duplicadas, así como saber si el nodo vecino sigue siendo alcanzable. El Campo Tipo de la cabecera ICMPv6 toma el valor 135. Anunciación de Vecino (NA: Neighbor Advertisement): es generado por los nodos en respuesta a los mensajes NS, o bien para indicar que se ha producido cambios en las direcciones de la capa de enlace. El Campo Tipo de la cabecera ICMPv6 toma el valor 136. Redirección (Redirect): si un router halla un mejor salto para alcanzar un destino, se lo notifica al nodo afectado con un mensaje de este tipo. El Campo Tipo en de la cabecera ICMPv6 toma el valor 137. La siguiente imagen [2-14] explica gráficamente el uso de algunos de estos mensajes: Figura Escenarios donde se usan ND.

33 3 MOBILE IPV6 (MIPV6) E l concepto de movilidad está estrechamente ligado al avance de las tecnologías móviles. En este capítulo veremos la necesidad de que haya soporte para la movilidad en IP, tanto en su versión 4, como en la 6. Posteriormente, explicaremos conceptos básicos para entender su funcionamiento. También entraremos en materia de seguridad, en su difícil expansión en grandes redes, y terminaremos explicando el proyecto UMIP, que será la base empleada en nuestras pruebas Historia y motivación Para entender por qué surge el concepto de movilidad, hay que remontarse a los orígenes de la informática. En un principio, los primeros ordenadores eran equipos gigantes que eran ubicados en un lugar concreto, y debido a su enorme peso y tamaño, nunca eran desplazados. Cuando se desarrolló IP, y en concreto, cuando apareció el direccionamiento sin clases (conocido como CIDR) se hizo pensando en este tipo de equipos. Recordando cómo funciona CIDR, las direcciones IP se dividen en dos partes, la primera identifica a la red, y la segunda al host dentro de esa red. Esto implica que la dirección IP que obtenga un equipo, depende de la red en la que se halle. Esto no es un problema para los equipos tradicionales, como los ordenadores de sobremesa, pero debido al enorme avance de la tecnología, cada vez hay dispositivos más pequeños y potentes como Smartphones, Tablets, Notebooks, etc., que por su pequeño tamaño, nos permite llevarlos encima y desplazarnos con ellos. Esto unido al desarrollo de las tecnologías inalámbricas, nos capacita poder desplazarnos con nuestros equipos a cualquier lugar e ir cambiando de red. Aparentemente esto no es un inconveniente, seguimos teniendo conexión a la red estemos donde estemos. Pero si lo miramos desde otro punto de vista seguro que identificamos el problema. Supongamos que estoy con mi portátil conectado a la red de la Escuela Superior de Ingenieros de Sevilla, donde tendré una dirección IP. Desde allí establezco conexiones con otros equipos de otras redes, por lo que cuando ellos quieren ponerse en contacto conmigo, van a usar la dirección IP que obtuve en la Escuela. Si ahora me desplazo a la Universidad Pablo de Olavide, también en Sevilla, cambiaré de red y por tanto obtendré una nueva dirección IP. Esto provoca que los equipos que se estaban comunicando conmigo, si quieren volver a hacerlo, deban de conocer mi nueva dirección IP. Además si teníamos conexiones TCP/IP establecidas, estas se romperán ya que hemos cambiado de dirección. Ya hemos identificado el problema, IP no está preparado para que un dispositivo móvil cambie de una red a otra. Para solucionar esto, podemos plantear dos soluciones bien distintas: Cada equipo se identifica con una dirección IP global única. De esta forma da igual en la red que estemos, ya que siempre tenemos la misma dirección. No vamos a tener problemas con el número de direcciones, ya que con IPv6 tenemos millones para usar. El gran inconveniente que hace que esta solución sea inviable, sería el enorme tamaño de las tablas de enrutamiento de los routers, ya que se necesitaría una entrada para cada equipo. CIDR apareció para solucionar este tipo de problemas en las tablas, ya que una entrada representa a miles de equipos. Por lo que adoptar esta solución, sería un paso atrás y adentrarnos en un problema aún mayor. Inventarnos un nuevo protocolo para dar soporte a la movilidad en IP. Estás son a priori las soluciones más viables, y que finalmente se adoptaron. De aquí surge IP Mobility Support for IPv4, que se definió por primera vez en el RFC Posteriormente se dió soporte a la movilidad en IPv6 con el RFC 3775: Mobility Support in IPv6 4, que será el que veremos en la siguiente sección. 3 Obsoleta por el RFC Su versión más reciente es el RFC

34 14 Mobile IPv6 (MIPv6) No entraremos en detalle en explicar por qué finalmente se impone la movilidad en IPv6 en vez de IPv4, pero podemos decir que esta decisión se toma en base a las ventajas que se hallan inherentemente en el protocolo IPv6, y de algunos problemas que presenta la movilidad en IPv4 como puede ser la necesidad de definir un nodo especial en las redes visitadas (Foreign Agent), que no es necesario en el esquema de MIPv Funcionamiento básico En este apartado, intentaremos que el lector conozca las principales entidades funcionales que intervienen en MIPv6, así como entender la interacción entre ellos. La entidad protagonista en un esquema de movilidad es el Nodo Móvil o Mobile Node (MN). Un nodo móvil tiene la capacidad de movilidad, es decir, el nodo puede moverse libremente por distintas redes sin dejar en ningún momento de estar disponible. Para que esto sea posible, en el marco de Internet, el MN debe tener siempre la misma dirección IP. De ello se va a encargar MIPv6. En un primer momento, antes de desplazarse, el MN se encuentra en la red de su casa, conocida como Home Network (HN). Allí, ya sea por SLAAC, por DHCPv6 u otro mecanismo, obtendrá una dirección IP llamada Home of Address (HoA), la cual queremos que le sirva para identificarlo unívocamente en toda Internet. De momento, al estar en la HN, todos los paquetes cuya dirección de destino sea la HoA, pasarán por el Router de Acceso y serán entregados al MN. Es decir, el paquete será encaminado usando los mecanismos tradicionales de Internet. En un instante dado, el MN decide migrar a otra red, a la que llamaremos genéricamente Foreign Network (FN). Este proceso de migración, se conoce en movilidad como Handover (a veces usaremos su traducción al español: traspaso). Una vez el MN ha alcanzado la nueva red 5, necesita de una nueva dirección, a la que llamaremos Care-of Address (CoA). Para conseguirla, el MN necesitará información de la red, que es proporcionada mediante un mensaje RA. El MN puede esperar a que le llegue el RA, o puede forzar que este mensaje le sea enviado por medio de un RS, que es la mejor opción, para así evitar esperar un tiempo innecesario que provocaría retardos. En ese RA, se le puede indicar al MN que se necesitará del protocolo DHCPv6 para que obtenga una dirección IPv6 válida, o bien si no se especifica nada, el MN, a través de la información de dicho mensaje, podrá hacer uso de SLAAC para auto configurarse y obtener una o varias direcciones y que una de ellas sea la CoA. Como hemos dicho, queremos que nuestro MN sea alcanzable en todo Internet, por lo tanto, necesitamos que tenga una única dirección IP. Esta dirección será la HoA. Pero en la situación en la que estamos, si un equipo externo, el cual llamaremos Correspondent Node (CN), decide mandar un mensaje al MN usando como dirección de destino la HoA, el paquete no llegará a entregarse, puesto que nosotros estamos usando otra dirección que es la CoA. Para solucionar el problema anterior, necesitamos de otra entidad funcional de gran importancia. Se trata del Home Agent (HA). El HA será un nodo situado en la HN, encargado de recoger los paquetes cuyo destino sea la HoA y reenviarlos a la dirección CoA. Con esto conseguimos que cualquier equipo pueda comunicarse con nosotros sin importar la red en la que estemos, ya que el HA actúa de intermediario al recoger los paquetes y entregarlos al MN. La siguiente pregunta que nos surge es cómo sabe el HA la nueva dirección del MN. El mecanismo propuesto [3-1] consiste en lo siguiente: una vez que el MN obtiene la CoA, existirá una asociación (Binding) entre ésta y su HoA. Esta asociación hay que registrarla, primero en el MN, concretamente en la Binding Update List (BUL), y posteriormente en el HA, para que éste sepa que cuando recibe un paquete con dirección destino HoA, no debe de entregarlo en su red, sino que debe de reenviarlo a la CoA. Para registrar la asociación en el HA, el MN envía un mensaje llamado Binding Update (BU). Tras recibirlo, el HA registra la asociación en una tabla especial que se llama Binding Cache que se irá actualizando conforme le vayan llegando nuevos BU procedente del MN, o cuando a alguna de las entradas le expira su tiempo de vida. Como respuesta, el HA le envía al MN un mensaje llamado Binding Acknowledgement (BA). Una vez que se ha registrado la asociación, el HA ya puede reenviar paquetes al MN sin importar donde se encuentre. El siguiente paso es ver cómo el MN responde a ese paquete. El MN puede optar por dos caminos, mandar el mensaje de respuesta usando al HA de intermediario, o de forma directa al CN. A continuación 5 Sabrá que ha cambiado de red, gracias al protocolo ND explicado en el capítulo 2.

35 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 15 detallamos cada modo. El primero, es el más elemental. Consiste en usar túneles bidireccionales entre el HA y el MN, tal y como detalla la siguiente figura: Figura 3-1. Modo de túnel bidireccional. En un principio, el HA, usando ND, intercepta todos los paquetes cuya dirección destino sea HoA. Cada paquete interceptado, es enviado a través de un túnel IPv6-in-IPv6 a la CoA. Una vez que el MN recibe el paquete, envía la respuesta usando el mismo túnel en modo reverso. Cuando el paquete de respuesta llega al HA, solo falta reenviarlo al CN. Cabe señalar que, la dirección origen de la respuesta debe ser la CoA, ya que si fuera la HoA, probablemente las políticas ACL en FN descartarían el paquete. Para poder llevar a cabo el segundo camino, llamado Route Optimization y detallado en la siguiente imagen, es necesario que el CN tenga soporte de MIPv6: Figura 3-2. Modo Route Optimization. En esta ocasión, cuando el paquete llega al MN, éste envía un mensaje BU con origen CoA (por la misma

36 16 Mobile IPv6 (MIPv6) razón que antes) directamente al CN. Posteriormente, el MN manda el paquete de respuesta. Puede parecer que hay un inconveniente, ya que el CN envió un paquete a la dirección HoA, y le llega una respuesta procedente de otra dirección distinta (CoA), lo que puede provocar problemas en las capas superiores del CN. Pero esta situación nunca llega a darse, ya que el MN añade al mensaje de respuesta una cabecera de extensión llamada Destination Option, donde se incluye la HoA, de tal forma que cuando el paquete llega al CN, éste sustituye la CoA por la HoA, por lo que las capas superiores solo son conscientes de que existe una única dirección (HoA). A partir de aquí, como el CN sabe que el MN se encuentra en otra red, si tiene que enviarle más paquetes lo hará directamente a la CoA, usando para ello una cabecera de encaminamiento del tipo 2 donde se incluye la HoA para que el MN pueda recuperar esa dirección cuando le llega el paquete. Encaminar los paquetes directamente a la CoA del nodo móvil, permite usar la ruta más corta, esto reduce la congestión en el HA y en el enlace propio, y además, reduce el impacto de cualquier posible fallo del HA o las redes de la ruta [3-2]. Para el modo Route Optimization, el mensaje BU que manda el MN al CN necesita de seguridad 6, es por ello que se usan los siguientes mensajes (portados en la cabecera de movilidad que veremos más adelante), que no pasaremos a detallar en profundidad: Home Test Init Home Test Care-of Test Init Care-of Test 3.3. Cabecera MIPv6 Una vez explicado el funcionamiento del protocolo de movilidad IPv6, es conveniente presentar la cabecera. Ésta es identificada con el valor 135 en el campo Next Header de la cabecera que le preceda. Su formato podemos verlo en la siguiente figura: Protocolo Carga Útil Longitud Cabecera Tipo Mensaje Reservado Checksum Datos del Mensaje Figura 3-3. Cabecera MIPv6. A continuación, vamos a explicar el significado de cada campo [3-1]: Protocolo Carga Útil (Payload Protocol): selector de 8 bits. Su función es identificar el tipo de cabecera que sigue a la de movilidad. Usa los mismos valores que en el campo Next Header de la cabecera IPv6. Longitud Cabecera (Header Length): entero de 8 bits sin signo. Representa la longitud de la cabecera de movilidad en unidades de 8 octetos, excluyendo los 8 primeros. Tipo Mensajes (MH Type): selector de 8 bits. Identifica el mensaje de movilidad en cuestión. Algunos de ellos los veremos en la siguiente sección de este capítulo. 6 Necesitamos garantizar que hemos sido nosotros los que hemos enviado el BU y que nadie ha modificado ese mensaje.

37 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 17 Reservado (Reserved): campo de 8 bits reservado para usos futuros. Por defecto toma el valor 0. Checksum: entero de 16 bits sin signo. Contiene la suma de verificación de la cabecera de movilidad. Datos del Mensaje (Message Data): campo de longitud variable que contiene los datos del mensaje que se trate Mensajes importantes Aunque son varios los mensajes que componen la movilidad en IPv6, en esta sección solo vamos a describir los que a priori son más importantes para nosotros, puesto que son los que aparecerán en nuestras pruebas. El primero de ellos es el mensaje BU (cuyo valor MH Type en la cabecera de movilidad toma el valor 5), el cual tiene el formato que detalla la siguiente imagen: Secuencia # A H L K Reservado Tiempo de Vida Opciones de Movilidad Figura 3-4. Formato Mensaje Binding Update. A continuación, pasamos a describir cada campo [3-3]: A (Acknowledge): el nodo móvil pone este bit a uno para solicitar un mensaje BA de respuesta. H (Home Registration): MN pondrá este bit a uno para indicarle a su receptor que actúe como su HA. L (Link-Local Address Compatibility): este bit se pone a uno cuando la HoA enviada por el MN puede tener el mismo identificador de interfaz que su dirección local de enlace. K (Key Management Mobility Capability): si el bit está a cero, el protocolo encargado de establecer las SA de IPsec entre el MN y el HA, no soportará traspasos. Esto quiere decir que tras un traspaso, el protocolo debe volver a ejecutarse. Este bit también estará a cero si se configura IPsec manualmente. Por último, decir que los CN deben ignorar este bit. Reservado (Reserved): debe estar puesto a cero. El receptor debe ignorarlo ya que este campo no se usa. Secuencia # (Sequence #): entero de 16 bits sin signo, usado por el nodo receptor para conocer el número de secuencia del BU y por el nodo remitente para identificar el mensaje BA de respuesta. Tiempo de vida (Lifetime): entero de 16 bits sin signo. Indica el número de unidades de tiempo (cada unidad de tiempo son 4 segundos) antes de que la asociación (binding) pase a ser considerada como caducada. Cuando su valor es cero, la asociación debe ser borrada de la Binding Cache. Opciones de Movilidad (Mobility Options): campo de longitud variable múltiplo de 8 octetos. Una de las opciones incluidas es la de Alternate Care-of Address Option. Si este campo no está presente, la CoA que el HA usa para la asociación, es la dirección origen de la cabecera IPv6. Si por el contrario esta opción es usada y la dirección que contiene, llamada Alternate CoA, es correcta (es una dirección unicast encaminable), se toma ésta como nueva CoA. El siguiente mensaje que nos proponemos a detallar es el BA. Éste toma el valor 6 en el campo MH Type de la

38 18 Mobile IPv6 (MIPv6) cabecera de movilidad. Como venimos haciendo hasta ahora, en primer lugar mostraremos el formato del mensaje a través de una figura, y posteriormente pasaremos a detallar cada campo: Estado K Reservado Secuencia # Tiempo de Vida Opciones de Movilidad Figura 3-5. Formato Mensaje Binding Acknowledgement. Secuencia # (Sequence #): entero de 16 bits sin signo, copiado del mensaje BU al que responde. Estado (Status): entero de 8 bits sin signo. Indica el resultado de la recepción al mensaje BU. Si es aceptado, tomará un valor menor a 128, en caso contrario, un valor mayor. Algunos de los valores empleados son: o o o o 0 : Binding Update accepted (BU aceptado) 1 : Accepted but prefix discovery necessary (aceptado pero se requiere descubrimiento de prefijo) 134 : Duplicate Address Detection failed (Detección de direcciones duplicadas ha fallado) 174 : Invalid Care-of Address (CoA inválida) K (Key Management Mobility Capability) y Reservado (Reserved): mismo significado que en mensajes BU. Tiempo de Vida (Lifetime): entero de 16 bits sin signo. Número de unidades de tiempo (cada unidad de tiempo son 4 segundos) concedidas hasta la expiración de la asociación. Si el BU es rechazado, este campo queda indefinido. Opciones de Movilidad (Mobility Options): campo de longitud variable múltiplo de 8 octetos. Algunas de sus opciones son: Binding Authorization Data y Binding Refresh Advice. El siguiente mensaje que presentamos no lo hemos nombrado hasta ahora, pero es interesante saber que existe ya que se envía en caso de error. Estamos hablando del mensaje Binding Error (BE), cuyo valor en el campo MH Type es el 7. Su formato se detalla a continuación: Estado Reservado Home Address Opciones de Movilidad Figura 3-6. Formato Mensaje Binding Error.

39 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 19 Estado (Status): entero de 8 bits sin signo. Indica la razón que ha originado el error, pudiendo tomar los siguientes valores: o o 1 : Binding desconocido para la opción Home Address especificada. 2 : Valor de MH Type no reconocido. Reservado (Reserved): campo de 8 bits reservado para uso futuro. De momento debe ser ignorado por el receptor. Home Address: es la HoA contenida en la opción Home Address dentro de la cabecera de extensión Destination Option (que veremos más adelante). El MN usa esta información para determinar cuál asociación no existe, en el caso que el MN tuviera varias HoA. Opciones de Movilidad (Mobility Options): campo de longitud variable múltiplo de 8 octetos Modificación en otros protocolos La aparición de MIPv6 ha provocado que ciertos protocolos tengan que ser modificados para poder dar soporte a este servicio. Uno de ellos es el protocolo ICMPv6, que tal como comentamos en el apartado 2.6, implementa una serie de mensajes para dar soporte a algunos protocolos, entre ellos, MIPv6. Estos mensajes son los que citamos a continuación [3-3]: Home Agent Address Discovery Request (ICMP type 144): mensaje usado por el nodo móvil para iniciar el mecanismo de descubrimiento dinámico de dirección de HA. Home Agent Address Discovery Reply (ICMP type 145): se usa para responder a un MN que usa el procedimiento de descubrimiento dinámico de dirección de HA. Mobile Prefix Solicitation (ICMP type 146): este mensaje es originado por el MN cuando está fuera de casa con destino al HA. El objetivo es saber si se han producido cambios en el prefijo de la HN. Esta información puede ser usada para actualizar la HoA del MN, conforme a los cambios en el prefijo. Mobile Prefix Advertisement (ICMP type 147): este mensaje es enviado por el HA como respuesta al mensaje anterior, o de forma periódica. Indica el prefijo de la HN. Otro protocolo como el ND también ha sufrido modificaciones. La principal ha consistido en modificar el mensaje RA, al cual se le han efectuado una serie de cambios. Uno de ellos consiste en añadir un bit H, el cual si tiene el valor 1, indica que ese router funciona en su enlace como HA. También se definen dos nuevas opciones usadas en los mensajes RA. Una de ellas es la opción Advertisement Interval que el router usa para anunciar el intervalo empleado en el envío de mensajes RA multicast no solicitados. La otra opción es la Home Agent Information, que incluye campos 7 como Home Agent Preference y Home Agent Lifetime. MIPv6 también ha provocado la aparición de una nueva cabecera de extensión. Se trata de la cabecera Destination Option (valor Next Header igual a 60). Es usada por el MN en los paquetes que envía para incluir su dirección HoA mientras está fuera de casa. Para terminar este apartado, vamos a ver una variante de la cabecera de encaminamiento que ha surgido a raíz de la implementación de MIPv6. Se trata de la cabecera de tipo 2, que contiene un campo que incluye la HoA del MN. Esta cabecera se usa para permitir que el paquete sea encaminado directamente desde un CN hasta la dirección CoA del MN. Como esta dirección es insertada dentro de la Dirección Destino de la cabecera IPv6, no habrá problemas de que el paquete sea rechazado al atravesar firewalls. Una vez que éste llega a la dirección CoA, el MN recupera su HoA de la cabecera de encaminamiento, y es usada como dirección final de destino para el paquete. 7 Solo incluye esos campos si toman valores distintos a los de por defecto.

40 20 Mobile IPv6 (MIPv6) 3.6. Seguridad Para que la movilidad IPv6 se extienda no solo a nivel de baja escala, sino en ámbitos más extensos, es necesario que este protocolo sea lo más seguro posible. Tal y como hemos presentado a MIPv6, podemos ver carencias de seguridad obvias, como por ejemplo, que estamos mandando mensajes con información sensible, sin ningún tipo de protección. En primer lugar vamos a identificar los problemas de seguridad, y luego vamos a ver si se ha podido dar solución con algunos de los mecanismos que se han explicado en el capítulo 2.5. Uno de los problemas de seguridad al que nos enfrentamos es el siguiente. Supongamos que estamos mandando mensajes BU que contiene una asociación entre la dirección actual que tenemos (CoA) y la dirección que teníamos en nuestra red de casa (HoA). Es evidente que esta información no debe estar circulando sin protección por Internet, ya que cualquier usuario malicioso podría intervenir siempre con el fin de tener un servicio de movilidad de forma fraudulenta. Lo primero que podría hacer es cambiar parte de la información del mensaje para poner como CoA su propia dirección y ser él quien se registre en el HA. Esto lo podemos solucionar con algún protocolo de seguridad que nos garantice la integridad del mensaje, es decir, que el HA pueda darse cuenta de que alguien ha manipulado el mensaje. Lo segundo que podría hacer es, en vez de manipular el mensaje, capturar toda la información posible para luego usarla y hacerse pasar por nosotros. Esto lo solucionamos usando un protocolo que nos proporcione confidencialidad en el mensaje, es decir, queremos que use criptografía para que un tercero no pueda leer el mensaje. Para dar solución a estos problemas podemos usar IPsec, en concreto, ESP. Así lo pensó el IETF, y por ello se creó el RFC Pero para que IPsec funcione correctamente tenemos que establecer, tanto en el MN como en el HA, las claves necesarias en el establecimiento de las SA que usa IPsec. Como comentamos en la sección 2.5, las claves pueden introducirse de manera manual en ambos equipos, o usar un mecanismo seguro para el intercambio de dichas claves. Este mecanismo lo proporciona el protocolo IKE. Sin embargo, éste es demasiado complejo, luego el IETF no lo ha considerado para usarlo con la movilidad. No obstante su evolución, conocida como IKEv2, sí que se ha implementado para usarse como método de intercambio de claves en MIPv6, definiéndose en el RFC Despliegue a gran escala Nos gustaría antes de continuar con este proyecto, explicar brevemente por qué aún MIPv6 no está extendido en grandes escenarios con miles de dispositivos. Podemos pensar que es un protocolo seguro, por lo que hemos visto en el apartado anterior, y con un funcionamiento correcto. Sin embargo hay diversos aspectos que deben corregirse para que un operador pueda llevar a cabo un despliegue a gran escala. MIPv6 solo proporciona la definición de los agentes involucrados en el soporte de movilidad, su funcionamiento y sus interacciones. Esto es suficiente para un despliegue experimental o a baja escala en el que participen muy pocos usuarios y donde la configuración de los agentes se hace de manera manual. Pero si queremos pensar en la movilidad como un servicio que pueda explotar un operador, este marco no nos vale. De hecho lo primero que hace un proveedor, es pensar cómo debe afrontar la identificación del usuario (proceso conocido como autenticación o autentificación) para posteriormente acreditar si éste tiene derecho a disfrutar del servicio de movilidad (este proceso es conocido como autorización). Por último una vez se ha autenticado y autorizado al usuario, habrá que calcular cuánto tiempo ha estado usando el servicio para poder facturarlo. Pues bien, este tipo de funciones son realizadas por medio de infraestructuras AAA (siglas del inglés Authentication, Authorization and Accounting), pero MIPv6 no recoge su implementación. También hay otro tipo de problemas que de momento impiden el despliegue a gran escala. Uno de estos obstáculos es la presencia de firewalls en las redes por las que pasan paquetes relacionados con MIPv6. Estos, pueden rechazar el paquete de movilidad porque no entiendan los mensajes de señalización de MIPv6 (BU, BA, etc.) o las cabeceras de movilidad. O incluso pueden no permitir el paso de paquetes IPsec puesto que no saben su contenido. El último problema al que haremos alusión es a la compatibilidad de MIPv6 con IPv4. Como su nombre indica, MIPv6 es un protocolo diseñado para funcionar sobre redes IPv6, pero es muy probable que aunque el operador que proporciona la movilidad cuenta con una red IPv6, el MN tenga que desplazarse por redes de

41 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 21 otros operadores que solo cuenten con redes IPv4. Así que habría que estudiar cómo conseguir que los mensajes de movilidad lleguen a una red IPv4 desde una red IPv6 y viceversa. Para dar solución a todos estos problemas, se creó un proyecto IST financiado por la Unión Europea, llamado proyecto ENABLE. La investigación que se llevó a cabo con el proyecto ENABLE permitirá el despliegue del servicio de movilidad sobre IPv6 de una manera robusta, además, que se soporten posibles evoluciones futuras y un uso intensivo de la red con aplicaciones como multimedia (vídeo y audio), servicios de localización, etcétera [3-3] Proyecto UMIP Esta pequeña sección nos servirá como introducción a los siguientes capítulos, donde desarrollaremos un escenario de movilidad para su posterior análisis. Para crear un escenario de movilidad, lo primero que tenemos que hacer es identificar quién va a asumir el papel de HA, MN y CN. Pero para que cada uno pueda llevar a cabo el rol adjudicado, necesitará de un software que implemente una serie de librerías que puedan dar soporte a la movilidad. Pues bien, UMIP es quién nos proprociona ese software [3-4]. UMIP es una implementación de código abierto de MIPv6 y de soporte básico de NEMO para Linux, bajo licencia GPLv2. Da soporte a las siguientes RFC: 6275 (Mobile IPv6), 3963 (NEMO), 3776 y 4877 (IPsec e IKEv2). Actualmente se encuentra en la versión 1.0, la cual está basada en UMIP versión 0.4 heredada del proyecto USAGI. UMIP está adquiriendo cada vez más importancia en estos años, y es que al software que nos propociona MIPv6 se les ha unido otras implementaciones de nuevas extensiones a la movilidad, como son: Multiple Care-of Addresses Registration (MCoA, RFC5648), Dual Stack Mobile IPv6 (DSMIPv6, RFC5555), Proxy- Mobile IPv6 (PMIPv6, RFC5213) y Fast Handovers for Mobile IPv6 (FMIPv6, RFC 4068).

42

43 4 DESARROLLO DEL ESCENARIO E n esta sección trataremos de explicar cómo crear un escenario para hacer pruebas de movilidad. En una primera instancia, presentaremos a los equipos que participarán en tal escenario. Posteriormente enseñaremos cómo configurarlos para que soporten las funciones de movilidad. También se describirá el diseño lógico de la red. El objetivo final es poder usar este escenario para hacer pruebas de movilidad que se llevarán a cabo en el siguiente capítulo de este proyecto Equipos utilizados Para poder crear el escenario de movilidad, debemos tener por cada entidad funcional descrita en el capítulo 3, un equipo que lleve a cabo tal papel. El equipo que asumirá el rol del MN, es un Pentium 4 con 512 MB de memoria RAM, que cuenta con dos tarjetas de red que nos serán de gran utilidad para poder hacer las pruebas. El sistema operativo por el que se ha optado ha sido el Debian 7.4. El nombre que recibe este equipo es s1ipv6. El siguiente equipo en presentar es el s2ipv6. Éste asume el papel del HA. Las características técnicas con las que cuenta son: microprocesador Pentium 4, 256 MB de memoria RAM y una sola tarjeta de red. Este equipo al igual que s1pv6 cuenta con el sistema operativo Debian 7.4. Ya tenemos un MN y un HA. Necesitamos de otra entidad funcional que se encuentra en una red cualquiera y tenga la capacidad de ponerse en contacto con el MN a través de su CoA. Se trata, como ya bien es sabido a alturas de este proyecto, del CN. Su papel lo desempeñará mi equipo personal, que se trata de un portátil Toshiba, modelo Satellite Pro, con un microprocesador Inter Dual Core y 3 GB de memoria RAM. En este equipo se ha creado una partición donde se ha instalado el mismo sistema operativo que en los otros. El nombre que se le ha proporcionado a este equipo es el de CN1. El lector se preguntará cuál es la razón por la que se ha escogido usar en todos los equipos el sistema operativo Debian. En un principio siempre se optó por usar algún sistema operativo Linux debido a su fácil instalación, mantenimiento y gran capacidad en la administración de redes. La razón que nos llevó a escoger finalmente Debian, ha venido condicionada por el software que proporciona UMIP, ya que su repositorio solo contiene paquetes de este sistema operativo. Para poder completar nuestro escenario, necesitamos un equipo con el que se pueda crear o simular varias redes donde poder colocar las entidades funcionales anteriores. Además debe permitir el intercambio de paquetes entre ellos, es decir, si le llega un paquete de un equipo situado en la red A con destino un equipo localizado en la red B, ya que él no es el destinatario, debe reenviar el paquete. Un router puede perfectamente cumplir ambas funciones. Aunque podríamos optar por usar un router por cada red que creemos y luego interconectarlos, es lógico que resulte más económico usar un único router. A la duda de cómo podemos simular varias redes usando un único router, la solución consiste en crear distintas Virtual Local Area Network (VLAN). Cada vez que queramos ir de una VLAN a otra, el paquete debe pasar obligatoriamente por el router, debido a que las VLANs representan distintos dominios de difusión (tendrán un rango IP distinto y mutuamente excluyentes), entonces es como si tuviéramos distintas redes. Ya hemos decidido que solo emplearemos un router para nuestro escenario. El modelo escogido es el Cisco 892. Podrá ver las características de este dispositivo, así como una descripción más completa de los equipos anteriores, en el Anexo A. 23

44 24 Desarrollo Del Escenario 4.2. Configuración del Router Para que nuestro router cumpla las funciones especificadas en el apartado anterior, necesitará de una configuración previa. A menos que el router del que se disponga sea completamente nuevo y/o tenga la configuración de fábrica, es conveniente que lo reseteemos para poder configurarlo desde cero. Podemos optar por dos tipos de reset, uno manual y otro por software. Aunque en este proyecto se ha optado por el segundo, le indicamos al lector ambos caminos para que él decida cuál le conviene. Para hacer el reset manual, lo primero que habría que hacer es leer el manual de configuración del router, ya que dependiendo del modelo, cada proceso puede ser diferente. En nuestro caso, según lo que dice el fabricante [4-1], tenemos que pulsar el botón de reset que se encuentra en la carcasa del dispositivo, durante los primeros 5 segundos del arranque del router. Como dijimos al principio, la segunda forma de hacer reset es vía software. Lo primero que debemos hacer es conectar nuestro equipo al puerto de consola mediante un cable específico para ello y conectarlo a algún PC que también cuente con un puerto serial. Lo segundo es instalar un software que nos permita enviar las órdenes necesarias al router, equivalente al famoso HyperTerminal de Windows pero para Linux. Nosotros hemos optado por el software Minicom, cuya instalación y posterior configuración podrá encontrarlas en el Anexo B. Una vez estemos conectados al router y corriendo en nuestro PC el programa Minicom, encendemos el router que empezará a cargar la imagen de su sistema operativo. Nuestra misión es interrumpir la carga para entrar en modo Rommon, para ello debemos realizar un break, que se consigue pulsando Ctrl-A+Z y luego tecla F. Posteriormente, escribimos estos comandos: rommon 1 > confreg 0x2142 rommon 2 > reset Una vez se resetee el router, se volverá a cargar la imagen del SO, proceso que ahora no debemos de interrumpir. Una vez que se haya cargado completamente introducimos: Router>enable Router#copy running-config startup-config La estrategia usada ha consistido en arrancar desde una posición de memoria vacía. Posteriormente se copia esta configuración a la de arranque, consiguiendo que se borre la antigua (incluyendo contraseñas y usuarios). Continuemos instaurando la antigua posición de arranque y reiniciando el router: Router#configure terminal Router(config)#config-register 0x2102 Router(config)#end Router#reload Esta forma de hacer reset es más laboriosa que la anterior ya que tenemos que instalar un programa externo como es Minicom, pero de todas formas es algo que tendremos que hacer más adelante si queremos configurar el router. Además resetear de esta manera es más elegante que hacerlo de forma manual. Una vez tengamos reseteado el router, procedemos a crear una configuración inicial. Ésta consistirá en darle un nombre al dispositivo, crear una contraseña para evitar que otros usuarios puedan manipular la configuración, etc. Los pasos a seguir se detallan en el siguiente código: Código 4-1. Configuración inicial del router. Router>enable Router#configure terminal % Cambiamos de nombre al router. Le pondremos RA (Router de Acceso) Router(config)#hostname RA

45 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 25 % Con esta orden, si introducimos un comando erróneo, el router no intentará traducirlo a una dirección RA(config)#no ip domain-lookup % Ponemos frase de bienvenida RA(config)#banner motd #ROUTER RA PFC 2014 MIGUEL MIRALLES.# % Cada vez que se introduzca enable por línea de comandos, tenemos que introducir un password RA(config)#enable secret PASS_ESCOGIDA %En vez de secret, podemos poner la palabra password. La diferencia entre ambos métodos consiste en que el primero encripta en MD5 y el segundo introduce el pass en claro en el archivo de configuración % Creamos usuario y contraseña. Ésta será solicitada cada vez que nos conectemos por el cable de consola al router RA(config)#username USUARIO secret 0 PASS_ESCOGIDA RA(config)#line console 0 RA(config-line)#login local RA(config-line)#exit % Este comando nos permite encriptar todas aquellas contraseñas que se hubieran guardado en claro RA(config)#service password-encryption % Aplicamos un timeout al Puerto de Consola, de tal forma que tras 5 minutos de inactividad se volverá a pedir el usuario y la contraseña RA(config)#line console 0 RA(config-line)#exec-timeout 5 % Por último guardamos toda la configuración nueva, para que esté disponible la próxima vez que se inicie el router RA#copy running-config startup-config Si desea hacer una configuración más exhaustiva, como por ejemplo, añadir roles o privilegios a los distintos usuarios, consulte [4-2]. Nuestro siguiente objetivo consiste en crear las VLANs donde albergar los equipos presentados en el apartado anterior. Para conseguir este propósito, lo primero es ver cuántas VLANs creamos. Finalmente hemos optado por tres. En una de ellas residirá el CN (VLAN 20), otra será la HN donde estará el HA y el MN cuando no haya migrado (VLAN 30), y la tercera será la FN que albergará al MN cuando se produzca el traspaso (VLAN 10). Lo segundo es ver la dirección que se le asignará a cada una. Para ello partimos de un bloque de direcciones IPv6 que tiene asignado el Departamento de Telemática de la Escuela de Ingenieros de Sevilla: 2001:720:c18:b8::/61. Lo último por ver es a qué puertos, de los 8 switchports 8 que trae nuestro router Cisco, asignaremos cada VLAN creada. La siguiente figura muestra las características finalmente escogidas para las VLANs: 8 Los nombres que reciben los switchports del Cisco 892 son: fastethernet0 (f0) para el primer puerto, fastethernet1 (f1) para el segundo, y así sucesivamente hasta el octavo puerto, que será el fastethernet7 (f7).

46 26 Desarrollo Del Escenario ID VLAN Nombre VLAN Puertos asignados Dirección interfaz virtual 10 P1 f0 y f1 2001:720:c18:b9::100/64 20 P2 f2 y f3 2001:720:c18:ba::200/64 30 P3 f4 al f7 2001:720:c18:bb::300/64 Figura 4-1. Características VLANs. Ahora tendremos que hacer efectiva la configuración de la figura anterior. Para ello hay que seguir el código que se detalla a continuación 9, teniendo en cuenta que como estamos ante switchport las VLANs se crean tal y como lo haríamos en un switch: Código 4-2. Crear VLAN. %Creamos vlan RA(config)#vlan 20 %Le ponemos nombre RA(config-vlan)#name P2 RA(config-vlan)#exit %Nos vamos a la interfaz virtual creada para la VLAN 20 RA(config)#int vlan 20 %Con el siguiente comando levantamos la interfaz RA(config-if)#no shut %No queremos dirección IPv4 RA(config-if)#no ip address %Seleccionamos la dirección IPv6 que tendrá la interfaz virtual RA(config-if)#ipv6 address 2001:720:c18:ba::100/64 RA(config-if)#exit %Seleccionamos los puertos RA(config)#int range f2-3 %Esos puertos serán de modo access 10 y pertenecientes a la VLAN 20 RA(config-if-range)#sw mode access RA(config-if-range)#sw access vlan 20 RA(config-if-range)#no shut RA(config-if-range)#exit %Por último guardamos la configuración RA#copy running-config startup-config Una vez creadas las VLANs, tenemos que introducir el siguiente comando para habilitar el reenvío de datagramas IPv6, que por defecto se encuentra deshabilitado: 9 Por simplicidad, solo se presenta el código para crear una VLAN. Las demás se crean usando los mismos comandos pero cambiando nombre de VLAN, puertos, etc., como es obvio. 10 Recordemos que un puerto de un switch tiene dos modos de funcionamiento: trunk y access. El primero se usa en la interconexión entre switches y el segundo cuando se interconecta switch con equipos finales.

47 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 27 RA(config)#ipv6 unicast-routing Podemos comprobar que el router está bien configurado y envía mensajes RA con información correcta de la red. Para ello usamos el siguiente comando que nos da información sobre el mensaje RA que envía el router para la VLAN que se diga, por ejemplo para la VLAN 10: RA(config-if)#do show ipv6 int vlan 10 Obtenemos la siguiente información: Vlan10 is up, line protocol is up IPv6 is enabled, link-local address is FE80::6E20:56FF:FE34:3FFC No Virtual link-local address(es): Global unicast address(es): 2001:720:C18:B9::100, subnet is 2001:720:C18:B9::/64 Joined group address(es): FF02::1 FF02::2 FF02::1:FF00:0 FF02::1:FF34:3FFC MTU is 1500 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ICMP unreachables are sent ND DAD is enabled, number of DAD attempts: 1 ND reachable time is milliseconds (using 30000) ND advertised reachable time is 0 (unspecified) ND advertised retransmit interval is 0 (unspecified) ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds ND advertised default router preference is Medium Podemos ver que la dirección de la interfaz y de la subred son las deseadas. También es posible observar que se envían mensajes RA cada 200 milisegundos 11 con un tiempo de vida de 1800 segundos. Esto es posible cambiarlo si el lector lo desea. Para cambiar cada cuánto tiempo se envía un RA, introducimos ipv6 nd rainterval VALOR (en milisegundos). Si lo que se desea es cambiar el tiempo de vida de los RA, escriba ipv6 nd ra-lifetime VALOR (en segundos). Solo falta un último detalle para dar por concluido la configuración del router. El papel del HA lo hará el equipo s2ipv6, luego para que s1ipv6, que es nuestro MN, pueda enterarse es necesario que s2ipv6 se lo notifique. Para ello, debe enviar un mensaje RA con el bit H activado e incluir la información a través de la opción Home Agent Information. Esto implica que el equipo s2ipv6 tiene que funcionar como router. El problema es para s1ipv6, ya que le llegarán RAs de dos equipos distintos y no sabemos a priori a cuál de las dos configuraciones aceptará así cómo a quién pondrá como puerta de enlace predeterminada. Para evitar problemas lo que hacemos es desactivar el envío de RA (tanto periódicos como los de respuesta a un RS) de la interfaz que esté en la subred que hemos destinado a que sea la HN. Para realizar tal cometido, introducimos los siguientes comandos 12 : RA(config)#interface vlan 30 RA(config-if)#ipv6 nd ra lifetime 0 Como nota antes de terminar, si usted ha realizado cambios en la configuración y desea deshacerlos, le 11 Aunque Cisco nos diga que se produce cada 200 segundos, el valor en realidad es en milisegundos pues se ha comprobado capturando tráfico. Se supone que es un fallo del software del dispositivo. 12 Recuerde que debe salvar los cambios antes de apagar el router, ya que si no lo hace, estos no estarán disponibles la próxima vez que encienda el dispositivo. Para guardar los cambios realizados ejecute: copy running-config startup-config

48 28 Desarrollo Del Escenario presentamos el siguiente comando. Lo que hace éste es regresar a la configuración guardada anteriormente: RA#copy startup-config running-config 4.3. Instalación Software de Movilidad Antes de pasar a la configuración de la movilidad en los equipos s1ipv6 y s2ipv6, primero tendremos que instalar el software de movilidad que nos proporciona UMIP en ambos equipos. Para ello hay que seguir los pasos que se describen en su web [4-3] Recompilar Kernel Para instalar ese software de movilidad, inicialmente es necesario realizar una recompilación del kernel en ambos equipos. Antes de nada necesitamos saber la versión actual de nuestro kernel, para ello, ejecutamos en un terminal como root: uname -a Si la versión de nuestro kernel es inferior a la 3.8.1, como es nuestro caso, podemos elegir uno de estos dos caminos: 1. Descargar de la siguiente URL: los archivos que usaremos como parches para poder realizar la recompilación. Según el README.txt, en nuestro caso necesitamos de los cuatro ficheros de ese repositorio: 0001-ipv6-fix-header-length-calculation-in-ip6_append_data.patch 0001-ipv6-fix-the-noflags-test-in-addrconf_get_prefix_route.patch 0001-ipv6-use-addrconf_get_prefix_route-for-prefix-route-lookup.patch 0001-xfrm-release-neighbor-upon-dst-destruction.patch 2. Instalar una versión de kernel superior a la 3.8.1, ya que estos kernels ya cuentan con soporte para la movilidad. Nosotros optaremos por el camino 2. Por lo que a partir de aquí explicaremos los pasos a seguir para llevar a cabo nuestro cometido. En primer lugar nos descargamos la versión del kernel desde la web. Nosotros hemos optado por la 3.8.2, que sabemos que lleva incluido los módulos para la movilidad IP y es una versión estable. Para ello ejecutamos en un terminal como root: cd /usr/src/ wget Posteriormente, descomprimimos e instalamos las librerías necesarias para la recompilación: bunzip2 linux tar.bz2 tar xf linux tar apt-get install fakeroot kernel-package apt-get install libncurses5-dev Ahora, copiamos la configuración de nuestro actual kernel, para así partir de ella en la nueva configuración: cp /boot/config pae /usr/src/linux-3.8.2/.config Hacemos efectivo lo anterior, ejecutando: make oldconfig

49 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 29 Nota: pulsamos enter hasta terminar para no cambiar nada de nuestra vieja configuración A continuación, ejecutamos make menuconfig. Para poder utilizar este comando necesitamos tener la librería libncurses5-dev, que ya instalamos en el paso 2: make menuconfig Una vez ejecutemos menuconfig nos saldrá un menú donde podremos activar y desactivar opciones del kernel. Para nuestro cometido tendremos que activar las siguientes: General setup --> Prompt for development and/or incomplete code/drivers [CONFIG_EXPERIMENTAL] --> System V IPC [CONFIG_SYSVIPC] Networking support [CONFIG_NET] --> Networking options --> Transformation user configuration interface [CONFIG_XFRM_USER] --> Transformation sub policy support [CONFIG_XFRM_SUB_POLICY] --> Transformation migrate database [CONFIG_XFRM_MIGRATE] --> PF_KEY sockets [CONFIG_NET_KEY] --> PF_KEY MIGRATE [CONFIG_NET_KEY_MIGRATE] --> TCP/IP networking [CONFIG_INET] --> The IPv6 protocol [CONFIG_IPV6] --> IPv6: AH transformation [CONFIG_INET6_AH] --> IPv6: ESP transformation [CONFIG_INET6_ESP] --> IPv6: IPComp transformation [CONFIG_INET6_IPCOMP] --> IPv6: Mobility [CONFIG_IPV6_MIP6] --> IPv6: IPsec transport mode [CONFIG_INET6_XFRM_MODE_TRANSPORT] --> IPv6: IPsec tunnel mode [CONFIG_INET6_XFRM_MODE_TUNNEL] --> IPv6: MIPv6 route optimization mode [CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION] --> IPv6: IP-in-IPv6 tunnel (RFC2473) [CONFIG_IPV6_TUNNEL] --> IPv6: Multiple Routing Tables [CONFIG_IPV6_MULTIPLE_TABLES] --> IPv6: source address based routing [CONFIG_IPV6_SUBTREES] File systems --> Pseudo filesystems --> /proc file system support [CONFIG_PROC_FS] Si se han completado con éxito todos los pasos anteriores, ya estamos en condiciones a poder continuar con la recompilación del kernel. Para ello ejecutamos: make-kpkg clean %Esta orden limpia el árbol del código fuente, por si se intentó configurar el kernel anteriormente y no hubo éxito export CONCURRENCY_LEVEL=5 %acelera el compilado del kernel fakeroot make-kpkg --append-to-version -mipv6 --revision 1 -- initrd kernel_image kernel_headers; shutdown h now % mipv6 es el nombre que le vamos a dar a nuestro nuevo kernel

50 30 Desarrollo Del Escenario El comando fakeroot puede tardar horas en terminar dependiendo del procesador del equipo. Es por ello que hemos añadido la orden shutdown para no tener que estar pendientes de apagar el equipo manualmente cuando termina el proceso. Una vez terminada la compilación, debemos corroborar la existencia de dos paquetes.deb en el directorio de trabajo. Ahora ejecutamos: dpkg -i *.deb Reiniciamos el PC y comprobamos que en el menú de arranque del equipo tenemos un nuevo kernel. Solo queda iniciar desde él Compilar e instalar UMIP Una vez hemos recompilado el kernel, nuestro cometido es compilar el código fuente del software de UMIP. Para poder compilar y posteriormente usar UMIP, se necesitan los siguientes paquetes: autoconf, automake, bison, flex, libssl-dev, indent, ipsec-tools y radvd. Para ello ejecutamos como root en un terminal: apt-get install autoconf automake bison flex libssl-dev indent ipsectools radvd Luego, bajamos el código fuente del repositorio oficial y nos situamos en la nueva carpeta que se ha creado: cd /usr/src/ git clone git://git.umip.org/umip.git cd umip/ Por último, procedemos a la compilación: autoreconf -i CPPFLAGS='-isystem /usr/src/linux-3.8.2/'./configure --enable-vt make make install CPPFLAGS sirve para indicar dónde se encuentran las cabeceras del núcleo. La opción --enable-vt hace que UMIP disponga de un terminal virtual, útil para recuperar información del MN y del HA, como puede ser la tabla de bindings, cuántos BA y BU se han mandado/recibido, etc Configuración s1ipv6 En este apartado procederemos a la configuración del equipo s1ipv6, que como ya se ha citado anteriormente, actuará de MN. Antes de nada, recordemos qué VLAN será la HN y cuál la FN. La VLAN 30 sea la HN y la VLAN 10 la FN. La decisión se tomó en el apartado 4.2 sin ningún motivo especial. Ahora comencemos a configurar al equipo s1ipv6. Para hacerlo correctamente, partimos de la información proporcionada en la web de UMIP [4-4]. Lo primero que tenemos que hacer es copiar el siguiente código en un fichero que crearemos, que se llamará mip6d.conf y que se situará en la ruta /usr/local/etc:

51 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 31 Código 4-3. Archivo de configuración MN. # Sample UMIP configuration file for a MIPv6 Mobile Node NodeConfig MN; # Set DebugLevel to 0 if you do not want debug messages DebugLevel 10; # Enable the optimistic handovers OptimisticHandoff enabled; # Disable RO with other MNs (it is not compatible # with IPsec Tunnel Payload) DoRouteOptimizationMN disabled; # The Binding Lifetime (in sec.) MnMaxHaBindingLife 60; # List here the interfaces that you will use # on your mobile node. The available one with # the smallest preference number will be used. Interface "eth1" { MnIfPreference 1; } Interface eth0 { MnIfPreference 2; } # Replace eth0 with one of your interface used on # your mobile node MnHomeLink "eth0" { HomeAgentAddress 2001:720:c18:bb:24f:4eff:fe01:ad52; HomeAddress 2001:720:c18:bb:24f:4eff:fe0f:77ff/64; } # Enable IPsec static keying UseMnHaIPsec disabled; KeyMngMobCapability disabled; # IPsec Security Policies information IPsecPolicySet { HomeAgentAddress 2001:720:c18:bb:24f:4eff:fe01:ad52; HomeAddress 2001:720:c18:bb:24f:4eff:fe0f:77ff/64; } # All MH packets (BU/BA/BERR) IPsecPolicy Mh UseESP 11 12; # All tunneled packets (HoTI/HoT, payload) IPsecPolicy TunnelPayload UseESP 13 14; # All ICMP packets (MPS/MPA, ICMPv6) IPsecPolicy ICMP UseESP 15 16; Comentemos un poco el archivo de configuración anterior. Podemos ver que se ha activado la opción Optimistic Handover. Ésta permite al MN, suponiendo que acaba de llegar a FN, transmitir paquetes tan pronto se envía el BU, sin tener que esperar a recibir el mensaje BA, con lo que se reduce el tiempo de traspaso. Lo segundo que observamos es que DoRouteOptimizationMN está desactivada, esto implica que en un principio no usaremos la opción Route Optimization, ya que su activación implicaría perder la protección de

52 32 Desarrollo Del Escenario IPsec para el tráfico de entrada/salida en la FN. También vemos que se usa un tiempo de vida de los mensajes de Bindings (BU, BA, etc) de un minuto. Lo siguiente que aparece es una lista donde se detallan las interfaces preferidas. Qué quiere decir esto. Supongamos que tenemos tres interfaces de red, dos de ellas Ethernet y otra inalámbrica. Cuando lleguemos a una red WLAN (Wireless Local Area Network), el MN se conectará a ella usando la interfaz inalámbrica. Pero qué pasa si la nueva red es Ethernet, cuál de las dos interfaces de las que disponemos será la que use el MN cuando llegue a la FN. Para ello tenemos esta lista de preferencias. Si queremos que la interfaz eth0 sea la primera que use el MN cuando llegue a una nueva red, le ponemos la preferencia 1. Si no pudiera estar disponible, le damos preferencia 2 a la que se debería usar en tal efecto, en este caso eth1. Lo próximo en poner es la dirección HoA y la del Home Agent. Esto hace que UMIP sea poco versátil y por eso de momento solo se usa en escenarios de pruebas. Y es que debemos de saber a priori la dirección del HA y la HoA. Lo bueno de estar usando SLAAC y tener siempre los mismos prefijos de red, es que estas direcciones no van a cambiar por lo que no vamos a tener que modificar el archivo, salvo que se quieran cambiar otras características como es obvio. A continuación, viene la opción UseMnHaIPsec que en un principio va a estar desactivada para así poder ver en las pruebas los mensajes de movilidad y su contenido. Aunque posteriormente habrá pruebas en las que se usen IPsec para mostrar que MIPv6 es un protocolo seguro, así que tendremos que activar en su momento esta opción. Lo siguiente en aparecer es KeyMngMobCapability. Si se activa, pone el bit K de los mensajes BU y BA a uno, lo que indica que se debe usar un protocolo de intercambio de claves. En nuestro proyecto las claves se suministrarán manualmente por lo que esta opción siempre estará deshabilitada. El siguiente bloque de configuración (IPsecPolicySet) es de particular interés. Se ocupa de la protección IPsec del tráfico, tanto de datos como de señalización, entre el HA y el MN. Lo primero que se proporcionan son las direcciones del HA y la HoA del MN. Seguidamente se describen las políticas IPsec, donde se usa ESP, y son las siguientes: Tráfico de señalización entre MN y HA, es decir, mensajes BU, BA y BE (IPsecPolicy Mh UseESP 11 12). Los datos del tráfico entre el MN y HA (IPsecPolicy TunnelPayload UseESP 13 14). Tráfico ICMP entre el MN y HA (IPsecPolicy ICMP UseESP 13 14). Estas reglas cubren todo el tráfico entre el MN y el HA. Para llevarlas a cabo, UMIP necesitará establecer SAs cuya implementación explicaremos a continuación. Creamos el fichero setkey.conf y lo situamos en /usr/local/etc. Ahí situamos el siguiente código de configuración: Código 4-4. Configuración de las SA de IPsec. # IPsec Security Associations # HA address: 2001:720:c18:bb:24f:4eff:fe01:ad52 # MR HoAs: 2001:720:c18:bb:24f:4eff:fe0f:77ff/64; # Flush the SAD and SPD flush; spdflush; # MN1 -> HA transport SA for BU add 2001:720:c18:bb:24f:4eff:fe0f:77ff 2001:720:c18:bb:24f:4eff:fe01:ad52 esp 0x11 -u 11 -m transport -E 3des-cbc "MIP " -A hmac-sha1 "MIP " ;

53 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 33 # HA -> MN1 transport SA for BA add 2001:720:c18:bb:24f:4eff:fe01:ad :720:c18:bb:24f:4eff:fe0f:77ff esp 0x12 -u 12 -m transport -E 3des-cbc "MIP " -A hmac-sha1 "MIP " ; # MN1 -> HA tunnel SA for any traffic add 2001:720:c18:bb:24f:4eff:fe0f:77ff 2001:720:c18:bb:24f:4eff:fe01:ad52 esp 0x13 -u 13 -m tunnel -E 3des-cbc "MIP " -A hmac-sha1 "MIP " ; # HA -> MN1 tunnel SA for any traffic add 2001:720:c18:bb:24f:4eff:fe01:ad :720:c18:bb:24f:4eff:fe0f:77ff esp 0x14 -u 14 -m tunnel -E 3des-cbc "MIP " -A hmac-sha1 "MIP " ; # MN1 -> HA transport SA for ICMP (including MPS/MPA) add 2001:720:c18:bb:24f:4eff:fe0f:77ff 2001:720:c18:bb:24f:4eff:fe01:ad52 esp 0x15 -u 15 -m transport -E 3des-cbc "MIP " -A hmac-sha1 "MIP " ; # HA -> MN1 transport SA for ICMP (including MPS/MPA) add 2001:720:c18:bb:24f:4eff:fe01:ad :720:c18:bb:24f:4eff:fe0f:77ff esp 0x16 -u 16 -m transport -E 3des-cbc "MIP " -A hmac-sha1 "MIP " ; Hay que tener en cuenta que MR HoAs es la dirección HoA de nuestro MN. Y con esto damos por concluida la configuración de este equipo Configuración s2ipv6 Esta sección está dedicada a la configuración del s2ipv6, que recordemos actuará de HA. Igual que para la configuración del MN, partiremos de las indicaciones que nos da UMIP en su página web [4-4]. Lo primero que haremos es crear el fichero de configuración llamado mip6d.conf en la siguiente ruta /usr/local/etc. En ese fichero introducimos el siguiente código de configuración 13 : 13 Recuerde que las direcciones de los equipos s1ipv6 y s2ipv6 se obtienen mediante SLAAC. Al usar siempre el mismo prefijo de red, éstas no cambiarán luego no hará falta modificar el fichero. Recuerde que para saber las direcciones de las interfaces de un equipo deberá ejecutar ifconfig en un terminal.

54 34 Desarrollo Del Escenario Código 4-5. Archivo de configuración HA. # Sample UMIP configuration file for a MIPv6 Home Agent NodeConfig HA; # Set DebugLevel to 0 if you do not want debug messages DebugLevel 10; # Replace eth0 with the interface connected to the home link Interface "eth0"; # Binding information BindingAclPolicy 2001:720:c18:bb:24f:4eff:fe01:ad52 allow; DefaultBindingAclPolicy deny; # Enable IPsec static keying UseMnHaIPsec enabled; KeyMngMobCapability disabled; # IPsec Security Policies information IPsecPolicySet { HomeAgentAddress 2001:720:c18:bb:24f:4eff:fe01:ad52; HomeAddress 2001:720:c18:bb:24f:4eff:fe0f:77ff/64; # All MH packets (BU/BA/BERR) IPsecPolicy Mh UseESP 11 12; # All tunneled packets (HoTI/HoT, payload) IPsecPolicy TunnelPayload UseESP 13 14; # All ICMP packets (MPS/MPA, ICMPv6) IPsecPolicy ICMP UseESP 15 16; } Comentemos un poco el código anterior. Como se puede apreciar, una de las cosas que tenemos que indicar es la interfaz que estará conectada a la HN, en nuestro caso la eth0. Un aspecto de seguridad importante que UMIP tiene en cuenta, es la autenticación en el servidor. Ésta la realiza mediante políticas ACL, de tal forma que el HA solo intercambiará Bindings con el equipo que tendrá la dirección IPv6 que estamos indicando en la opción BindingAclPolicy DIRECCION IPv6 allow. Si viene otro dispositivo, que evidentemente tendrá otra dirección IPv6, según nuestra política ACL, rechazaremos su Binding 14. El último bloque se usa para la protección IPsec. La configuración es la misma que para el MN, luego este código es el mismo que aparece en el archivo de configuración del MN. Esto implica que las SAs son iguales, de ahí que usemos el mismo fichero de configuración que para el MN. Para ello, copiamos el código 4-4 y lo insertamos en el fichero setkey.conf que tenemos que crear en la ruta /usr/local/etc. Como comentamos en el apartado 4.2, este equipo actuará de router, por lo que tendrá que asumir las principales funcionalidades de un encaminador en IPv6, entre ellas, tener la capacidad de enviar y recibir RA y RS respectivamente, y la de reenviar paquetes cuando él no sea el destinatario. Para que s2ipv6 pueda enviar RA, necesitará de una serie de librerías para llevar a cabo tal cometido. Es por ello que en el apartado se instaló el software radvd. Este programa de código abierto, no es más que un daemon que envía RA periódicos que contienen el prefijo de la red, así como el MTU máximo y la puerta de enlace determinada. Es evidente que el siguiente paso es configurar radvd para que envíe la información que nosotros queramos. 14 Como UMIP solo se usa en escenarios de pruebas no vamos a suponer que hayan usuarios maliciosos, ya que seríamos vulnerables a ataques simples. Por ejemplo, un usuario malicioso que conozca nuestra IP, puede robárnosla y usarla para esquivar las políticas ACL que hemos introducido.

55 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 35 Para ello tenemos que crear un fichero que radvd use como configuración por defecto. Este fichero se llamará radvd.conf y se hallará en /etc. Deberá contener el siguiente código: Código 4-6. Configuración de radvd. # Home Agent radvd configuration file # Replace eth0 with the interface connected to the home link interface eth0 { AdvSendAdvert on; MaxRtrAdvInterval 3; MinRtrAdvInterval 1; AdvIntervalOpt on; AdvHomeAgentFlag on; AdvHomeAgentInfo on; HomeAgentLifetime 1800; HomeAgentPreference 10; }; # Home Agent address prefix 2001:720:c18:bb::/64 { AdvRouterAddr on; AdvOnLink on; AdvAutonomous on; }; Se puede apreciar que estamos dando información tal como el prefijo que queremos que se anuncie, que éste puede ser usado para hacer SLAAC (AdvAutonomous on), el tiempo de vida del Home Agent (recordar que es un campo de la opción Home Agent Information de un mensaje RA), el tiempo máximo entre mensajes RA (que no han sido solicitados) consecutivos, etc. [4-5] Por defecto radvd suele arrancar en el inicio, pero si queremos ejecutarlo manualmente, hay que escribir en línea de comandos: radvd -C /etc/radvd.conf Lo siguiente que debe hacer s2ipv6 es poder reenviar paquetes, para ello tenemos que modificar el fichero /etc/sysctl.conf descomentando la siguiente línea: net.ipv6.conf.all.forwarding=1 Por último debido a que el router Cisco no envía mensajes RA en la subred donde se encuentra s2ipv6, éste no sabe dónde está la puerta de enlace por defecto. Por lo que tenemos que añadir a la tabla de encaminamiento de s2ipv6, la siguiente entrada: route -Ainet6 add default gw 2001:720:c18:bb::300 Con esto último hemos terminado de configurar al equipo s2ipv Configuración CN1 Este equipo no necesita de apenas configuración. Solo requerimos que tenga instalado el Sistema Operativo Debian. Aunque sí podemos añadir una serie de herramientas en función de las pruebas que acometeremos en el siguiente capítulo. Por ejemplo, una de las pruebas consistirá en una transferencia FTP. Para facilitarnos el trabajo es buena idea instalar un cliente FTP como es el caso de FileZilla, cuya instalación y configuración puede consultarla en el Anexo C.

56 36 Desarrollo Del Escenario 4.7. Esquema de conexión Una vez ya tenemos todos nuestros equipos correctamente configurados, el siguiente paso será conectarlos correctamente para que todo pueda funcionar. El esquema de conexión que vamos a seguir lo detallamos a continuación: s1ipv6: recordemos que este equipo dispone de dos interfaces de red. La interfaz eth0 la conectaremos a la HN, que como dijimos será la VLAN 30, concretamente al switchport número 4. La otra, eth1, irá conectada al switchport 0, perteneciente a la VLAN 10 (que es la FN). Además usaremos un puerto serie de este equipo que irá conectado al puerto de consola del router, para labores de configuración y mantenimiento de éste. s2ipv6: este equipo solo dispone de una única interfaz. Ésta irá conectada al switchport número 7, perteneciente a la VLAN 30. CN1: usaremos una interfaz Ethernet para conectarlo mediante cable RJ-45 (el mismo usado para las otras conexiones, menos para la del puerto de consola) al switchport número 4, perteneciente a la VLAN 20. Todas las conexiones citadas se muestran en la siguiente figura: Figura 4-2. Esquema de conexión Arrancar servicios de Movilidad Ya tenemos todo el escenario montado y los equipos configurados. El siguiente paso sería activar el software de movilidad tanto en el MN como en el HA. Podemos optar por dos caminos para llevar a cabo dicha tarea. La primera sería utilizar el script de arranque que se encuentra en la web de UMIP y que hemos plasmado en el Anexo D. De esta forma, el servicio de movilidad en ambos equipos se iniciaría en el arranque del sistema. La otra alternativa es iniciar el software de forma manual, para ello ejecutamos en un terminal del HA y del MN la siguiente instrucción como root: mip6d -c /usr/local/etc/mip6d.conf

57 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 37 Ésta es la opción que hemos optado en este proyecto, así tenemos un mayor control, ya que solo usamos el servicio cuando queremos y así quitamos carga de trabajo a la CPU. Recuerde que para hacer pruebas de movilidad, antes de nada, deberá de arrancar el software de movilidad en ambos equipos.

58

59 5 ANÁLISIS E stamos ante la sección principal de nuestro proyecto. A lo largo de esta memoria hemos enlazado capítulo a capítulo para obtener todos los conocimientos necesarios para entender todo lo que se verá en esta sección. Habíamos comenzado con una introducción a IPv6 donde se explicó los distintos tipos de direcciones, ya que algunas de ellas las podremos observar en las pruebas. También explicamos brevemente protocolos que se usarán inherentemente como son ND e ICMPv6. Después continuamos hablando sobre los principales conceptos de movilidad. De esta forma ya estaríamos preparados para poder hacer pruebas de MIPv6, no sin antes disponer de un escenario para llevar a cabo tal cometido, es por esa razón, que dedicamos un capítulo a su creación y configuración. A partir de ahora veremos las distintas pruebas que hemos llevado a cabo. El objetivo de éstas tiene una doble vertiente. La primera es demostrar las cualidades de MIPv6 que llevamos recordando a lo largo de este proyecto: si un equipo cambia de red, su dirección IP no cambia, con todas las ventajas que esto conlleva. Lo segundo, es valorar el rendimiento de la movilidad, es decir, necesitamos saber cuánto tiempo aproximado tarda nuestro equipo en estar disponible para recibir nuevos paquetes. Las primeras pruebas serán de análisis del protocolo de movilidad y tendrán un fin didáctico. Es decir, son pruebas que no nos sirven para medir el rendimiento de MIPv6, pero sí para entender el funcionamiento de éste. Posteriormente realizaremos una serie de pruebas con el objetivo de poder evaluar MIPv6, para ello tenemos que obtener unos datos fiables con los que poder hacer un balance sobre el rendimiento de este protocolo Análisis del funcionamiento Como se comentó anteriormente, estas pruebas tienen como objetivo mostrar el funcionamiento de MIPv6 y comprobar si la puesta en práctica varía mucho de lo propuesto en los RFC correspondientes. Las pruebas para análisis que hemos hecho son las siguientes: ping6 15 sin traspaso, es decir, el MN se encuentra en la HN. ping6 con traspaso, esto es, el MN en un cierto instante pasa de la HN a la FN. ping6 traspasado, esto significa que en el momento del ping6 el MN ya se encuentra en la nueva red. ping6 con regreso, es decir, el MN se encuentra en la FN, pero en cierto instante decide volver a casa. Las tres primeras pruebas pero con el protocolo ESP activado. Todas estas pruebas se hallan recogidas en el CD que se adjunta a esta memoria. Se tratan de capturas del tráfico hechas con Wireshark tanto en el MN como en el HA. Además de ficheros de texto que recogen la información de los terminales virtuales y demonios que se ejecutan en el MN y el HA, se incluyen la salida de pantalla de los resultados de ping6 hechos en el CN1. En esta memoria solo se han recogido las pruebas que se detallan a continuación porque son las que consideramos más interesantes para mostrar. 15 Todos los ping6 se hacen desde el CN hacia el MN 39

60 40 5 Análisis Prueba 1: Ping6 con traspaso. Para llevar a cabo esta prueba, tenemos que tener desactivado el protocolo ESP en nuestros archivos de configuración del MN y del HA 16. Para ello, asegúrese que la opción UseMnHaIPsec aparece marcada como disabled. Hemos decidido no proteger los mensajes de movilidad que se intercambian MN y HA con ESP porque, si los encriptásemos, solo veríamos un flujo de paquetes IPv6 en ambas direcciones sin saber qué contienen. Cómo el objetivo de este apartado es didáctico, es conveniente ver el contenido de esos mensajes para así comprobar que en la práctica la movilidad funciona tal y como se describe en los RFCs. Esta prueba consiste en hacer varios ping6 desde el CN hasta el MN que en un principio se encuentra en la HN. Al encontrarse el nodo móvil en su casa, no hay ningún intercambio de bindings entre él y el HA. Además los paquetes se entregarán al MN según los mecanismos tradicionales, tal y como se comentó en el capítulo 3.1. Esta situación puede verse en la siguiente figura, donde las flechas verdes representan la trayectoria de los mensajes de ida y las rojas los de vuelta: La trayectoria que sigue los mensajes es la siguiente: Ida: Vuelta: Figura 5-1. Escenario prueba 1 con MN en casa. Expliquemos un poco por qué se sigue esa trayectoria. CN1 (1) envía echo request que llega al router Cisco (2). Éste ve que el destino es s1ipv6 y se lo entrega directamente (4) puesto que está accesible. El equipo s1ipv6 (4) responde con un echo reply y mira su tabla de encaminamiento, como la puerta de enlace es la del equipo s2ipv6 17 le envía a éste la respuesta. Ésta pasa de s2ipv6 (3) al router (2), y finalmente al CN1 (1). Para hacer ping6, abrimos un terminal en el CN1 y escribimos lo siguiente: 16 No olvide que la ruta de los archivos de configuración en ambos equipos es: /usr/local/etc/mip6d.conf 17 Recuerde que habíamos desactivado el envío de los RA del router y que en esa subred solo enviaba este tipo de mensajes el equipo s2ipv6. Estos contienen como puerta de enlace predeterminada la dirección IPv6 del s2ipv6

61 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 41 ping6 DIRECCION_IPv6_MN -c 20 -i 5 Con la opción c indicamos el número de echo request a enviar, en este caso 20. Y con la opción i indicamos el intervalo de tiempo que habrá entre un echo y otro, en este caso 5 segundos. La razón por la cual se ha tomado estos valores y no otros, es porque así podemos ver mejor que sucede entre un ping y otro. En unos instantes posteriores al recibir el quinto echo reply, el MN pasa de la VLAN 30 a la VLAN 10, simulando que hemos hecho un traspaso de la HN a la FN. Para conseguir el handover, podemos coger el cable que une a la interfaz eth0 con el router y cambiarlo de puerto, así se consigue que el equipo pase de una VLAN a otra. Pero esta opción no es viable, ya que para medir el rendimiento en posteriores apartados, el tiempo que tardamos en desenchufar el cable y cambiarlo de puerto, es difícil de medir. Entonces tenemos que optar por un mecanismo que haga el cambio de una red a otra en un tiempo tan insignificante que luego no nos influya en las medidas del rendimiento. Recordemos que el equipo s1ipv6 tiene dos tarjetas de red, y que según el apartado 4.7 una de ellas se conectó a la VLAN 30 y la otra a la VLAN 10. Esto no se hizo por casualidad ya que lo que pretendemos hacer es lo siguiente: en un principio solo está activa la interfaz eth0 que se encuentra conectada al puerto que pertenece a la VLAN 30 (HN) y la interfaz eth1, conectada a la VLAN 10, estará desactivada. Cuando queramos hacer el traspaso, bajamos la interfaz eth0 y subimos la eth1, consiguiendo así el traspaso deseado, ya que el equipo s1ipv6 solo tendrá una interfaz activa que pertenece a otra subred. Para poder llevar a cabo lo explicado en el anterior párrafo, usamos el script que podrá encontrar en el Anexo E. Según éste, hay que ejecutar como root el script con el formato./scriptinterfaz.sh interfaz_on interfaz_off, donde el primer parámetro es la interfaz que inicialmente queremos que esté arriba y el segundo, la interfaz que queremos que esté abajo, en nuestro caso, eth0 y eth1 respectivamente. Retomemos por dónde íbamos. CN se encuentra mandando ping6 periódicos al MN cada 5 segundos. Aproximadamente cuando el CN ha recibido el quinto echo reply, se ejecuta en el MN scriptinterfaz.sh con parámetros eth0 y eth1. A partir de ese momento, tenemos el siguiente escenario donde las flechas naranjas representa la trayectoria de los mensajes de ida y vuelta: Figura 5-2. Escenario prueba 1 con MN en FN. MN detecta el cambio de red gracias al protocolo ND. Puede averiguar este cambio porque envía un NS y

62 42 5 Análisis obtiene información del medio distinta a la de antes, o porque le llega un RA con un información nueva. En nuestra prueba se ha dado el segundo caso. Cabe decir que debido al bajo periodo de envío de RA por parte del router, no es necesario que el MN envíe mensajes RS para solicitarlo. Continuemos nuestra explicación viendo la siguiente figura: Figura 5-3. Mensajes a la llegada del MN a la FN. Podemos ver que antes del ping con número de secuencia igual a 5, se reciben RA provenientes de la dirección del HA, luego el MN no había migrado. Posteriormente se recibe un RA (1) que proviene del router Cisco, esto ya nos dice que ha habido un traspaso. Una vez que el MN configura su dirección mediante SLAAC gracias a la información del prefijo recogida del RA (3), manda un NS (2) para comprobar que su dirección no está duplicada en la red. En este momento, se produce una asociación entre la HoA y la CoA. Comprobemos que esto se produce ejecutando el terminal virtual de UMIP en el MN, para ello introducimos como root telnet localhost 7777 y luego, verbose yes. A partir de aquí podemos usar dos órdenes, stats para ver cuántos y de qué tipos son los mensajes de movilidad que se han enviado y recibido, y bul que nos muestra información de la Binding Update List (BUL). Ejecutando esta última orden, obtenemos: mip6d> bul == BUL_ENTRY == Home address 2001:720:c18:bb:24f:4eff:fe0f:77ff Care-of address 2001:720:c18:b9:20d:61ff:fec6:f8c4 CN address 2001:720:c18:bb:24f:4eff:fe01:ad52 lifetime = 60, delay = flags: IP6_MH_BU_HOME IP6_MH_BU_ACK IP6_MH_BU_LLOCAL ack ready dev eth1 last_coa 2001:720:c18:b9:20d:61ff:fec6:f8c4 lifetime 17 / 60 seq resend 0 delay 57(after 14s) expires 17 mps / Donde podemos ver la dirección HoA, CoA y la CN address que en este contexto no es la dirección del CN, sino la del equipo al que se le envía la respuesta. Como en este caso no estamos usando Route Optimization, el equipo de destino es el HA. Una vez guardada la asociación en la BUL, envía el mensaje BU. El paquete que contiene a este mensaje lleva la información que podemos ver en la siguiente imagen:

63 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 43 Figura 5-4. Mensaje BU enviado por el MN. Comentemos la figura anterior. Primero observamos que la dirección que muestra Wireshark como origen del paquete (1) es distinta a la que contiene el campo Source Address de la cabecera IPv6 (2). Recordemos que existía el campo Destination Option donde se incluye la HoA. Pues bien, Wireshark ha cogido el valor de este campo para sustituirlo a la dirección del origen del paquete, así a ojos de las capas superiores parece que no se ha cambiado de red, aunque para el objetivo de esta prueba, esto da lugar a confusión pues puede hacer pensar que no se ha migrado de red. Continuando con la descripción de la figura, vemos que una de las opciones (3) es pedir un BA como respuesta al BU. Por último apreciamos que se envía la Alternate CoA (4). Esto quiere decir que no se coge el origen del paquete como CoA, sino la dirección que está incluida en este campo. A continuación, se registra la asociación en la Binding Cache, y si todo está correcto se manda un mensaje BA de respuesta. Aquí se deja un extracto de la salida de pantalla del demonio que se ejecuta en el HA: Tue Jul 29 17:21:36 mh_bu_parse: Binding Update Received Tue Jul 29 17:21:37 ndisc_do_dad: Dad success Tue Jul 29 17:21:37 tunnel_add: created tunnel ip6tnl1 (5) from 2001:720:c18:bb:24f:4eff:fe01:ad52 to 2001:720:c18:b9:20d:61ff:fec6:f8c4 user count 1 Tue Jul 29 17:21:37 mh_send_ba: status Binding Update accepted (0) Tue Jul 29 17:21:37 mh_send: sending MH type 6 from 2001:720:c18:bb:24f:4eff:fe01:ad52 to 2001:720:c18:bb:24f:4eff:fe0f:77ff Tue Jul 29 17:21:37 mh_send: remote CoA 2001:720:c18:b9:20d:61ff:fec6:f8c4 Tue Jul 29 17:22:33 mh_bu_parse: Binding Update Received Tue Jul 29 17:22:33 tunnel_mod: modifying tunnel 5 end points with from 2001:720:c18:bb:24f:4eff:fe01:ad52 to 2001:720:c18:b9:20d:61ff:fec6:f8c4 Tue Jul 29 17:22:33 mh_send_ba: status Binding Update accepted (0) Tue Jul 29 17:22:33 mh_send: sending MH type 6 from 2001:720:c18:bb:24f:4eff:fe01:ad52

64 44 5 Análisis to 2001:720:c18:bb:24f:4eff:fe0f:77ff Estos son los eventos más importantes con la fecha y hora a la que suceden. Vemos que cuando se recibe el BU, se comprueba que la dirección del MN no está duplicada (DAD), y en ese caso, se crea un túnel por donde circularán los paquetes de movilidad y de datos entre el HA y el MN. Posteriormente, se envía el mensaje BA de respuesta 18. Se puede comprobar que cuando se reciben nuevos BU procedentes del mismo MN lo que se hace es modificar el túnel existente, no crear uno nuevo. Mediante Wireshark hagamos como con el BU y veamos el contenido del paquete que contiene al BA que manda el HA al MN: Figura 5-5. Mensaje BA enviado por el HA. Ocurre lo mismo que comentamos en el paquete que contiene al BU. Wireshark cambia la dirección, en este caso la destino (1), por la que realmente lleva el paquete (2). Vemos que se manda una cabecera de encaminamiento del tipo 2 (3). Aunque en el apartado 3.2 se comentó que ésta se usaba cuando el CN enviaba mensajes directamente al MN, se observa que también se usa en los mensajes BA. Seguramente, el cometido de incluir esta cabecera será que el MN extraiga la dirección que contiene (4) para así ver que coincida con su HoA y así comprobar que, efectivamente, el binding que registra el HA es correcto. Ya situados en el mensaje BA, apreciamos que el mensaje BU ha sido aceptado (5). También vemos el valor de la bandera K, que se encuentra a cero. Esto significa que si se necesitaran claves de seguridad, se administrarán manualmente. Una vez que la asociación se ha registrado correctamente en la Binding Cache, el HA recogerá todos los paquetes cuya dirección destino sea la HoA y se los entregará al MN por medio de un túnel IPv6-in-IPv6. Posteriormente, el MN enviará la respuesta por este túnel en modo reverso, para que finalmente, el HA retransmita la respuesta al CN. Para comprobar que esto sucede así, hemos capturado el tráfico en el HA: 18 Recordar que el MH Type de un mensaje BA es el 6

65 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 45 Figura 5-6. Mensajes Echo request/reply cuando MN está en FN. Para que el lector pueda interpretar mejor el contenido de la figura anterior, recapitulemos las direcciones reales de los equipos de nuestras pruebas: s1ipv6 (MN): HoA = 2001:720:c18:bb:24f:4eff:fe0f:77ff y CoA = 2001:720:c18:b9:20d:61ff:fec6:f8c4 s2ipv6 (HA): 2001:720:c18:bb:24f:4eff:fe01:ad52 CN1 (CN): 2001:720:c18:ba:21e:33ff:fe81:4263 El mensajes número 58, que contiene lo que aparece en (1), es un Echo request, que envía el CN a la dirección HoA. Este mensaje es interceptado por el HA, que lo encapsula en un paquete IPv6 (de ahí que digamos túnel IPv6-in-IPv6) y lo envía a la dirección CoA (2). Una vez que el MN recibe el mensaje, origina la respuesta y la deposita en un paquete IPv6 con origen la HoA y destino la dirección del CN, que es encapsulado por otro paquete IPv6 con origen CoA y destino el HA (3). Una vez que éste último recibe el paquete, lo desencapsula y envía la respuesta al CN (4). Este proceso se repite hasta que el CN recibe el Echo reply con número de secuencia igual a 20, momento en el que deja de enviar más pings. Con esta prueba, vemos que la implementación que UMIP ha hecho de MIPv6 no difiere de las recomendaciones recogidas en los RFC correspondientes. También hemos conseguido demostrar una de las principales ventajas de la movilidad en IPv6: si un equipo que está comunicándose con otro cambia de red, sigue pudiendo intercambiar mensajes, ya que este mecanismo permite que pueda seguir usando la dirección IP que tenía antes de migrar. Por último, decir que Ping no es una buena herramienta para medir rendimiento, además, el hecho de haber tomado 5 segundos entre mensajes echo request hace que aún sea más difícil hacerlo. Ésta es la razón por la que esta prueba solo se ha usado para ver el funcionamiento de MIPv Prueba 2: Ping6 con regreso. Para que esta prueba dé comienzo, introducimos en un terminal del CN1 el comando ping6 que se propuso en la prueba anterior. Recordemos que al ejecutar éste, se están enviando 20 ping6 con un intervalo de 5 segundos. En esta prueba sucede lo siguiente: CN1 envía ping6 cada 5 segundos a la dirección HoA. El MN que se

66 46 5 Análisis encuentra en la FN, recibe estos paquetes gracias a la labor ya conocida del HA. En un instante dado, el MN decide volver a casa. Para que regrese, podemos ejecutar el script de arranque pero cambiando los parámetros, en este caso el primero sería eth1 y el segundo eth0, o ejecutamos los siguientes comandos manualmente 19 : ifconfig eth1 down: baja la interfaz eth1. En el momento de ejecutarse, el equipo no está disponible puesto que no está conectado a ninguna red. ifconfig eth0 up: levanta la interfaz eth0 que estaba conectada a la HN. En ese momento el equipo vuelve a estar disponible. El objetivo de esta prueba es ver qué sucede cuando el MN regresa a la HN después de haber estado fuera de casa. En primer lugar, consultamos al demonio de la movilidad que está ejecutándose en el MN: == BUL_ENTRY == Home address 2001:720:c18:bb:24f:4eff:fe0f:77ff Care-of address 2001:720:c18:bb:24f:4eff:fe0f:77ff CN address 2001:720:c18:bb:24f:4eff:fe01:ad52 lifetime = 60, delay = flags: IP6_MH_BU_HOME IP6_MH_BU_ACK IP6_MH_BU_LLOCAL Tue Jul 29 17:53:49 mn_move: 1874 Tue Jul 29 17:53:49 mn_move: in home net Vemos como en la tabla BUL, la HoA y la CoA coinciden, esto ya es un indicativo de que ha vuelto a casa. Para más inri, en el último mensaje, UMIP dice que estamos en la red de casa. Llegados a este punto, sería interesante ver cómo se entera el HA de tal suceso. Para ello capturamos con Wireshark el tráfico, obteniéndose lo siguiente: Figura 5-7. Mensajes BU cuando MN regresa a casa. 19 Para este paso no hace falta ejecutar ningún script, ya que la finalidad de esta prueba es ver qué ocurre cuando el MN regresa a su casa y da igual no tener controlado el tiempo del cambio de red, puesto que no vamos a medir rendimiento.

67 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 47 Como ya se encuentra en la HN, es lógico que la dirección origen del paquete IPv6 (1), sea la HoA. Esto ya es un toque de atención al HA para que sospeche que ya no está en la FN. Pero además como Alternate CoA, se usa la dirección HoA (3) con lo que indica claramente que ya no está en la FN. Además le notifica que esta asociación tiene un tiempo de vida de 0 segundos, por lo que realmente nunca se añade a la Binding Cache. Y qué sucede con la antigua asociación del MN registrada en la Binding Cache? Pues que cuando su tiempo de vida expire, será eliminada, como se puede comprobar en el demonio de movilidad del HA 20 : Tue Jul 29 18:00:47 mh_send_ba: status Binding Update accepted (0) Tue Jul 29 18:00:47 mh_send: sending MH type 6 from 2001:720:c18:bb:24f:4eff:fe01:ad52 to 2001:720:c18:bb:24f:4eff:fe0f:77ff Tue Jul 29 18:00:47 mh_send: remote CoA 2001:720:c18:b9:20d:61ff:fec6:f8c4 Tue Jul 29 18:01:47 tunnel_del: tunnel ip6tnl1 (5) from 2001:720:c18:bb:24f:4eff:fe01:ad52 to 2001:720:c18:b9:20d:61ff:fec6:f8c4 user count decreased to 0 Tue Jul 29 18:01:47 tunnel_del: tunnel deleted Se observa que el HA acepta el BU y envía BA de respuesta al MN a su HoA. Finalmente vemos que se elimina el túnel que conectaba al HA con la CoA del MN, puesto que el contador ha llegado a cero. Así, finalmente, se consigue que el HA tenga limpia su Binding Cache, por lo que si llegan mensajes con destino la HoA, serán reenviados siguiendo los mecanismos tradicionales de Internet, como puede comprobarse en la siguiente captura, donde vemos que el HA no interviene en la comunicación (1) como sí hacía antes del regreso a casa: Figura 5-8. Mensajes directos entre CN y MN Prueba 3: Ping6 con traspaso (ESP). Esta prueba es la misma que la 5.1.1, pero esta vez encriptaremos todo el tráfico que hay entre el MN y el HA con ESP. Para ello, recordar que establecimos unas SAs que cubrían todo el tráfico entre el MN y el HA, incluido mensajes de movilidad y datos. Solo falta habilitar la protección por ESP, por lo que tenemos que modificar el fichero de configuración /usr/local/etc/mip6d.conf tanto del MN como del HA. En concreto, hay que cambiar la opción UseMnHaIPsec a enable. El objetivo de esta prueba es demostrar que la movilidad IP es capaz de solventar problemas de seguridad, tal y como se comentó en el capítulo 3.6. Esto nos lleva a que en esta prueba solo vamos a ver que, efectivamente, el tráfico entre el MN y el HA está encriptado. Para ello vamos a usar Wireshark en el HA para ver que esto ocurre realmente: 20 Las fechas de los demonios ejecutados en HA y MN no coinciden, ya que los equipos donde se ejecutan tienen horas distintas.

68 48 5 Análisis Figura 5-9. Tráfico encriptado con ESP. Nos ponemos en situación. MN ya ha migrado, por lo que ya ha mandado un BU y recibido un BA de respuesta. A partir de ahora, todo el tráfico que llegue a la dirección HoA será interceptado por el HA y lo reenviará a la CoA a través de un túnel que se encuentra encriptado por ESP. Vemos que el echo request (1) lleva como dirección destino HoA, por lo que el mensaje número 39 que va encriptado con ESP (2) debe ser el echo request reenviado desde el HA al MN. El siguiente mensaje, el número 40, debe ser el echo reply que en un principio va hacia el HA pero que luego, gracias a información en el interior, será reenviado al CN. Hemos supuesto que lo que se envía encriptado es tráfico de datos porque es lo que aparentemente debería ser, pero podrían tratarse de mensajes BU y BA perfectamente. Esto nunca lo podremos saber debido a la encriptación que se ha aplicado, por lo que ha quedado demostrado que ESP ha cumplido su cometido Análisis del rendimiento En esta sección trataremos de obtener, en la medida de lo posible, una aproximación del rendimiento de MIPv6. Para llevarlo a cabo, realizaremos una serie de pruebas con el fin de ver, principalmente, el tiempo de indisponibilidad del MN y la sobrecarga de paquetes, ya sean por retransmisión o de movilidad, que se produce en una comunicación cuando el nodo móvil se cambia de red. Las pruebas de análisis se realizaron a nivel 3 del modelo de capas OSI. Para las de rendimiento subiremos un nivel en la pila y nos situaremos en el nivel de transporte. De esta forma, estamos simulando una comunicación entre CN y MN, ya que estamos transportando datos. El CD que acompaña a esta memoria, incluye las siguientes pruebas: Transferencia fichero del MN al CN : el servidor FTP se encuentra alojado en el MN y el cliente, que es el CN, solicita la transferencia de un fichero. En esta prueba, no hay retransmisiones de datos FTP puesto que el MN, que es quien envía los datos, en el momento del traspaso cesa el envío del fichero. Por lo que solo podemos medir el handover latency (latencia de traspaso) y las retransmisiones de los ACK que se pierdan. Transferencia fichero del CN al MN : el servidor y el cliente FTP son los mismos equipos que en la prueba anterior. La diferencia se encuentra en que ahora es el CN (cliente FTP) quien envía el fichero. Con esta prueba se pueden medir la sobrecarga de paquetes que introduce la movidad, es decir, cuántas retransmisiones son necesarias para que la transferencia del fichero sea satisfactoria. UDP del MN al CN : para esta prueba se usa la interfaz gráfica Jperf en ambos equipos. MN actúa de cliente enviando constantemente datagramas UDP al servidor que es el CN. Como en el momento del traspaso MN cesa el envío de paquetes, solo podemos medir el retraso que provoca el traspaso. Aunque Iperf es inteligente y predice cuántos paquetes le deberían haber llegado, estimando de esta forma los paquetes perdidos. Los resultados de esta prueba es la salida de pantalla que Iperf muestra en el CN. UDP del CN al MN : envío de datagramas UDP del CN al MN, usando Iperf. El objetivo es medir el retraso de la transferencia y paquetes perdidos utilizando Wireshark. En todas las pruebas anteriores, se hacen 10 experimentos sin traspaso y luego otros 10 donde el MN cambia de red en un momento dado.

69 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 49 En esta memoria solo se incorporan aquellas pruebas que hemos considerado más relevantes. Por último, antes de continuar, decir que la dirección IP del equipo CN1 puede ser distinta en algunas pruebas, debido a que hemos tenido que cambiar de tarjeta de red por motivos técnicos 21. Luego el CN1 puede aparecer a partir de aquí, con dos direcciones IP distintas: 2001:720:c18:ba:21e:33ff:fe81:4263 o 2001:720:c18:ba:21e:33ff:fe6e:eceb Prueba 1: UDP del CN al MN Esta prueba consta de dos partes. La primera consiste en lo siguiente: el CN envía paquetes UDP de forma constante al MN que se encuentra escuchando por un puerto determinado. Figura Escenario prueba UDP sin traspaso. Como este escenario es sin traspaso, lo único que podemos medir es si se pierden paquetes por fallos en la red. Para llevar a cabo esta prueba, necesitamos de un software en el cliente que sea capaz de envíar datagramas de forma constante durante 10 segundos. Para ello usaremos Iperf. Éste dispone de una interfaz gráfica llamada Jperf 22 que nos facilita la tarea de configurar al cliente: escribimos la dirección del servidor, puerto, tamaño del datagrama a enviar (en este caso 1400 bytes), duración 23 (10 segundos) y que estamos en IPv6, y ya este programa se encarga de crear la correspondiente orden Iperf que ejecuta esta tarea, así no tenemos que aprender a manejarlo. También necesitamos de un software en el servidor que sea capaz de escuchar datagramas UDP en un determinado puerto. Para ello también tenemos a Iperf y Jperf. Abriendo éste último, configuramos al servidor diciéndole que escuche datagramas UDP en IPv6 en un determinado puerto que debe ser el mismo que se indicó en la configuración del cliente. 21 Recordar que SLAAC obtenía la dirección IP a partir de la MAC. 22 La instalación y configuración de Iperf y Jperf podrá encontrarla en el Anexo F. 23 Aunque se indique que la duración son 10 segundos, realmente el envío dura un poco más de tiempo. Los 10 segundos se corresponden con el tiempo en el que se estarán enviando datos, pero después el programa sigue enviando datagramas UDP para intercambiar información de control con el servidor, como puede ser el número de paquetes perdidos y el jitter.

70 50 5 Análisis Iperf proporciona en el lado del servidor útiles resultados como son los paquetes que se han perdido y el jitter en cada intervalo que se ha definido (por defecto un segundo). El problema es que Iperf no se ejecuta correctamente en el servidor por motivos que desconocemos, así que la información la tendremos que sacar manualmente a través de Wireshark. Para ello nos pondremos a capturar tráfico tanto en el MN como en el CN, de esta forma veremos cuántos paquetes envía el cliente y cuántos llega a recibir el servidor, además de ver el tiempo que tarda en recibir un paquete este último cuando ha realizado un traspaso. En la primera parte de esta prueba, donde recuerden que no hay traspaso, realizaremos un total de 10 experimentos. Los resultados obtenidos han sido los siguientes 24 : Prueba Paquetes enviados Paquetes recibidos Paquetes perdidos (%) p ,00 p ,00 p ,00 p ,00 p ,00 p ,00 p ,00 p ,00 p ,00 p ,00 MEDIA ,00 σ ,00 σ 0 0 0,00 Figura Resultados de experimentos UDP sin traspaso. Como es lógico, al no haber traspaso, no se pierde ningún paquete. Pero así ha quedado demostrado que nuestra red es fiable y en condiciones normales no se pierden paquetes. Ahora vamos con el segundo escenario. Al igual que antes, el cliente (CN) envía datagramas UDP al servidor (MN) a un puerto especificado, pero a diferencia de antes, éste último cambia de red en un cierto instante. Es decir, en un primer momento tenemos el escenario que muestra la figura 5-12, y en el momento que ejecutemos el script para hacer el traspaso, tendremos el escenario de la figura 5-13, donde las flechas rojas representa el recorrido que siguen los paquetes: 24 Hemos usado el siguiente filtro en Wireshark para recopilar los datos: (udp.dstport == 5001) and udp

71 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 51 Figura Escenario 1 prueba UDP con traspaso. Figura Escenario 2 prueba UDP con traspaso. Nuestro objetivo será medir el tiempo que dura el traspaso y ver cuántos paquetes se pierden. Antes de presentar el resultado de los 10 experimentos, vamos a coger uno de ellos e iremos comentando los pasos realizados para obtener los resultados.

72 52 5 Análisis En primer lugar, vamos a ver cuántos paquetes hemos recibido. Para ello necesitamos usar un filtro en Wireshark para que solo nos muestre los paquetes UDP al puerto que deseemos. Pero además hay que añadir otro filtro debido a una anomalía que hemos detectado y que trataremos de explicar. En las capturas podemos ver que después del traspaso, capturamos los paquetes que van del CN al MN que el HA intercepta, además de los que el HA reenvía al MN. El lector puede preguntarse por qué se reciben los paquetes que van destinados a la HoA y que el HA intercepta, si el MN ya no se encuentra en la HN. Una posible respuesta puede ser que en el momento de hacer la captura le decimos a Wireshark que capture en modo promiscuo por todas las interfaces del dispositivo, ya que en un primer momento se usa la interfaz eth0 y luego la eth1. Por este motivo, aunque la eth0 esté abajo después del traspaso, se siguen capturando los paquetes de esta subred 25. Así, el filtro que ponemos en las capturas del MN es el siguiente 26 : (!(ipv6.src == 2001:720:c18:bb:24f:4eff:fe01:ad52) and udp) && (udp.dstport == 5001) Una vez aplicado este filtro, pulsamos en File Export Specified Packets y nos sale una pantalla como ésta donde se aprecia el número de paquetes seleccionados: Figura Paquetes seleccionados con el filtro en Wireshark. Vemos que en este caso hemos seleccionado 533 paquetes. Ahora el siguiente paso sería ver el tiempo que ha durado el traspaso, para ello observamos cuál ha sido el último paquete recogido (que estará antes de un mensaje BU) y pulsamos click derecho y opción Set Time Reference y vemos cuál es el siguiente datagrama UDP recibido. En el campo Time nos aparecerá en qué instante de tiempo con respecto al de referencia, ha llegado este paquete. Por lo que estamos obteniendo el 25 En el momento del traspaso se ha comprobado que eth0 no captura nada. Esto es beneficioso porque no está capturando los paquetes que se pierden en el momento en el que se está produciendo el traspaso, por lo que nos facilita la tarea de contar los paquetes totales recibidos. 26 Nos da igual medir los paquetes que el HA intercepta, o los que el HA reenvía al MN, puesto que lo que pretendemos es saber el número de paquetes recibidos. Al poner que no queremos los paquetes cuyo origen IPv6 sea la dirección del HA, estamos capturando los paquetes que el HA intercepta.

73 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 53 tiempo en el que el MN no ha estado recibiendo paquetes por culpa del traspaso. Es interesante ver lo que nos muestra la gráfica I/O de Wireshark, así podemos ver qué ocurre intuitivamente en nuestra prueba: Figura Gráfico I/O prueba UDP con traspaso. En la gráfica podemos ver de color negro todos los paquetes capturados por el MN, incluidos mensajes de movilidad, del protocolo ND, así como los datagramas UDP recibidos. De color rojo se representan únicamente los datagramas UDP recibidos. Hagamos un recorrido por la gráfica: cercano a los 8 segundos comenzamos a recibir los datagramas provenientes del CN. Después de los 13 segundos dejamos de recibir datagramas UDP, por lo que ha tenido lugar el traspaso, y por lo tango, los paquetes que estamos capturando son del protocolo ND y de movilidad. Pasados el segundo 17 comenzamos a recibir nuevamente los datagramas UDP, por lo que a ojo podemos decir que el tiempo de indisponibilidad ha sido en torno a los 4 segundos. Ahora continuemos con el prósito de esta prueba que es obtener el tiempo de indisponibilidad y los paquetes perdidos, para ello, seguimos los pasos anteriores con los 10 experimentos, obteniéndose los siguientes datos: Prueba Paquetes enviados Paquetes recibidos Paquetes perdidos (%) Tiempo indisponibilidad (seg) p ,04 4, p ,28 3, p ,50 3, p ,73 3, p ,62 3, p ,49 3, p ,82 4, p ,48 4, p ,92 4, p ,63 3, MEDIA ,2 38,25 3, σ ,36 8,03 0, σ 0 25, ,83 0, Figura Resultados pruebas UDP con traspaso.

74 54 5 Análisis Viendo la figura de arriba podemos decir con casi total seguridad, que cuanto mayor sea el tiempo en que el MN tarda en estar disponible, mayor será el número de paquetes que se perderán. Queremos sacar una conclusión a raíz de esta prueba. La media del tiempo de indisponibilidad es de 3,86 segundos aproximadamente, lo que hace que MIPv6 sea incompatible con aplicaciones Streaming que se basen en el intercambio de datos mediante UDP, como por ejemplo, alguna aplicación de voz sobre IP. Y es que la comunicación estaría cortada cerca de 4 segundos, lo que haría pensar a los extremos que la conexión se ha cerrado. Bien es cierto que una vez que se produce el traspaso, MIPv6 nos asegura la recepción del 100% de los paquetes, es decir, que no se pierde ninguno. Por lo que la solución consiste en buscar algún mecanismo que disminuya el tiempo de indisponibilidad del MN al cambiar de red, como por ejemplo, usar FMIPv Prueba 2: Transferencia fichero del CN al MN Como comentamos en la introducción de la sección 5.2., queremos hacer pruebas en la capa 4 del modelo OSI, es decir, a nivel de transporte. En esta prueba trataremos concretamente con el protocolo TCP. Para medir el rendimiento de la movilidad usando este protocolo, tenemos que establecer un flujo TCP entre el CN y el MN. Para facilitar esta tarea, usaremos un protocolo de nivel superior al que TCP le de soporte. Se trata de FTP, usado para transferencias de ficheros. En esta prueba necesitamos de un servidor FTP que se halla alojado en el MN. Hemos usado ProFTPd que viene incorporado por defecto en la instalación de Debian. Para las labores del cliente podemos usar la línea de comandos, o utilizar un software de cliente FTP que nos facilite la tarea. Nosotros hemos empleado FileZilla cuya instalación y configuración se detallan en el Anexo C. Esta prueba constará de dos partes, la primera de ellas será una situación normal donde no hay traspaso, y una segunda donde sí lo habrá. Empecemos explicando la primera. El CN se conecta al servidor FTP alojado en el MN y envía un fichero llamado foto.jpg que tiene un tamaño de 1,9 MB. El servidor acepta la transferencia y se abren dos flujos TCP, uno para control de los datos y otro para recibir los bits que componen la foto 27. En este escenario no habrá traspaso como ya se ha comentado. Figura Escenario prueba TCP sin traspaso. 27 Estamos usando el modo pasivo, por lo que el servidor no envía/recibe datos por el puerto 20, sino por un puerto mayor a 1023.

75 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 55 Usando este escenario hemos realizado un total de 10 experimentos, cuyos resultados están recogidos en la figura de abajo. El tiempo total es la duración desde que se transmite el primer paquete de datos, hasta que se envía el mensaje FTP de transferencia completa. El número de paquetes totales solo contabilizan los referentes a la comunicación de control y a la de datos. Prueba Tiempo total (ms) Paquetes totales p1 7, p2 7, p3 7, p4 7, p5 7, p6 7, p7 7, p8 7, p9 7, p10 7, MEDIA 7, ,3 σ2 0, ,01 σ 0, , Figura Resultados pruebas TCP sin traspaso. Puede parecer que al variar el número de paquetes totales en este escenario donde no hay traspaso haya problemas en la red que provoquen pérdidas de paquetes y por lo tanto retransmisiones.viendo Wireshark, puede comprobarse que esta variación se debe a que aparecen mensajes del tipo: TCP ACKed unseen segment. Ahora comenzamos la segunda parte de esta prueba. Partiendo del escenario de la figura 5-19, el CN empieza a enviar un fichero (en mismo que el anterior) al MN. Éste en cierto instante, cambia de red usando el script que diseñamos para ello, dando lugar al escenario Figura Escenario 1 prueba TCP con traspaso.

76 56 5 Análisis Figura Escenario 2 prueba TCP con traspaso. El objetivo de esta segunda parte es medir cuántos paquetes son necesarios para que la transferencia del fichero sea satisfactoria. Otra medida que se podría calcular es la latencia del traspaso, en inglés handover latency. Con latencia nos referimos al retardo temporal que registra un paquete cuando se propaga por la red, en este caso, la latencia de traspaso será el retardo que sufre un paquete debido al handover. En UDP no hablábamos de latencia de traspaso porque cuando había un handover el paquete simplemente se perdía, ahora en TCP esto no ocurre puesto que se retransmite. En TCP, el handover latency no coincide con el tiempo de indisponibilidad del MN que sí calculamos en la prueba anterior, ya que el paquete no sufrirá un retardo igual al tiempo que tarda el MN en estar disponible al producirse el citado traspaso. Como sabemos TCP cuenta con un control de la congestión que regula el ritmo de envío de segmentos de datos. En el momento que se detecte una situación de congestión en la red, la ventana de congestión se iguala a uno y comienza la fase de arranque lento. Si la congestión se ha debido a que ha vencido el temporizador de retransmisión, el umbral de arranque lento se fija a la mitad, esto significa que transmitiremos a menos tasa. Por esta razón la latencia de handover es superior al tiempo de indisponibilidad del MN. Antes de presentar los resultados de los 10 experimentos, vamos a centrarnos aleatoriamente en uno de ellos y vamos a mostrar unas gráficas hechas con Wireshark 28. La primera de ellas es la gráfica Stevens la cual muestra la evolución de los números de secuencia en función del tiempo 29. Con ella podemos hacernos una idea de cuánto tiempo se tarda en recibir nuevos paquetes una vez se ha producido el traspaso: 28 Consulte el Anexo G para ver cómo se realiza gráficas con Wireshark. 29 Habrá que hacerla sobre el flujo de datos FTP.

77 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 57 Figura Gráfica Stevens de los datos FTP. Vamos a proceder a comentar la gráfica, para ello nos hemos apoyado en las capturas de Wireshark. Al principio, los números de secuencia empiezan a incrementarse hasta aproximadamente el segundo 4. Es aproximadamente en ese momento cuando se ha producido el traspaso. Por lo que los paquete que están con un recuadro rojo se han perdido (1). Cuando vence el temporizador de retransmisión, se vuelve a enviar el primer paquete que se estaba esperando a ser asentido, comenzando la fase de arranque lento de TCP, pero a una tasa que es la mitad de la que se tenía en un principio. Nuevamente al vencer el temporizador, se vuelve a reenviar el paquete y la tasa de envío se reduce otra vez a la mitad (en la gráfica vemos las retransmisiones de este paquete con un círculo en rojo). Así hasta que en un cierto instante, alrededor de los 10.5 segundos, se reenvía el paquete y el receptor asiente su llegada, por lo que el emisor puede continuar reenviando todos los paquetes que se habían perdido (2). A partir de ahí vemos en la gráfica como los números de secuencia vuelven a crecer, por lo que ya se están enviando paquetes nuevos. Con la información extraida en el párrafo anterior, podemos deducir que el handover latency, en este caso, está en torno a los 6 segundos. La siguiente gráfica, recogida en la figura 5-22, nos sirve para ver el RTT de cada paquete (cada uno identificado con su número de secuencia como es obvio). En ella podemos ver que los valores RTT más altos se dan para los números de secuencia en torno al millón. Mirando los paquetes capturados con Wireshark, esos números de secuencia coinciden con paquetes que se han tenido que retransmitir.

78 58 5 Análisis Figura Gráfica RTT de los datos FTP. Sin embargo vemos que el RTT sigue siendo bajo por lo que esas retransmiones se deberán a otras circunstancias, pero no debido al traspaso. Analizando Wireshark vemos que, efectivamente, es lo que ocurre. Así que tenemos que analizar la gráfica RTT pero aplicando un zoom menor para así identificar aquellos paquete que sufren un RTT que debe de ser superior a varios segundos. Figura Gráfica RTT de los datos FTP (2).

79 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 59 En la gráfica anterior se pueden observar los números de secuencia de unos paquetes que tienen un valor RTT de aproximandamente 6.7 segundos, cifras más coherentes con este escenario. En efecto, al ver la captura de Wireshark, estos son los paquetes que se pierden en el momento del traspaso del MN. Una vez terminado con el análisis de las gráficas, continuemos mostrando los resultados de los 10 experimentos con traspaso 30 : Prueba Tiempo total (ms) Paquetes totales p1 12, p2 12, p3 12, p4 12, p5 12, p6 12, p7 12, p8 11, p9 11, p10 11, MEDIA 12, ,3 σ2 0, ,41 σ 0, , Figura Resultados pruebas TCP con traspaso. Vemos que la media del tiempo total de transferencia es bastante superior a cuando no había traspaso. En esta situación se tarda alrededor de 5 segundos más. Este incremento de tiempo se debe a que hay que esperar a que el MN esté disponible y a la retransmisión de paquetes perdidos. En cuanto al número de paquetes, vemos que debido a las retransmisiones, se envian aproximadamente unos 40 paquetes más. Es interesante unificar los datos obtenidos en ambos escenario en una única tabla ordenada de menor a mayor y mostrar los resultados en una gráfica, así se puede ver más intuitivamente la diferencia de tiempos y paquetes cuando se hace traspaso y cuando no. A continuación os mostramos la Figura 5-25 y la Figura 5-26 que recogen dichos datos. 30 Para obtener estos datos, así como los de la primera parte de la prueba, se ha capturado tráfico usando Wireshark en el CN.

80 60 5 Análisis Sin traspaso Con traspaso Tiempo de transferencia Tiempo (ms) Sin traspaso Con traspaso Coeficiente de correlacion Figura Tabla y gráfica comparativa de tiempos de transferencia TCP sin/con traspaso. Sin traspaso Con traspaso Paquetes (uds) Paquetes enviados Sin traspaso Con traspaso Coeficiente de correlacion Figura Tabla y gráfica comparativa de paquetes enviados TCP sin/con traspaso. A diferencia de UDP donde se premia más el poco retardo que la fiabilidad en la entrega, en TCP si queremos obtener una tranferencia 100% fiable sin ninguna pérdida de paquetes. Es por esto que la movilidad en IPv6 es un buen soporte para TCP, aunque bien es cierto que incrementa unos instantes de tiempo el intercambio de datos, esto no es importante para aplicaciones que usen el protocolo TCP ya que buscarán una fiabilidad absoluta.

81 6 CONCLUSIONES Y TRABAJOS FUTUROS L a movilidad IPv6 es un excelente mecanismo que nos permite conservar nuestra dirección IP y lo hace de forma transparente a las capas superiores. Esto ha quedado demostrado en las pruebas de rendimiento, como la de la transferencia FTP, donde nuestro equipo cambió de red, y a pesar de ello siguió conservando la dirección IP y eso permitió que se mantuviera la descarga del fichero sin tener que establecer una nueva conexión. Con nuestro escenario y la puesta en práctica de las pruebas de rendimiento, hemos conseguido hacer un pequeño balance sobre MIPv6. Hemos visto que actúa de forma correcta para el protocolo TCP puesto que garantiza la entrega del 100% de los paquetes, pero que es no es una alternativa fiable para protocolos de capas superiores que usen UDP y requieran que no se produzcan cortes en la comunicación de poco más de milisegundos (recuerde que cuando se hacía un traspaso, el nodo móvil no estaba operativo pasado unos 4 segundos de media). Por lo que lo aconsejable sería utilizar un protocolo que proporcionase un tiempo de traspaso menor, como puede ser FMIPv6. Es por ello que, aprovechando el escenario que se ha usado, como trabajo futuro recomendamos implementar FMIPv6 y realizar una prueba de UDP, donde poder ver si los resultados obtenidos son mejor que los de ahora. También se propone instalar algún software de movilidad al equipo que actúa de CN para que éste entienda de MIPv6 y así poder usar la opción de Route Optimization. Posteriormente sería recomendable hacer la prueba de TCP y ver cómo el tiempo de descarga disminuye puesto que los paquetes no pasan por el HA e irían de forma más directa. Sería una buena idea realizar algún software que nos facilite la ardua tarde de recopilación de datos a través de las capturas de Wireshark. Su tarea sería mecanizar el proceso de obtención de datos para que así el usuario no tenga que hacerlo de forma manual. Debido a los problemas que hemos tenido con la interfaz gráfica Jperf, otro software interesante para desarrollar sería un programa en el cliente que envíe datagramas UDP a un determinado puerto del servidor. Estos paquetes llevarían en sus datos información de la hora local y un número de secuencia que se iría incrementando por cada paquete enviado. En el servidor correría otro programa que recoge los paquetes que le llegan a un determinado puerto e iría recapitulando los datos que contienen. Comparando con su hora local, vería el retraso que lleva el paquete e iría apuntando los números de secuencia para así determinar cuántos paquetes se han perdido. Con esta información el programa puede mostrarnos gráficas y/o tablas con los resultados obtenidos. Como conclusión personal, me gustaría dar una valoración a este proyecto. Ha sido unos meses intensos y de mucha constancia para obtener los resultados previstos. Aunque el lector pueda pensar que un proyecto de estas características no requiere de mucho tiempo, se equivoca, ya que la informática es muy impredecible. He tenido problemas con el reseteo del router, ya que la manera manual no me funcionaba, y esto me ha llevado a estar varios días con este cometido. La recompilación del Kernel ha sido de las tareas más duras. No lo conseguí hasta el cuarto intento, porque en Internet los caminos que se proponían no eran los correctos y tuve que ir recopilando información hasta dar con la tecla. Además he tenido problemas de permisos con el servidor FTP que no permitía llevar a cabo las pruebas, fallos en Jperf, y sobre todo problemas con UMIP que al estar únicamente en la versión 1.0 tiene aún muchos bugs que solucionar. Como veis, a lo largo de este proyecto me he encontrado con muchos obstáculos que he conseguido saltar y se lo debo a la formación que se nos han dado a lo largo de la carrera. Me he dado cuenta que he adquirido la principal virtud de un ingeniero, que no es otra que la de encontrar solución a los problemas. 61

82 62

83 ANEXO A: CARACTERÍSTICAS DE EQUIPOS En este anexo mostraremos las características más relevantes de los equipos usados en el escenario de movilidad. A.1. Equipo s1ipv6 Este equipo hace la función de Mobile Node en nuestras pruebas. Las características de este dispositivo son: Sistema Operativo Debian: o o Hardware: Versión 7.4 (wheezy) de 32-bit Núcleo Linux mipv6 o GNOME o o o Memoria RAM disponible: 501,9 MiB Procesador: Intel Pentium 4 CPU 3.00Ghz Dos interfaces de red Ethernet con controlador Realtek Semiconductor Co., Ltd. RTL- 8139/8139C/8139C+ o Tarjeta gráfica Nvidia GeForce FX 5200 Figura A-1. Equipo s1ipv6. A.2. Equipo s2ipv6 Este dispositivo actúa de Home Agent. Las características a destacar son: Sistema Operativo Debian: 63

84 64 Anexo A: Características de equipos o o Hardware: Versión 7.4 (wheezy) de 32-bit Núcleo Linux mipv6 o GNOME o o o Memoria RAM disponible: 501,9 MiB Procesador: Intel Pentium 4 CPU 1.50Ghz Una interfaz de red Ethernet con controlador Realtek Semiconductor Co., Ltd. RTL- 8139/8139C/8139C+ o Tarjeta gráfica Nvidia RIVA TNT2 model 64 Figura A-2. Equipo s2ipv6. A.3. Router Cisco 892 Figura A-3. Cisco 892. Las características del router las encontramos en la siguiente tabla:

85 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 65 General Tipo de dispositivo Tipo incluido Tecnología de conectividad Protocolo de interconexión de datos Router - conmutador de 8 puertos (integrado) Sobremesa Cableado Ethernet, Fast Ethernet Capacidad Túneles VPN IPSec : 50 Red / Protocolo de transporte Protocolo de direccionamiento Protocolo de gestión remota Algoritmo de cifrado Método de autentificación Características Cumplimiento de normas Memoria RAM Memoria Flash Indicadores de estado Expansión/Conectividad L2TP, IPSec, FTP, DHCP, DNS, L2TPv3, DDNS OSPF, RIP-1, RIP-2, BGP, EIGRP, HSRP, VRRP, NHRP, PIM-SM, GRE Telnet, SNMP 3, HTTP, HTTPS, SSH LEAP, DES, Triple DES, SSL, PEAP, TKIP, PKI, AES de 128 bits, AES de 192 bits, AES de 256 bits RADIUS, TACACS+ Soporte de NAT, asistencia técnica VPN, equilibrio de carga, soporte VLAN, señal ascendente automática (MDI/MDI-X automático), snooping IGMP, limitación de tráfico, Stateful Packet Inspection (SPI), filtrado de contenido, soporte DiffServ, filtrado de dirección MAC, soporte IPv6, Alta disponibilidad, Sistema de prevención de intrusiones (IPS), filtrado de URL, Stateful Failover, Class-Based Weighted Fair Queuing (CBWFQ), Weighted Fair Queuing (WFQ), admite Spanning Tree Protocol (STP), soporte de Access Control List (ACL), Quality of Service (QoS), Link Fragmentation and Interleaving (LFI), Dynamic Multipoint VPN (DMVPN), recuperación de errores WAN, Servidor DHCP, Virtual Route Forwarding-Lite (VRF-Lite), DNS proxy, Bidirectional Forwarding Detection (BFD) IEEE 802.1D, IEEE 802.1Q, IEEE 802.1x, CISPR 24, EN , EN55022, ICES-003, EN , EN55024, CISPR 22, EN , EN55022 Class B, ICES-003 Class B, EN , AS/NZ 3548 Class B, EN , FCC CFR47 Part 15, EN , FCC CFR47 Part 15 B, VCCI V MB (instalados) / 768 MB (máx.) 256 MB (instalados) / 256 MB (máx.) Estado puerto, alimentación Interfaces LAN : 8 x 10Base-T/100Base-TX - RJ-45 Administración : 1 x consola - RJ-45 WAN : 1 x 10Base-T/100Base-TX - RJ-45 WAN : 1 x 10Base-T/100Base-TX/1000Base-T - RJ-45 Administración : 1 x auxiliar - RJ-45 USB 2.0 : 2 x 4 PIN USB tipo A WAN : 1 x BRI ST Figura A-4. Características CISCO 892. A.4. Equipo CN1 Este equipo es un portátil Toshiba modelo Satellite Pro que tendrá el rol de Correspondent Node. Sus principales características son: Sistema Operativo Debian: o Versión 7.6 (wheezy) de 32-bit o Núcleo Linux pae

86 66 Anexo A: Características de equipos Hardware: o GNOME o Memoria RAM disponible: 2,8 GiB o Procesador: Intel Pentium 4 Dual CPU 2.00 GHz x 2 o o Una interfaz de red Ethernet con controlador Realtek Semiconductor Co., Ltd. RTL- 8139/8139C/8139C+ Tarjeta gráfica Mobile Intel 4 Series Express Chipset Family Figura A-4. Equipo CN1.

87 ANEXO B: INSTALACIÓN MINICOM Minicom es un software de emulación de terminal para Sistemas Operativos Linux. En nuestro proyecto será usado tanto para poder resetear el router como para posteriores configuraciones de éste. La instalación es muy sencilla, solo tenemos que abrir un terminal y teclear: apt-get install minicom Una vez completada, procedemos a la configuración. En primer lugar, escribimos en el terminal, como root, minicom s, y nos aparecerá una ventana como la siguiente: Figura B-1. Menú de configuración de Minicom. Nos vamos a configuración de la puerta serial, donde con la tecla F le tenemos que decir al programa que no queremos establecer ningún control de flujo por hardware. Posteriormente, pulsando en A, cambiamos la ruta donde se encuentra el puerto serial, prestando especial atención, ya que el que usamos en nuestro caso se encuentra en /dev/ttys0, pero la primera vez que se salva la configuración, el programa puede cambiar automáticamente la ruta a /dev/tty0, lo que impediría poder conectarnos al dispositivo deseado. Figura B-2. Ruta del puerto serial. 67

88 68 Anexo B: Instalación Minicom Continuemos con nuestra configuración pulsando la tecla E. En el menú que nos aparece, cambiamos los baudios por segundo (hay que dejarlo en 9600) la paridad (8 bits) y bits de parada (1): Figura B-3. Parámetros de comunicación. Finalmente, guardamos nuestra configuración indicando que queremos que sea la de por defecto: Figura B-4. Guardar configuración. Una vez terminado estos pasos, podemos optar por pulsar el botón Salir para poder enviar los comandos al dispositivo al que estemos conectados, o Salir del Minicom, si no queremos utilizar aún este programa.

89 ANEXO C: INSTALACIÓN FILEZILLA FileZilla es un cliente FTP multiplataforma de código abierto y software libre. Soporta los protocolos FTP, SFTP y FTP sobre SSL/TLS (FTPS). La instalación de FileZilla es bastante simple. Solo hay que abrir un terminal como root y ejecutar: apt-get install filezilla Una vez se ha completado la instalación, procedemos a la configuración según nuestras necesidades. Lo primero que vamos a hacer es limitar la velocidad tanto de bajada como de subida a 256 kb/s. Para ello pulse en Transferencia Límites de Velocidad Configurar. Y nos saldrá una ventana como ésta donde introduciremos la velocidad deseada y activaremos este límite de velocidad: Figura C-1. Límites de velocidad de transferencia. Debido a la alta velocidad de nuestra red, la descarga del fichero que usamos en nuestra prueba era muy corta y no daba tiempo a ejecutar el script de traspaso. Había por tanto dos opciones, o usar un fichero más grande o cambiar la velocidad de transferencia. La primera da lugar a archivos de capturas de Wireshark demasiado grandes y difíciles de manejar, es por ello que se optó por la opción de limitar la velocidad. Lo segundo que hacemos es pulsar en Edición Opciones y en la ventana que se abre buscamos Transferencia Tipos de archivos y añadimos la extensión del tipo de archivo que queremos transferir, en nuestro caso jpg. El último paso es configurar al cliente para que se conecte al servidor deseado. Para llevarlo a cabo, pulsamos en Archivo Gestor de sitios y se nos muestra la siguiente ventana donde escribiremos la dirección IPv6 de nuestro servidor entre [ ] (el número de puerto no hace falta indicarlo porque se usará el de por defecto), que utilizaremos FTP simple, y por último seleccionamos modo de acceso Normal y escribimos el nombre de usuario y contraseña de un usuario del servidor, preferentemente uno con privilegios de root, para evitar problemas de permisos con ficheros y carpetas. 69

90 70 Anexo C: Instalación FileZilla Figura C-2. Conectar a servidor. Ya solo falta pulsar en conectar y ya podremos subir ficheros al servidor FTP o descargárnoslo desde él.

91 ANEXO D: SCRIPT DE ARRANQUE Este script arranca el software de movilidad. Debe situarse en /etc/init.d. #!/bin/sh # Copyright (C)2006,2007 USAGI/WIDE Project. All rights reserved. # Adapted by Martin Andre <andre@hongo.wide.ad.jp> # Further modified by Arnaud Ebalard <arno@natisbad.org> ### BEGIN INIT INFO # Provides: mip6d # Required-Start: $network $syslog # Required-Stop: $network $syslog # Should-Start: $local_fs # Should-Stop: $local_fs # Default-Start: # Default-Stop: # Short-Description: Start/Stop MIPv6 Deamon (UMIP) # Description: (empty) ### END INIT INFO PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin DESC="UMIP daemon" NAME=mip6d MIP6D=/usr/sbin/mip6d MIP6D_CONF=/etc/mip6d.conf MIP6D_DEBUG_LOG=/var/log/mip6d.log PIDFILE=/var/run/mip6d.pid FORCE_IPV6_FORWARDING="no" RUN="no". /lib/lsb/init-functions DIETIME=1 # Include defaults if available if [ -f /etc/default/$name ] ; then /etc/default/$name fi. if [ "x$run"!= "xyes" ] ; then log_failure_msg "$NAME disabled, please adjust the configuration to your needs" log_failure_msg "and then set RUN to 'yes' in /etc/default/$name to enable it." exit 1 fi if [! -e $MIP6D_CONF ]; then log_failure_msg "ERROR: $MIP6D_CONF does not exist." 71

92 72 log_failure_msg " syntax and" log_failure_msg " log_failure_msg " exit 0 fi Anexo D: Script de Arranque See mip6d.conf(5) for configuration file sample configuration elements." => $DESC will not be started" if [! -x $MIP6D ]; then log_failure_msg "ERROR: While trying to start $DESC, found its binary was" log_failure_msg " missing ($MIP6D)." log_failure_msg " => $DESC will not be started" exit 0 fi if [! -e /proc/sys/net/ipv6 ]; then log_failure_msg "ERROR: In-kernel IPv6 is required for $DESC to work." log_failure_msg " => $DESC will not be started." exit 0 fi set -e MIP6D_OPTS="-c ${MIP6D_CONF}" if [ x"$mip6d_debug_log"!= x"" ]; then MIP6D_OPTS="${MIP6D_OPTS} -l ${MIP6D_DEBUG_LOG}" fi post_war_cleaning() { # clean-up XFRM (BCE/BUL) for t in sub main; do ip xfrm policy flush ptype ${t} > /dev/null 2>&1 true done for p in esp ah comp route2 hao; do ip xfrm state flush proto ${p} > /dev/null 2>&1 true done # clean-up tunnel device tnls=`ifconfig -a awk '/^ip6tnl/ { print $1 }'` for tnl in $tnls; do ip -6 tunnel del $tnl > /dev/null 2>&1 true done # clean-up neighbor cache devices=`ip link 2>&1 grep '^[0-9]' awk '{print $2}' sed -e 's/:$//'` for dev in $devices; do ip neigh flush dev $dev > /dev/null 2>&1 true done } return 0 case "$1" in start)

93 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 73 echo -n "Starting MIP6D: " PID=x`pgrep -f $MIP6D true` if [ "${PID}"!= "x" ] ; then echo "failed (already started)." exit 0 fi if [ x"$force_ipv6_forwarding" = x"yes" ]; then echo 1 > /proc/sys/net/ipv6/conf/all/forwarding fi start-stop-daemon --start --quiet --exec ${MIP6D} -- ${MIP6D_OPTS} echo "done." ;; stop) echo -n "Stopping MIP6D: " PID=x`pgrep -f $MIP6D true` if [ "${PID}" = "x" ] ; then echo "done (none found)." exit 0 fi # Be nice... HOW="" pkill -f ${MIP6D} sleep $DIETIME # Hum, you did not understand. Louder... PID=x`pgrep -f $MIP6D true` if [ "${PID}"!= "x" ] ; then pkill -TERM -f ${MIP6D} true sleep $DIETIME PID=x`pgrep -f $MIP6D true` if [ "${PID}"!= "x" ] ; then post_war_cleaning fi HOW=" (TERMinated)" fi # Ok, go to hell... PID=x`pgrep -f $MIP6D true` if [ "${PID}"!= "x" ] ; then pkill -KILL -f ${MIP6D} true sleep $DIETIME post_war_cleaning HOW=" (KILLed)" exit 0 fi echo "done.${how}" ;; reload) echo -n "Reloading MIP6D: "

94 74 Anexo D: Script de Arranque pkill -HUP -f ${MIP6D} true echo "done." ;; restart force-reload) $0 stop $0 start ;; status) status=" NOT" PID=x`pgrep -f $MIP6D true` if [ "${PID}"!= "x" ] ; then status="" fi echo "${DESC} (${NAME}) is${status} running." exit 0 ;; *) N=/etc/init.d/$NAME echo "Usage: $N {start stop restart force-reload status}" >&2 exit 1 ;; esac exit 0

95 ANEXO E: SCRIPT PARA TRASPASO En este anexo se presenta al script que se usará en las pruebas para simular un traspaso. El nombre del script es scriptinterfaz.sh y podrá encontrarlo en el CD que viene con este proyecto. Su contenido es el siguiente: #!/bin/bash #-*-ENCODING: UTF-8 -*- ### BEGIN INIT INFO # MIGUEL MIRALLES CABEZA. PFC 2014 # Parametros: interfaz_on interfaz_off # Breve Descripcion: cambia al equipo de VLAN # Descripcion: activa una interfaz eth y desactiva la otra, asi el # equipo solo está en una red. Cuando el programa lo solicite, al # pulsar intro, interfaz_on estará abajo e interfaz_off arriba, dando # asi la sensacion de que se ha cambiado de red. ### END INIT INFO echo -e "\nscript QUE CAMBIA AL EQUIPO S1IPV6 DE VLAN" case "$1" in -h) echo -e "AYUDA\n" echo -e "Llamada a la función como root:\n./scriptinterfaz.sh interfaz_on interfaz_off\n" echo "interfaz_on indica la interfaz que se subira al arranque del script" echo -e "interfaz_off indica la interfaz que se bajara al arranque del script\n" exit 0 ;; esac if [ $#!= 2 ]; then echo "Error llamando a la funcion. Mas info consulte la ayuda:./scriptinterfaz.sh -h" exit 1 fi #Empieza el programa ifconfig $1 up ifconfig $2 down echo "Actualmente esta activada la interfaz $1 y desactivada la interfaz $2. Para cambiar de red se bajara $1 y se subira $2. Pulse intro para continuar" read echo "Hora:min:seg.ns a la que se inicia el traspaso: " date +%H:%M:%S.%N ifconfig $1 down ifconfig $2 up 75

96 76 Anexo E: Script para Traspaso echo "Hora:min:seg.ns a la que finaliza: " date +%H:%M:%S.%N echo -e echo "El programa va a finalizar. Si desea resetear las interfaces pulse Si[S], si no, pulse cualquier otra tecla." read dato if [ $dato == "S" ]; then service network-manager force-reload fi echo -e "PROGRAMA FINALIZADO\n" exit 0 La labor del script puede interpretarse viendo el código anterior, pero aún así vamos a explicarlo. En la llamada usamos dos parámetros. El primero indica la interfaz que queremos que esté arriba en un principio, y el segundo parámetro indica la que se bajará. Es decir, nada más ejecutar el script tendremos una interfaz activada y otra desactivada. Posteriormente, se nos pedirá que pulsemos intro para producir el traspaso. Lo que sucede realmente es que se baja la interfaz que antes estaba activa y se sube la que estaba desactivada, simulando así un traspaso de red. Por último, si se pulsa la tecla S, se fuerza a reiniciar las dos interfaces de red, esto es, se bajan las dos interfaces eliminando las direcciones IP que hayan obtenido y se vuelven a levantar, si no, se quedan como están. La ventaja de usar este script es que el tiempo de traspaso es casi despreciable, por lo que no interferirá en la medida de otros tiempos.

97 ANEXO F: INSTALACIÓN IPERF Y JPERF Iperf es una herramienta que se utiliza para hacer pruebas en redes informáticas. El funcionamiento habitual es crear flujos de datos TCP y UDP y medir el rendimiento de la red. Hay dos formas de instalar Iperf. La primera de ellas es la más sencilla. Consiste en abrir un terminal como root y ejecutar: apt-get install iperf La segunda de ellas, radica en descargar el código fuente desde el repositorio oficial: Descomprimimos el fichero descargado con la orden tar xvzf. Una vez descomprimido, entramos en la carpeta y ejecutamos las siguientes instrucciones:./configure make make install Una vez completada la instalación ya podremos usar Iperf. Pero debido a que su utilización es a través de línea de comandos, se recomienda emplear Jperf que es una interfaz gráfica desarrollada en Java que nos facilita el manejo de Iperf, puesto que solo tenemos que ir rellenando una serie de campos y él se encarga de traducirlos a un orden Iperf. Para instalar Jperf, descargamos el código desde: y descomprimimos con unzip. Para empezar a utilizarlo, basta con entrar en la carpeta descomprimida y ejecutar jperf.sh. Aparecerá una ventana donde vamos seleccionando si queremos usar TCP o UDP, si usamos IPv6, etc. además de ver una gráfica de ancho de banda, si ejecutamos el programa como cliente, y de ancho de banda más jitter, si lo hacemos como servidor. Por último abajo a la derecha aparece una ventana que es la salida por pantalla que mostraría Iperf por línea de comandos. Figura F-1. Jperf como servidor. 77

98 78 Anexo F: Instalación Iperf y Jperf Figura F-2. Jperf como cliente.

99 ANEXO G: GRÁFICAS CON WIRESHARK En este anexo se muestra cómo hacer las gráficas que se han usado en el capítulo 5 con el software Wireshark. La primera de ellas es la gráfica del tipo Stevens. Para llevarla a cabo, abrimos un fichero que contenga paquetes de una conexión TCP y seleccionamos un segmento del sentido de la comunicación que queremos analizar 31. A continuación, seleccionamos en el menú de Wireshark: Statistics TCP Stream Graph Time- Sequence Graph (Stevens). Apareceran dos ventanas, una con la gráfica y otra con una serie de opciones para el mejor manejo y tratamiento de la gráfica. La ventana de opciones tiene un aspecto cómo éste: Figura E-1. Ventana de opciones de la gráfica. A continuación, explicamos que podemos hacer en cada una de las pestañas: Zoom: seleccionado in u out, realizamos el tipo de zoom y lo aplicamos con el botón izquierdo del ratón en la pantalla de la gráfica. La información del zoom aplicado se muestra en Horizontal y Vertical. En Horizontal y Vertical Step indicamos el número de divisiones de los intervalos en ambos ejes. Podemos bloquear el zoom tanto en un eje como en el otro en Zoom Lock. Magnify: se trata de una ventana de zoom como si de una lupa se tratase. En esta pestaña podemos indicar el tamaño del zoom aplicado. Origin: cómo vamos a mostrar la gráfica dependiendo del origen de los datos, es decir, desde el principio de la conexión TCP o desde el principio de la captura, y el origen del número de secuencia: 0 (absoluto) o número de secuencia inicial. Cross: cómo se nos muestra el puntero del ratón. De la forma típica o en forma de cruz de ejes (guías). Graph type: tipo de gráfico mostrado, en este caso, Time/Secuence o tipo Stevens. Ahora veamos la gráfica que nos muestra: 31 Como una conexión TCP permite el envío de datos en ambos sentidos, se pueden visualizar 2 gráficas Stevens diferentes: las correspondientes a cada sentido de la comunicación. De ahí a que tengamos que seleccionar un segmento correspondiente a uno de los dos sentidos. 79

100 80 Anexo G: Gráficas con Wireshark Figura E-2. Gráfica Stevens. Podemos usar una serie de controles con el ratón y el teclado sobre esta ventana, sin tener que usar la ventana de opciones: Seleccionar paquete de la pantalla de edición desde la gráfica: nos situamos en uno de los segmentos de la gráfica, pulsamos Ctrl+botón izquierdo del ratón. Con esta acción resaltará el paquete en la pantalla principal de la captura. Zoom: para acercarnos, usamos el botón derecho del ratón. Para alejarnos, Shift+botón derecho del ratón. Desplazamiento: nos desplazaremos por la pantalla con el botón derecho pulsado y arrastrando. Mostrar guías: pulsar la barra de espacio (es igual que la opción Cross de la ventana de opciones). Otra gráfica que usamos es la referente al RTT. Para realizarla, seleccionamos en el menú de Wireshark: Statistics TCP Stream Graph Round Trip Time Graph. Nos aparecerán dos ventanas, la de opciones que es la misma que la descrita anterior, y una ventana donde se muestra una gráfica como ésta:

101 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6 81 Figura E-3. Gráfica RTT. El siguiente tipo de gráfica que vamos a mostrar es la de Input/Output. Podemos encontrarla en Statistics I/O Graph. Figura E-3. Gráfica I/O. Si nos fijamos en la parte inferior, nos encontramos con múltiples inputs para introducir filtros para solo representar el tráfico que queramos. Según vayamos introduciéndolos veremos, en diferentes colores, su representación en la gráfica. Si observamos líneas que se solapan y difíciles de distinguir, podemos pulsar sobre Style y nos encontraremos con otro tipo de representación, por ejemplo, mediante barras verticales, para facilitar su comprensión.