Source: https://ru.scribd.com/document/89910065/ImplementacionIpv6-UTFSM-proyecto
Timestamp: 2020-08-12 08:17:53+00:00

Document:
ImplementacionIpv6_UTFSM_proyecto | Protocolos de internet | Yo Pv6
сохранитьСохранить «ImplementacionIpv6_UTFSM_proyecto» для последующего чтения
Apunte_EDO_para_MAT023_2_2011
PROFESORES CORREFERENTES :
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.
Felipe Ernesto Jara Saba. Memoria presentada como requisito parcial para optar al título de Ingeniero Civil Telemático.
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.
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.
2. La necesidad de IPv6
Problemas existentes en IPv4
2.1.1. Agotamiento direcciones IP
2.1.2. Problemas de arquitectura
Motivadores del cambio a IPv6
3. El protocolo IPv6
3.1. Características del protocolo IPv6
3.2. Estructura de un paquete IPv6
3.3. Formato de una dirección IPv6
3.4. Direccionamiento IPv6
3.4.1. Unicast
3.4.2. Direcciones “unicast” locales al enlace
3.4.3. Direcciones “unicast” locales únicas
3.4.4. Direcciones “unicast” Globales:
3.4.5. Multicast
3.4.6. Anycast
3.5. Algoritmos de Enrutamiento
3.6. ICMPv6
3.7. Mecanismos de configuración de direcciones
3.8. Fragmentación
4. Análisis red institucional y evaluación de alternativas
4.1. Red Institucional UTFSM
4.2. Mecanismos de implementación de redes IPv6
4.3. Análisis del soporte IPv6 en la red institucional
4.4. Alternativas de equipamiento
4.5. Comparación de alternativas de equipamiento
4.5.1. Soporte IPv6
4.5.2. Tecnologías y filosofía de
4.5.3. Costos de implementación y soporte
Diseño e Implementación de la red IPv6
5.1. Topología revisada de la red institucional UTFSM
5.2. Conexión a Internet mediante IPv6
5.2.1. Selección de un proveedor de servicios de Internet (ISP)
5.2.2. Obtención de un prefijo IPv6
5.3.1. Protocolo de enrutamiento externo
5.3.2. Protocolo de enrutamiento interno
5.4. Direccionamiento IPv6 en la UTFSM
5.5. Configuración equipos
6. Soporte IPv6 en sistemas operativos y aplicaciones
Soporte IPv6 en sistemas operativos
6.1.1. Sistemas operativos Windows
6.1.2. FreeBSD, OpenBSD y NetBSD
6.1.3. Linux
6.2. Soporte IPv6 aplicaciones uso común
6.3. Configuración de servidor IPv6 y servicios asociados
6.3.1. Servidor DNS (BIND)
6.3.2. Servidor Web (Apache)
6.3.3. Servicios de monitoreo y administración de Redes
7. Consideraciones de desempeño
7.1. Aspectos Teóricos
7.2. Desempeño en servidor Apache
7.3. Desempeño en servidor FTP
8. Seguridad en redes IPv6
8.1. Reconocimiento en redes IPv6
8.2. Vulnerabilidades en ICMPv6
8.2.1. Configuración automática de direcciones (SLACC)
8.2.2. Resolución de direcciones
8.2.3. Detección de direcciones Duplicadas (DAD)
8.2.4. Redirección
Protocolo SeND Secure Neighbor Discovery (SEND)
Mecanismos de seguridad en “switches”
8.3.3. Microsegmentación
8.3.4. NDPMon
9.2. Trabajo Futuro
9.2.1. Plan de actualización de la
9.2.2. Tecnologías y protocolos complementarios
Anexo A: Códigos direcciones IPv6 UTFSM
A.1. Casa Central
Anexo B: Configuración de equipos red IPv6
Configuración equipo border-gw
Configuración equipo firewall-primary
Configuración equipo sw-inside
Anexo C: Configuración de un servidor en una red IPv6
Anexo D: Pruebas de seguridad en una red IPv6
Figura 2.1 Distribución actual de bloques
Figura 2.2 Proyección del agotamiento de bloques /8
Figura 3.1 Estructura de un paquete IPv6
Figura 3.2 Cambios en la cabecera de los paquetes
Figura 3.3 Contextos de direcciones
Figura 3.4 Creación del identificador de
Figura 3.5 Estructura de una dirección local única
Figura 3.6 Estructura de una dirección “unicast”
Figura 3.7 Jerarquía de delegación de prefijos “unicast”
Figura 3.8 Estructura direcciones
Figura 3.9 Estructura dirección "multicast" de nodo solicitado
Figura 4.1 Topología simplificada Red UTFSM
Figura 5.1 Topología simplificada Red UTFSM (04/2009)
Figura 5.2 “Multihoming” con espacio direccionamiento
Figura 5.3 Diagrama configuración equipos
Figura 6.1 Evolución de MIBs unificadas
Figura 7.1 Escenario de pruebas servidor
Figura 7.2 Escenario de pruebas servidor
Figura 7.1 Configuración automática de
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
Figura 7.4 Ejemplo de ataque basado en la detección de direcciones
Figura 7.5 Procedimiento de
Figura 7.6 Generación de una dirección CGA
Figura B.1 Diagrama configuración equipos red IPv6
Figura B.2 Diagrama configuración "dual-stack" de VLANs en
Figura D.1 Escenario para pruebas de vulnerabilidades
Tabla 3.1 Códigos de contexto en una dirección “multicast”
Tabla 3.2 Direcciones de grupos "multicast" fijos
Tabla 3.3 Ejemplos direcciones “multicast” de nodo
Tabla 3.4 Protocolos de enrutamiento en IPv6
Tabla 3.5 Características protocolo descubrimiento de vecinos
Tabla 3.6 Diferencias entre DHCPv4 y DHCPv6
Tabla 4.1 Análisis equipos existentes Red Institucional UTFSM
Tabla 4.2 Propuesta
Tabla 4.3 Propuesta Juniper
Tabla 4.4 Características IPv6 equipos Cisco
Tabla 4.5 Características IPv6 equipos Juniper
Tabla 4.6 Comparación entre IOS y
Tabla 5.1 Equipos reemplazados en la red institucional
Tabla 5.2 Estructura direcciones IPv6 de la UTFSM
Tabla 5.3 Detalle campos direcciones IPv6 UTFSM
Tabla 5.4 Número de direcciones IPv6 disponibles en la
Tabla 6.1 Soporte IPv6 en sistemas operativos utilizados en la red UTFSM
Tabla 6.2 Soporte IPv6 aplicaciones uso
Tabla 6.3 Servicios instalados en servidor FreeBSD 7.1
Tabla 6.4 Ejemplo de un sitio asociado a direcciones IPv4 e IPv6
Tabla 6.5 Ejemplo de registro PTR para una dirección IPv6
Tabla 7.1 Calculo “overhead” paquetes IPv4 e IPv6
Tabla 7.2 Resultados prueba servidor
Tabla 7.3 Cálculo teórico transmisión archivo de 734.271
Tabla 7.4 Resultados prueba transmisión
Tabla A.1 Códigos campo “Unidad” direcciones IPv6 Casa Central
Tabla B.1 Configuración gw-border
Tabla B.2 Comandos IOS para diagnóstico de equipo
Tabla B.3 Reglas implícitas en una ACL
Tabla B.4 Configuración equipo fw-primary
Tabla B.5 Configuración interfaz VLAN Catalyst
Tabla C.1 Configuración IPv6 de una
Tabla C.2 Configuración demonio snmpd
Tabla C.3 Creación archivos
Tabla C.4 Configuración
Tabla C.5 Configuración named.conf
Tabla C.6. Archivo utfsm.cl.0.7.2.0.0.0.8.2.ip6.arpa.hosts
Tabla C.7 Archivo 0.7.2.0.0.0.8.2.ip6.hosts
Tabla C.8 Archivo /usr/local/etc/apache22/httpd.conf
Tabla D.1 Configuración inicial interfaz de red PC
Tabla D.2 Tabla de rutas inicial PC 1
Tabla D.3 Configuracion "router" Cisco 2811
Tabla D.4 Archivo de configuración de NDPMON (extracto)
Tabla D.5 Ataque de falsificación de
Tabla D.6 Configuración interfaz PC 1 tras
Tabla D.7 Tabla de rutas PC 1 tras ataque
Tabla D.8 Alerta generada por NDPMON durante el
Tabla D.9 Ataque de resolución de
Tabla D.10 Tabla de vecinos PC 1 tras
Tabla D.11 Alerta generada por NDPMON durante el
Tabla D.12 Ataque de detección de direcciones duplicadas
Tabla D.13 Tabla de vecinos PC 1 tras
Tabla D.14 Alerta generada por NDPMON durante el
Tabla D.15 Ataque de
Tabla D.16 Tabla de vecinos PC 1 tras
Tabla D.17 Alerta generada por NDPMON durante el
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.
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.
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
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.
Bloques Reservados
Número de bloques /8 asignados
Figura 2.1 Distribución actual de bloques /8.
En la Figura 2.1 se observa que la mayor parte de los bloques se encuentra asignado al registro regional ARIN, que distribuye direcciones a Canada, EE.UU. e islas del Noratlántico. Se puede apreciar que una parte importante de los bloques /8 se encuentran asignados directamente a empresas y organizaciones,quienes recibieron dichos bloques como producto de las politicas de asignación anteriores a 1993. Dentro de los grupos reservados, se encuentran los bloques asignados a direcciones IP privadas, tráfico “multicast” y otros usos aun no definidos. Los 39 bloques libres son manejados directamente por el IANA, quien los delega a cada registro regional de acuerdo a sus requerimientos.
1 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”).
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
 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.
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
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.
 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.
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.
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”.
La Figura 3.1 muestra la estructura de un paquete IPv6.
Figura 3.1 Estructura de un paquete IPv6.
Un paquete IPv6 tiene una cabecera de tamaño fijo e igual a 40 [byte], el doble de la cabecera IPv4. Este aumento se debe a que el tamaño de los campos “Source
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 “router” que 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 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).
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).
2001:0000:1234:0000:0000:C1C0:ABCD:0876.
Con el fin de simplificar la escritura y memorización de direcciones, se pueden aplicar las siguientes reglas a las direcciones IPv6.
a) No se hace distinción entre mayúsculas y minúsculas. “ABC9”‟ es equivalente a “abC9‟.
b) Los ceros al inicio de un campo son opcionales. “00c1” es equivalente a
“c1”.
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:
Mediante la regla a), se puede escribir como:
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].
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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
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])
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.
Todos los nodos en la interfaz
Todos los nodos en el enlace
Todos los routers en la interfaz
Todos los routers en el enlace
Todos los routers en el sitio
Dirección multicast de nodo solicitado Para realizar la asociación entre direcciones capa 2 (MAC) y direcciones IPv6, se utiliza la dirección “multicast” de nodo solicitado. Esta dirección contiene parte de la dirección IPv6 que se desea consultar y posee la estructura descrita en la Figura 3.9.
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.
2800:270:bcd0:3::1
2800:270::1230:1000:a34:9e9a
ff02::1:ff34:9e9a
2800:270::34de:2000:a34: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.
Una dirección “anycast” es aquella que identifica a un grupo de interfaces. Los paquetes enviados a una dirección anycast son reenviados por la infraestructura de enrutamiento hacia la interfaz más cercana al 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 “router” una ruta directa hacia dicha dirección (/128). La idea es que cada “router” posea en su tabla de enrutamiento varias entradas hacia la misma dirección, con sus métricas asociadas. Al fallar la ruta más cercana, se selecciona automáticamente la siguiente.
El uso de “anycast” permite entre otras cosas implementar balanceo de carga y tolerancia a fallas. Por lo general, su uso se suele restringir al contexto de un sitio o red local. Las direcciones “anycast”, al igual que las “multicast” solo son válidas como direcciones de destino en los paquetes IPv6.
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.
Versión IPv6
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
Equivalente IPv4
Descubrimiento de “routers”
Permite a los dispositivos detectar a los “routers” presentes en el enlace.
Descubrimiento de prefijo
Permite a los nodos conocer el prefijo utilizado en el enlace.
Permite a los nodos auto configurar parámetros como MTU o número máximo de saltos.
Permite a los dispositivos auto
configurar su propia
Permite a los nodos determinar las direcciones capa 2 de los dispositivos presentes en el enlace.
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”
Permite a los nodos determinar si una dirección está en uso.
ARP con origen=0
Permite a los “routers” informar a los nodos de un mejor próximo salto para una dirección en particular.
ICMPv4 Redirect
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 “routers” presentes en el enlace y generar una dirección IPv6 a partir del prefijo que estos anuncias. Los pasos que realiza un nodo para obtener una dirección son los siguientes:
 Descubrir un prefijo utilizado en el enlace: El nodo escucha los anuncios que envían los “routers” periódicamente al enlace (mensajes RA) o puede solicitar un anuncio, enviando un mensaje 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.
