Memoria presentada como requerimiento parcial para optar al título profesional de INGENIERO CIVIL EN INFORMÁTICA por Yonathan Helmuth Dossow Acuña

Transcripción

1 UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA DEPARTAMENTO DE INFORMÁTICA VALPARAÍSO, CHILE PROPUESTA DE MIGRACIÓN A IPV6 PARA LA UTFSM Memoria presentada como requerimiento parcial para optar al título profesional de INGENIERO CIVIL EN INFORMÁTICA por Yonathan Helmuth Dossow Acuña Comisión Evaluadora: Mg. Javier Cañas Dr. Horst von Brand JUNIO 2014

2

3 UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA DEPARTAMENTO DE INFORMÁTICA VALPARAÍSO, CHILE TÍTULO DE LA MEMORIA: PROPUESTA DE MIGRACIÓN A IPV6 PARA LA UTFSM AUTOR: YONATHAN HELMUTH DOSSOW ACUÑA Memoria presentada como requerimiento parcial para optar al título profesional de Ingeniero Civil en Informática de la Universidad Técnica Federico Santa María. Profesor Guía Mg. Javier Cañas Profesor Correferente Dr. Horst von Brand Junio Valparaíso, Chile. I

4

5 Dedicado a mi esposa, quien me ha acompañado durante estos años por esta travesía, y a mis padres por el apoyo incondicional que me han entregado. III

6

7 Índice general Índice de Figuras IX 1. Introducción Identificación del problema Objetivos Estado del Arte IPv Direccionamiento Fragmentación Encabezados Limitaciones de IPv IPv Direccionamiento DNS Encabezados Fragmentación Mejoras sobre IPv Métodos de transición IPv6 sobre IPv IPv4 sobre IPv Dual Stack Uso actual de IPv Uso de IPv6 en el mundo V

8 IPv6 en la UTFSM Soporte IPv6 en Aplicaciones Implementación de IPv Acceso a IPv Asignación de Números IPv Asignación estática de direcciones Asignación dinámica de direcciones Descripción de la red del Departamento de Informática Redes IPv Acceso a IPv6 desde redes de usuarios Implementación de Servicios en Dual Stack Servicios Web: Apache HTTPD Bases de Datos Servicios Correo Electrónico Servicios de apoyo Pruebas y Resultados Uso de IPv6 dentro de las redes UTFSM Servicios sobre IPv Soporte de IPv6 en Aplicaciones Estabilidad de servicios y redes IPv Impacto en usuarios Servicios Críticos Recomendaciones Conclusiones Sobre la implementación Conclusiones Generales Trabajo Futuro Apéndices 61 VI

9 A. Asignación Dinámica de Direcciones 63 A.1. Configuración de DHCPv A.2. Configuración de radvd B. Configuración Apache HTTPD 69 B.1. Script que automatiza modificación de VirtualHosts C. Configuración de MySQL 71 C.1. Instalación de Mysql C.2. Migración desde MySQL 5.1 a C.3. Permitir acceso a Bases de datos desde clientes IPv D. Configuración de PostgreSQL 75 D.1. Archivo de control de acceso pg hba.conf E. Configuración de Postfix 77 E.1. Archivo de configuración main.cf F. Configuración de Zimbra 81 F.1. Habilitar ambos protocolos en zimbra F.2. Modificar redes de confianza G. Configuración rbldnsd 83 G.1. Compilación de rbldnsd con soporte IPv G.2. Configuración de rbldnsd G.3. Access List con IPv G.4. Ejemplo Lista negra IPv H. Configuración servicio DNS 89 H.1. Configuración Bind H.2. Ejemplo Zona con registros IPv H.3. Ejemplo Zona reversa IPv I. Configuración del servidor LDAP 389-ds 95 I.1. Control de acceso sobre IPv VII

10 I.2. Creación acuerdo de réplica sobre IPv J. Configuración de NTP 97 K. Red Hat Enterprise Virtualization 99 K.1. Configuración guest Bibliografía 101 VIII

11 Índice de figuras 2.1. Redes con distintos máximos de transmisión Encabezados paquete IPv Encabezados paquete IPv Acceso a IPv6 mediante Túnel sobre redes IPv Acceso a IPv6 mediante 6rd Acceso a IPv4 mediante NAT64/DNS Asignación de IPv6 manteniendo ultimo octeto de IPv Asignación de IPv6 utilizando la dirección IPv4 completa como identificador de host Redes dentro del Departamento de Informática Arquitectura Sistema de correo UTFSM Pasos para consulta DNS por el registro Control de acceso de clientes LDAP sobre IPv Control de acceso de clientes LDAP sobre IPv Entrada de texto limitada solo a IPv Vista de direcciones IP que reporta el agente de RHEV Tráfico Internet, comparación entre IPv4 e IPv Gráfico de uso de ancho de Banda hacia redes IPv6 durante un año Gráfico de uso de ancho de Banda hacia redes IPv4 durante un año Gráfico conexiones a servidor de correo durante último mes Gráfico accesos a portal DI durante último mes Ejemplo de IPv6 funcionando mejor que IPv IX

12

13 Capítulo 1 Introducción 1.1. Identificación del problema Las redes de Internet históricamente han hecho uso de la cuarta versión del Protocolo de Internet 1 también llamado IPv4. Este protocolo fue creado en los años 80[50], y fue el primero en ser ampliamente usado. En la especificación de IPv4, las direcciones IP son de 32 bits, lo cual permite un máximo de direcciones IP, de las cuales se debe descontar las direcciones reservadas (privadas, multicast, link local, etc), quedando una menor cantidad para el usuario final. En los primeros tiempos de Internet, 4 mil millones 2 de direcciones IP eran más que suficientes. Lo que permitió a las redes de Internet crecer a gran velocidad, más de lo que inicialmente estaba considerado, provocando que, actualmente las direcciones IP disponibles estén prácticamente agotadas. El agotamiento de direcciones IP se ha mitigado estableciendo métodos de asignación de redes más eficientes[32], y también por el uso de redes privadas[54]. Pero ya en febrero del año 2011 se produjo el agotamiento de direcciones IP en la Internet Assigned Numbers Authority (IANA), entidad a cargo de la custodia de números IP, cuando se asignaron los últimos bloques de direcciones a los Registros Regionales de Internet (RIR)[6]. En los Registros Regionales, APNIC, el registro de direcciones IP para Asia 1 En inglés, Internet Protocol (IP). 2 En Estados Unidos, 4 billones. 1

