Вы находитесь на странице: 1из 105

UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA

DEPARTAMENTO DE

ELECTRÓNICA

VALPARAÍSO CHILE

MARÍA DEPARTAMENTO DE ELECTRÓNICA VALPARAÍSO – CHILE “ ESTUDIO E IMPLEMENTACIÓN DE UNA RED IPV6 EN

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 MARABOLI R. AGUSTÍN GONZÁLEZ V. 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

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.

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.

Í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

36

4.5.3. Costos de implementación y soporte

37

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

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

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: Configuración de equipos 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: Configuración de un 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

Índice de figuras

Figura 2.1 Distribución actual de bloques

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

16

Figura 3.3 Contextos de direcciones

19

Figura 3.4 Creación del identificador de

20

Figura 3.5 Estructura de una dirección local única

20

Figura 3.6 Estructura de una dirección “unicast”

21

Figura 3.7 Jerarquía de delegación de prefijos “unicast”

22

Figura 3.8 Estructura direcciones

22

Figura 3.9 Estructura dirección "multicast" de nodo solicitado

23

Figura 4.1 Topología simplificada Red UTFSM

31

Figura 5.1 Topología simplificada Red UTFSM (04/2009)

40

Figura 5.2 “Multihoming” con espacio direccionamiento

42

Figura 5.3 Diagrama configuración equipos

45

Figura 6.1 Evolución de MIBs unificadas

52

Figura 7.1 Escenario de pruebas servidor

57

Figura 7.2 Escenario de pruebas servidor

58

Figura 7.1 Configuración automática de

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

65

Figura 7.5 Procedimiento de

66

Figura 7.6 Generación de una dirección CGA

68

Figura B.1 Diagrama configuración equipos red IPv6

79

Figura B.2 Diagrama configuración "dual-stack" de VLANs en

85

Figura D.1 Escenario para pruebas de vulnerabilidades

90

Í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

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

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

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

44

Tabla 6.1 Soporte IPv6 en sistemas operativos utilizados en la red UTFSM

46

Tabla 6.2 Soporte IPv6 aplicaciones uso

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

57

Tabla 7.3 Cálculo teórico transmisión archivo de 734.271

58

Tabla 7.4 Resultados prueba transmisión

59

Tabla A.1 Códigos campo “Unidad” direcciones IPv6 Casa Central

77

Tabla B.1 Configuración gw-border

80

Tabla B.2 Comandos IOS para diagnóstico de equipo

81

Tabla B.3 Reglas implícitas en una ACL

82

Tabla B.4 Configuración equipo fw-primary

83

Tabla B.5 Configuración interfaz VLAN Catalyst

85

Tabla C.1 Configuración IPv6 de una

86

Tabla C.2 Configuración demonio snmpd

86

Tabla C.3 Creación archivos

87

Tabla C.4 Configuración

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

90

Tabla D.2 Tabla de rutas inicial PC 1

91

Tabla D.3 Configuracion "router" Cisco 2811

91

Tabla D.4 Archivo de configuración de NDPMON (extracto)

91

Tabla D.5 Ataque de falsificación de

92

Tabla D.6 Configuración interfaz PC 1 tras

92

Tabla D.7 Tabla de rutas PC 1 tras ataque

92

Tabla D.8 Alerta generada por NDPMON durante el

92

Tabla D.9 Ataque de resolución de

93

Tabla D.10 Tabla de vecinos PC 1 tras

93

Tabla D.11 Alerta generada por NDPMON durante el

93

Tabla D.12 Ataque de detección de direcciones duplicadas

93

Tabla D.13 Tabla de vecinos PC 1 tras

94

Tabla D.14 Alerta generada por NDPMON durante el

94

Tabla D.15 Ataque de

94

Tabla D.16 Tabla de vecinos PC 1 tras

95

Tabla D.17 Alerta generada por NDPMON durante el

95

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]

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.

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.

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

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