Mensaje de reconfiguración
Permite a los servidores solicitar a los clientes que actualicen su información.
Dirección de destino de la
Grupo multicast que agrupa a todos los servidores DHCP.
solicitud DHCP de un
Dirección de origen en la solicitud DHCP.
Dirección local de enlace del nodo.
Asociación de identidad
Los clientes pueden solicitar información a varios servidores DHCPv6 y obtener múltiples direcciones.
Etiqueta de configuración asistida
Un “router” puede anunciar a los nodos si es que está permitido el uso de DHCPv6.
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.
4.Análisis red institucional y evaluación de alternativas
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 “backbone” de fibra óptica multimodo (que comunica a los edificios internos del Campus) y equipamiento activo de comunicaciones, principalmente orientado al uso de “Fast Ethernet” (normas 100BaseTX y 100BaseFX). Los enlaces principales de unión de los equipos de distribución (acceso departamental) cuentan con enlaces “Gigabit Ethernet” (1000 [Mbps]).
En la Figura 4.1 se presenta la topología simplificada de la red institucional UTFSM al momento de realizar el análisis.
Figura 4.1 Topología simplificada Red UTFSM (11/2008).
Los equipos campus-gw y fibra-gw se encuentran conectados a través del “switch” sw-inside y utilizan el protocolo RIP para el intercambio de rutas. En conjunto, dichos equipos componen el núcleo de la red, manejando la configuración de las VLANS de la red y realizando el enrutamiento entre ellas y hacia el exterior de la red.
Dado que IPv6 es un protocolo capa 3, su uso es transparente para todos los dispositivos capa 2. Por ello, en este análisis no se consideran los “switches” de acceso que se encuentran a lo largo de las dependencias de la UTFSM. No se considera tampoco el equipo PacketShaper, ya que no se aplicarán políticas de calidad de servicio en el tráfico IPv6.
El objetivo de este análisis es la implementación de una red IPv6 que permita conectar a la Red LAN de la casa Central a Internet. De esta forma, los departamentos
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.
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 “router” que realiza la transformación de paquetes. Es más complejo que el tradicional protocolo NAT de IPv4, ya que es necesario modificar íntegramente cada paquete IPv4/IPv6. Solo se recomienda su uso como medida temporal, cuando no existe otra alternativa.
En la UTFSM ya se han realizado implementaciones de redes IPv6 mediante el uso de túneles [12] [13]. El objetivo de este trabajo es implementar una red que funcione nativamente en IPv6, sin requerir el uso de IPv4, utilizando la técnica de “dual stack”. De esta forma se evita depender de IPv4 para realizar la comunicación entre nodos, generando un escenario más realista respecto al futuro, cuando IPv6 sea el protocolo dominante en Internet.
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.
¿Soporta
Actualizar IOS a una versión superior a la 12.2R.
Gw-Border
Sw-border
Reemplazar Equipo.
Nacional-gw
campus-gw
Admin-gw, Gateway de sedes y campus
Si se desea utilizar enrutamiento IPv6, se requiere utilizar la serie “Advanced IP Services” del sistema IOS.
Firewall Primary
Actualizar PIX OS a una versión superior a la 7.0.
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.
Cisco ASA Software Versión
Reemplazo PIX 525
Reemplazo Catalyst
Tabla 4.3 Propuesta Juniper.
SCREENOS 6.1
Reemplazo Catalyst 3550
JUNOS for EX Series 9.1
Reemplazo Catalyst 2950T
Comparación de alternativas de equipamiento
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.
 Provee control de acceso y servicios de firewall para ambientes de redes nativos IPv6 y mixtos (IPv4 & IPv6).
 Entrega servicios de inspección para aplicaciones basados en HTTP, FTP, SMTP, ICMP, UDP y TCP.
 Permite 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.
 Enrutamiento estático y RIPng
 DHCPv6
 Túneles IPSec+Ipv6.
 PPPoE
 NAT-PT
 Radius
 ICMPv6