14 Pacífico, es el que tiene menos direcciones IP disponibles, llegando a tener 0,86 bloques /8 disponibles[5] en Junio de Lo cual los ha llevado a tener una política mucho más estricta para aceptar solicitudes de bloques IPv4. Es por este crecimiento acelerado que tuvo Internet, que en los años 90 se empezó a buscar alternativas para la creación de un nuevo protocolo, y en el año 96 se lanzó el Protocolo de Internet versión 6 (IPv6). En este nuevo protocolo, las direcciones son de 128 bits, permitiendo tener hasta 3, direcciones IP, lo cual equivale a aproximadamente direcciones IP por cada persona viva en el planeta. Además, IPv6 entrega beneficios adicionales como la Movilidad de nodos, la seguridad con IPSec es mucho más natural, y se disminuyen los recursos de CPU necesarios para su procesamiento. Lamentablemente los protocolos mencionados anteriormente, no son compatibles entre si, por lo cual, para poder comunicar estas dos redes, se requiere de puertas de enlace especiales, u otro mecanismo de transición, tales como NAT64[26, 25], Teredo, 6rd, entre otros. Muchos de estos mecanismos permiten a usuarios de IPv4 conectarse a redes IPv6 sin disponer de conexión nativa a redes IPv6. Actualmente la Universidad Técnica Federico Santa María, dispone de un bloque IPv4 con máscara /20, el cual permite aproximadamente 4000 nodos con direcciones IP públicas. Si bien el número puede sonar bastante grande, pero dado el tamaño de nuestra Universidad y el crecimiento que ha tenido, y seguirá teniendo, se hará necesario utilizar nuevos protocolos que permitan garantizar la conectividad de toda la red UTFSM. La Universidad, a través de la Dirección de Tecnologías de Información, dispone de conectividad nativa a redes IPv6, gracias al proveedor de Internet Level3, lo que permitiría llevar este nuevo protocolo a cada estación de trabajo de la Universidad. 2

15 1.2. Objetivos El objetivo de este trabajo es elaborar una propuesta de migración al protocolo IP versión 6 para las redes de toda la Universidad Técnica Federico Santa María sin perjudicar la experiencia del usuario, para solucionar así los futuros problemas que se presentarían si se mantiene el uso exclusivo de IPv4, todo esto utilizando como base práctica la migración a este protocolo que se realizará en el Departamento de Informática. Esta propuesta considerará los siguientes aspectos: Un plan técnico de la implementación de IPv6 en los servicios de la Universidad. La detección de los posibles problemas que podrían ocurrir al habilitar IPv6 en servicios críticos Además, tenemos los siguientes objetivos específicos, que nos permiten cumplir el objetivo general: Investigar sobre el soporte IPv6 de los servicios que provee la UTFSM. Habilitar laboratorio de pruebas en donde se implementen las mismas aplicaciones que utiliza DTI utilizando IPv6. Llevar IPv6 a producción en servicios del Datacenter del DI, como un mecanismo para conocer el comportamiento de estas aplicaciones en ambientes reales. Realizar mediciones de uso y comportamiento de servicios habilitados con IPv6. Definir una base de buenas prácticas para aplicarlo a nivel universidad. 3

16

17 Capítulo 2 Estado del Arte IPv6 promete ser la respuesta al problema de agotamiento de direcciones IP en que nos encontramos actualmente a nivel mundial. En este capítulo se describirán los protocolos de Internet y las diversas mejoras que provee IPv6 sobre IPv4. También se describirán los métodos existentes de transición hacia una red Internet 100 % IPv6. Finalizando el capítulo, se analizará el uso actual de IPv6 y el soporte de las aplicaciones más utilizadas dentro de los datacenter de la Universidad Técnica Federico Santa María IPv4 El protocolo Internet versión 4, diseñado inicialmente en Septiembre del año 1981, provee el mecanismo para el paso de datagramas desde un origen a un destino, los cuales tienen una dirección de largo fijo[50]. IPv4 es el protocolo ampliamente más utilizado en Internet, llegando fácilmente a un 99 % en Junio de 2012[30] Direccionamiento El protocolo IPv4 define sus direcciones de tamaño fijo de 32 bits, las cuales son representadas en 4 octetos de 8 bits cada uno, en notación decimal. El siguiente 5

18 ejemplo corresponde a una dirección IPv4: La dirección IPv4 se descompone en dos partes, el número (o dirección) de red, que corresponde a la parte fija dentro del ámbito local de la red y la dirección local, que es la parte variable dependiendo del equipo conectado a la red. El RFC 791[50] define esta separación en 3 clases distintas: Clase A, de nodos, en donde el primer octeto corresponde a la dirección de red. Clase B, de nodos, en donde los dos primeros octetos corresponden a la dirección de red, y Clase C, de 254 nodos, en donde los tres primeros octetos son la dirección de red. El resto de octetos corresponden a la dirección local. Por ejemplo, el Departamento de Informática tiene, entre otras, la red clase C , para la dirección IP , que corresponde la red mencionada, su número de red es y la dirección local es 32. En 1993, el RFC 1519[33] y posteriores actualizaciones en 2006[32] definen la estrategia de direccionamiento ClassLess, o sin clases, en donde para identificar la separación entre la dirección de red y la dirección local ya no se utiliza una clase, si no que se usa una máscara que indica la cantidad de bits que corresponden a la dirección de red. Este esquema se diseñó pensando en los siguientes motivos[35]: Agotamiento de redes Clase B, dado a que no existía una Clase que considerara a organizaciones de tamaño medio, más grandes que 254 equipos, pero mucho más chicas que equipos, Obligando a estas organizaciones a obtener una red Clase B. Tamaño de tablas de rutas, las que estaban creciendo a límites que el software, ni las personas podían manejar. Agotamiento de números de red, principalmente debido a la poca densidad de uso de las clases asignadas. El esquema ClassLess intenta enfrentar estos problemas al definir mecanismos que hacen que la velocidad de crecimiento de números de red asignados sea más lenta. Para el ejemplo anterior, la red clase C , ahora es la red /24 6