Entidad a cargo

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 la Figura 2.1 se observa la distribución actual 1 de bloques /8.

RIPENCC

Bloques Reservados

Bloques Libres

LACNIC

Empresas

ARIN

APNIC

AFRINIC

30

30

 
35

35

39

39

7

7

42

42

 
68

68

32

32

 
3

3

0

10

20

Número de bloques /8 asignados

60

40

30

50

70

80

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 Datos al 20/09/2008 2 Esta regla sólo se puede utilizar una vez en una dirección IPv6, de lo contrario el sistema no sabría

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 aquellos bloques asignados que no son anunciados (“Unadvertised”).

asignados que no son anunciados (“Unadvertised”). Figura 2.2 Proyección del agotamiento de bloques /8.

Figura 2.2 Proyección del agotamiento de bloques /8. Fuente: “IPv4 Address Report”.

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.

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:

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

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.

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.

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ítulo 2.

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·10 38 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

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.

IPv6 La Figura 3.1 muestra la estructura de un paquete IPv6. Figura 3.1 Estructura de un

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

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”): Incluye 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 routerque reenvía el paquete. Si el valor llega a cero, el paquete es descartado.

Dirección de origen (“Source Destination Address”): Indica la dirección IPv6 del nodo que generó el paquete.

Dirección de origen (“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.

Figura 3.2 Cambios en la cabecera de los paquetes IPv6. El protocolo IPV6 reemplazó el

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

es

2001:0000:1234:0000:0000:C1C0:ABCD:0876.

Un

ejemplo

de

dirección

IPv6

válida

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

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 <dirección>/<prefijo>. 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.

“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 de 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-local 3 ”): 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”).

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.

El contexto global es el más amplio, englobando al resto. Figura 3.3 Contextos de direcciones “unicast”.

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:<identificador de interfaz>”‟. El identificador de interfaz se genera automáticamente a partir de su dirección MAC, siguiendo el formato EUI-64. En la Figura 3.4 se detalla cómo se construye el identificador de interfaz IPv6 a partir de la dirección MAC.

Figura 3.4 Creación del identificador de interfaz. Las direcciones locales al enlace permiten proveer de

Figura 3.4 Creación del identificador 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 IPv4 4 , 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.

hacia Internet. Su estructura se detalla en la Figura 3.5. Figura 3.5 Estructura de una dirección

Figura 3.5 Estructura de una dirección local única.

4 Bloques 10/8, 172.16/12 y 192.168/16.

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 2 16 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 a las 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 /64 5 . 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 interfaz de un determinado nodo. En la Figura 3.6 se observa la estructura de una dirección unicast global.

se observa la estructura de una dirección unicast global. Figura 3.6 Estructura de una dirección “unicast”

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.

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 la Figura 3.7 se presenta la estructura utilizada actualmente para la delegación de prefijos.

utilizada actualmente para la delegación de prefijos. Figura 3.7 Jerarquía de 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 por 2 16 subredes, cada una con capacidad para conectar hasta 2 64 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 la Figura 3.8

“multicast” tienen la estructura presentada en la Figura 3.8 Figura 3.8 Estructura direcciones “multicast”. 22

Figura 3.8 Estructura direcciones “multicast”.

El campo L indica el tiempo de vida de un grupo multicast, tomando el valor de 0 cuando es un grupo permanente y 1 cuando es 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])

Contexto del grupo

1

Interfaz

2

Enlace

5

Sitio

8

Organización

E

Global

Otros valores

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 la Tabla 3.2 se muestran algunos de los grupos multicast fijos existentes.

Tabla 3.2 Direcciones de grupos "multicast" fijos.

Dirección Multicast

Descripción

FF01::1

Todos los nodos en la interfaz

FF02::1

Todos los nodos en el enlace

FF01::2

Todos los routers en la interfaz

FF02::2

Todos los routers en el enlace

