desarrollo de escenario para el anÁlisis de la...

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

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

Proyecto Fin de Carrera: DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6

Autor: Miguel Miralles Cabeza

Tutor: Juan Antonio Ternero Muñiz

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2014

El Secretario del Tribunal

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

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

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

Índice

Agradecimientos i

Resumen iii

Abstract v

Índice vi

Índice de Códigos ix

Índice de Figuras xi

Notación xiii

1 Introducción 1 1.1. Estado del Arte 1 1.2. Alcance y Objetivos 2

2 Internet Protocol Version 6 (IPv6) 3 2.1. Motivación 3 2.2. Cabecera IPv6 3 2.3. Las direcciones en IPv6 4

2.3.1. Representación 4 2.3.2. Subredes 5 2.3.3. Tipos de direcciones 5

2.4. Stateless Address Autoconfiguration (SLAAC) 7 2.5. IPsec (Internet Protocol security) 8 2.6. Internet Control Message Protocol version 6 (ICMPv6) 10 2.7. Neighbor Discovery (ND) 12

3 Mobile IPv6 (MIPv6) 13 3.1. Historia y motivación 13 3.2. Funcionamiento básico 14 3.3. Cabecera MIPv6 16 3.4. Mensajes importantes 17 3.5. Modificación en otros protocolos 19 3.6. Seguridad 20 3.7. Despliegue a gran escala 20 3.8. Proyecto UMIP 21

4 Desarrollo Del Escenario 23 4.1. Equipos utilizados 23 4.2. Configuración del Router 24 4.3. Instalación Software de Movilidad 28

4.3.1. Recompilar Kernel 28 4.3.2. Compilar e instalar UMIP 30

4.4. Configuración s1ipv6 30 4.5. Configuración s2ipv6 33 4.6. Configuración CN1 35

4.7. Esquema de conexión 36 4.8. Arrancar servicios de Movilidad 36

5 Análisis 39 5.1. Análisis del funcionamiento 39

5.1.1. Prueba 1: Ping6 con traspaso. 40 5.1.2. Prueba 2: Ping6 con regreso. 45 5.1.3. Prueba 3: Ping6 con traspaso (ESP). 47

5.2. Análisis del rendimiento 48 5.2.1. Prueba 1: UDP del CN al MN 49 5.2.2. 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

Í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

Í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-64. 8

Figura 2-9. Formato AH (arriba) y formato ESP (abajo). 9

Figura 2-10. Requisitos de implementación de algoritmos para AH y ESP según RFC 7321. 10

Figura 2-11. ICMPv6 encapsulado dentro de paquete IPv6. 10

Figura 2-12. Cabecera ICMPv6. 11

Figura 2-13. Mensajes ICMPv6. 11

Figura 2-14. 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 5-10. Escenario prueba UDP sin traspaso. 49

Figura 5-11. Resultados de experimentos UDP sin traspaso. 50

Figura 5-12. Escenario 1 prueba UDP con traspaso. 51

xi

51

52

53

53

54

55

55

56

57

58

58

59

60

Figura 5-13. Escenario 2 prueba UDP con traspaso.

Figura 5-14. Paquetes seleccionados con el filtro en Wireshark.

Figura 5-15. Gráfico I/O prueba UDP con traspaso.

Figura 5-16. Resultados pruebas UDP con traspaso.

Figura 5-17. Escenario prueba TCP sin traspaso.

Figura 5-18. Resultados pruebas TCP sin traspaso.

Figura 5-19. Escenario 1 prueba TCP con traspaso.


Figura 5-21. Gráfica Stevens de los datos FTP.

Figura 5-22. Gráfica RTT de los datos FTP.

Figura 5-23. Gráfica RTT de los datos FTP (2).

Figura 5-24. Resultados pruebas TCP con traspaso.

Figura 5-25. Tabla y gráfica comparativa de tiempos de transferencia TCP sin/con traspaso.

Figura 5-26. Tabla y gráfica comparativa de paquetes enviados TCP sin/con traspaso. 60

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

1 INTRODUCCIÓN

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.

1.1. 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

E

Dime y lo olvidaré. Muéstrame y lo recordaré. Involúcrame y lo entenderé.

Proverbio chino

1

Introducción 2

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).

1.2. 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.

2 INTERNET PROTOCOL VERSION 6 (IPV6)

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.

2.1. 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 232 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 2460. Este protocolo nos proporciona 2128

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.

2.2. Cabecera IPv6 En la siguiente figura se muestra la cabecera adoptada en este protocolo [2-1]:

0 4 8 12 16 20 24 28 31 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.

C

3

Internet Protocol Version 6 (IPv6) 4

• 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.

2.3. Las direcciones en IPv6

2.3.1. 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:3210

1080: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

5 DESARROLLO DE ESCENARIO PARA EL ANÁLISIS DE LA MOVILIDAD EN IPv6

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:13.1.68.3, o en su forma compacta: ::13.1.68.3.

2.3.2. 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 2.3.1. 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 296 /48 Organizaciones 280 /64 Subredes de la Organización 264

/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.

2.3.3. 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.


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 1111111010 0 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 0000…………………………..………….0000 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 formato1 [2-2]:

8 bits 4 bits 4 bits 112 bits 11111111 000T Á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 2.7.1 del RFC 4291 [2.3]


• 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.

2.4. 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


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.

2.5. 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.


• 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.

0 7 15 31 Cabecera Siguiente Longitud de la Carga RESERVADO

Índice de Parámetros de Seguridad (SPI)

Número de Secuencia

Datos de Autentificación (Longitud variable)

0 7 15 23 31

Í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


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 DES-CBC [RFC2405]

SHOULD AES-XCBC-MAC-96 [RFC3566] MAY AES-CTR [RFC3686]

ESP Authenticated Encryption (Combined Mode

Algorithms*)

ESP Encryption 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 2-10. Requisitos de implementación de algoritmos para AH y ESP según RFC 7321.

2.6. 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 2-11. ICMPv6 encapsulado dentro de paquete IPv6.

Como vemos en la anterior imagen, los mensajes ICMPv6 incluyen una cabecera2, 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.


0 7 15 31

Tipo Código Checksum

Figura 2-12. 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) 1

Mensaje de error que informa al host remitente de

que un paquete no se puede entregar.

Packet Too Big (Paquete demasiado grande) 2

Mensaje de error que informa al host remitente de

que el paquete es demasiado grande para el reenvío.

Time Exceeded (Tiempo agotado) 3 Mensaje de error que informa al host remitente de que el límite

de saltos de un paquete IPv6 ha caducado.

Parameter Problem (Problemas de parámetros) 4

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.

Echo Request (Solicitud de eco) 128 Mensaje informativo que se utiliza para determinar si un nodo IPv6 está disponible en la red.

Echo Reply (Respuesta de eco) 129 Mensaje informativo que se emplea para responder al mensaje de solicitud de eco ICMPv6.

Figura 2-13. 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


profundidad, acabaremos este capítulo hablando brevemente del protocolo ND.

2.7. 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 2-14. Escenarios donde se usan ND.

3 MOBILE IPV6 (MIPV6)

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.

3.1. 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 20023. Posteriormente se dió soporte a la movilidad en IPv6 con el RFC 3775: Mobility Support in IPv64, que será el que veremos en la siguiente sección.

3 Obsoleta por el RFC 5944 4 Su versión más reciente es el RFC 6275

E

13

Mobile IPv6 (MIPv6) 14

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 MIPv6.

3.2. 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 red5, 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.


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


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 seguridad6, 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:

0 7 15 23 31 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.


• 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.

3.4. 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:

0

15 31

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


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:

0 15 23

31

Estado K Reservado

Secuencia # Tiempo de Vida


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 ‘0’: Binding Update accepted (BU aceptado)

o ‘1’: Accepted but prefix discovery necessary (aceptado pero se requiere descubrimiento de prefijo)

o ‘134’: Duplicate Address Detection failed (Detección de direcciones duplicadas ha fallado)

o ‘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:

0 15 23 31

Estado Reservado

Home Address


Figura 3-6. Formato Mensaje Binding Error.


• Estado (Status): entero de 8 bits sin signo. Indica la razón que ha originado el error, pudiendo tomar los siguientes valores:

o ‘1’: Binding desconocido para la opción Home Address especificada.

o ‘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.

3.5. 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 campos7 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.


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 3776.

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 4877.

3.7. 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


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].

3.8. 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).

4 DESARROLLO DEL ESCENARIO

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.

4.1. 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.

E

23

Desarrollo Del Escenario 24

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


% 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 switchports8 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).


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ón9, 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 access10 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.


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 30000 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 milisegundos11 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 ra-interval 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 comandos12: 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


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].

4.3.1. 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: http://umip.org/docs/patches/, 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 http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.8.2.tar.bz2

Posteriormente, descomprimimos e instalamos las librerías necesarias para la recompilación: bunzip2 linux-3.8.2.tar.bz2 tar xf linux-3.8.2.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-3.2.0-4-686-pae /usr/src/linux-3.8.2/.config

Hacemos efectivo lo anterior, ejecutando: make oldconfig


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


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.

4.3.2. 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 ipsec-tools 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.

4.4. 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:


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


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 "MIP6-011--12345678901234" -A hmac-sha1 "MIP6-011--1234567890" ;


# HA -> MN1 transport SA for BA add 2001:720:c18:bb:24f:4eff:fe01:ad52

2001:720:c18:bb:24f:4eff:fe0f:77ff esp 0x12 -u 12 -m transport -E 3des-cbc "MIP6-012--12345678901234" -A hmac-sha1 "MIP6-012--1234567890" ; # 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 "MIP6-013--12345678901234" -A hmac-sha1 "MIP6-013--1234567890" ; # HA -> MN1 tunnel SA for any traffic add 2001:720:c18:bb:24f:4eff:fe01:ad52

2001:720:c18:bb:24f:4eff:fe0f:77ff esp 0x14 -u 14 -m tunnel -E 3des-cbc "MIP6-014--12345678901234" -A hmac-sha1 "MIP6-014--1234567890" ; # 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 "MIP6-015--12345678901234" -A hmac-sha1 "MIP6-015--1234567890" ; # HA -> MN1 transport SA for ICMP (including MPS/MPA) add 2001:720:c18:bb:24f:4eff:fe01:ad52

2001:720:c18:bb:24f:4eff:fe0f:77ff esp 0x16 -u 16 -m transport -E 3des-cbc "MIP6-016--12345678901234" -A hmac-sha1 "MIP6-016--1234567890" ;

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.

4.5. 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ón13:

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.


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 Binding14.

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 4.3.2 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.


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 s2ipv6.

4.6. 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.


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.

4.8. 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


É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.

5 ANÁLISIS

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.

5.1. 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:

• “ping615 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

E

39

5 Análisis 40

5.1.1. 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 HA16. 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:

Figura 5-1. Escenario prueba 1 con MN en casa.

La trayectoria que sigue los mensajes es la siguiente:

• Ida: 1-2-4

• Vuelta: 4-3-2-1

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 s2ipv617 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


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

5 Análisis 42

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 = 57000 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 21292 resend 0 delay 57(after 14s) expires 17 mps 77427 / 77757

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:


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

5 Análisis 44

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 respuesta18. 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


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 MIPv6.

5.1.2. 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

5 Análisis 46

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 manualmente19:

• 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 = 24000 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.


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 HA20: 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.

5.1.3. 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.

5 Análisis 48

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.

5.2. 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.


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écnicos21. 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.

5.2.1. 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 5-10. 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 Jperf22 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ón23 (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.

5 Análisis 50

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 siguientes24:

Prueba Paquetes enviados Paquetes recibidos Paquetes perdidos (%) p1 904 904 0,00 p2 904 904 0,00 p3 904 904 0,00 p4 904 904 0,00 p5 904 904 0,00 p6 904 904 0,00 p7 904 904 0,00 p8 904 904 0,00 p9 904 904 0,00 p10 904 904 0,00 MEDIA 904 904 0,00 σ2 0 0 0,00 σ 0 0 0,00

Figura 5-11. 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




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.

5 Análisis 52

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 subred25. Así, el filtro que ponemos en las capturas del MN es el siguiente26:

(!(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 5-14. 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.


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 5-15. 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)

p1 904 533 41,04 4,169649 p2 904 567 37,28 3,786207 p3 904 574 36,50 3,707823 p4 904 581 35,73 3,629299 p5 904 573 36,62 3,718917 p6 904 547 39,49 3,976541 p7 904 544 39,82 4,042731 p8 904 529 41,48 4,122155 p9 904 525 41,92 4,190533 p10 904 609 32,63 3,297162 MEDIA 904 558,2 38,25 3,8641017 σ2 0 656,36 8,03 0,073918122 σ 0 25,61952381 2,83 0,271878874

Figura 5-16. Resultados pruebas UDP con traspaso.

5 Análisis 54

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 FMIPv6.

5.2.2. 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 foto27. En este escenario no habrá traspaso como ya se ha comentado.

Figura 5-17. 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.


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,118107 1731 p2 7,138919 1844 p3 7,172361 1673 p4 7,133739 1820 p5 7,125792 1769 p6 7,228333 1840 p7 7,261559 1822 p8 7,025276 1730 p9 7,157631 1960 p10 7,192973 1874 MEDIA 7,155469 1806,3 σ2 0,003823377 6185,01 σ 0,061833462 78,64483454

Figura 5-18. 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 5-20.


5 Análisis 56


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 Wireshark28.

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 tiempo29. 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.


Figura 5-21. 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.

5 Análisis 58

Figura 5-22. 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 5-23. Gráfica RTT de los datos FTP (2).


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 traspaso30:

Prueba Tiempo total (ms) Paquetes totales p1 12,200198 1838 p2 12,224835 1795 p3 12,117668 1736 p4 12,893888 1867 p5 12,231039 1805 p6 12,052404 1797 p7 12,765905 1925 p8 11,79184 1870 p9 11,804901 1930 p10 11,987572 1870 MEDIA 12,207025 1843,3 σ2 0,119920235 3366,41 σ 0,346295012 58,02077214

Figura 5-24. 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.

5 Análisis 60

Coeficiente de correlacion

0.911649563

Figura 5-25. Tabla y gráfica comparativa de tiempos de transferencia TCP sin/con traspaso.

Coeficiente de correlacion

0.96352777

Figura 5-26. 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.

0

2

4

6

8

10

12

14

1 2 3 4 5 6 7 8 9 10Ti

empo

(ms)

Tiempo de transferencia

Sin traspaso

Con traspaso

1500

1600

1700

1800

1900

2000

1 2 3 4 5 6 7 8 9 10

Paqu

etes

(uds

)

Paquetes enviados

Sin traspaso

Con traspaso

Sin traspaso Con traspaso 7.025276 11.79184 7.118107 11.804901 7.125792 11.987572 7.133739 12.052404 7.138919 12.117668 7.157631 12.200198 7.172361 12.224835 7.192973 12.231039 7.228333 12.765905 7.261559 12.893888

Sin traspaso Con traspaso 1673 1736 1730 1795 1731 1797 1769 1805 1820 1838 1822 1867 1840 1870 1844 1870 1874 1925 1960 1930

6 CONCLUSIONES Y TRABAJOS FUTUROS

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.

L

61

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 Versión 7.4 (wheezy) de 32-bit

o Núcleo Linux 3.8.2-mipv6

o GNOME 3.4.2

• Hardware:

o Memoria RAM disponible: 501,9 MiB

o Procesador: Intel Pentium® 4 CPU 3.00Ghz

o 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:


63



o Núcleo Linux 3.8.2-mipv6

o GNOME 3.4.2

• Hardware:

o Memoria RAM disponible: 501,9 MiB

o Procesador: Intel Pentium® 4 CPU 1.50Ghz

o 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:


General

Tipo de dispositivo Router - conmutador de 8 puertos (integrado)

Tipo incluido Sobremesa

Tecnología de conectividad Cableado

Protocolo de interconexión de datos Ethernet, Fast Ethernet

Capacidad Túneles VPN IPSec : 50

Red / Protocolo de transporte L2TP, IPSec, FTP, DHCP, DNS, L2TPv3, DDNS

Protocolo de direccionamiento OSPF, RIP-1, RIP-2, BGP, EIGRP, HSRP, VRRP, NHRP, PIM-SM, GRE

Protocolo de gestión remota Telnet, SNMP 3, HTTP, HTTPS, SSH

Algoritmo de cifrado LEAP, DES, Triple DES, SSL, PEAP, TKIP, PKI, AES de 128 bits, AES de 192 bits, AES de 256 bits

Método de autentificación RADIUS, TACACS+

Características

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)

Cumplimiento de normas IEEE 802.1D, IEEE 802.1Q, IEEE 802.1x , CISPR 24, EN 61000-3-2, EN55022, ICES-003, EN 61000-3-3, EN55024, CISPR 22, EN50082-1, EN55022 Class B, ICES-003 Class B, EN 61000-6-1, AS/NZ 3548 Class B, EN 60555-2, FCC CFR47 Part 15, EN300-386, FCC CFR47 Part 15 B, VCCI V-3

Memoria RAM 512 MB (instalados) / 768 MB (máx.)

Memoria Flash 256 MB (instalados) / 256 MB (máx.)

Indicadores de estado Estado puerto, alimentación

Expansión/Conectividad

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:



o Núcleo Linux 3.2.0-4-686-pae


o GNOME 3.4.2

• Hardware:

o Memoria RAM disponible: 2,8 GiB

o Procesador: Intel Pentium® 4 Dual CPU T3200 @ 2.00 GHz x 2

o Una interfaz de red Ethernet con controlador Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+

o Tarjeta gráfica Mobile Intel® 4 Series Express Chipset Family

Figura A-4. Equipo CN1.

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

Anexo B: Instalación Minicom 68

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.

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

Anexo C: Instalación FileZilla 70

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.

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 <[email protected]> # Further modified by Arnaud Ebalard <[email protected]> ### BEGIN INIT INFO # Provides: mip6d # Required-Start: $network $syslog # Required-Stop: $network $syslog # Should-Start: $local_fs # Should-Stop: $local_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # 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


log_failure_msg " See mip6d.conf(5) for configuration file syntax and" log_failure_msg " sample configuration elements." log_failure_msg " => $DESC will not be started" exit 0 fi 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=ìfconfig -a | awk '/îp6tnl/ { print $1 }'` for tnl in $tnls; do ip -6 tunnel del $tnl > /dev/null 2>&1 || true done # clean-up neighbor cache devices=ìp 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)


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: "


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

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

Anexo E: Script para Traspaso 76

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.

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:

https://code.google.com/p/walami/downloads/detail?name=iperf-2.0.5.tar.gz&can=2&q=

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: https://code.google.com/p/xjperf/, 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

Anexo F: Instalación Iperf y Jperf 78

Figura F-2. Jperf como cliente.

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 analizar31. 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

Anexo G: Gráficas con Wireshark 80

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:


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.

BIBLIOGRAFÍA En este capítulo se muestran las referencias citadas en el texto. Aquellas que no están numeradas, han sido usadas para la elaboración de este texto y/o se recomiendan para ampliar conocimientos.

CAPÍTULO 2: Internet Protocol Version 6 [2-1] Deering, S. y Hinden, R."Internet Protocol, Version 6 (IPv6) Specification", RFC 2460. Diciembre 1998.

[2-2] Mateo, A. (2005). “Análisis y simulación de: Gestión de la movilidad IPv6 Móvil Jerárquica (HMIPv6)” (pp. 30, 36,39). Proyecto fin de carrera, Universidad de Sevilla. Escuela Técnica Superior de Ingeniería.

[2-3] Hinden, R. y Deering, S. “IP version 6 Addressing Architecture”, RFC 4291. Febrero 2006.

[2-4] SURFnet bv. (2011). “Preparing an IPv6 Addressing Plan”. Consulta en marzo de 2014, en http://www.rediris.es/conectividad/IPv6_addr_plan4.pdf

[2-5] Network Information Center México S.C. (Fecha desconocida). “Fundamentos de IPv6”. Consulta en marzo de 2014, en http://www.ipv6.mx/index.php/informacion/fundamentos/ipv6

[2-6] Arias, E. (2013). “Supuesto práctico de análisis para la transición de IPv4 a IPv6 en un entorno de redes empresariales WAN/LAN” (pp. 19). Universitat Oberta de Catalunya.

[2-7] Alejandro Corletti. (2005). “Protocolo IPSEC”. Consultada en agosto de 2014, en http://www.worktec.com.ar/consetic2005/consecri/pdf/Consecri%2026-09-01/Sal%F3n%20General/Exposiciones/09-Protocolo%20IPSEC.pdf

[2-8] Kent, S. “IP Authentication Header”, RFC 4302. Diciembre 2005.

[2-9] Kent, S. "IP Encapsulating Security Payload (ESP)", RFC 4303. Diciembre 2005.

[2-10] McGrew, D. y Hoffman, P. “Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)”. RFC 7321. Agosto 2014.

[2-11] Microsoft. (2005). “Protocolo de mensajes de control de Internet para IPv6 (ICMPv6)”. Consultada en Julio 2014, en http://msdn.microsoft.com/es-es/library/cc757063(v=ws.10).aspx

[2-12] Autor desconocido. (2013). “ICMPv6”. Consultada en Julio 2014, en http://es.wikipedia.org/wiki/ICMPv6

[2-14] Autor desconocido. (2013). “Neighbor Discovery”. Consultada en agosto de 2014, en http://www.see-my-ip.com/tutoriales/protocolos/ipv6_neighbor%20discovery.php

Bruce Sinclair. (2013). “Biggest risks in IPv6 security today”. Consultada en febrero de 2014, en http://www.networkworld.com/article/2171504/tech-primers/biggest-risks-in-ipv6-security-today.html

INTECO. (2013). “Configuración silenciosa en IPv6 – Ataque al protocolo SLAAC de autoconfiguración de direcciones”. Consultada en febrero de 2014, en https://www.inteco.es/blogs/post/Seguridad/BlogSeguridad/Articulo_y_comentarios/ipv6_Ataque_SLAAC

Network Computing. “Six Benefits Of IPv6”. (2011). Consultada en febrero de 2014, en http://www.networkcomputing.com/networking/six-benefits-of-ipv6/d/d-id/1232791?

Cisco. (2012). “NAT64 Technology: Connecting IPv6 and IPv4 Networks”. Consultada en febrero de 2014, en http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html

Microsoft. (2005). “Descripción general de los conceptos de la directiva IPsec”. Consultada en febrero de 2014, en https://www.microsoft.com/spain/technet/recursos/articulos/ipsecapa.mspx

Johnson, D. y Deering, S. "Reserved IPv6 Subnet Anycast Addresses", RFC 2526. Marzo 1999.

Hinden, R. y Deering, S. "IPv6 Multicast Address Assignments", RFC2375. Julio 1998.

83

Bibliografía 84

Thomson, S. y Narten, T. "IPv6 Stateless Address Autoconfiguration", RFC 2462, Diciembre 1998.

Narten, T. and Draves, R. "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041. Enero 2001.

CAPÍTULO 3: Mobile IPv6 (MIPv6) [3-1] Perkins, C., Johnson, D. y Arkko, J. "Mobility Support in IPv6", RFC 6275. Julio 2011.

[3-2] Mateo, A. (2005). “Análisis y simulación de: Gestión de la movilidad IPv6 Móvil Jerárquica (HMIPv6)” (pp. 49, 60, 73-79). Proyecto fin de carrera, Universidad de Sevilla. Escuela Técnica Superior de Ingeniería.

[3-3] Díaz, M.A, Olvera, C. y Morales, P. (Fecha desconocida). “Despegando con movilidad IPv6 (MIPv6)”. Consulta en Agosto de 2014, en http://aui.es/IMG/ponencia1268_2.pdf

[3-4] Autor desconocido. (2013). “UMIP - Mobile IPv6 and NEMO for Linux”. Consultada en Marzo de 2014, en http://umip.org

Arkko, J., Devarapalli, V. y Dupont, F. “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents”, RFC 3776. Junio 2004.

Devarapalli, V. y Dupont, F. “Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture”. RFC 4887. Abril 2007.

Chang, F. (2005). “Servicios Y Soluciones Que Brinda El Protocolo De Internet Movil (Mobile Ip) En Redes De Tercera Generación”. Proyecto fin de carrera, Universidad de Ecuador. Escuela Politécnica del Ejército.

Díaz, Javier F., Demasi, M, Robles, M. y Vodopivec, G. (2006). “Movilidad en IPv6”. Consultada en Marzo de 2014, en http://sedici.unlp.edu.ar/bitstream/handle/10915/20873/Documento_completo.pdf?sequence=1

García, T. (2003). “Análisis de las extensiones a IPv6 Móvil para la mejora del proceso de handover”. Proyecto fin de carrera, Universidad de Sevilla. Escuela Técnica Superior de Ingeniería.

CAPÍTULO 4: Desarrollo del escenario [4-1] Cisco. (2013). “Cisco 890 Series Integrated Services Routers FAQ”. Consultada en marzo de 2014, en

http://www.cisco.com/c/en/us/products/collateral/routers/800-series-routers/qa_c67-520756.html

[4-2] Gerometta, O. (2008). “Seguridad en el acceso a dispositivos Cisco”. Consultada en marzo de 2014, en

http://librosnetworking.blogspot.com.es/2008/10/seguridad-en-el-acceso-dispositivos.html

[4-3] UMIP (2013). “How to install UMIP (kernel and userland)”. Consultada en marzo de 2014, en

http://umip.org/docs/umip-install.html

[4-4] UMIP (2013). “How to setup a Mobile IPv6 testbed with IPsec static keying”. Consultada en abril de 2014, en http://umip.org/docs/umip-mip6.html

[4-5] Autor desconocido (2010). “radvd.conf - configuration file of the router advertisement daemon”. Consultada en abril de 2014, en http://manpages.ubuntu.com/manpages/saucy/man5/radvd.conf.5.html

Autor desconocido (2013). “Cómo compilar e instalar el último Kernel (3.12.1) en CrunchBang Waldorf / Debian Wheezy”. Consultada en marzo de 2014, en http://yoyo308.com/2013/11/22/como-compilar-e-instalar-el-ultimo-kernel-3-12-1-en-crunchbang-waldorf-debian-wheezy/

Cisco. (2013). “Basic Router Configuration”. Consultada en marzo de 2014, en http://www.cisco.com/c/en/us/td/docs/routers/access/800/860-880-890/software/configuration/guide/SCG880-860/routconf.pdf

Cisco. (2013). “Auxiliary Port, Console Port, And Adapter Pinouts For Cisco 1000, 1600, 2500, 2600, And 3600 Series Routers”. Consultada en marzo de 2014, en http://www.cisco.com/c/en/us/support/docs/routers/1600-series-routers/46789-port-pinout.html


Autor desconocido (2014). “Router Cisco: Configuración básica”. Consultada en marzo de 2014, en http://es.kioskea.net/faq/2759-router-cisco-configuracion-basica#poner-una-contrasena-al-acceso-privilegiado

Dpto. Ingeniería de Sistemas Telemáticos U.P.M. (2009). “Manual Rápido de Configuración de un Router CISCO”. Consultada en marzo de 2014, en http://www.lab.dit.upm.es/~labrst/config/manuales-cisco/config-ciscos-v3.pdf

Autor desconocido (fecha desconocida). “Configuring IPv6 Router Advertisements and a Static Address”. Consultada en marzo de 2014, en http://www.telecom.otago.ac.nz/tele301/student_html/postinst-router-advertisements.html

Cisco (fecha desconocida). “Configuring IPv6”. Consultada en marzo de 2014, en http://www.cisco.com/c/en/us/td/docs/security/asa/asa72/configuration/guide/conf_gd/ipv6.html#wp1057332

CAPÍTULO 5: Análisis Iapichino,G. y Bonnet, C. (2010). “Experimental Evaluation of Proxy Mobile IPv6: an Implementation Perspective”. Consultada en septiembre de 2014, en http://0-ieeexplore.ieee.org.fama.us.es/stamp/stamp.jsp?tp=&arnumber=5506477

Autor desconocido (2008). “Gráficas con Wireshark (II Parte). Tcptrace”. Consultada en septiembre de 2014, en http://seguridadyredes.wordpress.com/2008/12/01/graficas-con-wireshark-ii-parte-tcptrace/

Autor desconocido (2009). “Wireshark / Tshark. Usando IO Graph para relacionar ACKs duplicados, lost segment y retransmisiones”. Consultada en septiembre de 2014, en http://seguridadyredes.wordpress.com/2008/12/01/graficas-con-wireshark-ii-parte-tcptrace/

Autor desconocido (2009). “Wireshark: Análisis de gráficas de “tcptrace” de conexiones TCP”. Consultada en septiembre de 2014, en http://docencia.etsit.urjc.es/moodle/file.php/17/Curso_2009_2010/Practicas/practica-5/wireshark-tcptrace.pdf

http://seguridadyredes.wordpress.com/2008/12/01/graficas-con-wireshark-ii-parte-tcptrace/

Índice de Conceptos Estos conceptos han sido extraídos de la web http://www.ipv6.es/es-es/glosario del Gobierno de España o añadidos por el autor de este texto.

• Binding: asociación que se establece entre la dirección HoA y CoA del nodo móvil.

• Binding Update List: lista mantenida en cada nodo móvil. Contiene un elemento por cada binding que el nodo móvil tiene o está intentando establecer. Ambos registros, direcciones HoA y CoA, están incluidos en esta lista. Los elementos de la lista son eliminados cuando expira el tiempo de vida del binding correspondiente.

• Bootstrapping: procedimiento único mediante el cual el usuario de movilidad se autentica frente al operador, obtiene diversos parámetros de red (HN, HoA) necesarios para el inicio de la movilidad, se le asigna un HA y se establece el material criptográfico para el stablecimiento de las SAs que permitan cifrar la señalización MIPv6.

• Cabecera de extensión: Cabecera que se sitúa entre la cabecera IPv6 y las cabeceras de protocolos de nivel superior, y que permiten agregar funcionalidades adicionales a IPv6.

• Cabecera de opción hop-by-hop (salto a salto): Cabecera de extensión IPv6 que contiene opciones que deben ser procesadas por todos los nodos.

• CIDR: Notación mediante la cual se expresan los prefijos de red. Tiene la forma prefijo (en hexadecimal)/longitud del prefijo (en decimal).

• Correspondent Node: Un nodo que se comunica con un nodo móvil que se encuentra fuera de su red habitual.

• DHCPv6 (Protocolo Dinámico de Configuración de nodos): Protocolo de configuración con estado (en inglés stateful) que proporciona direcciones IP, direcciones de los servidores DNS y otros parámetros de configuración.

• Dirección: Identificador único asignado a nivel de la capa de red a una interfaz o conjunto de ellas, que puede ser empleado como campo de origen o destino en datagramas IPv6.

• Dirección MAC: Dirección de nivel de enlace, conocidas comúnmente como dirección física, dirección de hardware o dirección de la interfaz de red.

• Encaminador: Nodo que retransmite datagramas que no van destinados a él. En las redes IPv6 los encaminadores envían también anuncios relativos a su presencia y la información de configuración.

• Enlace: Segmento o segmentos de una red de área local limitados por encaminadores. • Enlace habitual (home link): Término utilizado en movilidad IP para indicar el enlace en el que el

nodo móvil reside cuando está en su red. • EUI-64: Dirección del nivel de enlace de 64 bits, definida por IEEE (Institute of Electrical and

Electronic Engineers), utilizada para la generación del identificador de interfaz en IPv6. • Host: Véase nodo. • ICMPv6: Protocolo que proporciona en IPv6 mensajes de error, control, información, diagnóstico,

descubrimiento de vecindario, etc. • Interfaz: Nexo físico o lógico de un nodo a un enlace. • IPsec: Conjunto de estándares que proporciona comunicaciones privadas y autenticadas a nivel de

red, por medio de servicios criptográficos. IPSEC soporta autenticación a nivel de entidades de red, autenticación del origen de datos, integridad y cifrado de datos y protección anti-repeticiones.

• Neighbour Discovery: Conjunto de mensajes y procesos ICMPv6 que determinan las relaciones entre nodos vecinos. Sustituye a ARP, al descubrimiento de rutas ICMP y al mensaje de redirección ICMP empleados en IPv4. También proporciona detección de vecino inalcanzable.

87

Índice de Conceptos 88

• Nodo: Dispositivo que no puede reenviar datagramas no originados por él mismo. Habitualmente un

nodo es el origen y/o el destino del tráfico y por tanto descartará aquello que no esté dirigido específicamente a sí mismo.

• Nodo móvil: nodo que residiendo en la red de su “casa”, tiene la capacidad de migrar a otras redes. • Paquete: Unidad de datos del protocolo (PDU, Protocol Data Unit), que en el caso de IPv6, consta

de una cabecera IPv6 y la carga útil. • Prefijo de red: Parte fija de una dirección IPv6 que permite determinar la ruta, rango de direcciones

o subred. • Prefijo de sitio: Prefijo de 48 bits que identifica el bloque de direcciones de dicho sitio. La tabla de

prefijos almacena dicho prefijo de tal manera que se evita que el tráfico de dicho sitio pueda ser filtrado a Internet.

• Protocolo de nivel superior: Protocolo que utiliza IPv6 como transporte y se sitúa en la capa inmediatamente superior a IPv6, por ejemplo ICMPv6, TCP o UDP.

• RFC: Paso previo de un documento estándar de Internet (STD), aunque en la actualidad, los fabricantes implementan en sus productos RFCs, sin esperar a que sean STD.

• Router: Véase encaminador. • Round-trip delay time (RTT): tiempo que tarda un paquete de datos enviado desde un emisor en

volver a éste, habiendo pasado por el receptor de destino. • Subred: Uno o más enlaces que utilizan el mismo prefijo de 64 bits. • Traspaso: cuando un nodo móvil cambia de punto de unión a Internet, es decir, que ya no está

conectada al mismo link que antes. Si un nodo móvil no está conectado a su home link, se dice que está “fuera de casa”.

• Tiempo de indisponibilidad: intervalo de tiempo que comienza cuando un equipo que estaba recibiendo/enviando paquetes deja de estar disponible, hasta que vuelve a estar operativo.

• Vecinos: Nodos conectados en el mismo enlace.

desarrollo de escenario para el anÁlisis de la...

Documents