19 PC 1 MTU 1500 Router A MTU 1280 Router B MTU 1500 PC 2 Figura 2.1: Redes con distintos máximos de transmisión o / , en donde los primeros 24 bits corresponden al número de red, y los últimos 8 bits a la dirección local Fragmentación Fragmentación es el acto de dividir un paquete IP en múltiples trozos debido a que pueden existir redes externas en las que el tamaño máximo de cada paquete (MTU 1 ) sea menor que el de origen. IPv4 soporta fragmentación a nivel de routers, en donde estos dividen los paquetes IP en múltiples trozos si el siguiente salto tiene un MTU más pequeño que el actual tamaño del paquete. La Figura 2.1 presenta un ejemplo en el cual existen distintos MTU, en este caso si se envía un paquete de 1500 bytes desde el PC 1 al PC 2, este será fragmentado por el Router A en dos paquetes IP, uno de 1280 bytes y otro de 220 bytes. Router B reenvía dos paquetes y PC 2 recibe estos dos paquetes, y finalmente los re-ensambla Encabezados El RFC 791[50] define los siguientes encabezados como parte del protocolo, que se pueden ver en la figura 2.2: 1 Maximum Transmission Unit 7

20 Version IHL TOS Total Length Identification Flags Fragment Offset Time To Live Protocol Header Checksum Source Address Destination Address Options Padding Figura 2.2: Encabezados paquete IPv4 Version: La versión del protocolo, en este caso 4. IHL: Tamaño del encabezado IP. TOS: Calidad de Servicio. Priorización de paquetes. Total Length: Tamaño total del datagrama, incluyendo la carga útil. Identification: Identificador utilizado para el re-ensamblado de paquetes previamente fragmentados. Flags: Bits de control sobre la fragmentación de paquetes. Fragment Offset: Ubicación de este fragmento dentro del datagrama original. TTL: Tiempo máximo de vida del datagrama, este valor es decrementado por cada router por el que pasa el paquete. Actualmente se conoce también como hop limit e indica el número máximo de saltos que puede dar un datagrama entre routers Protocol: Indica el protocolo al que corresponde la carga útil del paquete IP. Header Checksum: Suma de comprobación del paquete, el cual es re-calculado cada vez que se hagan modificaciones al paquete. Source Address: Dirección IP de Origen. Destination Address: Dirección IP de Destino. 8

21 Options: Campos opcionales, rara vez utilizados. Padding: Relleno con ceros, para asegurar que el tamaño del encabezado es múltiplo de 32 bits Limitaciones de IPv4 La limitación más importante de IPv4 es el hecho de que el espacio de direcciones, de 32 bits, es muy pequeño para el crecimiento que ha tenido Internet, y se han hecho necesarias múltiples técnicas para retrasar el inminente agotamiento de direcciones disponibles. Estas técnicas son principalmente el direccionamiento ClassLess y Network Address Translation. Network Address Translation (NAT), es un mecanismo en el cual una red privada[52], la cual no es enrutable a nivel global, accede a redes públicas mediante el cambio de la dirección de origen por una que sí es enrutable globalmente. Para una respuesta desde el exterior, se mantiene una tabla que traduce la dirección pública por la privada correspondiente. En Febrero de 2011, IANA distribuyó completamente los segmentos IPv4 a los registros regionales (RIR), quedando éstos limitados a las reservas que tengan. El registro regional de Asia y Pacífico, APNIC, es aquel que tiene menos números de red disponibles. En Abril de 2011, APNIC solo tenía un segmento de tamaño /8 disponible, obligándolos a tener políticas más estrictas de asignación de segmentos de red[7]. Otras limitaciones incluyen la escasa seguridad del protocolo, mitigado posteriormente por IPsec[42], dificultades de asignación de IP, y la funcionalidad limitada que provee la Calidad de Servicio IPv Direccionamiento IPv6 define, al igual que IPv4, direcciones de largo fijo, pero con la diferencia que el tamaño de ésta es de 128 bits[28], permitiendo hasta números IP distintos. 9

22 La estructura de la dirección, es similar a IPv4 en donde se tiene un número de red, y una dirección local. En IPv6 no se utilizan clases para la separación, como se solía hacer en IPv4 según el RFC 791[50], solo se utiliza el método ClassLess, que permite un mayor control del tamaño de las redes. Inicialmente las primeras especificaciones del protocolo[37], sugerían la asignación de redes de máscara /48 para los usuarios finales. Posteriormente el RFC 6177[46] descarta esta recomendación, ya que se estaría volviendo a lo que eran las asignaciones mediante clases de IPv4. El RFC 6177 indica que el tamaño de la red asignada a usuarios finales debe estar acorde al tamaño de la organización, y su crecimiento esperado en el orden de años. Dentro de la organización se recomienda el uso de redes de máscara /64, ya que este tamaño de red permite el uso de la autoconfiguración de direcciones IP. Sin embargo, no hay restricciones para la asignación de redes más pequeñas. Solo existe la limitante de no poder utilizar autoconfiguración de direcciones en estas redes pequeñas, ya que ésta utiliza un identificador de 64 bits llamado EUI-64[36]. Este identificador es basado en la dirección de Hardware, o dirección MAC, el cual junto a un prefijo se utiliza para formar una dirección IPv6 automática[57]. Las direcciones IP se representan mediante ocho piezas de 16bit cada una, las cuales son escritas en forma hexadecimal[36]. Esta representación implica que el largo de las direcciones IP es de hasta 32 caracteres. El siguiente ejemplo corresponde a una dirección IPv6: 2001:0DB8:0000:0000:0000:0000:0000:003D El RFC 4291[36] presenta métodos para comprimir los ceros, que pueden ser bastante comunes dado el largo de una dirección IPv6. La compresión consiste en eliminar los ceros de mayor orden dentro de cada uno de los ocho trozos de la dirección IPv6. La dirección anterior quedaría así: 2001:DB8:0:0:0:0:0:3D Además el RFC 4291[36] introduce el uso de ::, que permite el reemplazo de una serie de trozos contiguos y que correspondan enteramente a ceros. El uso de :: solo se puede utilizar una sola vez, ya que, de otra forma, se introducirían 10

23 ambigüedades sobre la cantidad de trozos que representa el ::. La dirección de ejemplo ahora se verá así: 2001:DB8::3D DNS El servicio Domain Name System (DNS) es una base de datos distribuida, y de estructura jerárquica, encargada principalmente de asociar nombres de dominio, con su dirección IP. También puede asociar un dominio con sus servidores de correo, o los registros reversos que asocian una dirección IP con su nombre de dominio. Al ser las direcciones IPv6 de un tamaño bastante mayor al de IPv4, es necesario definir nuevos registros de DNS que permitan almacenar esta información. El RFC 3596[56] define el registro AAAA 2, que permite una única dirección IPv6. En caso de requerir más de una dirección, se definen múltiples registros tipo AAAA. Los registros reversos para IPv6, que permiten el mapeo de una dirección IPv6 a un nombre de dominio, también son distintos. Se define una raíz nueva, llamada ip6.arpa. La representación de una dirección IPv6 dentro de esta zona de reversos se realiza mediante una secuencia de trozos, separados por puntos, con el sufijo ip6.arpa. Cada trozo representa un dígito hexadecimal de la dirección IPv6 original, sin compresión de ceros, los cuales son ordenados de forma reversa. Así el nombre asociado a la dirección IP 2001:DB8::3D será el valor del registro PTR llamado 3.D B.D IP6.ARPA. 2 Lease: Cuádruple A, o en ingles quad A, pero no Ahhhhh! 11

24 Bit Version Traffic Class Flow Label Payload Length Next Header Hop Limit Source Address Destination Address Figura 2.3: Encabezados paquete IPv Encabezados Los encabezados en IPv6 son mucho más simples y de tamaño fijo, permitiendo que los routers requieran menos recursos para procesar los paquetes. Por el contrario, estos son más grandes, consumiendo más memoria. La figura 2.3 muestra la estructura de los encabezados IPv6. En ella se pueden ver los siguientes encabezados: Version: Versión del protocolo. En este caso 6. Traffic Class: Permite la implementación de Calidad de Servicio. Flow Label: Permite la definición de flujos de datos, los cuales deben ser tratados de forma diferente al resto de los paquetes[24]. Payload Length: El tamaño de la carga útil que contiene el paquete IPv6. Next Header: Indica el protocolo o tipo de encabezado que está a continuación del encabezado IPv6. Hop Limit: La máxima cantidad de saltos permitida. Source Address: Dirección IPv6 de origen. 12

25 Destination Address: Dirección IPv6 de destino. Como se puede notar, el paquete IPv6 es mucho más simple, múltiples campos del encabezado que eran parte de IPv4 ya no están en IPv6, dejando solo lo que es realmente importante como parte del encabezado. Otras funcionalidades, que pueden no ser tan usadas, se implementan mediante encabezados adicionales al de IPv6. A diferencia de del campo Options de IPv4, que hacen que el encabezado sea de largo variable, los encabezados de extensión, son de largo fijo y se ubican entre el encabezado IPv6 descrito anteriormente, y el encabezado de la capa superior, tal como TCP o UDP. Estos se identifican mediante el campo Next Header. Algunos encabezados opcionales definidos por el RFC 2460[28] son: Hop-by-Hop Options: Opciones que son revisadas por cada uno de los saltos que están entre el origen y el destino. Routing: Utilizado para especificar uno o más nodos intermedios que deben ser visitados antes de llegar al destino. Fragment: Utilizado para la fragmentación de paquetes que no caben dentro del MTU de algún enlace. Destination Options: Opciones que son revisadas solo por el nodo de destino. Authentication: Diseñado para proveer servicios de autenticación (IPsec)[40] Encapsulating Security Payload: Diseñado para proveer confidencialidad, autenticación de origen, integridad, entre otros[41] Fragmentación En IPv6 la fragmentación se realiza de forma distinta a IPv4. Como se mencionó anteriormente, IPv4 realiza fragmentación en el momento que se encuentra con una ruta con un MTU más pequeño que el tamaño de la carga útil que lleva nuestro paquete IP, y es realizado por los routers entre el origen y el destino. 13

26 En IPv6, los routers no realizan fragmentación. En caso de encontrarse con un paquete más grande que el máximo permitido, este simplemente es descartado por el ruoter, retornando un mensaje ICMPv6 Packet Too Big al origen. Otro punto importante en IPv6 es que cada ruta en Internet debe tener un MTU mayor o igual a Si no es posible, se debe realizar fragmentación en una capa inferior a IPv6[28]. Para lograr que los paquetes lleguen a su destino, el nodo de origen debe realizar un descubrimiento del mínimo MTU[44] en toda la ruta, desde el origen hasta el destino. Y a partir de este dato los paquetes son fragmentados solo en el nodo de origen, y re-ensamblados en el destino. Para el caso de la figura 2.1, el nodo de origen PC 1, realiza el descubrimiento del mínimo MTU, detectando que este valor es Solo el PC 1 realiza la fragmentación de los paquetes. En caso de implementaciones de IPv6 simplificadas, como se pueden encontrar en sistemas integrados, se puede omitir el uso del descubrimiento de mínimo MTU, y simplemente enviar paquetes de tamaño 1280 como máximo[28] Mejoras sobre IPv4 Algunas de las mejoras que IPv6 provee son: Mayor espacio de Direcciones: Como se mencionó anteriormente, las direcciones IPv6 son de 128 bits, mientras que en IPv4 son de solo 32 bits. IPv6 provee aproximadamente trescientos cuarenta trillones de trillones de trillones 3 de direcciones IP, mientras que IPv4 provee cerca de cuatro billones 4, por lo que no hay motivos para pensar, en el largo plazo, sobre agotamiento de direcciones IPv6. Multicast Reemplaza a Broadcast: Broadcast es un modo de comunicación entre nodos de una red en donde un paquete tiene como destino a todos los nodos de la red. En IPv6 no se utiliza Broadcast, si no que se utiliza solo 3 Exactamente: 340,282,366,920,938,463,463,374,607,431,768,211,456 4 Exactamente: 4,294,967,296 14

27 Multicast, en donde un mensaje va a destinado a un grupo de nodos dentro de la red. Permitiendo que el uso de la red sea más limpio. Por ejemplo, en DHCPv6 se utiliza Multicast para el la configuración de IP de los nodos. Los mensajes de DHCP son solo recibidos por los servidores DHCP que existan en la red, y no por todos los nodos, como era en IPv4. Autoconfiguración de direcciones: Se provee un mecanismo llamado Neighbor Discovery Protocol[47], que permite entre otros la asignación de dirección IP de forma automática, sin necesidad de configuración del nodo. Capa de Seguridad: IPsec es un componente que permite la seguridad de extremo a extremo. Este componente en las primeras especificaciones de IPv6 era obligatorio, pero luego se hizo opcional[38]. En IPv6 la seguridad de extremo a extremo es más fácil de implementar ya que no es necesario tener NAT en IPv6, el cual complica de gran manera IPsec en IPv4. Procesamiento Simplificado: El hecho que los encabezados de IPv6 sean de largo fijo, permite a los routers evitar el cálculo del tamaño del paquete, haciendo que éstos utilicen menos ciclos de CPU para procesar cada paquete. También se elimina el campo llamado checksum, dejando la tarea de comprobación de sumas a las capas inferiores y superiores a IPv6, evitando tener que re-calcular el valor de este encabezado cada vez que se modifica el hop count. Movilidad: protocolo que permite que un nodo se mantenga accesible mientras se está moviendo alrededor de la red IPv6[49]. Extensiones de Privacidad: Permite que la dirección autoasignada cambie a medida que pasa el tiempo, para hacer más difícil la recolección de información de un nodo.[45] 2.3. Métodos de transición El protocolo IPv6 no es compatible hacia atrás con el protocolo IPv4, por lo que no es posible realizar el cambio de protocolo y olvidarse de IPv4, sino que 15

28 Figura 2.4: Acceso a IPv6 mediante Túnel sobre redes IPv4 será necesario un mecanismo de transición. Los mecanismos de transición los podemos separar en tres categorías: IPv6 sobre IPv4, o aquellos en donde se accede a IPv6 a través de redes IPv4 nativas, IPv4 sobre IPv6, en donde el acceso a IPv4 se realiza a través de redes IPv6 nativas, y dual stack, en donde ambos protocolos están implementados en forma nativa simultáneamente IPv6 sobre IPv4 Estas técnicas comprenden el uso de IPv6 mediante túneles entre un nodo y otro que tenga acceso nativo a IPv6. La figura 2.4 presenta un ejemplo en donde la máquina identificada como Dual Stack Host tiene acceso a redes IPv4 de forma nativa, y también tiene acceso a IPv6, pero mediante un túnel. Entre las técnicas para acceder a IPv6 sobre redes IPv4 existentes son: 6to4, permite el acceso a IPv6 de forma automática, sin configurar un túnel explícito. Esto se logra mediante la dirección IPv4 anycast , que tiene configurado el Tunnel Broker[27]. 16

29 Figura 2.5: Acceso a IPv6 mediante 6rd 6in4, utiliza el protocolo IP número 41, para el paso de paquetes IPv6, como payload 5 de un paquete IPv4. Requiere la configuración manual de un túnel[48], como es el ejemplo de SixXS[13]. 6over4, requiere el uso de multicast en IPv4, el cual no es ampliamente soportado en la infraestructura IPv4 6rd, derivado de 6to4, con la diferencia que el Tunnel Broker es parte de la red del proveedor de servicios de Internet del usuario[29]. Haciendo que el servicio sea de mejor calidad comparado a 6to4 La figura 2.5 muestra un ejemplo de una configuración 6rd, en donde el router llamado 6rd gateway es parte de la red local del proveedor de Internet IPv4 sobre IPv6 Estas técnicas utilizan la infraestructura IPv6 nativa existente para conectarse a redes IPv4. Estas técnicas aún no son muy utilizadas, ya que parten de la base que la red local nativa es IPv6. 5 También conocido como Carga Útil, o datos del paquete 17

30 Figura 2.6: Acceso a IPv4 mediante NAT64/DNS64 Estos métodos están pensados para organizaciones que tengan IPv6 pero que no puedan adquirir segmentos de red IPv4, ya sea por el agotamiento de direcciones IPv4 o límites impuestos por los Registros de Internet Regionales. En el mediano plazo organizaciones deberán hacer uso de estos métodos por el inminente agotamiento de direcciones IPv4. Entre las técnicas que acceden a IPv4 mediante IPv6 nativo, tenemos: Nat64 / DNS64, utiliza un servidor DNS especial, que al encontrar solo registros tipo A, responde con un registro tipo AAAA que apunta a una máquina, con conexión a redes IPv4, que traduce esta dirección IPv6, y se conecta al destino IPv4 original. La figura 2.6 muestra un ejemplo de NAT64/DNS64. 4in6, al contrario de 6in4, este método encapsula un paquete ipv4 dentro de un paquete IPv6, el cual va con destino a un túnel configurado previamente. 4rd, corresponde a un borrador, busca ser el opuesto de 6rd Dual Stack El método dual stack, implica acceso nativo a las redes IPv4 e IPv6 de forma simultánea. Requiere que la infraestructura de redes de la organización soporte 18

31 ambos protocolos simultáneamente, o la adquisición de hardware nuevo para el nuevo protocolo. Los nodos que están conectados a una red dual stack pueden acceder directamente a redes IPv4 e IPv6, utilizando la infraestructura correspondiente. Estos nodos deben ser configurados para que tengan simultáneamente una dirección IPv4 y una dirección IPv6. El mecanismo ideal de transición es el acceso nativo a ambas redes, ya que no implica la creación de túneles, el gasto adicional de ancho de banda para implementarlo y su estabilidad. Solo cuando no se tenga acceso nativo a IPv6, se debe pensar en túneles IPv6 sobre IPv4. Los túneles IPv4 sobre IPv6 aún no tienen mucho sentido ya que el acceso a IPv4 nativo es fácil de obtener Uso actual de IPv Uso de IPv6 en el mundo El hecho que la migración a este protocolo implica complicaciones para los administradores de redes, no hay un gran interés por parte de las organizaciones en comenzar la transición. Es por eso que el uso de IPv6 en el mundo, según mediciones realizadas por Google, no supera el 0,7 % en promedio[34]. Las mediciones de Google también indican que los países con mayor uso de IPv6 son: Rumania: 8,55 % Francia: 4,73 % Japón: 1,52 % Estados Unidos: 1,43 % Los porcentajes altos que se ven en Rumanía y Francia, se deben principalmente a el despliegue de IPv6 por parte de proveedores de Internet, en redes hogareñas[9, 8]. En Rumanía el proveedor que tiene el mayor despliegue de IPv6 es RCS&RDS, y en Francia el Proveedor Free. 19

32 En Chile los datos muestran que el uso de IPv6 llega al 0,1 % aproximado. NIC Chile es uno de los principales promotores de IPv6 en Chile[12]. World IPv6 Day y World IPv6 Launch En Junio de 2011 y Junio de 2012, se realizaron 2 eventos a nivel mundial para alentar el uso de IPv6, organizados por la Internet Society. El evento del año 2011 se llamó World IPv6 Day, y consistió en la habilitación por 24 horas de IPv6, por grandes empresas del rubro de Internet. Entre ellas, Google, Akamai, Facebook, entre otras. Esto provocó tráfico IPv6 nunca antes visto a nivel mundial. La prueba fue todo un éxito, a tal punto que muchas de las organizaciones participantes decidieron mantener IPv6 habilitado para siempre. Posteriormente en Junio de 2012 se realizó un segundo evento, llamado World IPv6 Launch, el cual consistió en habilitar IPv6, pero esta vez para siempre, por empresas con gran presencia en Internet. Esta vez se sumaron además, grandes Proveedores de Internet Mundiales y Fabricantes de Hardware de redes hogareñas IPv6 en la UTFSM La red UTFSM[1] está compuesta por 3 enlaces a Internet de los proveedores, Level3, Claro y REUNA, de los cuales, al día de hoy, solo Level3 proporciona acceso nativo a IPv6. Reuna provee el servicio, pero aún no se ha configurado en la UTFSM. La actual red institucional no hace uso actualmente de IPv6, y solo existen redes de prueba en la Dirección de Tecnologías de Información, Departamento de Informática, Electrónica y Física. Siendo la red de Informática la única en la que los usuarios 6 pueden hacer uso de ella. Además tampoco existe un plan que contemple IPv6 en redes y servicios que provee DTI. 6 Entiéndase como usuario a las personas que no administran la red. 20

33 Soporte IPv6 en Aplicaciones Las aplicaciones que nos interesan son aquellas que se utilizan para entregar servicios en la UTFSM. Ellas se pueden descomponer en: Servicios Web Apache HTTPD El servidor web Apache HTTPD es el más usado a nivel mundial y a nivel UTFSM también. Este servidor web soporta IPv6 dual stack desde la versión 2.0[18]. Permite configurar los protocolos sobre los cuales se escucha, y también la configuración de VirtualHost. Desarrollos internos Los desarrollos internos que hagan uso de direcciones IP, por ejemplo para validar IP de usuarios, registros de acceso, o cualquiera sea el motivo para manipular una dirección IP, requerirán modificaciones para hacerlas compatibles con IPv6. Es necesario considerar que la representación hexadecimal de IPv6 al ser de largo variable y permitir compresión de ceros, su sintaxis es más compleja, y por lo tanto más difícil de verificar su correctitud mediante expresiones regulares. Bibliotecas disponibles, para los lenguajes web más comunes, permiten que la manipulación de direcciones IPv6 sea más simple para el desarrollador de la aplicación. Bases de Datos MySQL MySQL es el servidor de bases de datos más usado en aplicaciones web, por su facilidad de instalación y uso. IPv6 está soportado esde la versión 5.5.3[16] para escuchar sobre este protocolo, y también para la configuración de permisos de acceso. Red Hat Enterprise Linux (RHEL) 6 provee solo la versión 5.1 de esta base de datos. En Septiembre de 2013 Red Hat anuncia Red Hat Software Collections [22], que corresponden a un 21

34 conjunto de aplicaciones actualizadas para Red Hat Enterprise Linux 6. Entre ellas se incluye MySQL con soporte completo para IPv6. PostgreSQL Desde la versión 7.4, publicada en 2003, el motor de bases de datos PostgreSQL soporta IPv6 tanto como mecanismo de conexión, como también nuevos tipos de datos para almacenar direcciones IPv6 en la base de datos[4]. Este motor, si bien es menos usado que MySQL, es de alto rendimiento y se utiliza en aplicaciones de gran tamaño, tal como Red Hat Enterprise Virtualization, plataforma de virtualización usada en la Universidad. Oracle Database Oracle Database es un motor de base de datos que actualmente se utiliza en el Sistema de Información de Gestión Académica (SIGA). Desde la versión 11g Release 2 se soporta IPv6 en todos sus componentes, excepto en el sistema de cluster Oracle RAC[11]. Servicios Correo Electrónico Zimbra Zimbra es una solución empresarial de Correo Electrónico, Calendario, y Colaboración. Competencia directa de Servicios como Exchange e IBM Notes. Está construido sobre una base de herramientas Opensource, tales como Postfix, MySQL, OpenLDAP, ClamAV, SpamAssassin. Desde la versión 8.0 provee soporte IPv6, en modalidad Beta, soportando implementaciones IPv6 puro e IPv6 dual stack. Postfix Postfix es uno de los servidores de correo electrónico más populares en ambientes opensource, desde la versión 2.2, liberada en marzo de 2005, provee soporte para IPv6[20]. Sendmail Sendmail es el servidor de correo más conocido, dado que fue uno de los más usados, hoy en día su participación en el mercado ha ido decayendo 22

35 constantemente[10]. Su uso en la UTFSM solo se encuentra en sistemas legados. Desde la versión incluye soporte para IPv6. Exchange Exchange, similar a Zimbra, es una plataforma empresarial de Correo Electrónico, Calendarios, y colaboración. Desarrollada por Microsoft, exclusivamente para sistemas operativos Windows. En la UTFSM, se pretende utilizar Exchange como plataforma de correos para funcionarios y profesores. Desde Exchange 2010 se incluye soporte limitado para IPv6, y en Exchange 2013 soporte completo[15], viniendo además habilitado por defecto. RBL Real-time Blackhole List, es un mecanismo basado en DNS para el control de correo no deseado. Consiste en una lista a la cual se agregan cada una de las direcciones IP que envíen correo no deseado. IPv6 trae complicaciones[51] a los sistemas de listas negras, entre los cuales destacamos: Tamaño de la lista: IPv6, y su espacio de direcciones de 128 bits, hace que las listas sean más grandes, lo cual requiere de más memoria para el servidor de listas. Facilidad de cambiar dirección IP: Los spammers pueden tener a su disposición miles de millones de direcciones IPv6, las cuales pueden utilizar todas para enviar correo no deseado, lo que hace difícil bloquear efectivamente IPs específicas. Para mitigar esto se ha impuesto la idea de bloquear segmentos completos, siendo éste de máscara /64. Tamaño de cache en servidores recursivos: Combinando el tamaño de las listas negras y la facilidad para cambiar la dirección IP de un servidor de correo no deseado, tenemos el problema del cache de los servidores recursivos. El problema radica en el tamaño del cache, el cual podría crecer lo suficiente para generar una denegación de servicio. Para mitigar esto se propone definir listas IPv6 sin cache, o 23

36 en otras palabras TTL=0. La herramienta más popular para implementar una lista RBL se llama rbldnsd. Ésta trae soporte para listas de direcciones IPv6 desde la versión 0.997a, sin embargo no hay grandes proveedores de listas negras, como SpamHaus, SpamCop o Barracuda, que listen direcciones IPv6 aún. Solo Spamhaus ha declarado estar trabajando para proveer listas IPv6 en el futuro[43]. SpamAssassin / ClamAV Estos servicios son filtros AntiSPAM y AntiVirus normalmente usados en sistemas de correo OpenSource. Ellos funcionan mediante la inspección del cuerpo de los mensajes en busca de patrones que identifiquen Virus y SPAM. La comunicación entre el servidor de correo y los filtros se realiza normalmente mediante sockets Unix, por lo que en este caso no hay interacción con el protocolo IPv6. Sin embargo SpamAssassin soporta implementaciones utilizando IPv6 desde la versión 3.4[31]. Por el contrario ClamAV no soporta implementaciones con IPv6, funcionando solo mediante sockets Unix e IPv4. Servicios de apoyo En esta categoría van servicios que son parte del datacenter, pero que no necesariamente el usuario final los usa directamente, ni son usados exclusivamente por un solo sistema. DNS ISC Bind es la implementación de DNS utilizada para los sistemas de DNS primario, secundario y recursivos dentro de la UTFSM. La primera versión en soportar IPv6 fue la 9.0 en Octubre de 2000[3]. 389-DS 389-DS es el principal servicio de Directorios LDAP utilizado en la Universidad. Está compuesto por una aplicación de tipo servidor, junto a una aplicación de administración. Desde la versión 1.0.3, del año 2006 se soporta IPv6 para las conexiones desde los clientes, pero sin soporte 24

37 para control de acceso, replicación, o acuerdos de encadenamiento. Solo desde la versión hay soporte completo[14]. NFS NFS, es un sistema de archivos en red, muy utilizado para tener archivos de forma centralizada. En 2010 se dio prioridad a la implementación de IPv6 para nfs-utils, entregando el primer soporte en marzo de 2010 para los clientes NFS, y en Septiembre de 2010 para los servidores NFS. NTP NTP es el protocolo de sincronización de hora estándar, utilizado en múltiples sistemas operativos. Es importante ya que muchas aplicaciones distribuidas requieren tener la misma hora en cada uno de los nodos. ntpd es la implementación del protocolo más popular y usada por defecto en sistemas Linux. Soporta IPv6 desde la versión de 2003[17] Nagios Nagios es una herramienta de monitoreo, que se caracteriza por su flexibilidad, permite monitorear todo tipo de servicios de red, así también harware y software interno de un servidor. Se requiere que soporte IPv4 e IPv6 para poder hacer monitoreo a ambos protocolos.[55]. Nagios está compuesto por plugins específicos, encargados de monitorear un servicio particular, y por un núcleo que procesa las respuestas de los plugins y notifica a los administradores. El núcleo a su vez utiliza servicios como apache y Postfix para realizar las notificaciones, los cuales soportan IPv6. Los plugins provistos directamente por Nagios soportan IPv6, pero existen muchos que son provistos por terceros que podrían no tener soporte. Virtualización: RHEV Red Hat Enterprise Virtualization es la plataforma de virtualización de nivel empresarial que se utiliza en la UTFSM, está basada en la herramienta Open Source ovirt, y consiste en hipervisores, que son los servidores físicos donde se ejecutan las máquinas virtuales, y un Manager, 25

38 que se encarga de controlar a los hipervisores. La versión 3.3 es la última publicada por Red Hat, y provee soporte IPv6 solo para las máquinas virtuales que se ejecuten sobre la plataforma[21]. Toda la comunicación entre los usuarios, el Manager, y los hipervisores funciona mediante IPv4. Ya hay avances en el soporte de IPv6 para el Manager y los hipervisores en las versiones de desarrollo de ovirt[19]. 26

39 Tabla resumen A continuación se presenta una tabla que resume el soporte de las aplicaciones más utilizadas dentro de la UTFSM. Aplicación Soporte Observaciones Apache HTTPD Completo Desde versión 2.0. Desarrollos internos Parcial Es necesario revisar caso a caso el soporte de IPv6. MySQL Completo Desde versión PostgreSQL Completo Desde versión 7.4. Oracle Database Parcial Desde versión 11g Release 2. Zimbra Completo Modalidad Beta, desde versión 8.0. Postfix Completo Desde versión 2.2. Sendmail Completo Desde versión Exchange Completo Desde versión RBL Parcial Faltan listas públicas con direcciones IPv6. SpamAssassin Completo Desde versión 3.4. ClamAV Sin soporte Sin embargo, las implementaciones en la UTFSM son mediante sockets Unix. Bind Completo Desde versión DS Completo Desde versión 1.3. NFS Completo Desde Septiembre NTP Completo Desde versión Nagios Parcial Pueden existir plugins sin soporte. RHEV Parcial Solo soporta máquinas virtuales con IPv6. 27

40

41 Capítulo 3 Implementación de IPv6 La implementación de la solución se realiza en las dependencias del Departamento de Informática. Esta consiste en agregar a la red IPv4 actual, el segundo stack o la red IPv6 en paralelo. Podemos separar la implementación en las siguientes etapas: 1. Acceso a red IPv6 en el core de la red. 2. Definición de mecanismo de asignación de números IPv6. 3. Acceso a red IPv6 desde redes de usuarios. 4. Implementación de servicios en modalidad dual stack Acceso a IPv6 El primer paso consiste en proveer conectividad IPv6 al core de la red de la UTFSM. El core de la red es el núcleo, por donde todas las redes de la universidad deben pasar para llegar a Internet. Aquí se debe definir el mecanismo por el cual se accederá a redes IPv6. Como se mencionó anteriormente, la UTFSM tiene conectividad nativa a redes IPv6 externas mediante el proveedor Level 3, por lo que es posible implementar conectividad mediante dual stack otúneles como 6rd. 29