FF05::2

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.

consultar y posee la estructura descrita en la Figura 3.9. Figura 3.9 Estructura dirección "multicast" de

Figura 3.9 Estructura dirección "multicast" de nodo solicitado

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

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 la Tabla 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

Dirección multicast de nodo solicitado

2800:270:bcd0:3::1

ff02::1:ff00:1

2800:270::1230:1000:a34:9e9a

ff02::1:ff34:9e9a

2800:270::34de:2000:a34:9e9a

ff02::1:ff34:9e9a

fc00:0:0:1::aaaa:a1

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 anycastes 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 origen 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 routeruna ruta directa hacia dicha dirección (/128). La idea es que cada routerposea 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 anycastpermite 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.

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 la Tabla 3.4 se presentan las nuevas versiones desarrolladas para IPv6.

Tabla 3.4 Protocolos de enrutamiento en IPv6

Protocolo enrutamiento

Versión IPv6

RIP

RIPng

EIGRP

EIGRP para IPv6

OSPF

OSPFv3

IS-IS

Integrated IS-IS

BGP

BGP-MP

EIGRP

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

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. En la 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

Descripción

Equivalente IPv4

Descubrimiento de “routers”

Permite a los dispositivos detectar a los “routers” presentes en el enlace.

ICMP Router Discovery

Descubrimiento de prefijo

Permite a los nodos conocer el prefijo utilizado en el enlace.

No disponible

Descubrimiento de parámetros

Permite a los nodos auto configurar parámetros como MTU o número máximo de saltos.

PMTU Discovery

Autoconfiguración de direcciones

Permite a los dispositivos auto

No disponible

configurar su propia

dirección.

Resolución de direcciones

Permite a los nodos determinar las direcciones capa 2 de los dispositivos presentes en el enlace.

ARP

Determinación próximo salto

Permite a los nodos determinar el próximo salto para un destino dado.

Tabla ARP y/o tabla de enrutamiento en los dispositivos.

Detección de vecinos inalcanzables(NUD)

Detecta si se puede alcanzar un determinado nodo.

Dead Gateway Detection

Detección de direcciones duplicadas (DAD)

Permite a los nodos determinar si una dirección está en uso.

ARP con origen=0

Redirección

Permite a los “routers” informar a 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

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 routerspresentes 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 routersperiódicamente al enlace (mensajes RA) o puede solicitar un anuncio, enviando un mensaje de solicitació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.

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

DHCPv6

Mensaje de reconfiguración

No disponible

Permite a los servidores solicitar a los clientes que actualicen su información.

Dirección de destino de la

Dirección Broadcast

Grupo multicast que agrupa a todos los servidores DHCP.

solicitud DHCP de un

cliente

Dirección de origen en la solicitud DHCP.

0.0.0.0

Dirección local de enlace del nodo.

Asociación de identidad

No disponible

Los clientes pueden solicitar información a varios servidores DHCPv6 y obtener múltiples direcciones.

Etiqueta de configuración asistida

No disponible

Un “router” puede anunciar a 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 origen 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

cabecera IPv4, se utiliza una cabecera adicional para indicar que el contenido del paquete es un fragmento.

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 “backbonede 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.

Figura 4.1 Topología simplificada Red UTFSM (11/2008). Los equipos campus-gw y fibra-gw se encuentran conectados

Figura 4.1 Topología simplificada Red UTFSM (11/2008).

Los equipos campus-gw y fibra-gw se encuentran conectados a través del switchsw-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

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.

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 routerque 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 la Tabla 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

Función(es)

¿Soporta

Acción a realizar

IPV6?

Cisco

Actualizar IOS a una versión superior a la 12.2R.

7204VXR

Gw-Border

Sí

Cisco

Catalyst

Sw-border

No

Reemplazar Equipo.

2950T

Cisco

Nacional-gw

No

Reemplazar Equipo.

Catalyst 3550

campus-gw

Cisco

Admin-gw, Gateway de sedes y campus

 

Si se desea utilizar enrutamiento IPv6, se requiere utilizar la serie “Advanced IP Services” del sistema IOS.

Catalyst 3560

Cisco PIX

Firewall Primary

Sí

Actualizar PIX OS a una versión superior a la 7.0.

525

Firewall

Secundary

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-secundary fueron 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

Versión OS

 

Cantidad

 

Cisco ASA Software Versión

 

ASA 5520

Reemplazo PIX 525

8.0

2

Catalyst 3750G

Reemplazo Catalyst

CISCO IOS 12.2(44)SE

 

3

 

3550

Catalyst 2960G

Reemplazo Catalyst

CISCO IOS 12.2(44)SE

 

1

 

2950T

 

Tabla 4.3 Propuesta Juniper.

 
 

Equipos

Función

Versión OS

Cantidad

 

SSG-550M

Reemplazo PIX 525

SCREENOS 6.1

2

EX3200-48T

Reemplazo Catalyst 3550

JUNOS for EX Series 9.1

3

EX3200-24T

Reemplazo Catalyst 2950T

JUNOS for EX Series 9.1

1

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

Equipo

Características IPv6

 

Provee control de acceso y servicios de firewall para ambientes de redes nativos IPv6 y mixtos (IPv4 & IPv6).

ASA 5520

Entrega servicios de inspección para aplicaciones basados en HTTP, FTP, SMTP, ICMP, UDP y TCP.

Permite la administración remota desde SSHv2, Telnet, HTTP, HTTPS e ICMP corriendo sobre IPv6.

 

Enrutamiento estático.

Descubrimiento de máximo MTU.

Protocolo de descubrimiento de vecinos.

BPG4-MP, EIGRP, OSPFv3 y RIPng.

Catalyst 3750 y Catalyst 2960

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 Juniper

Equipo

Características IPv6

 

Enrutamiento estático y RIPng

DHCPv6

SSG-550M

Túneles IPSec+Ipv6.

PPPoE

NAT-PT

Radius

Equipo

Características IPv6

 

Protocolo de descubrimiento de vecinos.

ICMPv6

EX-3200 y

EX-4200

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 original. 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 la Tabla 4.6 se

presenta un cuadro resumen de las principales diferencias entre ambos sistemas operativos.

Tabla 4.6 Comparación entre IOS y JUNOS.

Juniper JUNOS

Cisco IOS

Creado en 1996

Creado en 1987

Ultima versión principal: 9.0

Ultima versión principal: 12.4

Arquitectura Modular

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

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.

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ítulo 4, 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. La Tabla 5.1 muestra los equipos reemplazados.

Tabla 5.1 Equipos reemplazados en la red institucional.

Nombre equipo

Equipo original

Equipo de reemplazo

Sw-border

Catalyst 2950T

Catalyst 2960G

Firewall primary

Pix 525

ASA 5520

Firewall secondary

Pix 525

ASA 5520

Sw-inside

Catalyst 2950T

Catalyst 3750

Fibra-gw

Catalyst 3550

Catalyst 3750

Campus-gw

Catalyst 3550

Catalyst 3750

Sw-wifi

Catalyst 2950T

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” que 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 la Figura 5.1 se muestra la nueva topología simplificada de la red institucional de la UTFSM.

Figura 5.1 Topología simplificada Red UTFSM (04/2009) 5.2. Conexión a Internet mediante IPv6 5.2.1. Selección

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

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ón 3.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.

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 activo, es decir, que está correctamente anunciado en la tabla de enrutamiento global 6 .

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.

en el acceso a IPv6, tal como se muestra en la Figura 5.2. Figura 5.2 “

Figura 5.2 Multihoming” con espacio direccionamiento independiente.

los

http://www.sixxs.net/tools/grh/dfp/lacnic/

6

La

lista