EX-3200 y
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.
Ultima versión principal: 9.0
Ultima versión principal: 12.4
Arquitectura monolítica (en proceso de cambio a arquitectura modular)
Misma versión corre en todos los equipos. (Excepto en “firewalls”)
Distintas versiones disponibles para cada equipo Cisco
Cabe destacar que ambas empresas han anunciado planes para permitir que aplicaciones desarrolladas por terceros tengan acceso a los servicios otorgados por sus sistemas operativos.
Si bien ambos sistemas implementan el mismo conjunto de protocolos y estándares utilizados en redes IP, Cisco destaca por estar constantemente actualizando sus sistemas operativos con herramientas y protocolos propios, que facilitan la configuración y administración de sus dispositivos. Dentro de dichos protocolos destacan “NetFlow”, “Hot Standby Router Protocol” (HSRP) y “VLAN Trunking Protocol” (VTP),
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.
5.Diseño e Implementación de la red IPv6
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.
Firewall secondary
Sw-inside
Fibra-gw
Sw-wifi
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.
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.
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
Dado que la UTFSM obtuvo un espacio de direccionamiento IPv6 independiente un ISP (prefijo /32), es necesario configurar un protocolo que permita anunciar la red IPv6 UTFSM hacia Internet.
El protocolo utilizado es BGP4-MP, definido en [19]. Dicho protocolo es usado en la red institucional UTFSM para anunciar la red IPv4 de la UTFSM hacia los proveedores Global Crossing y Telmex, por lo que ya se cuenta con un número de unidad autónoma (ASN). El uso de BGP4-MP permite en un futuro implementar “multihoming” en el acceso a IPv6, tal como se muestra en la Figura 5.2.
Figura 5.2 “Multihoming” con espacio direccionamiento independiente.
http://www.sixxs.net/tools/grh/dfp/lacnic/
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.
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.
Prefijo UTFSM
Dispositivo (Interfaz)
32[bit]
8[bit]
16[bit]
64[bit]
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
Identifica a la unidad administrativa o departamento al interior de un campus/sede
Ver valores en anexo A.
Especifica una red administrada por un departamento/unidad administrativa
Identifica a un dispositivo (interfaz) al interior de una red IPv6
::1 : Puerta de enlace (“Gateway”) de cada red
Esta política de asignación de direcciones permite a cada unidad administrativa 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.
En la Figura 5.3 se observa las direcciones IPv4 e IPv6 asignadas a los equipos de la red institucional de la UTFSM.
http://www.utfsm.cl/universidad/cifras.html
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.
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.
Ver sección 6.1.1
Soporte parcial a través de software adicional
Desde kernel 2.2
Desde versión 4
Desde versión 8
Desde versión 10.2
Desde la versión 7.0
Iphone (Mac OSX)
Desde versión 2003
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.
 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
 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.
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.
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.
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.
En versiones anteriores a la 7.0 no se puede especificar directamente una dirección IPv6, es necesario el apoyo de un servidor DNS.
Soporta uso directo de direcciones IPv6 para configurar cuentas de correo
Soporta uso directo de direcciones IPv6 para configurar cuentas de correo.
Usar Windows Mail.
No se puede especificar directamente una dirección IPv6, es necesario el apoyo de un servidor DNS.
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]”.
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.
2.2.9 y 1.3.41
BIND permite el uso indistinto de IPv4 ó IPv6 como protocolo de comunicación (capa 3) para realizar consultas al servidor DNS. El protocolo utilizado es independiente del tipo de consulta realizada: se pueden consultar por direcciones IPv4 utilizando IPv6 y viceversa.
Respecto a la resolución de nombres a direcciones IPv6, existe el registro “AAAA” que es el equivalente directo al registro “A” utilizado en IPv4. Un nombre de host puede estar asociado a una dirección IPv4 y/o a varias direcciones IPv6, basta con
agregar los correspondientes registros en el archivo de zona. En la Tabla 6.4 se muestra un ejemplo de ello.
prueba.utfsm.cl
200.16.32.2
2800:270:a3c4::2
3ffe:b00:0:1::1
Para la resolución inversa de direcciones IPv6, se utiliza el mismo registro PTR utilizado en IPv4. Para construir la parte izquierda del registro, se ingresa cada digito hexadecimal de la dirección IPv6, separándolos por un punto. A esta dirección se agrega el nombre de dominio superior “ip6.arpa”. En la Tabla 6.5 se ve un ejemplo para la dirección 3ffe:b00:0:1::1.
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
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.
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.
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.
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.
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]
Datos (“payload”) [byte]
Cabecera IP [byte]
Total Paquete IP[byte]
Overhead IP 10 [%]
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
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.
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.
Tiempo total utilizado [s]
Solicitudes/segundo atendidas
Tiempo medio por solicitud [ms]
Promedio uso CPU servidor [%]
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.
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.
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.
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].
Tamaño Paquete [byte]
Datos contenidos 12
Nº paquetes generados
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.
Tráfico Servidor ->PC 1 [Mbyte]
774.135
Tráfico Servidor ->PC 1 [paquetes]
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.
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.
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.
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 “ping” a la dirección “multicast” que representa a todos los nodos o a todos los “routers” conectados a dicha red (FF02::1 y FF02::2 respectivamente). De acuerdo a las especificaciones de IPv6, un nodo no debería responder a pings enviados a dichas direcciones, sin embargo varias implementaciones no han tomado en cuenta dicha recomendación.
Existen varias recomendaciones para evitar los problemas asociados al reconocimiento local o remoto de una red. La principal es que los identificadores de interfaz de los nodos no sean números correlativos y que no partan desde el límite inferior del rango (evitar las secuencias ::1, ::2, ::3, etc.). Esto se puede lograr mediante el uso de la autoconfiguración de direcciones IPv6, ya que es posible obligar a los nodos generar un identificador de interfaz pseudo-aleatorio o basado en la dirección física de la interfaz.
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.
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.
Figura 8.2 Ejemplo de ataque basado en configuración automática de direcciones.
Para ejecutar este ataque, se puede utilizar la herramienta “fake_router6” incluida en el paquete THC IPv6. Dicha herramienta permite enviar anuncios de enrutamiento en donde se puede definir el prefijo a anunciar y la dirección de enlace local 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.
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).
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_advertise6” incluida en el paquete THC IPv6. Dicha herramienta permite enviar mensajes de anuncio de vecino en donde se puede definir la dirección IPv6 a anunciar, la dirección MAC asociada y el destinatario de los mensajes (normalmente se utiliza la dirección ff02::1 que identifica a todos los nodos IPv6 en un enlace) .
El mecanismo de detección de direcciones duplicadas previene que dos nodos utilicen la misma dirección IPv6 en un enlace. Cada vez que un nodo desea utilizar cualquier tipo de dirección IPv6, envía un mensaje de solicitud de vecino preguntando por la dirección física de dicha dirección. Si no obtiene respuesta, significa que dicha dirección no está siendo utilizada actualmente, por lo que puede usarla sin problemas.
Al no existir autenticación, un atacante podría fácilmente realizar un ataque de denegación de servicio (DoS) pretendiendo poseer todas las direcciones IPv6 posibles. Cada vez que un nodo desea utilizar una dirección IPv6, el atacante responde su solicitud de solicitud de vecino, impidiendo su uso.
Figura 8.4 Ejemplo de ataque basado en la detección de direcciones duplicadas.
Para ejecutar este ataque, se puede utilizar la herramienta “dos-new-ip6” incluida en el paquete THC IPv6. Dicha herramienta responde a todos los mensajes de solicitud de vecinos que se reciben en una determinada interfaz, independiente de la dirección IPv6 consultada. De esta forma, el resto de los nodos presentes en el enlace no pueden utilizar ninguna nueva dirección IPv6.
La redirección es un mecanismo basado en ICMPv6 que permite a un “router” informar a otros nodos de un enlace la existencia de un mejor primer salto para llegar a una dirección o red determinada. Cuando un “router” recibe un paquete, revisa su tabla de rutas y si encuentra que existe un mejor primer salto envía un mensaje de redirección al nodo que envió el paquete. El nodo al recibir un mensaje de redirección, actualiza su tabla de rutas y envía el paquete al nuevo primer salto. En la Figura 8.5 se observa cómo opera dicho procedimiento.
Figura 8.5 Procedimiento de redirección.
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 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.
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
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).
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

References: Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución