View/Open - Universidad Católica de Pereira
Anuncio
ESTRATEGIA DE MIGRACIÓN DE IPv4 A IPv6 PARA LAS PYMES EN COLOMBIA HÉCTOR FABIO ARIAS PULGARÍN COD. 10032846 UNIVERSIDAD CATÓLICA DE PEREIRA PROGRAMA INGENIERÍA DE SISTEMAS Y TELECOMUNIICACIONES PEREIRA 2011 ESTRATEGIA DE MIGRACIÓN DE IPv4 A IPv6 PARA LAS PYMES EN COLOMBIA HÉCTOR FABIO ARIAS PULGARÍN COD.10032846 Trabajo de grado para optar por el título de Ingeniero de Sistemas y Telecomunicaciones Asesor LUIS ALEJANDRO FLETSCHER BOCANEGRA Ing. En Electrónica y Telecomunicaciones MSc. En Ingeniería UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍAS PEREIRA 2011 AUTORIZACIÓN Yo, HECTOR FABIO ARIAS PULGARIN mayor de edad, vecino de Pereira, identificado con la Cédula de Ciudadanía N° 10032846 de Pereira actuando en nombre propio, en mi calidad de autor del trabajo de grado, denominado: ESTRATEGIA DE MIGRACION DE IPv4 A IPv6 PARA LAS PYMES EN COLOMBIA. Presentado como requisito para optar el título de INGENIERO DE SISTEMAS Y TELECOMUNICACIONES, en el año 2011, hago entrega del ejemplar respectivo y de sus anexos de ser el caso, en formato digital o electrónico (CD-ROM) y autorizo a LA UNIVERSIDAD CATÓLICA DE PEREIRA, para que en los términos establecidos en la Ley 23 de 1982, Ley 44 de 1993, Decisión Andina 351 de 1993, Decreto 460 de 1995 y demás normas sobre la materia, utilice y use en todas sus formas, los derechos patrimoniales de reproducción, comunicación pública, transformación y distribución (alquiler, préstamo público e importación) y los demás derechos comprendidos en aquellos, que me corresponden como creador de la obra objeto del presente documento. También autorizo a que dicha obra sea incluida en bases de datos. Esta autorización la hago siempre que mediante la correspondiente cita bibliográfica se le de crédito a mi trabajo como autor. Con todo, en mi condición de autor me reservo los derechos morales de la obra antes citada con arreglo al artículo 30 de la Ley 23 de 1982. PARÁGRAFO: La presente autorización se hace extensiva no sólo a las facultades y derechos de uso sobre la obra en formato o soporte material, sino también para formato virtual, electrónico, digital, óptico, usos en red, internet, extranet, intranet, etc., y en general para cualquier formato conocido o por conocer. EL AUTOR - ESTUDIANTES, manifiesta que la obra objeto de la presente autorización es original y la realizó sin violar o usurpar derechos de autor de terceros, por lo tanto la obra es de su exclusiva autoría y tiene la titularidad sobre la misma. PARÁGRAFO: En caso de presentarse cualquier reclamación o acción por parte de un tercero en cuanto a los derechos de autor sobre la obra en cuestión, EL ESTUDIANTE - AUTOR, asumirá toda la responsabilidad, y saldrá en defensa de los derechos aquí autorizados; para todos los efectos la Universidad actúa como un tercero de buena fe. HECTOR FABIO ARIAS PULGARIN CC.10.032.846 Pereira, Noviembre 22 de 2011 DEDICATORIA A DIOS, quien ha estado a mi lado en todo momento, dándome las fuerzas necesarias para continuar luchando día tras día y salir adelante, rompiendo todas las barreras que se presenten. A mi querida madre MARIA LUCIELA, a quien le agradezco lo que soy, pues ha sido quien me ha brindado enseñanzas que me han permitido crecer más como persona íntegra y además quien me ha ayudado en mi formación académica, quien depositó su entera confianza en cada reto que se me presentaba sin dudar ni un solo instante de mis capacidades. A mi querida tía NORMA RUTH y abuela CARMEN, quienes han sido para mí como unas segundas madres, han estado conmigo desde mi niñez brindándome mucho amor y ayudando en mi crecimiento como persona. A mis hermanos OLMEDO y OSLANDER, quienes han estado acompañándome en mi formación personal y académica. HÉCTOR FABIO AGRADECIMIENTOS A DIOS, por iluminarme y ser la guía suprema, dándome fuerzas para atravesar obstáculos que se presentaran durante la carrera. A mis Seres Queridos, por la confianza, esfuerzo, dedicación y la perseverancia que me brindaron, para poder lograr las metas. Al asesor Luis Alejandro Fletscher, por orientarme y guiarme durante el proceso educativo y culminación del proyecto. A mis compañeros que estuvieron en el mismo proceso de formación académica. Cada uno de ellos aportó en mi crecimiento personal y académico. A todas las personas que estuvieron involucradas de una manera directa o indirecta con la realización de mi Proyecto de Grado, por alentarme siempre y aconsejarme para que el proceso culminara exitosamente. CONTENIDO Pág. INTRODUCCIÓN ...................................................................................................20 1.DEFINICIÓN DEL PROBLEMA ..........................................................................22 1.1OBJETIVO GENERAL ......................................................................................23 1.2OBJETIVOS ESPECÍFICOS .............................................................................23 2.GENERALIDADES DE DIRECCIONAMIENTO ..................................................24 2.1 CONTEXTUALIZACIÓN DE IP ........................................................................24 2.1.1 Direcciones IPv4 públicas .............................................................................24 2.1.2 Direcciones IPv4 privadas.............................................................................25 2.1.3 Direcciones reservadas.................................................................................25 2.2 TRADUCCIÓN DE DIRECCIÓN DE RED (NAT) .............................................28 2.2.1 Problemas de NAT ........................................................................................28 2.3 IP MULTICAST ................................................................................................29 3.CONTEXTUALIZACIÓN DEL DIRECCIONAMIENTO IPV6 ...............................30 3.1 IPV6…..............................................................................................................30 3.1.1 Características principales de IPV6 con respecto a IPV4 ............................31 3.1.2 Datagramas de encabezado IPV4 e IPV6 ...................................................34 3.1.3 Encabezados de extensión- ..........................................................................40 3.1.3.1 Orden de los encabezados de extensión (opcional) ................................41 3.1.3.1.1 Hop-by-Hop Options Header ...................................................................43 3.1.3.1.2 Destination Options Header ....................................................................43 3.1.3.1.3 Routing Header .......................................................................................44 3.1.3.1.4 Fragment Header ....................................................................................47 3.1.3.1.5 Authentication Header ............................................................................49 3.1.3.1.6 Encapsulating Security Payload Header ................................................51 3.1.3.1.7 Destination Options Header ....................................................................52 3.1.4 Representación del direccionamiento IPV6 ..................................................54 3.1.5 Nomenclatura de prefijos .............................................................................56 3.1.6 Arquitectura de direccionamiento en IPV6 ..................................................57 3.1.6.1 Unicast .......................................................................................................57 3.1.6.1.1 Direcciones de enlace local (link-local) ...................................................59 3.1.6.1.2 Direcciones de sitio local- .......................................................................60 3.1.6.1.3 Direcciones de enrutamiento global (Global Address)- ...........................61 3.1.6.2 Identificador de interfaz– (EUI-64) .............................................................62 3.1.6.3 Direcciones reservadas..............................................................................64 3.1.6.3.1 La dirección no especificada ...................................................................64 3.1.6.3.2 Dirección Loopback ó dirección de bucle invertido. ...............................64 3.1.6.4 Anycast ......................................................................................................65 3.1.6.5 Multicast ....................................................................................................66 4. ESTRATEGIAS DE MIGRACIÓN ......................................................................72 4.1 DUAL STACK (PILA DUAL) .............................................................................73 4.2 CONFIGURED TUNNELS ...............................................................................74 4.2.1 Tunnel Broker ...............................................................................................75 4.2.2 Tunnel 6to4 ...................................................................................................77 4.2.3 Tunnel ISATAP .............................................................................................79 4.2.4 Tunnel 6over4. .............................................................................................81 4.2.5 Tunnel Teredo ...............................................................................................81 4.2.6 Dual Stack Transition Mechanism (DSTM) ...................................................84 4.3 MÉTODOS DE TRASLACIÓN .........................................................................88 4.3.1 SIIT, NAT-PT and NAPT-PT .........................................................................89 4.3.2 Transport Relay Translator (TRT) .................................................................90 4.3.3 Bump in the Stack .........................................................................................93 4.3.4 Bump in the API ............................................................................................96 4.3.5 SOCK ............................................................................................................98 5. CONFIGURACIÓN DE ESTRATEGIAS DE MIGRACIÓN .................................99 5.1 CONFIGURACIÓN: MÉTODO DE TUNNELS .................................................99 5.1.1 Túnel manual Cisco IOS ...............................................................................99 5.1.2 6to4 ............................................................................................................. 101 5.1.2.1 Cisco IOS (as Client and Relay)............................................................... 101 5.1.2.1.1 Configuración del cliente: ...................................................................... 101 5.1.2.1.2 Configuración como un relay 6to4:........................................................ 102 5.1.3 ISATAP ....................................................................................................... 102 5.1.3.1 Cisco IOS Platform (As Router/Server). ................................................... 103 6. ETAPAS DE PROCESO DE MIGRACIÓN PARA LAS PYMES. ..................... 104 6.1 PROYECTO DE TRANSICIÓN ...................................................................... 105 6.1.1 Elementos del modelo de proyecto de transición. ....................................... 105 6.1.1.1 Planificación y definición de la estrategia. Incluya la necesidad de la inversión............................................................................................................... 105 6.1.1.2 ¿Cómo está su red?, ¿Cuáles son sus servicio?, ¿Cuál es la mejor forma de migración? ...................................................................................................... 106 6.1.1.2.1 Redes de área local .............................................................................. 106 6.1.1.2.2 Red de área amplia (WAN) ................................................................... 107 6.1.1.2.3 Servicios multimedia (voz, video, aplicaciones de tiempo real). ........... 108 6.1.1.2.4 Aplicaciones empresariales/corporativas .............................................. 109 6.1.1.2.5 Clientes/Usuarios finales....................................................................... 109 6.1.1.2.6 Aplicaciones integrales de administración ............................................ 110 6.1.1.2.7 Políticas ................................................................................................ 110 6.1.1.3 Defina los equipos, servicios, soportes, y capacitación. .......................... 111 6.1.1.4 Integre sin interrupciones o vulnerabilidades. Defina paso por paso. ...... 111 6.1.1.5 Gerencia, resuelva. Repare. Reemplace, siempre manteniendo la red estable. ................................................................................................................ 112 6.1.1.6 Adapte la red y los servicios de acuerdo a los requisitos de la Pyme. ..... 112 CONCLUSIONES ................................................................................................ 113 BIBLIOGRAFÍA .................................................................................................... 115 ANEXO 1. RFC´s para IPV6 .............................................................................. 119 LISTA DE TABLAS Pág. Tabla 1: Entidades delegan, administran y distribuyen las direcciones IP .............26 Tabla 2: Descripción de los campos del Datagrama de encabezado IPV4 e IPV6 ........................................................................................................................40 Tabla 3: Orden de los encabezados de extensión .................................................42 Tabla 4 : Hop-by-hop Options ................................................................................53 Tabla 5 : Destination Options .................................................................................53 Tabla 6: Direcciones Multicast Reservadas ...........................................................66 Tabla 7: Posibilidades campo Scope .....................................................................69 Tabla 8: Técnicas de Túneles ................................................................................74 Tabla 9: Estructura de las direcciones Teredo .......................................................82 Tabla 10: Mecanismos de traslación de protocolos ...............................................88 Tabla 11: Etapas de proceso de migración para las Pymes ................................ 104 LISTA DE FIGURAS Pág. Figura 1: Datagrama de encabezado IPV4 ............................................................35 Figura 2: Datagrama de encabezado IPV6 ............................................................36 Figura 3: Header Chaining Examples ....................................................................41 Figura 4: Cabecera de enrutamiento durante transporte de datagramas ..............46 Figura 5: Proceso de fragmentación para un paquete IPV6 ................................49 Figura 6: Alcance de direcciones Unicast en IPV6 ................................................58 Figura 7: Estructura de dirección IPv6 enlace local. .............................................59 Figura 8: Estructura de dirección IPv6 para enrutamiento de uso local. ...............60 Figura 9: Estructura de dirección IPv6 para enrutamiento global..........................61 Figura 10: Conversión dirección MAC de 48 bits a 64 bits. (Identificador de Interfaz)...........................................................................................................63 Figura 11: Estructura de una dirección Multicast IPV6. .........................................67 Figura 12: Estructura de direcciones IPV6 Multicast (Prefijo Basado en direcciones Unicast)...........................................................................................................68 Figura 13: Estructura de una dirección Multicast en IPV6 - incorporado (RP) ......69 Figura 14: Funcionamiento Pila-Dual .....................................................................73 Figura 15: Funcionamiento de Tunnel Broker ........................................................76 Figura 16: Funcionamiento del Tunnel 6to4 ...........................................................78 Figura 17: Funcionamiento de Tunnel ISATAP .....................................................80 Figura 18: Funcionamiento Tunnel Teredo ............................................................83 Figura 19: Funcionamiento DSTM .........................................................................85 Figura 20: Funcionamiento Translation (NAT-PT) .................................................89 Figura 21: Funcionamiento Transport Relay Translator .........................................92 Figura 22: The BIS Protocol Stack .........................................................................94 Figura 23: The BIA Protocol Stack .........................................................................96 LISTA DE ANEXOS Pág. ANEXO 1. RFC´s para IPV6 .............................................................................. 119 GLOSARIO “Ámbito (Scope): Para las direcciones IPV6, el ámbito es la porción de la red a la que se supone que se va propagar el tráfico. BIT: Acrónimo de Binary digit. (Dígito binario). Un bit es un dígito del sistema de Numeración binaria. Mientras que en nuestro sistema de numeración decimal se usan diez dígitos, en el binario se usan solo dos dígitos, el 0 y el 1. Un bit o dígito binario puede representar uno de esos dos valores, 0 ó 1. Datagrama: Conjunto estructurado de bytes que forma la unidad básica de comunicación del protocolo. Dirección: Identificador asignado a nivel de la capa de red a un interfaz o conjunto de interfaces que puede ser empleado como campo de origen o destino en datagramas IPV6. Dirección MAC: Es un identificador de 48 bits (3 bloques hexadecimales) que corresponde de forma única a una tarjeta o dispositivo de red. Se conoce también como dirección física, y es única para cada dispositivo. Está determinada y configurada por el IEEE (los últimos 24 bits) y el fabricante (los primeros 24 bits) utilizando el Organizationally Unique Identifier. Dominio: Un dominio es la parte de una URL (dirección de una página o recurso en internet) por la que se identifica al servidor en el que se aloja. Estado del enlace: Tecnología de protocolo de ruteo, que intercambia información de rutas, que consta de los prefijos de las redes conectadas a un router y su costo asociado. La información del estado del enlace se anuncia en el arranque, así como cuando se detectan cambios en la topología de red. Flujo: Una serie de datagramas intercambiados entre una fuente y un destino que requieren un tratamiento especial en los routers intermedios, y definidos por una dirección IP origen y destino específico, así como por una etiqueta de flujo con un valor distinto a 0. Fragmentación: Proceso por el que se divide la carga de un datagrama IPV6 en fragmentos por la máquina emisora, de modo que todos los fragmentos tienen una MTU apropiada al camino a seguir hasta el destino. Gateway: Equipo encargado de proporcionar los servicios a un host. Interfaz: Una representación de un nexo físico o lógico de un nodo a un enlace. Un ejemplo de un interfaz físico es una interfaz de red. Un ejemplo de un interfaz lógico es un interfaz de un túnel. MTU: Unidad máxima de trasferencia (Maximum Trasfer Unit - MTU), expresa el tamaño en bytes del datagrama más grande que puede pasar por una capa de un protocolo de comunicaciones. NODO: Espacio real en el que confluyen parte de las conexiones de otros espacios reales o abstractos que comparten sus mismas características y que a su vez también son nodos. Todos estos nodos se interrelacionan entre sí de una manera no jerárquica y conforman lo que en términos sociológicos o matemáticos le llamamos red. Paquete: Unidad fundamental de trasporte de información en todas las redes de cómputo. Un paquete está generalmente compuesto de tres elementos: Una cabecera (header) que contiene generalmente la información necesaria para trasladar el paquete desde el emisor hasta el receptor, el área de datos (payload) que contiene los datos que se desean trasladar, y la cola (trailer), que comúnmente incluye código de detección de errores. RFC (Request For Comments): Documento de especificaciones que se expone públicamente para su discusión. Socket: Tupla compuesta por una dirección IP y un número de puerto. Tabla de ruteo: Conjunto de rutas empleadas para determinar la dirección e interfaz del siguiente nodo en el tráfico IPV6 enviado por un equipo o reencaminado por un router. Tunneling: Encapsulado de un protocolo IPV6 dentro de un protocolo IPV4 o viceversa. Router: Es un dispositivo hardware o software de interconexión de redes de computadoras que opera en la capa tres (nivel de red) del modelo OSI. Este dispositivo interconecta segmentos de red o redes enteras.”1 1 6SOS.Glosario IPV6: Eduardo Jacob Taquet, Alex Muñoz Mateos, Fidel Liberal Malaina.2004.pag 38. Fuente: http://www.6sos.org/documentos/glosario-IPv6-v1-2.pdf RESUMEN RESUMEN ABSTRACT En Colombia son pocas las PYMES In Colombia there are few PYMES que se encuentran trabajando hoy en that are working today on IPv6, some día sobre IPv6, unas porque no han because they have not seen the need visto la necesidad de la migración de for migration from IPv4 to IPv6 and IPv4 a IPv6 y otras porque temen others because they fear this change este cambio debido a que no because they do not have trained cuentan con personal capacitado. personnel. Es por eso que el proyecto busca That's why the project seeks to build construir el soporte documental que the supporting documentation that permita a los administradores de allows network administrators of the redes de las diferentes PYMES de various SMEs in Colombia, to analyze Colombia, analizar los aspectos the theoretical and technical aspects teóricos y técnicos asociados a la associated with the migration to the migración hacia el nuevo protocolo new Internet protocol, also providing a de internet, aportando además, un study and analysis on of the new estudio y análisis acerca de la nomenclature protocol "IPv6" in order nueva nomenclatura del protocolo to ensure proper handling of “IPV6”, con el fin de garantizar un information in organizations. manejo adecuado a la información Keywords: datagrams, IPV4, IPV6, de las organizaciones. fragment, header, address, strategy, Palabras Claves: datagramas, IPV4, dual stack, tunnel, translations. IPV6, fragmento, dirección, estrategia, túneles, traducción. encabezado, pila dual, INTRODUCCIÓN “En los últimos años, el gobierno, la academia y el sector privado, particularmente el financiero, han dirigido sus estrategias de apoyo y promoción de sus servicios hacia el sector de las micro, pequeñas y medianas empresas (MiPyMEs), al darse cuenta que es en este sector empresarial donde se puede tener el pivote para alcanzar un acelerado crecimiento de nuestra economía y aunque siempre se habían considerado importantes, hoy han llegado a ser imprescindibles al proyectarse como una de las mejores opciones para lograr la plena reactivación de nuestra economía, aún con todas sus falencias como es la falta de gestión organizacional, financiera, comercial, administrativa y tecnológica “2. En la parte tecnológica, los creadores de IPv4, a inicios de los 70 a pesar de disponer de un espacio de direcciones de 32 bits, es decir cuatro mil millones de direcciones (4.294.967.296) no era posible asimilar, el gran éxito que el protocolo iba a brindar y que iba a ser utilizado no sólo en computadores, sino también en diferentes dispositivos de manos libres que pudiesen manejar una conexión a internet. “Podemos recordar algunas ´famosas frases` que nos ayudaron a entender hasta qué punto, los precursores de la revolución tecnológica llegaron a plasmar afirmaciones erróneas. “Pienso que el mercado mundial de ordenadores puede ser de cinco unidades”, Thomas Watson, Presidente de IBM en 1943. 2 http://www.usergioarboleda.edu.co/civilizar/Pyme_Situacion_Colombia.htm 20 “640 Kbps De memoria han de ser suficientes para cualquier usuario”, Bill Gates, Presidente de Microsoft desde 1975. “32 bits proporcionan un espacio de direccionamiento suficiente para Internet”, Dr. Vinton Cerf, Padre de Internet, 1977”3. En 1.994 se presentó un primer proyecto para solucionar el problema del posible agotamiento de las direcciones IP existentes, siendo en 1.995 cuando se define este proyecto definitivamente como IPv6 y se establece la primera especificación. IPv6 (Internet Protocol Versión 6) es el último nivel del Internet Protocol (IP) y ahora forma parte del soporte IP en muchos productos tales como los sistemas operativos de computadoras, teléfonos, televisión y radio, sistemas de seguridad, tele-vigilancia, control, entre otros. Es un protocolo de 128bits, lo que hace que algunos cálculos sitúen el número de conexiones posibles en aproximadamente 34 trillones. Las PYMES en Colombia no cuentan con un protocolo que sea de ayuda para los administradores de redes, donde encuentren una información sólida y coherente, que los induzca a buscar una solución más rápida y más efectiva, para lograr la migración de IPv4 a IPv6, basados en un estudio y análisis acerca de la nueva nomenclatura del protocolo “IPV6” y especificaciones en seguridad en las redes, con el fin de garantizar un manejo óptimo a la información de las organizaciones. 3 Tomado de http://www.6sos.org/documentos/6SOS_Tutorial_IPv6_v4_0.pdf 21 1. DEFINICIÓN DEL PROBLEMA Existe una gran problemática en las organizaciones con el agotamiento de direcciones IPv4, por causa, entre otras cosas, del desperdicio que existe de las mismas, o a la gran cantidad de usuarios que ahora recurren a Internet, que ha aumentado de forma considerable, ya que no sólo los computadores se conectan a Internet, sino también otros objetos tecnológicos como las PDA, los celulares, consolas, entre otros. Las organizaciones, en particular las PYMES de Colombia, conocen la necesidad de la migración de IPv4 a IPv6, pero el más grande problema es que se desconoce cómo es realmente el procedimiento en la nueva nomenclatura, compatibilidad con los protocolos de conexión y los procedimientos que se deben llevar a cabo para no descuidar la parte de seguridad en la información o tener el inconveniente de ser desconectados. Es por ésto, que algunas empresas se privan de dar el paso a nuevos cambios en tecnologías, siendo la causa principal la falta de personal experto que pueda llevar a cabo una migración no traumática entre ambos protocolos. 22 1.1 OBJETIVO GENERAL Plantear un marco de referencia que permita a las PYMES de Colombia, la migración del protocolo IPv4 a IPv6, aportando la conceptualización asociada, así como las estrategias y mecanismos para hacer viable dicha migración. 1.2 OBJETIVOS ESPECÍFICOS Conocer las causas que llevaron a cambiar el sistema de direccionamiento IPV4 por IPV6. Definir las principales diferencias entre el Protocolo de Internet versión 4 y el Protocolo de Internet versión 6. Interpretar el funcionamiento que posee IPv6 y las nuevas funciones que ayudarán a las Pymes de Colombia en el manejo de las redes de información. Identificar los mecanismos de migración que ayudarán a las Pymes en Colombia para la transición de IPV4 a IPV6. 23 2. GENERALIDADES DE DIRECCIONAMIENTO 2.1 CONTEXTUALIZACIÓN DE IP “Una dirección IP es un identificador de cada host dentro de su red de datos” 4, se caracteriza por ser única, ya que no sería algo lógico que dentro de una misma ciudad existieran varios números telefónicos con un mismo código o dígito de marcación y con un mismo propietario. Las direcciones IP se caracterizan por conformarse en dos partes: Una de ellas, identifica a la red y la otra identifica a la máquina dentro de la red, teniendo en cuenta que todas las máquinas que pertenecen a la misma red requieren de un mismo número de Red el cual debe ser además único en internet. Se clasifican en: 2.1.1 Direcciones IPv4 públicas Las direcciones IPV4 públicas son aquellos espacios que se encuentran disponibles para internet, son únicas ya que no se puede manejar una misma dirección IP para darles conectividad a varios equipos, este tipo de direccionamiento es manipulado por los Proveedor de Servicios de Internet (ISP) para permitir brindar conectividad a usuarios. 4 IntroduccionDireccionesIP.pdf. Microsoft Word-direccionesIP.doc.2004.pag 7. Fuente: http://www.educa.madrid.org/cms_tools/files/a8dae6a3-c890-4d13-a8fc5e928c9a98ec/ IntroduccionDireccionesIP.pdf 24 2.1.2 Direcciones IPv4 privadas Las direcciones IPV4 son aquellos tipos de direcciones que han sido reservadas para la administración de redes privadas, se caracterizan porque manejan un direccionamiento que no permite el acceso a la red pública. Algunos rangos en el direccionamiento IPV4 fueron reservados para la operación de este tipo de redes. Manejan algo en común a las redes públicas que son únicas e irrepetibles, para permitir la conectividad de los diferentes dispositivos que se encuentren dentro de la red. 2.1.3 Direcciones reservadas Las direcciones reservadas son grupos de direcciones que han quedado para un uso específico. Las más importantes son las siguientes: 0.0.0.0 (o la dirección .0 de cualquier subred). Esta es la dirección para referirse a la red. 255.255.255.255 (o la dirección .255 de cualquier subred). Esta es la dirección de broadcast. Equivale a todos los terminales de la red. 127.X.X.X Este es el rango de ip’s de loopback. Son para referirnos a nosotros mismos (nuestra máquina). También llamadas de diagnóstico. 127.0.0.1 (o localhost) Es un caso particular del anterior. Es la más usada para referirnos a nuestra máquina de manera local. IPV4 inicialmente sólo se pensó que permitiría dar conexión a equipos de cómputo, pues en la década de los años 80 internet no estaba extendido más allá de los ambientes científicos, universitarios y gubernamentales, pero debido a los avances tecnológicos que se están dando en nuestro futuro se requiere que cada 25 equipo que desee compartir información cuente con una dirección ip que le permita una conexión permanente a internet para así contar con acceso inmediato a la información. En estos momentos la IANA (Internet Assigned Numbers Authority), siendo la entidad que supervisa mundialmente la asignación del direccionamiento IPV4 realizó entrega de los últimos 7 bloques conformado cada uno por 16.777.216 direcciones, a los cinco RIR (Regional Internet Registry); pues éstas son las entidades que atienden y administran la delegación y distribución de las direcciones IP (Versión 4 -Versión 6), en todo el mundo, segmentado para estos propósitos en cinco regiones: LACNIC (América Latina y el Caribe), ARIN (América del Norte), RIPE NCC (Europa, Oriente Medio y Asia central), APNIC (Asia y Pacífico) y AFriNIC (África). Tabla 1: Entidades que delegan, administran y distribuyen las direcciones IP Fuente: http://lacnic.net/sp/politicas/manual2.html 26 “La última voz de alarma la levantó el Registro de Direcciones de Internet para América Latina y el Caribe (Lacnic), en un comunicado emitido en junio de este año donde se informó que en la actualidad quedan disponibles menos del 18% del total, proyectando que para el año 2011 el stock de IPv4 estaría totalmente agotado.”5 El agotamiento de direccionamiento IPv4 se originó debido al crecimiento de usuarios, aplicaciones, servicios y dispositivos que requieren de una dirección IP que les permita estar conectados para el compartimiento de información. Otra de las posibles causas para que esto ocurriera fue la asignación que se dio en los comienzos, pues no se tenían en cuenta los tipos de necesidades que las organizaciones requerían o la existencia de éstas, pues asignaron amplios bloques de direcciones IP a empresas individuales y organizaciones. Desafortunadamente, el control estricto de asignación de direcciones IP que existe en la actualidad no siempre estuvo presente y supondría un gran esfuerzo realizar el seguimiento de qué direcciones no se utilizan. Actualmente, la ICANN tendría la posibilidad de reclamar estos rangos y volver a expedir las direcciones a otras personas. Sin embargo, puede suponer mucho tiempo y dinero volver a numerar una red y probablemente muchas organizaciones se opondrían, hasta el punto de emprender acciones legales. Con la intención de resolver el agotamiento en el direccionamiento se desarrollaron algunos mecanismos o estrategias que han permitido extender la vida de IPv4 tales como: 5 Fuente: http://www.dcc.uchile.cl/sites/default/files/DCC-Inside/FCFM%2040_ Se%20agotan%20 direcciones%20IP.pdf 27 2.2 TRADUCCIÓN DE DIRECCIÓN DE RED (NAT) “Es un mecanismo que permite la traducción de direcciones privadas en públicas y viceversa. Accede a que una red tenga conexión con otra, siendo éstas de diferentes rangos de direccionamiento IP para el envío o recibo de paquetes”6. Para que una red privada tenga acceso a internet, se debe realizar por medio de un dispositivo ubicado en la frontera de las dos redes, que tenga configurado NAT para la traducción de direcciones. Este dispositivo NAT cambia y traduce la dirección origen en cada paquete de salida y el puerto de origen para que sea único. Estas traducciones de dirección se almacenan en una tabla, para recordar qué dirección y puerto le corresponde a cada dispositivo cliente y así saber dónde deben regresar los paquetes de respuesta. Ésto ayuda a garantizar la seguridad, ya que cada petición saliente o entrante debe pasar por un proceso de traducción que ofrece la oportunidad de verificar y autenticar la solicitud. NAT también se conserva en el número de direcciones IP globales que una empresa necesita y permite a la empresa utilizar una única dirección IP en su comunicación con el mundo. 2.2.1 Problemas de NAT “Este mecanismo no puede utilizarse en terminales móviles y además, muchas aplicaciones son incapaces de ser utilizadas mediante este tipo de 6 http://www.buenastareas.com/ensayos/Traductor-De-Direcci%C3%B3n-De-Red-Nat/2113453.html 28 direcciones, especialmente las relacionadas con la autenticación y la seguridad de las comunicaciones. Las tablas NAT son de gran tamaño, provocando que exista un bajo rendimiento en la red, debido a la saturación que éstas le pueden generar. Aumenta la probabilidad de pérdida de direcciones, debido a que se manejan tablas de enrutamiento muy extensas. Hace difícil el funcionamiento de ciertas aplicaciones, como las que requieren de mayor velocidad, por ejemplo video-conferencia y videojuegos. Esconde la identidad de hosts que se encuentren dentro de la red, evitando que los administradores cuenten con información propia”7. 2.3 IP MULTICAST Multicast IP es una tecnología de ancho de banda de conservación que reduce el tráfico de manera simultánea a la entrega de un único flujo de información a miles de potenciales beneficiarios de las empresas y hogares. IP Multicast proporciona el tráfico de aplicaciones de origen a múltiples receptores sin cargar la fuente o los receptores durante el uso de un mínimo de ancho de banda de red. Paquetes de multidifusión se replican en la red en el punto donde los caminos divergen por los routers, lo que resulta en la prestación más eficiente de datos a múltiples receptores. De acuerdo con la Internet Assigned Numbers Authority (IANA), su directriz RFC3171 específica que las direcciones 224.0.0.0 a 239.255.255.255 se designan como direcciones de multidifusión. 7 http://technet.microsoft.com/es-es/library/cc739126(WS.10).aspx 29 3. CONTEXTUALIZACIÓN DEL DIRECCIONAMIENTO IPV6 3.1 IPV6 “El protocolo de Internet versión 6 [RFC2460], es una tecnología que entrará poco a poco a reemplazar a la versión 4, su desarrollo contribuye en la búsqueda de soluciones a las problemáticas existentes en IPV4, está fue diseñada como la evolución del IPv4 presentando características de seguridad y mejor funcionamiento.”8 Desde inicios del protocolo de Internet se han podido realizar algunos desarrollos que permitieron un mejor desempeño de éste, así actualmente se encuentra en funcionamiento la versión 4. Este protocolo cuenta con un espacio de direcciones de 32 bits, es decir (4.294.967.296), siendo esta cantidad muy limitada, pues con el transcurso del tiempo se ha visto aún más la necesidad del aprovechamiento del protocolo, pues las empresas que generan nuevos avances tecnológicos, ofrecen día a día a usuarios públicos o privados nuevos tipos de productos y servicios a través de la internet. Debido a la falta de direccionamiento IP, se desarrolló IPV6, que a inicios de su creación se llamó como: IPng (Protocolo de Internet de Nueva Generación), que promete dar solución a 8 los problemas del direccionamiento, dándole un http://repositorio.utpl.edu.ec/bitstream/123456789/3735/1/004x679.pdf 30 mejoramiento en capacidad del envío de la información, la seguridad, la facilidad y el rendimiento en los equipos. “La nueva versión del protocolo usa direcciones de 128 bits lo cual equivale a tener 2^128 = 340.283.366.920.938.463.463.374.607.431.768.211.456 direcciones IP, que es representado en formato hexadecimal, esta cantidad de nuevas direcciones, podrán ser utilizadas por miles de millones de usuarios que requieran servicios en las diferentes plataformas que necesitan las direcciones IP como, las páginas Web, los dispositivos móviles como teléfonos celulares, PDA´s, dispositivos de consumo, vehículos, nuevas tecnologías de acceso como xDSL. De esta manera esta versión del protocolo permite solucionar el grave problema de direccionamiento que hoy en día se debe enfrentar con la versión 4.”9 3.1.1 Características principales de IPV6 con respecto a IPV4 “Como se ha comentado, IPv6 fue diseñado como una evolución natural a IPv4. Es decir, todo lo que funcionaba perfectamente en IPv4 se ha mantenido, lo que no funcionaba se ha eliminado, y se ha tratado de añadir nuevas funciones manteniendo la compatibilidad entre ambos protocolos” 10 . Las características principales de IPv6 son Capacidades de Direccionamiento Extendida “IPv6 incrementa el tamaño de dirección IP de 32 bits a 128 bits, para dar soporte a más niveles de direccionamiento jerárquico, un número mucho mayor de nodos direccionables, y una autoconfiguración más simple de direcciones. La 9 http://es.scribd.com/doc/44342778/Tdg-Ipv4-Ipv6-18n0v 10 http://www.ramonmillan.com/tutoriales/ipv6_parte1.php 31 escalabilidad del enrutamiento multienvío se mejora agregando un campo "ámbito" a las direcciones multienvío. Y se define un nuevo tipo de dirección llamada "anycast", usada para enviar un paquete a cualquiera de un grupo de nodos. Simplificación del Formato de Cabecera Se realizaron algunas modificaciones en el formato de la cabecera de IPV4, siendo para IPV6 más simple, pues posee menor cantidad de campos, sus estructuras y contenidos han sido mejorados; optimizando los recursos que utiliza, pues se han eliminado algunos campos repetitivos que ya se representaban anticuados, incrementando algunas características para hacer frente a las nuevas necesidades de las redes actuales, como comunicación en tiempo real y seguridad. Soporte Mejorado para las Extensiones y Opciones Los cambios en la manera en que se codifican las opciones de la cabecera IP permiten un reenvío más eficiente, límites menos rigurosos en la longitud de opciones y mayor flexibilidad para introducir nuevas opciones en el futuro. Capacidad de Etiquetado de Flujo Una nueva capacidad se agrega para permitir el etiquetado de paquetes que pertenecen a "flujos" de tráfico particulares para lo cual el remitente solicita tratamiento especial, como la calidad de servicio no estándar o el servicio en "tiempo real". 32 Capacidades de Autenticación y Privacidad Extensiones para utilizar autenticación, integridad de los datos, y (opcional) confidencialidad de los datos, se especifican para el IPv6.”11 Características de movilidad. “IPV6 permite que la comunicación pueda llevarse a acabo en cualquier momento y lugar con un óptimo grado de operabilidad, así como de forma trasparente al usuario, permitiéndole realizar su propia gestión y control. Cuestiones de gran importancia si queremos disfrutar de servicios multimedia en los terminales móviles de última generación (VozIP y Video). Protocolos como MPI (Mobile IP) o HMIP (Hierarchical MIP) posibilitan la implantación y explotación real de estos servicios. Autoconfiguración de los nodos. La autoconfiguración de direcciones es más simple. Especialmente en direcciones Globales Unicast, los 64 bits superiores son asignados por un mensaje desde el router (Router Advertisement) y los 64 bits más bajos son asignados con la dirección MAC (en formato EUI-64). En este caso, el largo del prefijo de la subred es 64, por lo que no hay que preocuparse más por la máscara de red. Además el largo del prefijo no depende del número de hosts por lo tanto la asignación es más simple. 11 http://www.rfc-es.org/rfc/rfc2460-es.txt. 33 Calidad de servicio y clases de servicios. Capacidad de una red para sostener un comportamiento adecuado del tráfico que transita por ella, cumpliendo con parámetros relevantes para el usuario final.” IPv6 fue diseñado con soporte extendido a QoS. En el encabezamiento se han incluido dos campos relacionados a QoS, éstos son: Clase de tráfico e Identificador de Flujo. Multihoming. Es la facilidad que se da a las empresas o instituciones que desean realizar el cambio de un proveedor a otro por algún motivo, no necesitaría cambiar de dirección, ni la realización de una nueva configuración de los equipos de comunicación. Es decir cumple con la facilidad de realizar el cambio de ISP´s (Proveedor de Servicios de Internet)”12. 3.1.2 Datagramas de encabezado IPV4 e IPV6 En la figura 1 se ilustra el encabezado de IPv4, que se encuentra conformado por 12 campos en su cabecera, éste será modificado en la nueva versión IPV6; pues uno de los motivos fundamentales que llevan a que estos campos (Tipo de servicio, indicadores, identificación y control de errores) sean eliminado, es por la redundancia de bits en algunos de éstos, manejando la misma información de diversas formas. 12 http://repositorio.utpl.edu.ec/bitstream/123456789/3735/1/004x679.pdf 34 El tamaño máximo de un datagrama es de 65536 bytes. Sin embargo, este valor nunca es alcanzado porque las redes no tienen suficiente capacidad para enviar paquetes tan grandes. Además, las redes en Internet utilizan diferentes tecnologías por lo tanto el tamaño máximo de un datagrama varía según el tipo de red. Campos que mantienen su nombre IPV4 en IPV6 Campos que se eliminarán en IPV6 Campos que cambian de nombre y Posición en IPV6 Campo nuevo en IPV6 bits 4 8 Versión Cabecera 16 TOS 32 Longitud Total Identificación TTL 20 Indicador Protocolo Desplazamiento de Fragmentación Checksum Dirección Fuente de 32 bits Dirección Destino de 32 bits Opciones Figura 1: Datagrama de encabezado IPV4 Fuente: http://docipv62009.blogspot.com/ En la Figura 2, IPV6 (RFC 2460), muestran un enfoque diferente donde la longitud de la cabecera básica es de 40 bytes, siendo el doble que en el caso de IPV4, pero con grandes ventajas, pues se ha simplificado el formato a tan solo 8 campos y con un tamaño constante, permitiendo reducir el tiempo de procesamiento en 35 routers y conmutadores, incluso mediante hardware, generando una mayor facilidad en el procesamiento de los paquetes. Además se ha introducido el concepto de flujo, consiguiendo que los routers, fuera de encaminar, puedan conmutar algunos de los paquetes que procesan. Por otro lado, se ha mejorado el mecanismo de codificación de los campos optativos en la cabecera, dando una mayor flexibilidad para la introducción de nuevas opciones futuras. Finalmente, IPv6 ha mejorado las capacidades de autentificación y privacidad de los datos transmitidos. De esta forma, en IPv6 una cabecera de autentificación garantiza que un paquete procede del origen que realmente se indica, mientras que en IPv4 el paquete podría venir de un origen distinto al indicado en la cabecera. Es decir, todo lo que funcionaba perfectamente en IPv4 se ha mantenido, lo que no funcionaba se ha eliminado, y se ha tratado de añadir nuevas funciones manteniendo la compatibilidad entre ambos protocolos como se describe en la tabla 2. bits 4 Versión 12 16 Clase de Trafico 24 32 Etiqueta de Flujo Longitud de la Carga Útil Siguiente Cabecera Limite de Salto Dirección de Fuente de 128 bits Dirección de Destino de 128 bits Figura 2: Datagrama de encabezado IPV6 Fuente: http://mundopc.net/ipv6-la-proxima-generacion-de-internet/ 36 Campo Descripción Encabezado IPV6 (4bits) Indica la versión del protocolo IP, en este caso su valor es igual a 6. El tener este Versión (“Version”) campo al comienzo del paquete, facilita una rápida identificación de la versión IP y el paso de ese paquete al protocolo de proceso apropiado: IPV4 o IPV6. Campo Renombrado Tipo de servicio (TOS): IPV4 (8 bits) Incluye información que permite a los “routers” clasificar el tipo de tráfico al que el paquete pertenece, aplicando distintas Clase de tráfico (“Traffic políticas de enrutamiento según sea el caso. Class”): IPV6 Realiza la misma función que el campo “Type of Service” de IPv4. Nuevo Campo en IPV6 (20 bits) Identifica a un flujo determinado de paquetes, Etiqueta de flujo permitiendo a los “routers” identificar rápidamente paquetes que deben ser tratados de la misma manera, como 37 aquellos con una calidad de servicio de no default o de tiempo real. También simplifica (“Flow Label”) el proceso de ruteo, manteniendo el rastro de a dónde va el flujo fuente/destino y hacer una búsqueda en las tablas. Campo Renombrado (16 bits) Indica el tamaño de la carga útil del paquete. Las cabeceras adicionales son Longitud total: IPV4 consideradas parte de la carga para este cálculo. El campo Payload Length es similar al campo longitud total de IPv4, excepto que Longitud de la carga útil las 2 medidas operan. Payload Lengh (“Payload Length”): IPV6 (IPV6) mide los datos después del encabezado, mientras Total Length (IPv4) mide los datos y el encabezado. Campo Renombrado (8 bits) identifica el encabezado inmediatamente siguiente de IPV6. Tiene dos Protocolo: IPV4 funciones, Determinar: 38 Options; IPV4 la cabecera de extensión siguiente. Identificar el protocolo de capa Siguiente Cabecera superior a la que el datagrama debe pasar. (“Next Header”): IPV6 Este campo utiliza los mismos valores de Protocol en IPV4. Campo Renombrado (8 bits) Indica el máximo número de saltos que puede realizar el paquete. Este valor es disminuido en uno por cada nodo que reenvía el Tiempo de vida: IPV4 paquete. Si el valor llega a cero, el paquete es descartado, y un mensaje ICMP se envía al remitente. Este campo es similar al campo Timeto_Live (TTL) encontrado en IPV4, con una excepción clave. El campo Hop Limit (IPV6) Límite de saltos mide el máximo de saltos que puede ocurrir mientras el paquete es enviado por varios (“Hop Limit”): IPV6 nodos. El campo TTL en IPV4 puede ser medido en saltos o segundos. Nótese que en Hop Limit usado en IPv6, la base del tiempo no está disponible más. 39 Dirección de fuente (128 bits) indica la dirección origen del (“Source Destination emisor del paquete. El formato de este Address”) campo es definido más ampliamente en el RFC 2373. (128 bits) Indica la dirección de destino final Dirección de destino (“Source Destination del paquete. Address”): Tabla 2: Descripción de los campos del Datagrama de encabezado IPV4 e IPV6 Fuente: Elaboración del autor 3.1.3 Encabezados de extensión13-14 El diseño de IPv6 simplifica el encabezado que se venía manejando en IPV4. Los diseñadores le brindaron otro enfoque en lugar de colocar campos opcionales al final de datagrama como se venía haciendo en IPV4, siendo éstos remplazados para IPV6 como cabeceras de extensión que permiten añadirse únicamente si se requiere, es decir, si es necesario fragmentar el datagrama, el encabezado de la fragmentación es puesto en él. 13 http://www.normes-internet.com/normes.php?rfc=rfc2460&lang=es 14 RFC 2460-Protocolo de Internet, versión 6(IPV6).Diciembre 1998 40 La Figura 3 ilustra algunos ejemplos de encadenamiento de cabecera. El primer datagrama es evidente IPv6 y TCP, el segundo contiene una cabecera de extensión simple (ruta) y la cadena de datagrama tercero incluye dos cabeceras de extensión (de enrutamiento y fragmento). a) Plain datagram (no extension headers) IPV6 Header Next=6(TCP) TCP segment b) Datagram containing Routing header IPV6 Header Next=43(Routing) Routing Header Next=6(Routing) TCP segment c) Datagram containing Routing and Frament headers IPV6 Header Next=43(Routing) Routing Header Next=44(Routing) Fragment Header Next=6(TCP) TCP segment Figura 3: Header Chaining Examples Fuente: http://tools.ietf.org/html/rfc2460 3.1.3.1 Orden de los encabezados de extensión (opcional)15 La tabla 3 muestra los encabezados de extensión de IPv6 (RFC 2460) que deben admitir todos los nodos de IPv6. 15 http://dmrodriguez.50megs.com/IPV6/IPV6_7.html 41 Value (Decimal) Extensión Header 0 Hop- by- hop option 60 Destination Options Header 43 Routing Header 44 Fragment Header 51 Authentication Header (AH) 50 Encapsulating Security Payload Header. Destination Option 60 Protocolos 6 TCP 8 EGP 9 IGP 17 UDP 46 RSVP 47 GRE 58 ICMP Tabla 3: Orden de los encabezados de extensión Fuente: http://dmrodriguez.50megs.com/IPV6/IPV6_7.html 42 3.1.3.1.1 Hop-by-Hop Options Header El encabezado Hop-by-Hop Options sirve para llevar información opcional que debe ser examinada por cada nodo a lo largo de una ruta de la entrega del paquete. Consta de un formato que contiene tres campos: Next Header (encabezado siguiente): Tiene como finalidad identificar el encabezado que da paso o continuidad a la opción hop-by-hop. Utiliza los mismos valores que en el campo Protocol que se maneja en IPv4, además contiene 8 bits de longitud. Header Extension Length (Longitud de extensión de encabezado): Es el número de bloques de 8 bytes del encabezado de extensión Hop-by-Hop Options, sin incluir los 8 primeros bytes. Contiene un tamaño de 8 bits de longitud. Options (Opciones): Es un entero múltiplo de 8 octetos de largo. Una opción es un encabezado dentro del encabezado de opciones de hop-by-hop que describe una característica específica de la entrega del paquete o proporciona relleno. Cada opción se codifica en el formato tipo-longitud-valor (TLV), que se utiliza comúnmente en los protocolos TCP/IP. El tipo de opción identifica a la opción y determina el tipo de tratamiento por parte del nodo de procesamiento. La longitud de la opción identifica su longitud 3.1.3.1.2 Destination Options Header La cabecera Opciones de destino se utiliza para llevar información opcional que necesita ser analizada por el (los) nodo(s) del destino del paquete(s). La cabecera 43 Opciones de Destino se identifica mediante el valor de 60 en el campo Next Header del encabezado procedente, y su formato contiene los siguientes campos: Next Header (encabezado siguiente): Tiene como finalidad identificar el encabezado que da paso o continuidad a la opción de destino de cabecera. Utiliza los mismos valores que en el campo Protocol que se maneja en IPv4, [RFC-1700], Además contiene 8 bits de longitud. Header Extension Length (Longitud de extensión de encabezado): Es el tamaño del encabezado de extensión Options Header, al momento de ser medido es dividido en bloques de 8 octetos, sin incluir los 8 primeros bytes, su tamaño en longitud es de 8 bits. Options (Opciones): Es un entero múltiplo de 8 octetos de largo. Cada opción se codifica en el formato tipo-longitud-valor (TLV), que se utiliza comúnmente en los protocolos TCP/IP. El tipo de opción identifica a la opción y determina el tipo de tratamiento por parte del nodo de procesamiento. La longitud de la opción identifica su longitud. El encabezado Destination Options se utiliza de dos maneras: Si hay un encabezado Routing (Enrutamiento), especifica opciones de entrega o de proceso en cada destino intermedio. Especifica opciones de entrega o de proceso en el destino final. 3.1.3.1.3 Routing Header IPv6 utiliza el encabezado de extensión Routing para definir una ruta de origen, una lista de destinos intermedios para que el paquete viaje por su ruta de acceso 44 al destino final. El encabezado Routing se identifica mediante el valor 43 en el campo Next Header (Encabezado siguiente) del encabezado anterior. Su formato contiene los siguientes campos: Next Header (encabezado siguiente): Se define del mismo modo que en el encabezado de extensión Hop-by-Hop Options, pues identifica el encabezado que continúa inmediatamente al encabezado routing. Header Extension Length (Longuitud de extensión de encabezado): Se define del mismo modo que en el encabezado de extensión Hop-by-Hop Options, mide la longitud del encabezado routing en unidades de tamaño de 8 bytes, teniendo en cuenta que los 8 primeros bytes no son tenidos en cuenta. Routing Type (Tipo de enrutamiento): Contiene una longitud de 8 bits, el RFC2460 define una variante simple, el encabezado Routing Type 0. Los datos específicos del tipo de enrutamiento son una lista de direcciones de destinos intermedios que serán visitadas durante la ruta del paquete. Cuando el paquete IPv6 llega a un destino intermedio, se procesa el encabezado Routing y la dirección del siguiente destino intermedio (según el valor del campo Segments Left) se convierte en la dirección de destino del encabezado de IPv6. Segments Left (Segmentos que quedan): Contiene una longitud de 8 bits, indica el numéro de nodos que quedan, es decir, el número de nodos intermedios explícitamente listados que todavía séran visitados antes de alcanzar el destino final. La figura 4, contiene el número de elementos de la secuencia. Cuando se entrega a la dirección de destino (en realidad el primer puesto de control) el router 45 encuentra el servicio de enrutamiento encabezado y se da cuenta que es sólo una estación intermedia. Por lo tanto, los swaps de la dirección en el destino Dirección y la dirección enésima desde atrás de la secuencia de cabecera de enrutamiento (donde N es el actual valor de los Segments Left). Segments Left es que disminuyó en un 1 y datagrama se envía a los nuevos destinos (que es el próximo punto de control). Este procedimiento se ejecuta en cada punto de control. Como se puede ver el encabezado de Segments Left en realidad separa las direcciones que ya han pasado y las direcciones que se visitarán en la secuencia del punto de control. Cuando el destinatario ve que Segmentos Left contiene cero, se sabe que este es el destino final de los datagramas, el datagrama será procesado y se pasa al protocolo de capa superior. S X Y source: S Z source: S D source: S source: S IPV6 Destination: X Routing Seg. left: 3 Address[1]:Y Address[2]:Z Address[3]:D IPV6 Routing IPV6 Destination: Y Seg. left: 2 Address[1]: Y Address[2]: Z Address[3]: D Routing Destination: Z Seg. left: 1 Address[1]: X Address[2]: Y Address[3]: D IPV6 Routing Destination: D Seg. left: 0 Address[1]: X Address[2]: Y Address[3]: Z Figura 4: Cabecera de enrutamiento durante transporte de datagramas Fuente: http://www.networkdictionary.com/Networking/Routing-Header.php 46 3.1.3.1.4 Fragment Header16 El encabezado Fragment es usado por una fuente IPV6 para trasmitir paquetes que son más grandes de los que cabrían en la unidad máxima de trasmisión (MTU). Si el datagrama IPv6 es más largo que el MTU, los datos deben dividirse y se inserta en el conjunto de datagramas IPv6 más pequeños, llamados fragmentos. La presencia del encabezado Fragment es identificada por un valor de 44 en el campo Next Header del encabezado procedente. Estos fragmentos son transportados de forma individual y acoplados por el receptor para crear el datagrama original. Esta es la fragmentación. El nodo receptor recoge los fragmentos y utiliza valores de identificación para el grupo de los correspondientes fragmentos, gracias a la particularidad de ser capaz de darles el orden correcto. Cuando los datos se encuentran completos y no existen fragmentos más a la izquierda, se encuentra en capacidad de reconstruir el datagrama original. El encabezado Fragment contiene 6 campos: El campo Next Header tiene 8 bits de largo e identifica el encabezado que continúa inmediatamente al header Fragment. El campo Reserved tiene 8 bits de largo, y está reservado para uso futuro. Este campo es inicializado en cero para la transmisión e ignorado en la recepción. El campo Fragment Offset es un entero sin signo de 13 bits que mide la compensación, en unidades de 8 octetos, de los datos que continúan este 16 Darwing Lamarck Santono Yunes.IPV6:Nueva Generación Protocolo de Internet.2004.pag 172 Fuente: http://www.lac.ipv6tf.org/docs/tutoriales/IPv6-LACTF.pdf 47 encabezado, relativo al comienzo de la parte fragmentable del paquete original. El campo reservado tiene 2 bits de largo, y está reservado para uso futuro. Este campo es inicializado en cero para la trasmisión e ignorado en la recepción. La bandera M es de 1 bit de longitud y determina si más fragmentos vienen (M=1) o si éste es el último fragmento (M=0). La identificación es única para cada datagrama original. Se utiliza para detectar los fragmentos del mismo datagrama (sosteniendo los mismos valores de identificación), este campo es generado por el nodo fuente, y contiene un tamaño de 32 bits de largo. La figura 5, muestra el proceso que se lleva al fragmentar un paquete IPV6, éste se divide inicialmente en una parte que se puede fragmentar y otra parte que no se puede fragmentar: Para un paquete IPV6, en la parte que no se puede fragmentar, éste tiene la característica que el paquete original debe ser procesado por cada nodo intermedio entre el nodo de fragmentación u origen y el destino. Esta parte consta del encabezado de IPv6, el encabezado Hop-by-Hop Options (Opciones de salto a salto), el encabezado Destination Options (Opciones de destino) para destinos intermedios y el encabezado Routing. Para un paquete IPV6,en la parte que se puede fragmentar sólo debe procesarse en el nodo de destino final, se encuentra constituida de un encabezado Authentication, el encabezado Encapsulating Security Payload (Carga de seguridad de encapsulación), el encabezado Destination Options para el destino final y la unidad PDU de nivel superior. 48 Parte no Fragmentable Parte Fragmentable Paquete Ipv6 original Parte no Fragmentable Parte no Fragmentable Parte no Fragmentable Encabezado de fragmento Fragmento 1 Encabezado de Fragmento Fragmento 2 Encabezado de Fragmento Ultimo fragmento Fragmentos Figura 5: Proceso de fragmentación para un paquete IPV6 Fuente: http://dmrodriguez.50megs.com/IPV6/IPV6_7.html 3.1.3.1.5 Authentication Header 17 Permite la autenticación de los datos, efectuando una comprobación del nodo que realiza el envío del paquete, además aprueba que los datos no sean modificados y sean íntegros durante el envío. El encabezado Authentication, que se describe en RFC 2402, forma parte de la arquitectura de seguridad para el Protocolo Internet definida en RFC 2401. 17 RFC2402 Authentication Header Noviembre 1998 49 El encabezado Authentication contiene 6 campos: El campo Next Header Identifica el encabezado que continúa inmediatamente al encabezado Authentification. Posee 8 Bits de largo. El campo Payload Length (Longitud del encabezado), tiene 8 bits de longitud y provee la longitud del encabezado Authentication en palabras de 32 bits, menos 2 (los primeros 8 octetos del encabezado Authentication no son contados). El valor mínimo es 1, que consiste en el valor de Authentification de 96 bits (3 palabras de 32 bits), menos el valor 2 (3-2=1). Este mínimo es solo usado en el caso de un algoritmo de autenticación “nulo”, empleado para procesos de depuración. El campo Reserved está reservado para usos futuros. Es inicializado en cero para la trasmisión. El campo Security Parameters Index (SPI o Índice de parámetros de seguridad) identifica una asociación de seguridad (SA) IP (IPSec, IP Security) específica. La asociación de seguridad, como se define en el RFC 2401, es una conexión simple y lógica que es creada para propósitos de seguridad. SA puede comprimir muchos parámetros, incluyendo el algoritmo Authentication, claves del algoritmo de authentication y otros. Según RFC 2402, el valor de SPI = 0 puede ser usado para propósitos locales, de implementación específicas. Otros valores, en el rango de 1 – 255, son reservados para uso futuro por la Internet Assigned Numbers Authority (IANA). El campo Sequence Number (Número de secuencia) proporciona protección contra la reproducción, tanto el contador el contador del que envía como el que recibe son inicializados en cero cuando una asociación de seguridad es establecida. Contiene un número de 32 bits. 50 Authentication Data (Datos de autenticación) que contiene un valor de comprobación de integridad (ICV, Integrity Check Value). ICV proporciona autenticación de datos e integridad. Es un campo de longitud variable, pero debe ser múltiplo integral de 32 bits. 3.1.3.1.6 Encapsulating Security Payload Header 18 El encabezado Encapsulating Security Payload (ESP) (RFC 2406), proporciona servicios de autenticación de origen de datos, provee confidencialidad, integridad sin conexión, un servicio anti-“replay” y confidencialidad de flujo limitado de tráfico para la carga encapsulada. El encabezado ESP contiene 7 campos: Security Parameters Index (SPI o Índice de parámetros de seguridad) es un campo obligatorio, que identifica la asociación de seguridad para este datagrama, relativo a la dirección IP destino en el encabezado IP con el que este encabezado de seguridad es asociado, y relativo al protocolo de seguridad empleado. El campo Next Header tiene 8 bits de largo e identifica el encabezado que inmediatamente continúa al encabezado ESP. El campo Sequence Number (Número de secuencia) proporciona protección contra la reproducción. El contador del que envía y el contador del que recibe son inicializados en cero cuando una asociación de seguridad es establecida. 18 RFC2406.IP Encapsulation Security Protocol (ESP). Noviembre 1998 51 El campo Payload Date es de longitud variable que contiene datos descritos por el campo Next Header, es un campo obligatorio. El campo Padding (Relleno), puede opcionalmente contener 0 – 255 octetos de información de relleno, como requerimiento por la implementación de seguridad. El campo Padding Length (Longitud de relleno) indica el número de octetos de relleno (0 - 255). El campo Authentication Data (Datos de autenticación) es de longitud variable, contiene el valor de comprobación de integridad (ICV) calculado sobre el paquete ESP menos los de autenticación de datos. El campo Authentication Date es opcional, y es incluido sólo si esa asociación de seguridad ha seleccionado servicio de autenticación. 3.1.3.1.7 Destination Options Header Proporciona información adicional relacionada con el datagrama o sus procesamientos. Están separados en dos grupos: Las opciones dedicadas a cada nodo de reenvío del datagrama (opciones hop-by-hop), y las opciones destinadas a la acogida destino único (destino opciones). En la Tabla 4 se muestran las opciones de Hop-by-hop (si existe), se colocan al comienzo de la extensión de la cadena de cabeceras, porque son importantes para cada nodo de reenvío del datagrama. La Tabla 5 muestra la ubicación de opciones de destino, éstas se dividen en dos tipos: Opciones dedicadas a la meta final (que se encuentran en el extremo de la extensión de la cadena de cabeceras) y las opciones asignadas al siguiente host 52 especificado por cabecera de enrutamiento (que se encuentra justo antes de la cabecera de enrutamiento). Value Meaning 0 Pad1 1 PadN 5 Router alert 194 Jumbo payload Tabla 4 : Hop-by-hop Options Fuente: http://www.secdev.org/projects/scapy/files/scapy6.py Value Meaning 0 Pad1 1 PadN 201 Home Address Tabla 5 : Destination Options Fuente: http://www.secdev.org/projects/scapy/files/scapy6.py 53 El significado de cada opción es el siguiente: PadN Pad1 (Relleno): Ellos no tienen ningún contenido, simplemente alinean el contenido siguiente a la posición adecuada. Alerta de Router (Router alert): Brinda asesoramiento al router en el contenido que puede ser importante. Carga útil Jumbo (Jumbo payload): Permite el transporte de datagramas que excedan el máximo de 64 KB. La opción hop-by-hop pide un tratamiento especial que es necesario para procesar estos jumbogramas. Domicilio (Home Address): Es una parte del apoyo a la movilidad. Contiene la dirección de viaje del nodo móvil. 3.1.4 Representación del direccionamiento IPV619 Las direcciones IPv6 tienen una forma diferente de representarse a las IPv4, a continuación se relacionan éstas: Forma hexadecimal: Una dirección IPV6 válida es representada por valores hexadecimales, los cuales se dividen en ocho piezas de 16 bits de dirección. x:x:x:x:x:x:x:x 19 http://www.normes-internet.com/normes.php?rfc=rfc2373&lang=es 54 Forma comprimida: Existen reglas que pueden ser aplicadas a las direcciones IPV6 con el objetivo de resumir un poco la sintaxis de las direcciones. 2001:0000:0000: 1234:0000:A1A0:ABEF:0816 Puede aceptar lo siguiente: Las letras pueden ser mayúsculas o minúsculas y las dirección se puede escribir como: 2001:0000:0000:1234:0000:a1a0:abef:0816 Los “ceros” consecutivos son opcionales y se pueden representar en la dirección como: 2001:0:0: 1234:0:a1a0:ABEF:0816 Los campos sucesivos de “ceros” pueden ser reemplazados por “::” y la dirección puede tomar la forma : 2001::1234:0:A1A0:ABEF:816 Pero, cualquier dirección que tenga más de una vez la representación “::” será una dirección inválida ya que solamente se puede usar esa representación una sola vez. 55 Forma mixta. Esta forma combina las direcciones IPv4 e IPv6. Una forma alternativa que a veces es más conveniente cuando se trata de un entorno mixto de nodos IPv4 e IPv6. x: x: x: x: x: x: dddd, donde las 'x' son los valores hexadecimales de las seis partes de 16 bits de orden superior de la dirección, y las 'd' son los valores decimales de las cuatro piezas de orden inferior de 8 bits de la dirección (representación estándar IPv4). Ejemplos: 0:0:0:0:0:0:13.1.68.3 0:0:0:0:0: FFFF: 129.144.52.38 o en forma comprimida: :: 13.1.68.3 :: FFFF: 129.144.52.38. 3.1.5 Nomenclatura de prefijos La representación de los prefijos IPv6 se realiza del siguiente modo: dirección-IPv6 /longitud-del-prefijo, donde dirección-IPv6 = una dirección IPv6 en cualquiera de las notaciones válida. longitud-del-prefijo = valor decimal indicando cuántos bits contiguos de la parte izquierda de la dirección componen el prefijo. 56 Ejemplo: Una representación legal de los 60 bits de prefijo es: 12AB00000000CD3 (hexadecimal): 12AB: 0000:0000: CD30: 0000:0000:0000:0000 / 60 12AB:: CD30: 0:0:0:0 / 60 12AB: 0:0: CD30:: / 60 3.1.6 Arquitectura de direccionamiento en IPV6 20 3.1.6.1 Unicast Es una dirección para una sola interface. Un paquete enviado a una dirección unicast es entregado sólo a la interfaz identificada con dicha dirección. Cada dirección IPV6 pertenece a un ámbito, que es un área dentro de la cual ésta puede ser utilizada como un identificador único de una o varias interfaces. En el caso de las direcciones unicast se podrían reflejar en ámbitos de diferentes tipos como se muestra en la figura 6. 20 RFC4291IP Version 6 Addressing Architecture Febrero 2006 57 MISMO NODO O LOOPBACK DIRECCION DE ENLACE LOCAL DIRECCIONES SITIO LOCAL DIRECCIONES GLOBALES Permite la comunicación con origen y destino en un mismo nodo IPV6 Identifica todos los dispositivos dentro de un dominio cualquiera de nivel 2. Identifica todos los dispositivos ubicados en un dominio administrativo, que normalmente contiene múltiples enlaces distintos. Identifica a todos los dispositivos que pueden alcanzarse a través de internet. Figura 6: Alcance de direcciones Unicast en IPV6 Fuente: https://proyectos.i-nis.com.ar/projects/4/wiki/IPv6 58 3.1.6.1.1 Direcciones de enlace local (link-local)21 En IPV6 las direcciones de enlace local han sido diseñadas para direccionar un mismo enlace para propósitos de autoconfiguración (mediante identificadores de interfaz), descubrimiento del vecindario, o situaciones en las que no hay routers. Por tanto, los routers no pueden retransmitir ningún paquete con direcciones fuente o destino que sean locales de enlace (su ámbito está limitado a la red local). FE80::/10 = FE80:0:0:0:/10 10bits 54 bits 1111111010 0 64 bits Interface ID (EUI-64) Figura 7: Estructura de dirección IPv6 enlace local. Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es Como se muestra en la figura 7, la estructura de las direcciones unicast de enlace local se encuentra conformada por 10 bits que identifican el prefijo, los siguientes 54 bits después de este campo deberán estar en ceros y por ultimo hay un campo que consta de 64 bits el cual se configura con la dirección MAC de cada máquina con el fin de que no se vaya a repetir ninguna dirección en la red. 21 RFC3513,Protocolo de Internet versión 6 (IPv6) Abordar Arquitectura, abril 2003 59 3.1.6.1.2 Direcciones de sitio local22-23 Las direcciones locales de sitio se definen en el RFC4193, éstas permiten Identificar interfaces en un mismo ‘sitio’ local u organización, sin la necesidad de un prefijo global. Se configuran mediante un identificador de subred de 16 bits, los routers no deben trasmitir fuera del sitio ningún paquete cuya dirección fuente o destino sea “local destino” (su ámbito está limitado a la red local o de la organización). Han sido desaprobadas en el RFC 3879, debido a que, pese a quedar definidas teóricamente, en la práctica su definición es ambigua, lo que supone un problema tanto para los desarrolladores de aplicaciones como para los routers. Aunque hayan sido desaprobadas, esto no ha impedido su uso, por lo menos hasta que se haya estandarizado el cambio y éstas hayan sido reemplazadas. Se encuentran conformadas por un formato que se muestra en la figura 8. fec0::/10 10bits 54 bits 64 bits 1111111011 ID Subred Interface ID (EUI-64) Figura 8: Estructura de dirección IPv6 para enrutamiento de uso local. Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es 22 23 RFC 4193 Unique local direcciones IPv6 Unicast, Octubre 2005 RFC3879 Obsoleto sitio de las direcciones locales , Septiembre 2004 60 3.1.6.1.3 Direcciones de enrutamiento global (Global Address)24-25 El prefijo de enrutamiento global ha sido diseñado para ser estructurado jerárquicamente por los RIR's (Regional Internet Registries) y los ISP's (Internet Service provider), pues son las direcciones utilizadas para el tráfico IPV6. Se encuentran conformadas por un formato que se ilustra en la Figura 9. 2001: ó 3ffe 3bits 45 bits 001 16 bits Prefijo Ruteable global ID Subred Provider 64 bits Interface ID (EUI-64) site Host Figura 9: Estructura de dirección IPv6 para enrutamiento global. Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es El prefijo 001 es asignado a un rango de direcciones Unicast globales agregables, éste además incluye 4 campos que permiten establecer los niveles de identificación. 24 25 RFC 3587 Direccion de enrutamientos globales, Agosto 2003 RFC2450 Proyecto de TLA y NLA reglas de asignación, Diciembre 1998 61 Para asignar este prefijo se utiliza la tabla de niveles de identificador de agregación (TLA) que contiene el más alto nivel de información sobre direcciones de enrutamiento y su tamaño es de 13 bits, lo cual limita el número del más alto nivel de rutas a 8192. La propuesta para la asignación de TLA está documentada en RFC 2450. El campo Reserved, que tiene 8 bits de longitud, está provisto para permitir la expansión más amplia de campos TLA o NLA. El campo próximo nivel de identificador de agregación (NLA), es usado por las organizaciones para crear una jerarquía de direccionamiento e identificar sites, su tamaño es de 24 bits. El identificador de la subred. El extremo de la red puede ser dividido en subredes. Esta parte de la dirección sirve para identificar las subredes individuales. 3.1.6.2 Identificador de interfaz– (EUI-64) Los identificadores de interfaz en las direcciones IPV6 unicast se utilizan para identificar interfaces en un determinado enlace. Se encuentra definido en el RFC 3513. Para las direcciones unicast en IPV6 las “Interface ID” deben de ser de 64 bits, por lo que, para convertir una dirección de enlace IEEE 802 48-bit MAC se requiere de la conversión de la dirección MAC en una versión modificada EUI-64, que está relacionada con el séptimo bit del identificador de 64 bits. Este bit 62 distingue identificadores globales (en todo el mundo unicast). El valor de este bit se invierte en las direcciones IPv6. El valor 0 de este bit indica una identificación local, mientras que un valor de 1 indica una identificación global. Además se inserta el valor entre el tercero y cuarto byte de la dirección MAC para alcanzar los 64 bits necesarios. Por ejemplo, la dirección MAC 00:8 C: a0: c2: 71:35 se convierte a la interfaz 028c ID: a0ff: FEC2: 7135 (la conversión se ilustra en la Figura 10). 0 0 : 8 C : A 0 : C 2 : 7 1 : 3 5 0010 0000 0000 1000 1100 1010 0000 1100 0010 0111 0001 0011 0101 0000 Invertir 7mo Bit Insertar cadena FFFE 0 0 0 0 0 0 1 0 1 0 0 0 1 1 0 0 1 0 1 0 0 0 0 0 1111 1111 1111 1110 1 1 0 0 0 0 1 0 0 1 1 1 0 0 0 1 0 0 1 1 0 1 0 1 EUI-64 0 2 8 C : A 0 F F : F E C 2 : 7 1 3 5 Figura 10: Conversión dirección MAC de 48 bits a 64 bits. (Identificador de Interfaz). Fuente: http://generalidadesipv6.blogspot.com/2009_11_01_archive.html 63 3.1.6.3 Direcciones reservadas26 3.1.6.3.1 La dirección no especificada La dirección 0:0:0:0:0:0:0:0 toma como nombre dirección no especificada, de forma abreviada se representa “0::0” o “::”. Nunca debe ser asignada a ningún nodo, pues indica la ausencia de una dirección. Un ejemplo de uso de esta dirección es en el campo dirección origen de un paquete IPv6 enviado por un host durante su proceso de inicialización, antes de que haya obtenido su propia dirección. La dirección de no especificada no puede ser usada como dirección origen para paquetes salientes, y un paquete con la dirección no especificada como destino nunca puede ser enviado fuera del nodo ni debe ser encaminado por los routers. 3.1.6.3.2 Dirección Loopback ó dirección de bucle invertido. La dirección unicast 0:0:0:0:0:0:0:1, se define como dirección loopback, ésta puede ser utilizada por un nodo destino para el envío de un paquete IPV6 a sí mismo. La dirección loopback no debe ser utilizada como fuente de la dirección en Paquetes IPv6 que se envían fuera de un solo nodo. Un paquete IPv6 con una dirección de destino de loopback nunca debe ser enviado fuera de un solo nodo y nunca debe ser remitido por un router IPv6. 26 Belén Aldecoa Sánchez del Río Luis Alberto Ramón Surutusa. Redes de Banda Ancha IPV6.pag 53. Fuente: http://es.scribd.com/doc/51187582/6/Direcciones-Unicast 64 3.1.6.4 Anycast27 Una dirección anycast es un identificador que se asigna a múltiples interfaces (típicamente pertenecen a diferentes nodos). Un paquete enviado a una dirección Anycast es entregado en una (cualquiera) de las interfaces identificadas con dicha dirección (la más próxima, de acuerdo a las medidas de distancia del protocolo de encaminamiento). Nos permite crear, por ejemplo ámbitos de redundancia, de forma que varias máquinas puedan ocuparse del mismo tráfico según una secuencia determinada (por el routing) si la primera “cae”. Una dirección anycast es difícil de distinguir. No hay un rango de espacio dedicado a este tipo de direcciones, pues ocupan el mismo rango de direcciones Unicast. La configuración local es responsable de identificación de las direcciones de difusión ilimitada. El uso de este tipo de direcciones es brindar una identificación a un conjunto de routers que pertenecen a una organización que proporciona los servicios de internet, o para identificar un conjunto de routers conectados a una red particular. Las direcciones Anycast no deben de ser utilizadas como una dirección de origen de un paquete IPV6, son rangos que son asignados por el administrador de la red o proveedor de servicios, para uso exclusivo de identificación de los router y no para asignación de los host. 27 http://www.normes-internet.com/normes.php?rfc=rfc4291&lang=es 65 3.1.6.5 Multicast 28 Se define en el RFC 3513, este tipo de direcciones cumple como un Identificador para un conjunto de interfaces (por lo general pertenecientes a diferentes nodos). Un paquete enviado a una dirección multicast es entregada a todas las interfaces identificadas por dicha dirección. La misión de este tipo de paquetes es evidente: aplicaciones de retrasmisión múltiple (Broadcast), teniendo en cuenta que para IPV6 no existen direcciones de Broadcast, las funciones son realizadas por direcciones multicast. En la Tabla 6 se ilustra el número de direcciones Multicast Reservadas y nunca serán asignadas a ningún grupo. Direcciones Multicast Reservadas FF00:0:0:0:0:0:0:0 FF01:0:0:0:0:0:0:0 FF02:0:0:0:0:0:0:0 FF03:0:0:0:0:0:0:0 FF04:0:0:0:0:0:0:0 FF05:0:0:0:0:0:0:0 FF06:0:0:0:0:0:0:0 FF07:0:0:0:0:0:0:0 FF08:0:0:0:0:0:0:0 FF09:0:0:0:0:0:0:0 FF0A:0:0:0:0:0:0:0 FF0B:0:0:0:0:0:0:0 FF0C:0:0:0:0:0:0:0 FF0D:0:0:0:0:0:0:0 FF0E:0:0:0:0:0:0:0 FF0F:0:0:0:0:0:0:0 Tabla 6: Direcciones Multicast Reservadas Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es 28 RFC3513,Protocolo de Internet versión 6 (IPv6) Abordar Arquitectura, abril 2003 66 Las direcciones Multicast en IPV6 se identifican por el prefijo ff00:: / 8. Así que cada dirección de multidifusión se inicia con "ff", que los hace fáciles de distinguir. El octeto siguiente a la inicial obligatoria “ff” contiene cuatro banderas y un valor de 4 bits que define el alcance de multidifusión, como se muestra en la figura 11. 128 Bits 8 Bits FF 11111111 4 Bits Flags 4 Bits Scope X 0 R 0 P 0 112 Bits Group ID T 0= Permanente 1= Temporal Figura 11: Estructura de una dirección Multicast IPV6. Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es El campo flags contiene cuatro flags (banderas) de 1 bit. Los 3 bits de las banderas más significativas están reservados para uso futuro y son inicializados en cero. La bandera T como se describe en el RFC 3513, indica si la dirección de multicast es permanente (valor 0) o transitoria (valor 1). En el caso de las direcciones transitorias (valor 1), éstas se clasifican en: Direcciones generales transitorias: Son las direcciones con todas las banderas a 0, pero el T bit con valor 1. Este tipo de direcciones se pueden utilizar para sesiones de pruebas. 67 Prefijo basado en direcciones Unicast para IPV6: Ver en la figura 12. Se caracterizan por tener las dos primaras banderas en cero y la bandera P y T se definen en 1. El RFC 3306 [RFC3306]29 define una manera de obtener direcciones de este tipo. FF Flags 8 4 Scope 4 res Plen 8 X 0 Prefix 8 64 R 0 P 1 Group(ID) 32 bits T 1 Figura 12: Estructura de direcciones IPV6 Multicast (Prefijo Basado en direcciones Unicast). Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es Direcciones incorporadas (Punto de encuentro (RP)): El RFC 3656 [RFC3656] 30 define una manera de integrar RP (Rendezvous Point). El problema se reduce con la asignación de direcciones de RP incorporado porque no puede haber una colisión sólo entre las direcciones derivadas del mismo RP. Ver en la figura 13. 29 RFC 3306 Unicast-Prefijo basado en direcciones IPv6 Multicast, agosto 2002 30 RFC3656 Rendezvous Point, Diciembre 2003 68 FF Flags scope res 8 4 4 Rpad plen 4 8 4 X 0 R 1 Prefix 64 P 1 Group ID 32bits T 1 Figura 13: Estructura de una dirección Multicast en IPV6 - incorporado (RP) Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es El campo de posibilidades hace que sea posible controlar el alcance de la emisión deseada con mucha facilidad. Ésto fue hecho en IPv4 con el valor TTL. El campo de alcance tiene un impacto importante en el proceso de asignación, ya que tiene que ser especificado para cada asignación. Ver tabla 7. Scope o alcance Significado 0 1 2 3 4 5 6 7 8 9 A B C D E F Reservado Alcance de Nodo local Alcance de link local Sin Asignar Administración de ámbito local Alcance local del sitio Sin Asignar Sin Asignar Alcance de organización local Sin Asignar Sin Asignar Sin Asignar Sin Asignar Sin Asignar Alcance Global Reservado Tabla 7: Posibilidades campo Scope Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es 69 Los restantes 112 bits de la dirección de multidifusión mantienen la identificación del grupo. Si en el bit T-bandera conjunto, el identificador es válido dentro de su ámbito de aplicación solamente, esto significa que el mismo identificador puede utilizarse fuera el alcance o de diferente alcance para hacer frente a otro grupo. Si la dirección no es transitoria, la dirección es independiente del ámbito de aplicación. Su significado sigue siendo el mismo y el alcance sólo limita la propagación del subgrupo de participantes. Definiciones adicionales de la estructura exterior del grupo de multidifusión ID se proporcionan en [ RFC3306 ]. Por ejemplo, el grupo (permanente) identificador 101 (hexadecimal) se ha asignado a todos los servidores NTP. Si alguien envía un datagrama dirigido a este grupo, el alcance de las direcciones tendran el siguiente significado: FF01:: 101 - todos los servidores NTP en la misma interfaz FF02:: 101 - todos los servidores NTP en el mismo enlace ff0e:: 101 - todos los servidores NTP en toda la Internet El alcance es un principio innovador que ofrece un mecanismo para restringir la distribución de multidifusión. El tiempo de vida de datagrama (TTL) se utiliza en IPv4 para resolver el mismo problema. La parte correspondiente de la dirección que define el ámbito de la red, en la distribución no podrá ser superior - los datagramas no pueden cruzar el límite de sus ámbito de aplicación. Por ejemplo, puede estar seguro de que los datagramas dirigida ff02: nunca saldrá de la red física a la que se han enviado. Algunas direcciones de multidifusión son reservadas, tiene significado predefinido. Otras son simplemente prohibidas, al igual que las direcciones que contengan todos los grupos de identificador cero y una bandera de T en cero. El RFC 3513 define el significado de algunas direcciones de multidifusión, de hecho 70 sustituciones de las emisiones anteriores. Éstas permiten el envío de paquetes a todos los nodos o routers dentro de un ámbito determinado. FF01:: 1 - todos los nodos en la misma interfaz FF02:: 1 - todos los nodos en el mismo enlace (capa 2 de red) FF01:: 2 - todos los routers en lala misma interfaz FF02:: 2 - todos los routers en el mismo enlace FF05:: 2 - todos los routers en el mismo sitio Otro tipo de dirección multicast, es de nodo solicitado, ésta facilita la consulta eficaz de los nodos de la red durante la resolución de direcciones. IPv6 utiliza el mensaje de solicitud de vecino para efectuar la resolución de direcciones. Sin embargo, en lugar de utilizar la dirección para todos los nodos de ámbito local del vínculo como destino del mensaje de solicitud de vecino, que afectaría a todos los nodos IPv6 del vínculo local, se utiliza la dirección de multidifusión de nodo solicitado. La dirección de multidifusión de nodo solicitado consta del prefijo FF02::1:FF00:0/104 y los últimos 24 bits de la dirección IPv6 que se esté resolviendo. El resultado de utilizar la dirección de multidifusión de nodo solicitado es que la resolución de direcciones, que suele producirse en un vínculo, no necesita utilizar un mecanismo que afecte a todos los nodos de la red. De hecho, son muy pocos los nodos que se ven afectados durante la resolución de direcciones. En la práctica, debido a la relación entre la dirección MAC de Ethernet, el Id. de interfaz IPv6 y la dirección de nodo solicitado, ésta actúa como una dirección de pseudounidifusión para lograr una resolución de direcciones muy eficaz. 71 4. ESTRATEGIAS DE MIGRACIÓN La transición de IPv4 a IPv6 no es sencilla, por lo cual se debe realizar de forma gradual ya que la coexistencia entre el protocolo actual y la versión IPV6 es un hecho, y tarde o temprano se tiene que producir un cambio de direcciones de 32 a 128 bits sin afectar a los servicios que se prestan en la actualidad. El primer paso hacia la transición es la instalación de equipos y aplicaciones que tengan capacidad para procesar los paquetes generados por ambos protocolos, por lo que este proceso debe ir acompañado por un mecanismo que conjuntamente con los DNS (Domain Name System), transformen los dominios actuales en direcciones de 128 bits, a su vez se debe diseñar una política encaminada a guiar a los nuevos usuarios hacia el protocolo IP versión 6. Hoy en día existen algunos mecanismos que permiten la coexistencia y la migración progresiva tanto de las redes como de los equipos de usuario. En general, los mecanismos de transición se clasifican en tres grupos: Dual Stack (Pila dual) Túneles Traducción 72 4.1 DUAL STACK (PILA DUAL)31 Es una de las técnicas más utilizadas en la migración de IPV4 a IPV6, ya que puede emplearse en diferentes puntos de la red: equipos clientes, servidores y routers. Como se ilustra en la figura 14. No habrá comunicación entre IPv4 e IPv6; sin que las aplicaciones soporten ambos modos. El desafío con dual stack es que todos los equipos de la red han de contar con la suficiente potencia de proceso y memoria, para gestionar dos pilas IP diferentes. Además, gestionar dos pilas IP supone un doble gasto en gestión y soporte, lo que incrementa los costes de TI. Figura 14: Funcionamiento Pila-Dual Fuente: http://www.6deploy.org/workshops/20101011_santa_cruz_bolivia/DIA4-1Consulintel_IPv6_ES_Mecanismos_Transicion.pdf 31 RFC2893 Mecanismos de transición para hosts y router IPv6 ,Agosto 2000 73 4.2 CONFIGURED TUNNELS32 Esta es una técnica que se define en el RFC 2893, encapsula las comunicaciones de uno de los protocolos sobre el otro, estableciendo para ello un túnel de comunicación (similar a una VPN). Para ello necesitaremos contar con dual stack en cada uno de los puntos del túnel. Los routers involucrados en este método han de ser capaces de mapear las direcciones del contrario. Este tipo de túneles point to point necesitan ser configurados manualmente, para el control de las rutas del túnel, y para reducir el alto nivel de ataques al servicio. En la tabla 8 se muestra las diferentes técnicas de túneles. Técnicas de Túneles Tunnel Broker Tunnel 6to4 Tunnel ISATAP Tunnel 6over4 Tunnel Teredo Dual Stack Transition Mechanism (DSTM) Tabla 8: Técnicas de Túneles Fuente: Elaboración del autor 32 RFC 2893 - Mecanismos de transición para hosts y router IPv6. Agosto 2000 74 Se debe tener en cuenta que los túneles IPV6 en IPV4 pueden ser utilizados por el protocolo de enrutamiento OSPFv3, porque IS-IS se basa en la capa 2, mientras los túneles IPV6 en IPV4 están totalmente en capa 3. La dificultad de ingeniería de este método hace que su desarrollo a gran escala sea de una complejidad extrema, y hará que para la mayoría de las organizaciones, se deba recurrir al soporte de ingenieros expertos ya sean internos o externos. 4.2.1 Tunnel Broker33 En lugar de configurar manualmente cada extremo del túnel es posible el uso de scripts ejecutables en su lugar. Esta alternativa "automática" se llama un "Tunnel Broker" y se presenta en el RFC 3053. Al igual que los túneles configurados manualmente, el Tunnel Broker es útil donde un usuario tiene una gran cantidad de dual stack dentro una red IPv4. La idea básica de un Tunnel Broker es permitir al usuario conectarse a un servidor web, opcionalmente permite entrar en algunos detalles de autenticación, y recibir de vuelta un pequeño script para ejecutar y establecer un túnel IPv6 en IPv4 al servidor de Tunnel Broker.como se ilustra en la figura 15. El proveedor del servicio del Tunnel Broker debe ofrecer un servidor web disponible a través de IPv4 o un router de dual-stack capaz de aceptar comandos 33 RFC 3053-Ipv6 Tunnel Broker. Enero 2001 75 automatizados de configuración para crear nuevos túneles a los extremos de cliente. Es posible que ambas funciones puedan servir desde una sola máquina. Figura 15: Funcionamiento de Tunnel Broker Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin Dunmore, September 2005. 442p Un túnel broker se puede implementar de muchas maneras y no está limitado a túneles IPv6 en IPv4. También pueden ser utilizados los túneles GRE o Capa 2. El requisito para el servicio es que necesita mantener el seguimiento de los túneles creados y a quien pertenecen. Lo ideal es que deban tener alguna autenticación para permitir el acceso al servicio, pero en la práctica la implementación no se requiere. 76 El servicio de Tunnel Broker es generalmente fácil de usar para el cliente, pero hay algunas preocupaciones acerca de la implementación de sistemas de servidores, por ejemplo, en la seguridad de acceso, y en la reasignación de los túneles donde los clientes dan uso dinámico de direcciones IPv4. Un Tunnel Broker es una ayuda importante de transición, que permite un fácil uso de acceder a la red IPv6. Los proveedores de túneles pueden ser desplegados por sitios locales (universidades, empresas) o por las redes nacionales. Si no hay ningún Tunnel Broker disponible para un participante nacional, brokers remotos se puede utilizar, pero reducirá probablemente la eficiencia de los túneles. 4.2.2 Tunnel 6to434 El mecanismo de transición conocido como Túnel 6to4 [RFC3056] es una forma automática de permitir la comunicación de router a router por medio del túnel, facilitando a los dominios aislados en IPv6 comunicarse con otros dominios IPv6 con una configuración mínima. La IANA asignó el prefijo IPv6 2002:: / 16 para designar un sitio donde participar. Al sitio de IPv6 se le asignará un prefijo de 2002: V4ADDR::/ 48, donde V4ADDR es el rango dirección única en IPv4, configurada en la interfaz del router de salida apropiada al dominio (vea la Figura 16). 34 RFC 3056 - Conexión de Dominios IPv6 a través de nubes IPv4. Febrero 2001 77 Figura 16: Funcionamiento del Tunnel 6to4 Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin Dunmore, September 2005. 442p Este prefijo tiene exactamente el mismo formato que los prefijos normales / 48 y por lo tanto permite un dominio IPv6 para utilizarlo como cualquier otro prefijo válido / 48, en el escenario donde los dominios 6to4 desean comunicarse con otros dominios 6to4. Los extremos del túnel son determinados por el valor del prefijo de enrutamiento global de la dirección IPv6 de destino contenida en el paquete IPv6 que se transmite e incluye la dirección IPv4. En este escenario, un número arbitrario de dominios 6to4 se puede comunicar sin necesidad de configurar el túnel, además los routers 6to4 no necesitan ejecutar ningún protocolo de enrutamiento externo en IPV6, como sucede en el caso del enrutamiento IPV4 externo que realiza la tarea. 78 Cuando los dominios 6to4 desean comunicarse con los dominios que no pertenecen al 6to4, la situación es un poco más compleja. En este caso, la conectividad entre los dominios se realiza a través de un enrutador de retransmisión, que es esencialmente un router que tiene al menos una interfaz 6to4 lógica y al menos un interfaz nativo IPv6. A diferencia del escenario anterior, IPv6 de enrutamiento externo debe ser utilizado. El enrutador de retransmisión anuncia la 6to4 2002: / con prefijo 16 en el dominio de enrutamiento IPv6 nativo. Además, el enrutador de retransmisión puede anunciar las rutas IPv6 nativa dentro de su conexión 6to4. El mecanismo 6to4 es utilizado generalmente para routers IPv6, ubicado en un sitio fronterizo con conectividad externa IPv4 para establecer conectividad automática a Internet IPv6, además otros métodos (ISATAP o la creación de redes nativas IPv6 si está disponible) se pueden emplear dentro del sitio. 4.2.3 Tunnel ISATAP35 Una alternativa a 6over4 es ISATAP (Intra-Site Protocolo de direccionamiento automático de túnel). ISATAP también usa el sitio infraestructura IPv4 como un vínculo virtual, pero no utiliza IPv4 multicast, por lo que el enlace es NBMA (nonbroadcast multiple Access). Véase en la figura 17. ISATAP, como 6over4, crea un identificador de interfaz basado en la dirección IPv4. ISATAP es compatible con una configuración automática o manual de direcciones, pero la dirección IPv4 de la interfaz se integrará como los últimos 32 35 RFC 4214 - Intra Site automático túnel abordar Protocol (ISATAP). Octubre 2005 79 bits de las direcciones IPv6. Al igual que 6over4, la dirección IPv4 sólo necesita ser única en la red en la que el servicio se despliega. Figura 17: Funcionamiento de Tunnel ISATAP Fuente: http://technet.microsoft.com/en-us/library/bb727021.aspx Por lo general, multicast se utiliza para las operaciones de descubrimiento de vecinos, resolución de la dirección y enrutamiento de direcciones. Desde la dirección IPv4 se constituye la dirección IPv6 y la resolución de la dirección es eficiente. Para trabajar solicitudes en el router anfitrión se debe haber aprendido las direcciones IPv4 de enrutadores ISATAP(a través de DHCP, DNS, etc), luego se omitirán respuestas ante la solicitud de un host.. ISATAP se ha implementado en algunas plataformas como Windows XP y el IOS, aunque se ha retirado de USAGI Linux, los autores consideran que si bien tienen 80 una aplicabilidad en algunos sitios, en otros se presenta una falencia debido a que no cumple con las especificaciones requeridas para el aplicativo. 4.2.4 Tunnel 6over436. 6over4 se define en el RFC 2529. Interconecta hosts IPv6 aislados en un sitio a través de IPv6 en IPv4 sin encapsulación explícita de túneles. Utiliza las direcciones IPv4 como identificadores de interfaz y crea un enlace virtual usando un grupo de multidifusión IPv4 con ámbito de organización local. El método 6over4 ha caído en desuso debido a una serie de razones, incluyendo la falta general de IPv4 multicast en las redes de ISP. Ha habido un pequeño número de implementaciones, incluyendo los de 3Com y Cisco, pero prácticamente no son adoptados. Por tanto, no se considera 6over4 en detalle, pues el método es obsoleto y por lo tanto no sería recomendado su uso. 4.2.5 Tunnel Teredo37 El mecanismo de transición Teredo, es una forma de túnel automático destinado a proporcionar conectividad IPv6 con direcciones IPv4 que se encuentran detrás de un NAT [RFC1613]. Se trata de un mecanismo de túnel automático que proporciona conectividad IPv6, cuando un host de dual-stack se localiza detrás de un NAT, para encapsular paquetes IPv6 en IPv4 el usuario se basa en el Protocolo de Datagramas de Mensajes (UDP). 36 RFC 2529 - Transmisión de paquetes IPv6 sobre IPv4. Marzo 1999 37 RFC 4380 - Teredo: Tunneling IPv6 sobre UDP. Febrero 2006 81 Como se ilustra en la Figura 18, el servicio Teredo emplea dos componentes, un servidor Teredo y un relay Teredo, con el fin de proporcionar conectividad IPv6 Teredo para clientes ubicados detrás de un NAT. A diferencia de otros mecanismos de túneles, Teredo encapsula los paquetes IPv6 en UDP (en lugar de directamente sobre IPv4). El puerto UDP (3544) es utilizado por el servidor Teredo para escuchar las peticiones de los clientes Teredo. Las direcciones Teredo tienen la siguiente estructura: 32 bits 32 bits 16 bits 16 bits 32 bits Teredo Prefix IPV4 Address of Teredo Server Flags Mapped Client UDP Port Mapped Client IPv4 Address Tabla 9: Estructura de las direcciones Teredo Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin Dunmore, September 2005. 442p Tanto el "Mapped Client UDP Port" y el "Mapped Client IPV4 Address" son confusos, cada bit de la dirección y el número de puerto están de modo inverso, pues las reglas de las direcciones IPv6 especifican que todas las direcciones unicast e identificadores de interfaz requieren ser de 64 bits, excepto aquellos que comienzan con el valor binario 000. Por lo tanto el campo flags ha de ser codificado para cumplir con este requisito. El servidor Teredo escucha las peticiones de los clientes Teredo, respondiendo con una dirección IPv6 para su uso. El servidor Teredo reenvía los paquetes IPv4IPv6 encapsulados enviados desde el Teredo client o el Teredo relay. El servidor también envía paquetes IPv6 recibidos desde el Teredo relay, que están destinados para un cliente Teredo, a la correspondiente dirección IPv4 y el puerto 82 UDP del cliente. El relay Teredo actúa como un router IPv6 y reenvía los paquetes destinados a los clientes del servidor, además permite la accesibilidad del servicio Teredo a la red IPv6. Figura 18: Funcionamiento Tunnel Teredo Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin Dunmore, September 2005. 442p Al analizar el formato de dirección Teredo IPv6 se evidencia que la especificación de Teredo hace poco uso del espacio de direcciones IPv6 con respecto a la asignación de los prefijos de enrutamiento. Es por esto que el relay Teredo debe anunciar la accesibilidad del servicio para el resto de la red IPv6. El prefijo de 32 bits es común para todos los servidores Teredo, por lo que el relay debe anunciar prefijos IPv6 que consten del prefijo Teredo más la dirección IPv4 del servidor 83 Teredo. Esto significa que los prefijos de enrutamiento para los diferentes servidores Teredo se deben asignar en la red IPv6. En teoría, esto podría significar la asignación de un prefijo de enrutamiento en la red IPv6 para cada sitio donde se utiliza NAT en IPv4. Como tal, el servicio Teredo sólo debe utilizarse como un "último recurso" donde la conectividad directa IPv6 o la unión de enrutar 6to4 con la NAT no es posible. Además, el método Teredo es muy complejo y no puede garantizar el trabajo en todos los NATs. Debido a la variación en la implementación de NAT. 4.2.6 Dual Stack Transition Mechanism (DSTM) DSTM (mecanismo de transición de doble pila) es una solución de túnel para las redes IPv6. El tráfico IPV4 es tunelizado sobre el dominio IPv6 hasta que alcance una puerta de entrada IPv6/IPv4, que está a cargo del paquete de encapsulación, desencapsulación y del transporte entre los dominios IPV6 e IPV4. La solución propuesta por DSTM es transparente a cualquier tipo de aplicación de IPv4 y permite el uso de la capa 3 de seguridad. Por lo general, un esquema de túnel necesita de una dirección IPv4 para cada host que se desee conectar a internet IPV4. DSTM reduce esta restricción asignando dinámicamente direcciones sólo por la duración de la comunicación, haciendo esto posible a través de varios host que compartan la misma dirección en una larga escala de tiempo. 84 DSTM puede llevarse a cabo si una infraestructura de red sólo es compatible con IPv6, pero algunos de los nodos de la red tienen la capacidad de dual-stack. DSTM consiste en tres componentes: Un servidor DSTM. Una puerta de entrada DSTM o TEP (punto final del túnel). Un host dual-stack (llamado un "cliente DSTM") que desee comunicarse con IPv4. Para mantener la simplicidad, hemos decidido presentar el servidor y la puerta de entrada como un equipo diferente, pero en las implementaciones reales, estas dos funcionalidades están localizadas en el mismo equipo. Figura 19: Funcionamiento DSTM Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin Dunmore, September 2005. 442p. 85 Siempre y cuando las comunicaciones puedan tener lugar en IPv6 nativa, ninguna de las capacidades de DSTM se requiere. Esto se aplica a protocolos como HTTP o SMTP, donde el uso de ALG (nivel de aplicación Puertas de enlace) es preferible. Cuando un nodo DSTM detecta la necesidad de una dirección IPv4 por consulta de DNS que resulta de una dirección de destino IPV4 o una aplicación que genera un socket IPV4, el proceso DSTM se pone en marcha. Cuando el primer paquete IPv4 es enviado, el cliente pide al servidor DSTM obtener una dirección (en el paso 1 Figura 19).Estos protocolos (DHCPv6, TSP, RPC) han sido propuestos para realizar eficientemente esta tarea. Después de una petición de dirección, el servidor solicita a la puerta de entrada DSTM agregar un punto final del túnel (TEP) para la solicitud DSTM del cliente. El servidor es el encargado de controlar la asignación de direcciones IPv4/IPv6 para realizar un mapa en la puerta de entrada DSTM. Las versiones iniciales de DSTM consideran que la entrada sería construir su tabla de mapa IPv6/IPv4 dinámica mediante la observación de cabeceras de los paquetes, pero este método ya está obsoleto, debido a problemas de seguridad. Si el punto final para el nuevo túnel se ha creado con éxito, siguiendo el mensaje de respuesta de la puerta de enlace, el servidor DSTM responde al host con la siguiente información (paso 2): La dirección IPV4 asignada Periodo en que fue asignada la dirección. La dirección IPv4 e IPV6 del TEP 86 Esta información es utilizada por el cliente para configurar un túnel IPv4-sobreIPv6 hacia el DSTM puerta de enlace (paso 3). En este punto, el cliente DSTM tiene conectividad IPv4 y obtiene una dirección global IPv4, que será capaz de conectarse a cualquier host IPV4 externo. En DSTM, el período de asignación se puede configurar con base a la disponibilidad de la dirección. Los clientes necesitan solicitar la renovación antes de que la asignación del tiempo expire. Dependiendo de la política local y el comportamiento del cliente, el servidor DSTM puede aceptar o rechazar la ampliación de la asignación. En funcionamiento normal, las solicitudes de renovación de la asignación se envían periódicamente hasta que la dirección ya no es necesaria por el cliente. Siempre y cuando la asignación de direcciones se extienda, el servidor DSTM no está obligado a actualizar mapeo IPv4/IPv6 de la tabla en la puerta de enlace. Sin embargo, cuando expira la asignación, el gateway debe ser informado con el fin de actualizar sus tablas, y para permitir a otros clientes reutilizar el TEP para la liberación de direcciones IPv4. La puerta de entrada DSTM está a cargo del reenvío de paquetes entre el dominio IPV6 y redes IPv4. Se lleva a cabo la encapsulación o desencapsulación de paquetes usando una tabla de mapeo IPV4 e IPV6. Para éxito la comunicación bidireccional, es muy importante permitir el reenvío de IPv4 en la entrada y para asegurarse de que, para cualquier paquete IPv4 que vienen del exterior, el camino hacia el cliente DSTM apunta a la TEP. DSTM permite a los nodos de doble pila obtener una dirección IPv4 y ofrecer una ruta por defecto (a través de un túnel IPv4 en IPv6) a una pasarela IPv4. Cualquier aplicación IPv4 sólo se puede ejecutar a través de una red IPv6, sólo si este esquema es utilizado y, si DSTM está configurado para asignar direcciones IPv4 mundiales. 87 4.3 MÉTODOS DE TRASLACIÓN Los métodos de traducción son los encargan de traducir las cabeceras de datagramas IPV6 a IPV4 y viceversa. La tecnología de traducción es utilizada cuando un único host IPV6 necesita comunicarse con otro o viceversa. Este método de migración es la única solución en IPV6 que permite eliminar definitivamente el direccionamiento IPV4 de los nodos de red. Las técnicas de traducción de protocolos se describen en los RFCs 2765 y 2766. Mecanismos de Traslación de protocolos Network Address Translation-Protocol Translation (NAT-PT)(RFC 2766) Transport Relay Translator (TCP-UDP Relay)(RFC 3142) Bump-in-the-Stack (BIS)(RFC 2767) El Bump en el API (BIA) [RFC3338] SOCK-BasedGateway (RFC 3089) Tabla 10: Mecanismos de traslación de protocolos Fuente: Elaboración del autor 88 4.3.1 SIIT, NAT-PT and NAPT-PT38 Figura 20: Funcionamiento Translation (NAT-PT) Fuente: http://www.ipv6tf.com.pt/documentos/geral/cisco/ipv6_NatPTforIPv6_Mai2003.pdf Network Address Translation with Protocol Translation (NAT-PT), se define en el RFC 2766, como un servicio que se puede utilizar para traducir los datos enviados entre nodos con direcciones IP heterogéneas. NAT-PT traduce un datagrama IPv4, en la medida de lo posible, como un equivalente semántico de datagrama IPv6, o viceversa. Para que este servicio funcione, tiene que estar en el punto de interconexión entre la red IPv4 e IPv6. (Véase en la figura 20). Al igual que la existencia del NAT en IPV4 se traducen por lo general direcciones IPv4 privadas y direcciones globalmente enrutables. El NAT hace parte del NATPT que se traduce desde una Dirección IPv4 a una dirección IPv6, o viceversa, así como de una dirección IPv4 privada a una dirección global de IPv6. La parte de PT 38 RFC 2766 – NAT-PT. Febrero 2000 89 de la NAT-PT se encarga de la interpretación y la traducción de la equivalente semántica de encabezados IP, ya sea de IPv4 a IPv6 o IPv6 a IPv4. Al igual que NAT, NAT-PT también utiliza un conjunto de direcciones, que se asigna dinámicamente a los datagramas traducidos. El RFC2766 especifica un servicio llamado Network Address Port Translation Traducción de paquetes (NAPT-PT). Este servicio permite que los nodos IPv6 se comuniquen de forma transparente con una sola dirección IPv4. NAPT-PT mantiene un conjunto de números de puerto, que se asigna dinámicamente a los sockets que se encuentra en el lado del receptor del nodo NAPT-PT. Para el IETF NAT-PT es inaplicable actualmente, pero puede ser modificado a un formato más aceptable. Debe ser visto como un método de transición de último recurso. 4.3.2 Transport Relay Translator (TRT)39 El traductor de relay de transporte (TRT) [RFC3142] permite sólo hots IPv6 para intercambio de tráfico (TCP o UDP) con hots IPv4. Ninguna modificación de los host es necesaria, el sistema TRT puede ser muy fácil de instalar en las redes con capacidades de IPv6. Un traductor de relay de transporte que se ejecuta en un nodo de dual-stack puede utilizar un protocolo sólo en la comunicación con el cliente o en aplicación del servidor. En el ajuste del relay es capaz de traducir en la capa de transporte todos los datos enviados entre el cliente y aplicación de servidor. Para TCP tal 39 RFC3142-Transport Relay Translator.Junio 2001 90 traducción incluye volver a calcular la suma de comprobación, manteniendo la información necesaria sobre el estado que está conectado a la toma de socket de cliente servidor y eliminar este estado cuando el cliente termina su comunicación. Con la suma de comprobación UDP es obligatorio cuando se utiliza IPv6, pero no cuando se utiliza IPv4. UDP es un protocolo no orientado a conexión y, en teoría, es imposible para un relay conocer cuales datagramas pertenecen a la misma sesión .La implementación del relevo UDP típicamente asumirá que un datagrama UDP que sigue otro con el mismo recurso y destino dentro de un mismo intervalo de tiempo pertenece a la misma sesión. El sistema TRT puede trabajar con la mayoría de las aplicaciones comunes de Internet: HTTP, SMTP, SSH, etc. La operación de mecanismo de transición es relativamente simple: El host IPv6 utiliza un DNS-ALG como su servidor de nombres para resolver sus consultas DNS. El host IPv6, cuando pregunta a su servidor de nombre por la dirección IPV6 (registro AAAA) de un solo host IPv4, recibirá una dirección IPV6 (registro AAAA) de la DNS-ALG, que fue construido especialmente de la dirección IPv4 (Un registro A), en lugar de un mensaje de error con la respuesta que ninguna dirección IPv6 puede encontrar correspondiente a la consulta. Las direcciones de construcción consisten en un prefijo de red especial asociado con un relay de transporte y un ID del host (los 64 bits inferiores) que incorpora la dirección IPv4 del host remoto. La red está configurada de tal manera que los paquetes destinados a direcciones con el prefijo de red especiales sean enrutados al nodo remoto TRT. El TRT intercepta sesiones de transporte y actúa a través del nodo como punto final de destino de una sesión de IPv6 y actúa hacia el nodo de servidor como el recurso para una sesión de IPv4, copiando todos los datos que recibe de cada sesión(Véase en la figura 21). 91 Figura 21: Funcionamiento Transport Relay Translator Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin Dunmore, September 2005. 442p Existen ventajas y desventajas en el empleo de los mecanismos de TRT. Las ventajas incluyen: No hay ningún problema con los paquetes ICMP (Protocolo de Mensajes de Control de Internet). Si cualquier error ocurre en cualquier parte de las conexiones TRT, el paquete ICMP/ICMPv6 es enviado de vuelta al servidor de retransmisión de TRT, donde el error pueden ser manejado con cuidado o reportado hacia el otro extremo de la conexión. No es necesario modificar la pila IPv6 del host inicial, ni la aplicación para el soporte de su reinstalación. Es relativamente fácil de configurar. Puede ser suficiente con tener sólo un servidor de transmisión de TRT para todo el sitio, y este router debe tener una sola dirección global IPV4. 92 Las desventajas Incluyen: Puede haber problemas con las aplicaciones que utilizan direcciones IP integradas (por ejemplo, FTP, H.323). La TRT relay tiene que ser lo suficientemente inteligente como para mirar dentro de los paquetes si dicha aplicación necesita soporte. En este caso, el servidor de transmisión de TRT se convierte en una especie de aplicación proxy. Es aprobado sólo para tráfico unicast TCP / IP, sin embargo, es teóricamente posible llevar a cabo la implementación con soporte multicast. El servidor de transmisión de TRT puede generar un problema de seguridad importante, ya que puede ser utilizado como un salto intermedio para llegar a los servidores IPv4. La comunidad que se beneficia de un servidor de trasmisión TRT tiene que ser cuidadosamente controlada por el filtrado de paquetes o las listas de control de acceso. Para reducir el problema de direcciones de sitios locales se podrían utilizar entradas de paquetes IPV6. TRT requiere una configuración especial del servidor DNS para funcionar. Debido a la naturaleza del servicio de relay de TCP / UDP, no se recomienda el uso de TRT para protocolos que utilizan la autenticación basada en dirección IP de origen (por ejemplo, rsh / rlogin). 4.3.3 Bump in the Stack40 El Bump in the stack (BIS), se define en el [RFC2767] .Es un mecanismo de traducción similar a tomar el enfoque de NAT-PT con SIIT. El BIS es una interfaz 40 RFC2767.Bump in the Stack Febrero 2000 93 de traducción entre las aplicaciones IPV4 y las redes situadas por debajo de IPV6 (es decir, el controlador de interfaz de red). El diseño de la stack se basa en una pila dual-stack, con la adición de tres módulos, un traductor, un nombre de la extensión de la resolución y la dirección de un mapper, como se muestra en la figura 22. Figura 22: The BIS Protocol Stack Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin Dunmore, September 2005. pág. 442. El traductor reescribe la salida de las cabeceras IPv4 a IPv6 e ingresan cabeceras IPv6 a IPv4 si aplica. Se utiliza el algoritmo de traducción de cabecera definidos en SIIT. El nombre de extensión de resolución actúa como el de DNS-ALG en el 94 mecanismo de NAT-PT. Se realizan consultas de DSN IPv4 y se crean otras consultas que resuelvan los registros IPV4 e IPV6, enviando de regreso el registro IPV4 a la aplicación de solicitud IPV4, si sólo los registros IPV6 son devueltos, el solicitante pide al mapper de direcciones para asignar una dirección IPv4 correspondiente a la dirección IPv6. La dirección mapper mantiene un grupo de direcciones IPv4 y las asociaciones entre las direcciones IPv4 e IPv6. También se asigna una dirección cuando el traductor recibe un paquete de la red IPv6 para que no muestre la dirección de origen. Debido a que las direcciones IPv4 no son en realidad transmitidas en la red, por esto no tienen que ser únicas globalmente, pero un conjunto de direcciones privadas si pueden ser usadas. El mecanismo de BIS puede ser útil durante las etapas iniciales de la transición de IPv4 a IPV6 cuando las aplicaciones IPv4 permanecen sin modificarse dentro de los dominios IPV6, sin embargo, el BIS se limita en sus capacidades de traducción y es por esto que no es muy utilizado. Se permite la comunicación de host IPv4 al IPv6 pero no viceversa. No se envía o recibe ningún paquete IPV4 para la red, por lo tanto una aplicación IPv4 intenta la comunicación con otra aplicación IPV4 utilizando BIS, se producirá un error si no existen mecanismos de traducción adicionales en algún lugar de la ruta de comunicación. Al igual que con NAT-PT, SIIT y BPI no van a funcionar las comunicaciones multicast, ni aplicaciones que incorporan las direcciones IP en sus cargas. Una ALG (Application Layer Gateway) es necesaria para cualquier aplicación que tiene este comportamiento. 95 4.3.4 Bump in the API41 El Bump in the API (BIA) [RFC3338] es un mecanismo de traducción similar al BIS, sin embargo en lugar de traducir las cabeceras IPv4 e IPv6; BIA inserta un traductor API entre el socket API y los módulos TCP / IP de la pila host. Figura 23: The BIA Protocol Stack Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin Dunmore, September 2005. Pág. 442 Por lo tanto, las funciones IPv4 socket API se traducen en las funciones socket API IPV6 y viceversa. De esta manera, la traducción IPv4/IPv6 puede lograrse sin la sobrecarga de traducir cada paquete de cabecera. Al igual que BIS, BIA se basa en la adición de tres módulos: El sistema de resolución de nombres de archivo, la 41 RFC3338 Bump in the API Octubre 2002 96 función asignador y direcciones de mapper. Tanto la extensión de resolución de nombres y los módulos de mapeo de direcciones funcionan exactamente de la misma forma que los módulos correspondientes en el BIS. La función del mapper es situar las llamadas de IPV4 socket a las llamadas IPv6 socket y viceversa. Mapper hace esto interceptando la función de llamadas IPV4 socket API y pidiendo las correspondientes funciones de llamadas IPV6 socket API en su lugar. Esta función de llamadas socket IPv6 se usan para comunicarse con el par IPV6 y son transparentes para la aplicación IPv4 que invocó la función de llamadas original IPv4 socket. Por lo tanto, las funciones IPv4 socket API se traducen en las funciones socket API IPV6 y viceversa. De esta manera, la traducción IPv4/IPv6 puede lograrse sin la sobrecarga de traducir cada paquete de cabecera. Al igual que BIS, BIA se basa en la adición de tres módulos: el sistema de resolución de nombre de archivo, la función asignador y direcciones de mapper. Tanto la extensión de resolución de nombres y los módulos de mapeo de direcciones funcionan exactamente de la misma forma que los módulos correspondientes en el BIS. La función mapper es trazar las llamadas de IPV4 socket a las llamadas IPv6 socket Mapper hace esto interceptando la función de y viceversa. llamadas IPV4 socket API y pidiendo correspondientes funciones de llamadas IPV6 socket API en su lugar. Esta función de llamadas socket IPv6 se usan para comunicarse con el par IPV6 y son transparentes para la aplicación IPv4 que invocó la función de llamadas original IPv4 socket. El mecanismo de BIA está diseñado para sistemas que tienen una pila IPv6, pero que contienen aplicaciones que no ha sido actualizadas a IPv6. Por lo tanto, BIA puede ser útil en las primeras etapas de la transición, cuando hay muchas aplicaciones IPV4 sin modificar dentro de los dominios IPV6. BIA permite la comunicación de host IPv4 a IPv6, pero no especifica el caso inverso. Sin 97 embargo, podría ser fácilmente extendido para atender la comunicación de host de IPv6 a IPv4 (esto también es aplicable a BIS). La ventaja que tiene BIA sobre BIS es que es independiente del controlador de interfaz de red y no introduce el encabezado de cada paquete de traducción. Sin embargo, BIA presenta limitaciones similares a las del BIS. No tiene soporte de comunicación multicast sin alguna funcionalidad adicional a la del módulo mapper y no se emplea para aplicaciones que incorporan direcciones IP en sus cargas. El método BIA es, al igual que el método de BIS, no muy utilizado. 4.3.5 SOCK42 SOCK [RFC3089] es otro ejemplo de un relay de transporte, pero por lo general es conocido como un proxy "protocolo para entornos cliente / servidor”. SOCK es una Puerta de Enlace (Gateway) entre dos redes que permite que ciertas aplicaciones se comuniquen con sus contrapartes en la otra red, en este caso desde una red IPv4 a una IPv6 o viceversa. Cuando un cliente quiere conectarse a un servidor de aplicaciones por primera vez, establece una conexión a un servidor proxy pre-configurado utilizando un protocolo de proxy especial. El cliente solicita al proxy acerca de la dirección IP y el número del puerto del servidor de aplicaciones con que se desean comunicar. El servidor proxy actualmente es responsable de establecer una conexión con el servidor de aplicaciones. Tan pronto como esta conexión es establecida y se ejecuta el paquete de relay del proxy entre el cliente y el servidor de aplicaciones se oculta la conexión actual. 42 RFC3089 SOCK Abril 2001 98 5. CONFIGURACIÓN DE ESTRATEGIAS DE MIGRACIÓN43 5.1 CONFIGURACIÓN: MÉTODO DE TUNNELS “El método que más se recomienda es el uso de túneles, en especial para la interconexión de redes pequeñas con redes grandes. Los tipos de túneles que generalmente se deben usar son: túneles estáticos, túneles 6to4 y túneles ISATAP. ”44 5.1.1 Túnel manual Cisco IOS La configuración manual de un túnel IPV6 en IPV4 en una plataforma de cisco IOS: se crea la interfaz con un simple cambio de configuración al modo de escribir. En el modo de configuración se puede crear la interfaz. Nota: el túnel puede ser cualquier número entre 0 y 65.000. Para configurar la interfaz con una dirección IPV6 se debe tener en cuenta dos posibilidades 43 European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin Dunmore, September 2005. Páginas 442. 44 David Núñez. Capítulo 3.2009, paginas 16. 99 O La primera posibilidad se traducirá en la interfaz que se configura con la dirección exacta que se tiene especificada. Teniendo en cuenta que la longitud de la subred se puede establecer con 128 bits. Utilizando la segunda posibilidad, seria especificando un prefijo que puede ser de hasta 64 bits de longitud. La dirección de la interfaz de IPv6 será configurado con incluye (por ejemplo) y la dirección MAC de los equipos en el identificador de interfaz se especifica en la norma EUI64. La fuente del túnel se puede especificar con el nombre de la fuente de IPv4 o directamente indicando la dirección IPv4 del extremo del túnel local, por ejemplo: o El destino del Túnel es creado por: 100 Finalmente hay que configurar el modo de túnel para “IPV6IP” para especificar el encapsulamiento y decapsulamiento correcto. Con la “ipv6 route” es un comando que puede configurar rutas de las interfaces de túnel al igual que con cualquier interfaz. 5.1.2 6to4 5.1.2.1 Cisco IOS (as Client and Relay) Un router Cisco ejecutando una versión de IOS que incluye soporte 6to4 puede convertirse en un cliente de 6to4, si sólo tiene conectividad IPv4 o, si el router ya tiene conectividad IPv6 global, convertido en un 6to4 relay. 5.1.2.1.1 Configuración del cliente: Para configurar un router Cisco como cliente 6to4 es bastante fácil y se puede realizar mediante la creación de un túnel de la siguiente manera. 101 Es obligatorio establecer la siguiente ruta. 5.1.2.1.2 Configuración como un relay 6to4: Si el túnel y el router se configura como se ha descrito anteriormente, el cual también tiene conectividad exterior con el resto de la Internet IPv6, este router de forma automática funciona como un relé 6to4 y puede por lo tanto proporcionar conectividad con el exterior a todos los hosts conectados a él por 6to4. 5.1.3 ISATAP Para usar ISATAP dentro de un sitio, será necesario uno o más hosts IPv6 que apoyen ISATAP y también un router de dual stack que lo refuercen. Diferentes implementaciones del mecanismo se deben acoplar para que de esta manera las plataformas host y router se puedan mezclar según se requiera. 102 5.1.3.1 Cisco IOS Platform (As Router/Server). Para la configuración de un router Cisco como servidor ISATAP, se debe definir una interfaz de túnel de la siguiente manera: Si un cliente de ISATAP es creado para conocer acerca del router Cisco, será capaz de configurar automáticamente su interfaz con el prefijo anterior. 103 6. ETAPAS DE PROCESO DE MIGRACIÓN PARA LAS PYMES. La tabla 11 resume todos los elementos, capas y aspectos que deben ser tenidos en consideración por los profesionales de TI para las Pymes, cuando se planea hacer la implementación de IPv6. Las Pymes en general deben pensar en IPv6 como un proceso cíclico, que alinee todos los aspectos ligados a la infraestructura, procesos y servicios existentes: Tabla 11: Etapas de proceso de migración para las Pymes Fuente: http://staging.la.logicalis.com/pdf/IPv6.pdf 104 6.1 PROYECTO DE TRANSICIÓN 45 Al momento de realizar un plan de transición hacia la adopción de IPv6 se debe pensar en un proyecto, el cual, debe incluir una fase de iniciación, una de planificación, una de ejecución y una de cierre. A manera de referencia, el modelo planteado de resolución se limita a la fase de planeación. Lo anterior implica que, acorde al contexto estratégico que la tecnología tenga para cada Pyme, será entonces necesidad de cada organización liberar recursos para el proyecto de transición hacia IPv6 (fase de iniciación), el control de recursos (fase de ejecución), y el proceso para completar la transición (fase de cierre). 6.1.1 Elementos del modelo de proyecto de transición. Al iniciar con el modelo de proyecto de transición de IPV4 a IPV6, se definen un conjunto de elementos que deberían ser identificados y que conforman el alcance del plan de proyecto, pues es de gran ayuda para aquellas organizaciones que se encuentren en la fase temprana de inicialización del proceso de migración. 6.1.1.1 Planificación y definición de la estrategia. Incluida la necesidad de inversión. Las empresas deben adaptar e implementar tecnologías que cuenten con características que le permitan la migración de IPV4 a IPV6 para obtener el máximo beneficio en el funcionamiento de la red. 45 César Benítez Jiménez .Transición de IPv4 a IPv6 bajo un enfoque de la gestión de las Tecnologías de Información. Agosto de 2009.22 p. Fuente:http://www.tlalpan.uvmnet.edu/oiid/download/Transici%C3%B3n%20sistema%20Gesti%C3 %B3n_04_PO-ISC_PIT_E.pdf 105 Dentro de la planificación y definición de la estrategia se incluyen aspectos importantes como plantear una red que se ajuste a las exigencias de rendimiento, seguridad y escalabilidad de la pyme. Estas características hacen referencia a las necesidades puntuales del estado de la red en toda su arquitectura. Para los elementos que conforman el proyecto de transición a IPV6, es necesario que cada uno de ellos contemple las variables procedentes de equipos nuevos de cómputo, telecomunicación, y administración de riesgos que reflejen los estados financieros que se deben tener como parte del plan del proyecto de transición. 6.1.1.2 ¿Cómo está su red?, ¿Cuáles son sus servicios?, ¿Cuál es la mejor forma de migración? Se define un conjunto de elementos que deben ser identificados y que permiten asimilar el alcance del plan de proyecto, pues es de gran ayuda para la Pyme contar con una información veraz, que le ayudará en la implantación de nuevas tecnologías. 6.1.1.2.1 Redes de área local El protocolo IPv6 es una especificación de la capa de red del modelo OSI, y por tanto aquellos equipos que trabajen en esta capa deberán ser integrados dentro del plan de evaluación. Dado que se ha referido un modelo de transición de coexistencia de los dos protocolos en forma simultánea, como parte de este rubro deberán ser evaluados los conmutadores de red local (switch), los cuales reciben las conexiones de los usuarios ya sea en forma alámbrica como inalámbrica (puntos de acceso). Estos conmutadores tradicionalmente proveen el soporte en 106 las primeras dos capas del modelo OSI y, en estricta teoría, no deberían de requerir de reemplazo, sin embargo, algunas versiones poseen la habilidad de realizar funciones de capa tres, y por ende, el soporte de IPv6 debe ser considerado. Así mismo, aquellos conmutadores que tengan la capacidad de ser administrados en forma remota, trabajan en conformidad con el protocolo SNMP, el cual fue modificado acorde al protocolo IPv6 y por tanto requieren del soporte para la transición. Así mismo, en este rubro deberán ser considerados algunos servicios de red que han sido modificados en IPv6. Para organizaciones que emplean el servicio DHCP, éste es uno de los servicios que han permitido administrar redes en forma eficiente, y que debe ser parte del plan de transición. 6.1.1.2.2 Red de área amplia (WAN) En esta sección debemos considerar que residen la mayoría de los equipos que deben estar integrados en el alcance del proyecto de transición. Los routers son el principal elemento que interconecta edificios corporativos con redes de sucursales y con la Internet, por tanto este es el elemento crucial a ser identificado en el plan de transición. Forman parte de esta área, otros elementos que soportan la estrategia de seguridad perimetral de las redes de las organizaciones, como pueden ser detectores de intrusos o los muros de fuego (firewalls), también se incluyen convertidores de protocolos, puntos de acceso para redes virtuales, servidores de caché, puntos de interconexión con redes de proveedores y clientes, accesos remotos para asociados, servidores de contenido y el conjunto de software de monitoreo y administración de todos estos elementos. En este mismo contexto, el protocolo IPv6 obligó a definir nuevas especificaciones para los protocolos de intercambio de rutas (ruteo), por lo que para el modelo sugerido es 107 necesario integrar con prioridad los equipos de esta categoría, previamente al resto de los elementos del proyecto de transición. 6.1.1.2.3 Servicios multimedia (voz, video, aplicaciones de tiempo real). En este contexto, debemos considerar que en los años recientes, son múltiples los proveedores que han ido transformando el transporte de estos servicios, a través del protocolo TCP/IP, y por tanto resulta indispensable en el proceso de levantamiento de información, identificar aquellos casos donde el soporte por parte del fabricante esté contemplado. Existe la probabilidad que en algunas ocasiones el soporte de esos productos ya no se encuentre disponible, lo cual no implica necesariamente que los equipos tengan que desecharse, pero debe ser evaluada la inconveniencia que esto representa con el paso del tiempo por administrar dos redes durante varios años. Si los usuarios finales van a estar forzados a soportar ambos protocolos, entonces no hay una necesidad apremiante para acelerar el reemplazo de estos equipos. Por otro lado, algunos de los motivadores que podrían generar una implantación acelerada, serían aquellas condiciones donde estos servicios estén integrados en redes privadas de gran magnitud, debido a que, como referimos previamente, dentro de los beneficios de la versión seis del protocolo IP, encontramos que hay varios diferenciadores en cuanto al manejo de la calidad de servicio dentro de los parámetros de IPv6, así como un manejo transparente, íntegro y con posibilidad de manejar transmisiones de gran tamaño a lo largo de rutas de redes distantes. Estos aspectos, son quizás algunas variables que deben ser consideradas como parte del plan integral de transición y que promuevan una transición en plazos relativamente cortos por los beneficios identificados acorde al contexto de la organización. 108 6.1.1.2.4 Aplicaciones empresariales/corporativas En este rubro el proceso de inventario requiere contemplar dos escenarios. Para cada una de las aplicaciones cuya producción radica en servidores, tanto empresariales como servicios de terceros, se requiere evaluar el plan de migración, tanto de los servidores que soportan las aplicaciones, como de aquellos elementos que complementan el servicio, incluyendo, motores de bases de datos, aplicaciones de usuario y mecanismos de enlace de las aplicaciones. Como es de esperarse, los servidores que soportan estas aplicaciones deberán soportar en forma nativa el protocolo IPV6 para integrar su migración en un ambiente controlado. Así mismo, cada aplicación podrá requerir de la modificación de los componentes de enlace entre aplicaciones (sockets) y con ésto se hace necesario realizar un inventario de todas las aplicaciones. Adicionalmente, en aquellos casos donde el servidor no pueda ser actualizado, será necesario identificar el impacto de migración de estas aplicaciones en el futuro, de modo que se soporten adecuadamente. 6.1.1.2.5 Clientes/Usuarios finales Un elemento que podría ser asumido como fácil de implementar son los usuarios finales, que comprenden para una organización un componente que tradicionalmente se reemplaza en tiempos relativamente cortos. Como parte de este escenario, el elemento de la planeación de versiones de sistema operativo y un inventario completo del parque instalado, resultan ser quizás, los factores que faciliten o compliquen el plan de transición. 109 6.1.1.2.6 Aplicaciones integrales de administración En aquellas circunstancias donde la Pyme mantenga aplicaciones para administración de recursos informáticos, un elemento que cobra relevancia es aquel que integra a este rubro, siendo que al integrar plataformas nuevas tecnológicas, cobra mayor relevancia mantener el mismo nivel de administración tras la transición al nuevo protocolo. En este contexto, podemos decir que la plataforma de monitoreo de red, es quizás la práctica que mida, de manera efectiva, que el proceso de transición ha sido efectuado acorde a las expectativas de servicio definidas por el proyecto de transición. 6.1.1.2.7 Políticas En este contexto, existe la posibilidad de que algunos ambientes de operación mantengan políticas estrictas para el manejo de los datos en lo que respecta al medio de transmisión, formato de los paquetes, alternativas de tráfico y uso de redes acorde a especificaciones del contexto de la organización. Particularmente en esta sección, es necesario identificar que acorde al cambio que se anticipa por la introducción de IPv6, será necesario realizar reformas a las políticas, según haya sido identificado en el alcance del proyecto de transición, probado en los distintos ambientes de laboratorio y efectivamente integrado en los contratos de servicio de proveedores tales como sean de servicio, de soporte técnico, de administración de la infraestructura técnica, etc. Dentro de este contexto, debe integrarse como parte de los beneficios de la transición a IPv6, algunas características hacia el interior de la organización, en lo que respecta a la asignación de direcciones, rangos de crecimiento y uso de recursos del internet. 110 Algunas políticas externas que han sufrido cambios, tienen que ver con la manera como se asignan direcciones públicas en IPv6, y por tanto, éstas han de tener repercusiones en la manera como se realizan acuerdos de interconexión con empresas terceras como proveedores, socios de negocio y alianzas estratégicas. El impacto de estos cambios debe ser evaluado como parte del plan de proyecto de transición. 6.1.1.3 Defina los equipos, servicios, soporte y capacitación. Es de gran importancia para el personal encargado de la adquisición de nuevas tecnologías, revisar el plan de trabajo IPV6 de cada proveedor o fabricante, y el plazo establecido para dar cumplimiento al nivel de preparación en los servicios y el desempeño de los equipos de comunicación que le permiten a la Pyme llevar la migración de una forma más segura. Es de vital importancia revisar la línea de productos del fabricante, debido a que puede estar ofreciendo servicios que no cumplen con las especificaciones técnicas y certificaciones que necesita IPV6 para su funcionamiento. Incrementando en las Pymes los gastos de migración al adquirir tecnología obsoleta que dará solución al problema por un corto periodo de tiempo; además las empresas que acceden a estos servicios deben contar con personal que facilite la administración eficiente de los equipos. 6.1.1.4 Integre sin interrupciones o vulnerabilidades. Defina paso por paso. Es conveniente identificar las soluciones que se puedan necesitar y que faciliten la transición sin necesidad de recurrir a actualizaciones costosas y de alto riesgo que requieran una sustitución completa de toda la infraestructura. 111 Las pymes deben contar con un plan de contingencia que les permita mantener la estabilidad en la prestación de los servicios al momento de reestructurar los equipos, evitando que se encuentre en un estado de vulnerabilidad. 6.1.1.5 Gerencia, resuelva. Repare. Reemplace, siempre manteniendo la red estable. Para llevar a cabo exitosamente la transformación de la migración de IPV4 a IPV6, se debe fragmentar el proceso para que no genere alteraciones que afecten la prestación del servicio. La gerencia consiste básicamente en asumir el liderazgo de una organización, unificar criterios y trabajar conjuntamente para la consecución de objetivos élites que le permitan obtener el crecimiento corporativo. Para asumir una posición crítica frente a una problemática que se presenta al interior de la pyme, se analizan las causas que la conciben y las soluciones que pueden representar mayor favorabilidad para la organización. Éstas deben estar fundamentadas en los acontecimientos que ameriten decisiones provisionales (reparaciones) o drásticas (reemplazo). 6.1.1.6 Adapte la red y los servicios de acuerdo a los requisitos de la Pyme. Las pymes acceden a nuevas tecnologías para mejorar la competitividad y tener los servicios oportunamente al generar un impacto positivo al interior de la organización. También acopla la red de acuerdo a sus exigencias, teniendo en cuenta la tecnología disponible y la capacidad de adquirir un paquete que le proporcione bienestar, al mismo tiempo que le permite hacer un uso racional de sus recursos. 112 CONCLUSIONES La mayoría de las redes en las Pymes de Colombia, durante el proceso de migración del protocolo de Internet de IPV4 a IPV6 estará acompañada por el método de transición Dual Stack por un periodo de largo tiempo, pues es una de las estrategias que maneja una mayor simplicidad al momento de la adaptación de la nueva tecnología y permite estabilizar el funcionamiento de la red. Las direcciones IP que se manejan en la versión 4, se encuentran conformadas por 32 bits. Para IPV6 las direcciones están compuestas por 128 bits, permitiendo soportar más niveles de direccionamiento jerárquico que permiten al internet seguir creciendo, un mayor número de nodos direccionables y la simplificación de autoconfiguración de las direcciones. Además ayuda a mejorar la calidad de servicio,el manejo de la seguridad, ya que esta característica es nativa dentro del protocolo. El protocolo de Internet versión 6 posee compatibilidad con su anterior versión IPV4 de 32 bits, lo que le permite coexistir en la misma red. Las implementaciones de este nuevo protocolo empiezan a estar disponibles, y gracias a su compatibilidad permiten a los administradores de redes y directores de sistemas ir realizando las mejoras necesarias en sus equipos de forma temporal, teniendo en cuenta sus posibilidades y sin importar el tiempo empleado. Con IPv6 se tiene mayor velocidad en el procesamiento de paquetes en los routers dado que éstos no realizan fragmentación a cada salto, sólo los nodos de 113 origen son los encargados de realizar fragmentación, por tanto se elimina el tiempo que tomaba este proceso con IPv4 en cada salto. IPv6 permite manejar múltiples direcciones por interfaz de dispositivo haciendo la ruta simple y eficiente. En el caso de Ipv4, las direcciones tienen muy poca o ninguna conexión con los caminos de enrutamiento, por lo tanto los enrutadores deben mantener enormes tablas de caminos de enrutamiento, mientras que en Ipv6 los enrutadores mantienen pequeñas tablas de prefijos que permiten que la fuente envíe los paquetes al destino correcto. 114 BIBLIOGRAFÍA 6SOS.Glosario IPV6: Eduardo Jacob Taquet, Alex Muñoz Mateos, Fidel Liberal Malaina.2004.pag 38. Fuente: http://www.6sos.org/documentos/glosario-IPv6-v1-2.pdf Belén Aldecoa Sánchez del Río Luis Alberto Ramón Surutusa. Redes de Banda Ancha IPV6.pag 53. Fuente: http://es.scribd.com/doc/51187582/6/Direcciones-Unicast César Benítez Jiménez .Transición de IPv4 a IPv6 bajo un enfoque de la gestión de las Tecnologías de Información. Agosto de 2009.22 p. Fuente:http://www.tlalpan.uvmnet.edu/oiid/download/Transici%C3%B3n%20 sistema%20Gesti%C3%B3n_04_PO-ISC_PIT_E.pdf Darwing Lamarck Santono Yunes.IPV6:Nueva Generación Protocolo de Internet.2004.pag 172 Fuente: http://www.lac.ipv6tf.org/docs/tutoriales/IPv6-LACTF.pdf David Núñez. Capítulo 3.2009, paginas 16. European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin Dunmore, September 2005. 442p 115 F. Templin, T. Gleeson, M. Talwar, D. Thaler, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)”, IETF Internet Draft draft-ietf-ngtrans-isatap24.txt (work in progress), January 2005. IntroduccionDireccionesIP.pdf. Microsoft Word-direccionesIP.doc.2004.7p. Fuente: http://www.educa.madrid.org/cms_tools/files/a8dae6a3-c890-4d13a8fc5e928c9a98ec/ IntroduccionDireccionesIP.pdf J. Hagino, K. Yamamoto, “An IPv6-to-IPv4 Transport Relay Translator”, IETF Request for Comments 3142, June 2001 J. Bound, “Dual Stack IPv6 Dominant Transition Mechanism (DSTM)”, IETF Internet Draft draft-bound-dstm-exp-03.txt (work in progress), June 2005. Reddy, J. Bound, “Stack Transition Mechanism (DSTM) Options for DHCPv6”, IETF Internet Draft draft-reddy-dhcpv6-opt-dstm-exp-00.txt (work in progress), April 2005. RFC2402- Authentication Header Noviembre 1998 RFC3338-Bump in the API Octubre 2002 RFC2767-Bump in the Stack Febrero 2000 RFC 3056 - Conexión de Dominios IPv6 a través de nubes IPv4. Febrero 2001 116 RFC 3587-Dirección de enrutamientos globales, Agosto 2003 RFC 4214 - Intra Site automático túnel abordar Protocol (ISATAP). Octubre 2005 RFC2406-IP Encapsulation Security Protocol (ESP). Noviembre 1998 RFC 3053 - Ipv6 Tunnel Broker. Enero 2001 RFC4291-IP Version 6 Addressing Architecture Febrero 2006 RFC2893 - Mecanismos de transición para hosts y router IPv6. Agosto 2000 RFC2893- Mecanismos de transición para hosts y router IPv6 ,Agosto 2000 RFC 2766 – NAT-PT. Febrero 2000 RFC3879- Obsoleto sitio de las direcciones locales , Septiembre 2004 RFC3513-Protocolo de Internet versión 6 (IPv6) Aborda Arquitectura,Abril 2003 RFC2450- Proyecto de TLA y NLA reglas de asignación, Diciembre 1998 RFC 2460-Protocolo de Internet, versión 6(IPV6).Diciembre 1998 RFC3656-Rendezvous Point, Diciembre 2003 117 RFC3089- SOCK Abril 2001 RFC 4380 - Teredo: Tunneling IPv6 sobre UDP. Febrero 2006 RFC3142-Transport Relay Translator.Junio 2001 RFC 2529 - Transmisión de paquetes IPv6 sobre IPv4. Marzo 1999 RFC3306-Unicast-Prefijo basado en direcciones IPv6 Multicast,Agosto 2002 RFC3306-Unicast-Prefijo basado en direcciones IPv6 Multicast,Agosto 2002 RFC 4193- Unique local direcciones IPv6 Unicast, Octubre 2005 R. Hinden, S. Deering, “IP Version 6 Addressing Architecture”, IETF Request for Comments 2373, July 1998. S. Routhier, “Management Information Base for the Internet Protocol (IP)”, IETF Internet Draft draft-ietf-ipv6-rfc2011-update-10.txt, May 2004. S. Lee, M. Shin, Y. Kim, E. Nordmark, A. Durand, “Dual Stack Hosts Using ‘Bump in the API’ (BIA)”, IETF Request for Comments 3338, October 2002. 118 ANEXO 1. RFC´s para IPV6 119 120 121