de

prefijos

delegados

por

LACNIC

y

su

estado

se

pueden

ver

en

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 campus- gw, 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)

Tamaño campo

32[bit]

8[bit]

8[bit]

16[bit]

64[bit]

Prefijo

/32

/40

/48

/64

/128

 

Tabla 5.3 Detalle campos direcciones IPv6 UTFSM

 

Campo

Descripción

 

Valores establecidos

Campus

Identifica el campus o sede

 

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

Unidad

Identifica a la unidad administrativa o departamento al interior de un campus/sede

Ver valores en anexo A.

Red

Especifica una red administrada por un departamento/unidad administrativa

Dispositivo

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 contar con 65356 redes de 1,18x10 19 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 homogénea de ellas, se presenta en la el número de direcciones IPv6 disponibles 7 .

Tabla 5.4 Número de direcciones IPv6 disponibles en la UTFSM.

Direcciones IPv6 en total

7,92282 x10 28

Direcciones IPv6 por m 2

2,09545 x10 23

Direcciones IPv6 por persona (alumnos, profesores y administrativos)

5,24933 x10 24

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

http://www.utfsm.cl/universidad/cifras.html

2008

disponibles

en

Figura 5.3 Diagrama configuración equipos UTFSM. En el anexo B se encuentran detalladas las configuraciones

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.

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

Soporte IPv6

Observaciones

Windows 7

Windows Vista

Windows XP

Ver sección 6.1.1

Windows 2003

Ver sección 6.1.1

Sistema Operativo

Soporte IPv6

Observaciones

Windows 2000

No

Soporte parcial a través de software adicional

Windows 95/98/NT

No

Soporte parcial a través de software adicional

Linux

Desde kernel 2.2

FreeBSD

Desde versión 4

Solaris

Desde versión 8

Mac OSX

Desde versión 10.2

Symbian OS

Desde la versión 7.0

Iphone (Mac OSX)

No

Windows Mobile (Windows CE)

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

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 de IPv6 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

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.

 

Primera

Aplicación

¿Soporta

IPv6?

versión con

soporte IPv6

Notas

Explorer

Si

4.01

En versiones anteriores a la 7.0 no se puede especificar directamente una dirección IPv6, es necesario el apoyo de un servidor DNS.

Firefox

Si

1.5

Windows

Soporta uso directo de direcciones IPv6 para configurar cuentas de correo

Mail

Si

Outlook

Si

2003

Soporta uso directo de direcciones IPv6 para configurar cuentas de correo.

Outlook

Express

No

Usar Windows Mail.

Thunderbird

Si

No se puede especificar directamente una dirección IPv6, es necesario el apoyo de un servidor DNS.

Winamp

Si

5.34

VLC

Si

Windows

Media

Si

9.0

Player

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 la Tabla 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 AAAAque 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

agregar los correspondientes registros en el archivo de zona. En la Tabla 6.4 se muestra un ejemplo de ello.

Tabla 6.4 Ejemplo de un sitio asociado a direcciones IPv4 e IPv6

Nombre

Tipo de Registro

Valor

prueba.utfsm.cl

A

200.16.32.2

prueba.utfsm.cl

AAAA

2800:270:a3c4::2

prueba.utfsm.cl

AAAA

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

Tipo de Registro

Valor

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.0.

0.0.0.0.e.f.f.3.ip6.arpa

PTR

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 SNMP 8 , 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.

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.

que especifican contadores independientes para IPv4 e IPv6. Figura 6.1 Evolución de MIBs unificadas En el

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-IETF- IP-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

este trabajo, no existe la posibilidad de actualizar el sistema operativo para implementar MIBs basadas en los estándares más actuales 9 .

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 en C 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.

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.

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.

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]

 

IPv4

IPv6

IPv4

IPv6

Datos (“payload”) [byte]

44

24

1480

1460

Cabecera IP [byte]

20

40

20