42 Figura 3.1: Asignación de IPv6 manteniendo ultimo octeto de IPv Asignación de Números IPv6 Una de las dificultades que se presentan es el hecho de tener que asignar un número IPv6, complementario al actual número IPv4, a cada equipo que requiera acceso IPv Asignación estática de direcciones En el caso de asignaciones estáticas se proponen dos alternativas. Utilizar el ultimo octeto de la dirección IPv4 como el último grupo de la dirección IPv6. Tiene la ventaja de que las direcciones IPv6 son más cortas. Ver figura 3.1 Utilizar la dirección IPv4 completa como los últimos cuatro bloques de la dirección IPv6. Permite consolidar múltiples redes IPv4 en una sola red IPv6. Ver figura 3.2 Figura 3.2: Asignación de IPv6 utilizando la dirección IPv4 completa como identificador de host En la implementación realizada en el Departamento de Informática se utilizó la primera opción, ya que las direcciones son más cortas y no hay casos en donde múltiples equipos, de una misma red, tengan en su dirección IP el último octeto de igual valor. 30

43 Asignación dinámica de direcciones Dos modalidades existen en IPv6 para asignar direcciones de forma dinámica, DHCPv6: Dynamic Host Configuration Protocol v6 y SLAAC, mediante el protocolo NDP: Neighbor Discovery Protocol. Se pueden utilizar cada uno por separado, o una combinación de ambos[39]. DHCPv6 se prefiere en casos donde se requiera de un mayor control de los host que acceden a la red, por el contrario NDP se prefiere en casos donde no se necesite mayor control. Para la implementación de prueba se utiliza la implementación de ISC[23] de DHCPv6, y el software radvd que implementa el protocolo NDP. El el Apéndice A se encuentra mayor información para la configuración de estas herramientas Descripción de la red del Departamento de Informática La red de datos del Departamento de Informática, está conectada a la red que provee la Dirección de Tecnologías de la Información (DTI)[1] a todos los campus de la Universidad. Es esta red la que provee de acceso a Internet al Departamento de Informática, mediante los protocolos IPv4 e IPv6. Dentro del Departamento, es la Unidad de Infraestructura y Tecnología (I&T), que por medio de la Unidad de Servicios de Computación e Internet (usci)[2], está encargada de administrar la red del Departamento de Informática. Esto incluye la Asignación de números IP, cortafuegos, nombres de dominio, control del ancho de banda, entre otros. La Dirección de Tecnologías de la Información provee de los siguientes recursos: Ancho de Banda Simétrico de 42Mbps Internacional. Dos segmentos públicos /24 IPv4 Un segmento privado /16 IPv4 Un segmento /48 IPv6 31

44 Figura 3.3: Redes dentro del Departamento de Informática Estructura interna La estructura de la red del Departamento es muy similar a lo que es la red institucional, pero en menor escala. La red está compuesta por 8 subredes principales, las cuales tienen un rango público y un rango privado. 1. Red Servidores 2. Red Laboratorios 3. Red Laboratorios Multipropósito 4. Red CSRG 5. Red Profesores 6. Red Wireless 7. Red DMZ 32

45 Redes IPv6 La UTFSM tiene asignado el bloque 2800:270::/32, lo que permite a la UTFSM disponer de direcciones IPv6 (y segmentos de red) prácticamente ilimitadas. Mediante un trabajo realizado anteriormente por un ex-alumno de Ingeniería Civil Telemática, se propuso[53] asignar un bloque de máscara /48 a cada departamento de la Universidad, y en consecuencia se asignó al Departamento de Informática el bloque 2800:270:c::/48. Dentro de cada departamento, de acuerdo a su estructura, se pueden asignar redes de máscara /64 para cada unidad, laboratorio, piso, etc. Se sugiere seguir la misma estructura que se tiene en IPv4 dentro de los departamentos para facilitar el periodo de transición en donde se debe mantener ambos protocolos funcionando. Así en el Departamento de Informática se asignan las siguientes redes IPv6: Red Servidores: 2800:270:c:0::/64 Red Laboratorios: 2800:270:c:1::/64 Red Laboratorios Multipropósito: 2800:270:c:2::/64 Red Profesores: 2800:270:c:3::/64 Red CSRG: 2800:270:c:4::/64 Red Wireless: 2800:270:c:5::/64 Red DMZ: 2800:270:c:6::/ Acceso a IPv6 desde redes de usuarios Para acceder a IPv6 es necesario que el equipamiento del usuario soporte IPv6. La siguiente tabla muestra el estado actual del soporte de los sistemas operativos más comunes que utilizan los usuarios. 33

46 Sistema Soporte Observaciones Windows Soportado Completo desde Windows Vista, parcial en Windows XP. Mac OS Soportado Versiones anteriores a Lion (10.7) no soportan DHCPv6. Linux Soportado Soporte de DHCPv6 y SLAAC. Android Soportado No soporta DHCPv6. ios Soportado Soporte completo desde versión 4.3.1, en versiones anteriores el soporte es parcial. Windows Phone Soportado Soporte desde versión 8. Versión 7.5 no lo soporta de ninguna forma. De acuerdo a la información obtenida, DHCPv6 está menos soportado que la asignación sin estado, SLAAC. Por esto se recomienda implementar SLAAC en las redes de usuarios para tener el mayor soporte. El apéndice A.2 se encuentra la configuración del servicio radvd que implementa la asignación automática de direcciones IPv Implementación de Servicios en Dual Stack Los servicios que se consideran para la implementación son los siguientes: Servicios Web: Apache HTTPD El servidor web Apache es, hoy en día el estándar de facto a la hora de publicar un sitio web. Es el principal servidor web utilizado en la UTFSM. Por omisión, en la configuración de Red Hat Enterprise Linux, el servidor web escucha en todas las direcciones IP, de ambos protocolos. En caso de ser necesario que escuche en direcciones específicas, se necesita cambiar el parámetro Listen de la configuración, tal como se muestra a continuación. 34