40

Total Paquete IP[byte]

64

64

1500

1500

Overhead IP 10 [%]

44%

62.5%

1,3%

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

7.2.

Desempeño en servidor Apache

Se armó el escenario de pruebas descrito en la Figura 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.

2.3, el cual permite medir el desempeño de un servidor web. Figura 7.1 Escenario de pruebas

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 concurrencia 11 de 10. Los resultados obtenidos se muestran en la Tabla 7.2.

Tabla 7.2 Resultados prueba servidor Web.

 

IPv4

IPv6

Variación %

Tiempo total utilizado [s]

23.374

28.999

+24.06 %

Solicitudes/segundo atendidas

4278.32

3448.34

- 19,4%

Tiempo medio por solicitud [ms]

2.337

2.9

+24.06%

Promedio uso CPU servidor [%]

84.96

89.93

+5.8%

Se observa que el rendimiento obtenido por IPv6 es inferior al obtenido por IPv4. Tal como se menciona en la sección 7.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.

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 la Figura 7.2.

IPv6, se configuró el escenario mostrado en la Figura 7.2. Figura 7.2 Escenario de pruebas servidor

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

IPv4

IPv6

Tamaño Paquete [byte]

1500

1500

Datos contenidos 12

1460

1440

Nº paquetes generados

502926

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 la Tabla 7.4.

12 El total de datos contenidos corresponde al tamaño del paquete menos el “overhead” IP +TCP

Tabla 7.4 Resultados prueba transmisión FTP.

Medición

IPv4

IPv6

Variación %

Tráfico Servidor ->PC 1 [Mbyte]

765.464

774.135

+ 1.13%

Tráfico Servidor ->PC 1 [paquetes]

511067

527809

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

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ía utilizado 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

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,18x10 19 . 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 pinga la dirección multicastque representa a todos los nodos o a todos los routersconectados 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

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 la Figura 8.1 se observa como el “router” anuncia su presencia y permite a los equipos PC 1 y PC 2 configurar sus propias direcciones.

a los equipos PC 1 y PC 2 configurar sus propias direcciones. Figura 8.1 Configuración automática

Figura 8.1 Configuración automática de direcciones.

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 la Figura 8.2.

red sería descartado, tal como se indica en la Figura 8.2. Figura 8.2 Ejemplo de ataque

Figura 8.2 Ejemplo de ataque basado en configuración automática de direcciones.

Para ejecutar este ataque, se puede utilizar la herramienta “fake_router6incluida 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 del router” 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:

a) Se envía un mensaje de solicitud de vecino (”Neighbor 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).

”, NA) , que contiene su dirección física (MAC). Figura 8.3 Procedimiento de resolución de direcciones

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.

Para ejecutar este ataque, se puede utilizar la herramienta fake_advertise6incluida 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.

su solicitud de solicitud de vecino, impidiendo su uso. Figura 8.4 Ejemplo de ataque basado en

Figura 8.4 Ejemplo de ataque basado en la detección de direcciones duplicadas.

Para ejecutar este ataque, se puede utilizar la herramienta “dos-new-ip6incluida 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.

primer salto. En la Figura 8.5 se observa cómo opera dicho procedimiento. Figura 8.5 Procedimiento de

Figura 8.5 Procedimiento de redirección.

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 original 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 la 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 la Figura 8.6.

Figura 8.6 Generación de una dirección CGA. SeND agrega parámetros adicionales a los mensajes del

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.

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

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 anexo D), 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).

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 UTFSM. La red permite conectar a las distintas unidades administrativas y departamentos directamente a Internet mediante IPv6, sin necesidad de utilizar túneles o traducción de protocolos.

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 de actualizar o implementar una red IPv6. Se descubrió que muchos fabricantes anuncian soporte IPv6 en sus productos, pero en la realidad dicho soporte es parcial o se incluirá en futuras actualizaciones. En 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

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 es