sumario secciones técnicas sociedad de la información asuntos interiores Nº 174, marzo-abril 2005, año XXXI

Transcripción

1 Novática, revista fundada en 1975 y decana de la prensa informática española, es el órgano oficial de expresión y formación continua de ATI (Asociación de Técnicos de Informática). Novática edita también UPGRADE, revista digital de CEPIS (Council of European Professional Informatics Societies), en lengua inglesa, y es miembro fundador de UPENET (UP UPGRADE European NETwork) < < ATI es miembro fundador de CEPIS (Council of European Professional Informatics Societies) y es representante de España en IFIP (International Federation for Information Processing); tiene un acuerdo de colaboración con ACM (Association for Computing Machinery), así como acuerdos de vinculación o colaboración con AdaSpain, AI2 y ASTIC. CONSEJO EDITORIAL Antoni Carbonell Nogueras, Francisco López Crespo, Julián Marcelo Cocho, Celestino Martín Alonso, Josep Molas i Bertrán, Roberto Moya Quiles, César Pérez Chirinos, Mario Piattini Velthuis, Fernando Piera Gómez (Presidente del Consejo), Miquel Sàrries Griñó, Asunción Yturbe Herranz Coordinación Editorial Rafael Fernández Calvo <rfcalvo@ati.es> Composición y autoedición Jorge Llácer Gil de Ramales Traducciones Grupo de Lengua e Informática de ATI < Administración Tomás Brunete, María José Fernández, Enric Camarero, Felicidad López SECCIONES TECNICAS: COORDINADORES Administración Pública electrónica Gumersindo García Arribas, Francisco López Crespo (MAP) <gumersindo.garcia@map.es>, <flc@ati.es> Arquitecturas Jordi Tubella Murgadas(DAC-UPC) <jordit@ac.upc.es> Víctor Viñals Yúfera (Univ. de Zaragoza) <victor@unizar.es> Auditoría SITIC Marina Touriño Troitiño, Manuel Palao García-Suelto (ASIA) <marinatourino@marinatourino.com>, <manuel@palao.com> Bases de datos Coral Calero Muñoz, Mario G. Piattini Velthuis (Escuela Superior de Informática, UCLM) <Coral.Calero@uclm.es>, <mpiattin@inf-cr.uclm.es> Derecho y tecnologías Isabel Hernando Collazos (Fac. Derecho de Donostia, UPV)<ihernando@legaltek.net> Isabel Davara Fernández de Marcos (Davara & Davara) <idavara@davara.com> Enseñanza Universitaría de la Informática Joaquín Ezpeleta Mateo (CPS-UZAR) <ezpeleta@posta.unizar.es> Cristóbal Pareja Flores (DSIP-UCM) <cpareja@sip.ucm.es> Gestión del Conocimiento Joan Baiget Solé (Cap Gemini Ernst & Young) <joan.baiget@ati.es> Informática y Filosofía Josep Corco Juvinyà (UIC) <jcorco@unica.edu> Esperanza Marcos Martínez (ESCET-URJC) <cuca@escet.urjc.es> Informática Gráfica Miguel Chover Sellés (Universitat Jaume I de Castellón) <chover@lsi.uji.es> Roberto Vivó Hernando (Eurographics, sección española) <rvivo@dsic.upv.es> Ingeniería del Software Javier Dolado Cosín (DLSI-UPV) <dolado@si.ehu.es> Luis Fernández Sanz (PRIS-EI-UEM) <lufern@dpris.esi.uem.es> Inteligencia Artificial Federico Barber Sanchís, Vicente Botti Navarro (DSIC-UPV) <{vbotti, fbarber}@dsic.upv.es> Interacción Persona-Computador Julio Abascal González (FI-UPV) <julio@si.ehu.es> Jesús Lorés Vidal (Univ. de Lleida) <jesus@eup.udl.es> Internet Alonso Álvarez García (TID) <alonso@ati.es> Llorenç Pagés Casas (Indra) <pages@ati.es> Lengua e Informática M. del Carmen Ugarte García (IBM) <cugarte@ati.es> Lenguajes informáticos Andrés Marín López (Univ. Carlos III) <amarin@it.uc3m.es> J. Ángel Velázquez Itúrbide (ESCET-URJC) <a.velazquez@escet.urjc.es> Libertades e Informática Alfonso Escolano (FIR-Univ. de La Laguna) <aescolan@ull.es> Lingüística computacional Xavier Gómez Guinovart (Univ. de Vigo) <xgg@uvigo.es> Manuel Palomar (Univ. de Alicante) <mpalomar@dlsi.ua.es> Mundo estudiantil Adolfo Vázquez Rodríguez (Rama de Estudiantes del IEEE-UCM) <a.vazquez@ieee.org> Profesión informática Rafael Fernández Calvo (ATI) <rfcalvo@ati.es> Miquel Sàrries Griñó (Ayto. de Barcelona) <msarries@ati.es> Redes y servicios telemáticos Luis Guijarro Coloma (DCOM-UPV) <lguijar@dcom.upv.es> Josep Solé Pareta (DAC-UPC) <pareta@ac.upc.es> Seguridad Javier Areitio Bertolín (Univ. de Deusto) <jareitio@eside.deusto.es> Javier López Muñoz (ETSI Informática-UMA) <jlm@lcc.uma.es> Sistemas de Tiempo Real Alejandro Alonso Muñoz, Juan Antonio de la Puente Alfaro (DIT-UPM) <{aalonso,jpuente}@dit.upm.es> Software Libre Jesús M. González Barahona, Pedro de las Heras Quirós (GSYC-URJC) <{jgb,pheras}@gsyc.escet.urjc.es> Tecnología de Objetos Jesus García Molina (DIS-UM) <jmolina@correo.um.es> Gustavo Rossi (LIFIA-UNLP, Argentina) <gustavo@sol.info.unlp.edu.ar> Tecnologías para la Educación Juan Manuel Dodero Beardo (UC3M) <dodero@inf.uc3m.es> Francesc Riviere (PalmCAT) <friviere@wanadoo.es> Tecnologías y Empresa Pablo Hernández Medrano (Bluemat) <pablohm@bluemat.biz> TIC para la Sanidad Valentín Masero Vargas (DI-UNEX) <vmasero@unex.es> TIC y Turismo Andrés Aguayo Maldonado, Antonio Guevara Plaza (Univ. de Málaga) <{aguayo, guevara}@lcc.uma.es> Las opiniones expresadas por los autores son responsabilidad exclusiva de losmismos. Novática permite la reproducción de todos los artículos, a menos que lo impida la modalidad de o copyright elegida por el autor, debiéndose en todo caso citar su procedencia y enviar a Novática un ejemplar de la publicación. Coordinación Editorial, Redacción Central y Redacción ATI Madrid Padilla 66, 3º, dcha., Madrid Tlfn ; fax <novatica@ati.es> Composición, Edición y Redacción ATI Valencia Av. del Reino de Valencia 23, Valencia Tlfn./fax <secreval@ati.es> Administración y Redacción ATI Cataluña Ciudad de Granada 131, Barcelona Tlfn ; fax <secregen@ati.es> Redacción ATI Andalucía Isaac Newton, s/n, Ed. Sadiel, Isla Cartuja Sevilla, Tlfn./fax <secreand@ati.es> Redacción ATI Aragón Lagasca 9, 3-B, Zaragoza. Tlfn./fax <secreara@ati.es> Redacción ATI Asturias-Cantabria <gp-astucant@ati.es> Redacción ATI Castilla-La Mancha <gp-clmancha@ati.es> Redacción ATI Galicia Recinto Ferial s/n, Silleda (Pontevedra) Tlfn ; fax <secregal@ati.es> Suscripción y Ventas < en ATI Cataluña o ATI Madrid Publicidad Padilla 66, 3º, dcha., Madrid Tlnf ; fax <novatica.publicidad@ati.es> Imprenta Derra S.A., Juan de Austria 66, Barcelona. Depósito legal: B ISSN: ; CODEN NOVAEC Portada: Antonio Crespo Foix / ATI 2005 Diseño: Fernando Agresta / ATI 2005 Nº 174, marzo-abril 2005, año XXXI sumario en resumen La madre de todos los protocolos > 02 Rafael Fernández Calvo IPv6 - Más que un protocolo (En colaboración con UPGRADE, que la publica en inglés) Editores invitados: Jordi Domingo Pascual, Alberto García Martínez, Matthew Ford Presentación. IPv6: un nuevo paradigma de red > 03 Jordi Domingo Pascual, Alberto García Martínez, Matthew Ford Estado del despliegue de IPv6 en 2005 > 06 Jim Bound Visión general del protocolo IPv6 > 10 Albert Cabellos Aparicio, Jordi Domingo Pascual La migración de aplicaciones a IPv6 > 15 Eva M. Castro Barbero, Tomás P. de Miguel Desarrollo de servicios en redes IPv6 y experiencia en redes pre-comerciales > 19 Rüdiger Geib, Eduardo Azañón Teruel, Sandra Donaire Arroyo, Aurora Ferrándiz Cancio, Carlos Ralli Ucendo, Francisco Romero Bueno Seguridad con IPv6 > 27 Latif Ladid, Jimmy McGibney, John Ronan Herramientas para la provisión de multihoming en IPv6 > 32 Marcelo Bagnulo Braun, Alberto García Martínez, Arturo Azcorra Saloña NEMO: movilidad de redes en IPv6 > 37 Carlos Jesús Bernardos Cano, Ignacio Soto Campos, María Calderón Pastor, Dirk von Hugo, Emmanuel Riou Estado de IPv6 en el mundo y los Grupos de Trabajo de IPv6 > 44 Jordi Palet Martínez secciones técnicas Bases de Datos Uso real de los modelos matemáticos en los motores de recuperación de la información > 50 Jordi Ardanuy Baró Enseñanza Universitaria de la Informática Hacia el aprendizaje activo: un caso práctico en la docencia de Sistemas Operativos > 54 Marián Díaz Fondón, Miguel Riesco Albizu, Ana Belén Martínez Prieto Seguridad Diseño de un nuevo generador de secuencias de bits aleatorios por entrada de teclado > 59 Pedro María Alcover Garau, José M. García Carrasco, Luis Hernández Encinas Referencias autorizadas > 66 sociedad de la información Personal y transferible Ariba versus eplus: un caso judicial sobre infracción de patentes de software en EE.UU. > 72 Llorenç Pagés Casas asuntos interiores Coordinación editorial - Fé de erratas / Programación de Novática > 75 Normas de publicación para autores / Socios Institucionales > 76 Monografía del próximo número: "Ingeniería de Software Libre"

2 IPv6 - Más que un protocolo Jordi Domingo Pascual 1, Alberto García Martínez 2, Matthew Ford 3 1 Universitat Politècnica de Catalunya; 2 Universidad Carlos III de Madrid; 3 Brithish Telecom (Gran Bretaña) Presentación IPv6: un nuevo paradigma de red <jordi.domingo@ac.upc.es>, <alberto@it.uc3m.es>, <matthew.ford@bt.com>. 1. Introducción La nueva versión del protocolo IP, IPv6 (Internet Protocol version 6), ofrece nuevas funcionalidades de red que podrían ser suficientemente relevantes como para que IPv6 fuera considerado como un nuevo paradigma de red: un espacio de direccionamiento mucho más extenso, restauración de la conectividad extremo a extremo para facilitar la comunicación peer-to-peer y la seguridad extremo a extremo, mejores herramientas de autoconfiguración y varias mejoras en varios puntos del protocolo. Esta de Novática y UPGRADE está dedicada a presentar estas características desde un punto de vista crítico. La necesidad de un nuevo protocolo de red surgió a principios de los años 90, cuando la disponibilidad de direcciones empezó a ser preocupante para la comunidad técnica. La IETF (Internet Engineering Task Force) comenzó a desarrollar soluciones a corto plazo, tales como el reemplazo del modelo de clases que estaba vigente en aquel entonces por el modelo actual de CIDR (Classless Interdomain Routing, [1] Encaminamiento Interdominio Sin Clases), o el establecimiento de un modelo de delegación de direcciones más eficiente basado en su control por parte de los RIRs (Regional Internet Registries, Registros Regionales de Internet). Pero incluso considerando una exitosa implantación de estas medidas, se preveía un agotamiento a medio plazo de las direcciones por ejemplo, en [2] se predecía el agotamiento de las direcciones para 2006 como muy tarde. Por tanto, se requería una solución que permitiera la subsistencia de la conectividad a largo plazo y parecía razonable que implicara un rediseño del protocolo IP. Se discutieron bastantes ideas, que dieron como resultado a IPv6, con una primera versión del conjunto básico de estándares disponible a finales de Si bien el mayor impulso para el desarrollo de IPv6 era la extensión del espacio de direccionamiento disponible, también se tomó como una oportunidad de pulir algunos componentes del protocolo IP a partir de la experiencia obtenida en muchos años de uso de IPv4. Se reorganizó la estructura de la cabecera para permitir un procesamiento más eficiente y se mejoró la inclusión de opciones a través de las cabeceras de extensión. Se consideró como un criterio de Editores invitados Jordi Domingo Pascual es Ingeniero de Telecomunicación (ETSETB UPC), Doctor en Informática (FIB UPC), Catedrático de Universidad del Dept. d Arquitectura de Computadors (UPC). Promotor y fundador del Centro Específico de Investigación de Comunicaciones Avanzadas de Banda Ancha (CCABA) de la UPC. Participación en proyectos de investigación: Technology for ATD, EXPLOIT, InfoWin, MICC, IMMP, LONG, ENET, E-NEXT y EuQoS. Participación como responsable en proyectos financiados por la CICYT: PLANBA, AFTER, TR-1, SABA, SABA2, SAM. Participación en proyectos financiados por la CICYT: TIC C02-02, CASTBA, MEHARI, MIRA. Otros proyectos de I+D: Internet2 Catalunya (i2cat), responsable de la infraestructura de comunicaciones de banda ancha (proyecto GigaCAT). Participación en proyectos de cooperación: Programa Erasmus/Socrates, Leonardo, COST237 (Multimedia Telecommunication Services), COST264 (Enabling Networked Multimedia Group Communication), COST263 (Quality of Future Internet Services). Temas de investigación en los que ha publicado: conmutación ATM, redes ATM, encaminamiento ATM, control de admisiones ATM, caracterización de tráfico en redes ATM, comunicaciones de Banda Ancha, multicast, provisión de calidad de servicio en redes IP, servicios avanzados de red (multicast, IS, DS, MPLS, movilidad, IPv6), análisis de tráfico IP, coexistencia IPv4-IPv6 y mecanismos de transición. Más información en < y < Alberto García Martínez es Ingeniero de Telecomunicación por la Universidad Politécnica de Madrid. Obtuvo su doctorado en 1999, en el Depto. de Ingeniería Telemática de la misma universidad. Actualmente es Profesor Titular en el Depto. de Ingeniería Telemática de la Universidad Carlos III de Madrid. Ha participado en varios proyectos de investigación sobre IPv6, incluyendo proyectos IST (Information Society Technologies) europeos como LONG (Laboratories over Next Generation Networks), o 6LINK, y proyectos financiados por el Plan Nacional de I+D como SAM (Servicios Avanzados con Movilidad) y SABA2 (Nuevos Servicios para la Red Académica de Banda Ancha). Recientemente ha publicado varios artículos en relación con su tema de investigación actual, multihoming en IPv6. Matthew Ford es Consejero de Tecnología Comercial del Grupo de Gestión del Grupo de Trabajo de IPv6 del Reino Unido, y coordinador del Grupo de Proyectos relacionados con IPv6 del programa IST de la Unión Europea (IPv6 Cluster). Se incorporó a British Telecom en 1998 y trabajó inicialmente en el desarrollo de diseños de red para un amplio rango de plataformas, investigando también en tecnologías de seguridad emergentes como DNSsec y seguridad para IP móvil (MobileIP). Más recientemente, se ha centrado en la investigación, desarrollo, estandarización e implantación de IPv6. Ha participado y participa actualmente en proyectos de innovación tecnológica del programa IST de la Unión Europea tales como 6WINIT, 6LINK, SEINIT y Euro6IX. Es ponente regular en temas de IPv6 y seguridad de red en conferencias internacionales y ha presidido numerosos encuentros de profesionales de red. Obtuvo un MA por la Universidad de Glasgow (Reino Unido) y un MSc en la London School of Economics. Es miembro del Institute of Electrical Engineers. diseño la incorporación de un soporte apropiado para la autoconfiguración, dando lugar a la especificación de un mecanismo básico de autoconfiguración completamente automática para permitir la comunicación de dispositivos localizados en un mismo segmento, y a la integración en IPv6 del mecanismo de Router Advertisement (anuncio de enrutador). Finalmente, se incluyeron otras muchas mejoras, tales como el soporte nativo de multicast para equipos finales y routers IPv6, o los identificadores de flujo. 2. Problemas y desafíos: se están agotando las direcciones IP? No obstante todo lo anterior, y a pesar de la expectación levantada, está claro que a fecha de hoy IPv6 no es todavía un protocolo ampliamente usado. Existen varias razones para esto. La primera es que los apocalípticos anuncios respecto al agotamiento de las direcciones IPv4 no se han materializado todavía. Estudios recientes [3] utilizan el análisis de datos pasados para prever que las direcciones IPv4 durarán más allá del 2030, a menos que nuevas tecnologías o usos -- tales como una fuerte demanda de direcciones para telefonía móvil o un gran incremento de usuarios en China o India-- cambien la tendencia en el consumo de direcciones. Hay varias explicaciones para esta relajación de las previsiones: un estricto control de los RIRs sobre la asignación de direcciones, la reutilización de direcciones en accesos a novática / upgrade nº 174 marzo-abril

3 IPv6 - Más que un protocolo través de línea telefónica (dial-up), entre otros. Pero la implantación de NATs (Network Address Translators, Traductores de Direcciones de Red) se considera como la más significativa de todas las posibles explicaciones. Los NATs permiten la reutilización de un pequeño número de direcciones públicas en la provisión de conectividad para un número mucho mayor de equipos. Los NATs son actualmente muy populares y dan servicio tanto a grandes organizaciones como a usuarios residenciales. Aunque su implantación ha retrasado el problema de la escasez de direcciones, esto no se ha hecho a coste cero: en primer lugar, la conectividad se ha vuelto asimétrica, ya que algunos nodos son más capaces que otros de recibir comunicaciones iniciadas desde fuera de su red. En segundo lugar, ya no son válidas funciones extremo a extremo que dependan de que se preserve la dirección IP original en una comunicación, tales como el protocolo de seguridad IPsec (Secure Internet Protocol). La solución de estos problemas es ahora el objetivo de los defensores de IPv6. También ha habido obstáculos tecnológicos para el éxito de IPv6. Si bien la parte básica de los estándares ha estado disponible durante bastante tiempo, en otras partes el proceso de estandarización no ha sido tan rápido como se habría deseado. En efecto, la estandarización algunas cuestiones importantes del protocolo tales como DHCPv6 () o el soporte de movilidad para IPv6 han requerido un tiempo considerable. Adicionalmente, también se han producido cambios en los últimos años en la especificación básica, cambios como la sugerencia de eliminación de las direcciones site-local o como la actualización de las interfaces de programación (API, Application Program Interfaces). Por otro lado, hay problemas cuyas soluciones sólo han empezando a vislumbrarse recientemente, tales como el soporte a múltiples proveedores de conectividad (multihoming) o el modelo de seguridad a implantar. Pero incluso si la tecnología estuviera completamente disponible, existen muchos desafíos que hay que abordar. Uno de los mayores es el requisito de que las aplicaciones que utilizan el interfaz de sockets sean modificadas para poder utilizar IPv6, debido a las dependencias respecto al protocolo utilizado que dicha interfaz de programación impone. Por otro lado, aunque la mayoría de los sistemas operativos ya ofrecen soporte para IPv6, los proveedores de equipamiento de comunicaciones han sido menos entusiastas, y -- salvo notables excepciones -- han ofrecido un soporte de IPv6 inferior al de IPv4 en funcionalidad y rendimiento. Los grandes proveedores de conectividad también han sido reticentes al cambio en la infraestructura de sus redes para dar soporte a un protocolo con un número relativamente bajo de aplicaciones y usuarios debido al coste y la complejidad que esto acarrea. Y finalmente, los usuarios no han sido atraídos por una nueva aplicación o servicio para IPv6 que sea realmente atractivo. 3. Las buenas noticias A pesar de todo lo dicho, hay buenas noticias para IPv6 y éste podría ser un momento clave en el proceso de migración. La obtención de una masa crítica de usuarios IPv6 puede hacerse realidad con el fuerte impulso político que se está dando en los países asiáticos. Adicionalmente, las especificaciones para las redes móviles de tercera generación requieren la implantación de IPv6, por lo que se puede anticipar en el corto plazo un importante crecimiento en el número de usuarios. IPv6 también está siendo considerado como una oportunidad para los desarrolladores de hardware y software de comunicaciones en Europa y Asia, que tradicionalmente han estado detrás de los norteamericanos en ventas de productos para IPv4. Esto, junto con el trabajo entusiasta en la promoción de IPv6 de organizaciones como el IPv6 Forum o loss numerosos Grupos de Trabajo (Task Forces) de IPv6 a lo largo del mundo han generado un caldo de cultivo para el apoyo político a IPv6 por parte de la Unión Europea. Un ejemplo de este interés político es una tendencia creciente en la exigencia de soporte a IPv6 en nuevos contratos o consultorías públicas en toda Europa. Algunas tecnologías que sólo pueden implantarse en su modo actual sobre IPv6 también están generando expectativas; a modo de ejemplo, la implantación de seguridad extremo a extremo a nivel de red, que requiere una extensión del direccionamiento público que sólo puede ofrecer IPv6, o la posibilidad de dar un completo soporte de multihoming incluso a redes pequeñas o usuarios residenciales. Estas tecnologías podrían evolucionar hasta atraer a los últimos escépticos sobre IPv6. 4. El contenido de la Es conveniente destacar que éste es un momento excitante, con una gran cantidad de trabajo realizado que puede hacer realidad el comienzo de la implantación de IPv6. Para esta hemos invitado a autores con una gran experiencia en la investigación y promoción de IPv6, con el objetivo de ofrecer una amplia visión del estado actual de IPv6 a través de artículos que muestran diferentes perspectivas de su desarrollo. Este número está estructurado como sigue: El artículo "Estado del despliegue de IPv6 en 2005", de Jim Bound, Responsable de Tecnología (Chief Technology Officer) del IPv6 Forum, ofrece una panorámica de los modelos de desarrollo y visiones sobre IPv6, y de cómo IPv6 se está aproximando a la fase de implantación comercial. Recoge un resumen del estado actual del desarrollo de IPv6 con una especial atención a la influencia que tiene en ello la implantación de un modelo de seguridad extremo a extremo. "Visión general del Protocolo IPv6", de Albert Cabellos Aparicio y Jordi Domingo Pascual, presenta un resumen de las características básicas de IPv6, características que servirán como base para el resto de los artículos. En primer lugar se muestra el formato de cabecera de IPv6, dedicando cierto detalle a la nueva cabecera de extensión definida. La arquitectura de direccionamiento, que es la contribución más relevante de IPv6, se discute a continuación. Otra cuestión básica abordada es el mecanismo de Descubrimiento de Vecinos (Neighbour Discovery) y los modelos y herramientas de autoconfiguración. Finalmente se describen algunos mecanismos disponibles para la migración de redes IPv4 a IPv6. Los principales problemas y soluciones en la migración de aplicaciones en IPv6 son tratados en "La migración de aplicaciones a IPv6", escrito por Eva M. Castro Barbero, Tomás P. de Miguel Moro y Santiago Pavón Gómez. Primero, se identifican las dependencias de versiones concretas de IP en las aplicaciones. A continuación, se presentan unas herramientas que permiten la comunicación mediante IPv6 sin necesidad de modificar el código fuente. Se dan algunas recomendaciones sobre cómo migrar una aplicación a IPv6, o mejor aún (aunque con el coste de un mayor esfuerzo), sobre cómo transformarlas para dar soporte tanto a IPv4 como a IPv6. Finalmente se discuten los requisitos para la migración gradual para las aplicaciones implantadas en ciertos escenarios de transición. Algunos ejemplos de servicios y aplicaciones a implantar en redes pre-comerciales son presentados en "Desarrollo de servicios en redes IPv6 y experiencia en redes precomerciale", por Rüdiger Geib, Eduardo Azañón Teruel, Sandra Donaire Arroyo, Aurora Ferrándiz Cancio, Carlos Ralli Ucendo y Francisco Romero Bueno. Estos servicios están siendo desarrollados por el equipo de desarrollo de Euro6IX, un proyecto del programa europeo IST (Information Society Technologies), para su implantación en su red multiproveedor. Todas las aplicaciones descritas en este artículo se caracterizan por tener una gran integración con el entorno del proveedor de conectividad: la primera aplicación es una herramienta de gestión de red para redes IPv6 multiproveedor; La segunda permite la detección de intrusos en redes IPv6; finalmente, se describe una aplicación de Voz sobre IP (VoIP) que se beneficia del soporte de Calidad de Servicio (Quality of Service, QoS) que la red puede ofrecer. 4 novática / upgrade nº 174 marzo-abril 2005

4 IPv6 - Más que un protocolo La necesidad de un nuevo protocolo de red surgió a principios de los años 90 De entre las características más prometedoras que IPv6 puede ofrecer encontramos la seguridad extremo a extremo, tal y como presenta "Seguridad con IPv6", de Latif Ladid (Coordinador del Grupo de Trabajo europeo de IPv6 y Presidente del IPv6 Forum), Jimmy McGibney y John Ronan. Se presentan los desafíos de seguridad en lo que al nivel de red se refiere, seguidos a continuación de una descripción de IPsec, y de los beneficios que puede ofrecer IPv6 a la seguridad a nivel de red, basados en el modelo de comunicación extremo a extremo y en el gran número de bits disponibles en la dirección IPv6. También se considera la seguridad en entornos en transición. Multihoming, la capacidad de obtener conectividad a través de múltiples proveedores, es el tema clave de "Herramientas para la provisión de multihoming en IPv6", de Marcelo Bagnulo Braun, Alberto García Martínez y Arturo Azcorra Saloña. El soporte que da actualmente IPv4 para multihoming resulta ser limitado. En cambio, en IPv6 es posible implementar una arquitectura basada en el intercambio de información entre los equipos finales, teniendo a la vez en cuenta ciertas consideraciones de seguridad. Esta arquitectura está siendo desarrollada actualmente en el IEFT. "NEMO: movilidad de redes en IPv6", de Carlos Jesús Bernardos Cano, Ignacio Soto Campos, María Calderón Pastor, Dirk von Hugo y Emmanuel Riou, estudia la movilidad de redes en un entorno IPv6. Este artículo describe la solución de movilidad definida en el Grupo de Trabajo del IETF de NEMO (NEtwork MObility), analizando sus limitaciones. Adicionalmente, se presentan algunas de las contribuciones a la investigación en redes móviles desarrolladas en el marco del proyecto IST DAIDALOS (Designing Advanced network Interfaces for the Delivery and Administration of Location independent, Optimised personal Services). En último lugar, "Estado de IPv6 en el mundo y los Grupos de Trabajo de IPv6", de Jordi Palet Martinez, presenta un resumen de las iniciativas y esfuerzos llevados a cabo en Europa para la promoción de IPv6 por parte de laos Grupos de Trabajo de IPv6 europeos y nacionales. La estructura, objetivos y logros de dichos grupos son analiza- dos, prestando especial atención al grupo español. Finalmente, queremos agradecer encarecidamente a los autores el esfuerzo y el profundo conocimiento que han volcado en estos artículos, así como a los editores de Novática y UPGRADE por ofrecernos sus páginas para publicar esta. Esperamos que la lectura de la misma no sólo sea provechosa, sino que además inspire la curiosidad del lector sobre esta tecnología que podría constituir el paradigma de red del mañana. Referencias [1] V. Fuller, T. Li, J. Yu, K. Varadhan. "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy". RFC 1519, septiembre [2] G. Huston. "Observations on the Management of the Internet Address Space". RFC 1744, diciembre [3] G. Huston. IPv4-How long do we have? Cisco IP Journal, < enero Referencias útiles sobre Ipv6 Las siguientes fuentes complementan aquellas que aparecen en los artículos que forman esta, con el fin de facilitar la tarea de los lectores interesados en profundizar en la materia. Libros Christian Huitema. IPv6 the New Internet Protocol (second edition). Prentice Hall, Silvia Hagen. IPv6 Essentials. O Reilly, Niall Richard Murphy, David Malone. IPv6 Network Administration. O Reilly & Associates, Hesham Soliman. Mobile IPv6. Pearson Education, Jun-Ichiro Itojun Hagino. IPv6 Network Programming. Butterworth-Heinemann, Mark Miller, P. E. Miller. Implementing IPV6: Supporting the Next Generation Internet Protocols (segunda edición). Hungry Minds, Buck Graham. TCP/IP Addressing : Designing and Optimizing your IP Addressing Scheme (segunda edición). Morgan Kaufmann, Joseph Davies. Understanding IPv6. Microsoft Press, Pete Loshin. IPv6: Theory, Protocol, and Practice (segunda edición). Elsevier Science & Technology Books, Hyewon Keren Lee. Understanding IPv6. Springer-Verlag New York LLC, 2005 Marcus Goncalves, Kitty Niles. IPv6 Networks. McGraw-Hill Osborne, Sitios web IPv6 Forum. < com>. 6Link. < IPv6 Cluster. < IETF IPv6 Working Group. < IETF IPv6 Multihoming Working Group. < charter.html>. IETF IPv6 Operations Working Group: < / The IPv6 Portal. < IPv6 News: HS247. < Freenet6. < Capítulo Español del IPv6 Task Force. < / Publicaciones de sociedades (no especialmente orientadas a IPv6) IEEE Communications Magazine. < Communications of the ACM. < IEEE Network. < pubs/net/>. Otras publicaciones IPv6style.< index.shtml>. Conferencias IPv6 Forum Summits. < ipv6forum.com>. IPv6 Workshop at SAINT - International Symposium on Applications and the Internet. < novática / upgrade nº 174 marzo-abril

5 IPv6 - Más que un protocolo Jim Bound Chief Technology Officer, IPv6 Forum <Jim.Bound@hp.com> Estado del despliegue de IPv6 en 2005 Traducción: Alberto Cabellos Aparicio (Dept. d'arquitectura de Computadors, Universitat Politècnica de Catalunya). 1. Introducción Inicialmente, los despliegues piloto de IPv6 (Internet Protocol version 6) fueron caóticos, centrándose en las características técnicas básicas del protocolo, pero en la actualidad la atención se está empezando a centrar en las diferentes opciones a la hora de implantarlo. La atención se centra ahora en el despliegue de infraestructuras de red, despliegue que está siendo guiado por los proveedores, las empresas, los clientes, los servicios multimedia y las necesidades de movilidad de las redes de nueva generación. El impulsor del mercado son los servicios multimedia pues los usuarios requieren movilidad cuando usan sus dispositivos multimedia y este requerimiento da lugar a nuevos componentes de infraestructura de red en la redes de proveedores, empresas y clientes (PECN, Provider Enterprise and Consumer Networks). Los prototipos de red del 2005 ayudarán a preparar el despliegue de infraestructura de red IPv6 para PECN y definirán un conjunto de modelos de implantación y de transición que podrán ser usados por la industria o por las Administraciones Públicas. Este artículo explica el estado general actual de los modelos de despliegue y cómo están ayudando a la implantación comercial de IPv6. Para dar soporte a un despliegue comercial con garantías, debe empezarse por la infraestructura de red, aplicaciones, middleware, seguridad y gestión de red, tanto para los mercados PECN como para los usuarios. La planificación y el análisis operativo para un despliegue de IPv6 masivo en una red requieren experimentación y planificación, que no son imprescindibles sin embargo para empezar con el despliegue de la infraestructura de red y, de hecho, el despliegue actual de IPv6 demuestra este axioma. El despliegue de IPv6 deberá afrontar también algunos retos tecnológicos y de negocio para implementar los modelos descritos en este artículo, basándose en los mismos supuesto que las redes operativas actuales. Los beneficios de mercado de IPv6 se basan en el modelo extremo a extremo, pero éste no es el modelo de la mayoría de las redes actuales, por lo que se requiere una transformación de la tecnología para el nuevo mode- Resumen: el estado del despliegue de IPv6 (Internet Protocol version 6) en el año 2005 está caracterizado por redes experimentales repartidas alrededor del mundo aunque están apareciendo en la Internet pública algunos servicios IPv6 en producción. Existen productos IPv6 en el mercado, preparados para ser desplegados, pero se carece de las herramientas de gestión de red, y de las aplicaciones e infraestructuras de seguridad necesarias para un despliegue comercial. Asimismo, empiezan a aparecer planes de transición y de despliegue operacional, y el modelo de negocio está bastante bien definido para algunos mercados concretos, básicamente motivados por las ventajas tecnológicas que proporciona IPv6. Las diferentes zonas geográficas se están preparando para IPv6 a diferentes velocidades y con diferentes grados de compromiso público. Este artículo sólo puede referirse a la parte de despliegue de IPv6 que es de conocimiento público y que surge de información conocida por el autor. Asimismo, este artículo presenta modelos de despliegue actual de IPv6 y en qué contribuirán a una adopción masiva por el mercado de redes IPv6 en producción. Se discutirán estos modelos, partiendo del conjunto de actuales despliegues de IPv6 en el mundo y de lo aprendido en el IPv6 Forum y en sus grupos de trabajo (ver < Palabras clave: conectividad extremo a extremo, despliegue de IPv6, implantación de aplicaciones, implantación de seguridad. Autor Jim Bound es Chief Technology Officer del IPv6 Forum, < y coordinador del Grupo de Trabajo norteamericano de IPv6, < y trabaja también la empresa Hewlett-Packard como Fellow. Contribuye activamente a los trabajos de estandarización que lleva a cabo el IETF (Internet Engineering Task Force) y fue miembro del "IP Next Generation Directorate" del IETF que seleccionó IPv6 en 1994 como el protocolo de nueva generación para Internet. Desde 1978 se ha centrado en las redes como ingeniero y arquitecto para desarrollar nuevos productos. Ha sido galardonado con el premio IPv6 Forum Internet Pioneer como "fontanero jefe de IPv6" (IPv6 Lead Plumber). Como CTO del IPv6 Forum está trabajando como SME (Subject Matter Expert) en la Internet Society para el proyecto "Security Expert Initiative". lo, además de la propia transición hacia IPv6. La estrategia de negocio para determinar los costes y beneficios de desplegar IPv6 es un proceso en curso para los mercados objetivo PECN. 2. Modelos de despliegue Los mercados PECN se apoyan en el mismo resorte a la hora de afrontar con posibilidades de éxito el despliegue de IPv6: el proveedor. Los despliegues en empresas y clientes requerirán interoperabilidad con un proveedor y además cada uno de ellos puede ser a su vez un proveedor de su entorno. Esto no es obvio cuando se prepara el despliegue de IPv6 y tampoco lo es la razón por la cual muchos de los requerimientos y funciones para dicho despliegue son comunes en todas las PECN. Un proveedor proporciona prefijos a una empresa y ésta a su vez proporciona prefijos a su Intranet, o el consumidor a los dispositivos de su red doméstica. La asignación de direcciones IPv6 es similar en el conjunto de los mercados PECN. Esto también es aplicable a los modelos de despliegue que están siendo probados en redes experimentales y en implementación de prototipos. Las redes experimentales están probando diferentes modelos de despliegue, que son el soporte de IPv6 tanto en el núcleo del enrutado Internet, como en la frontera entre proveedor y cliente, y en las redes cliente. Por ello, dentro de este modelo se ofrecen posibilidades tanto de uso disperso o denso para el despliegue IPv6 nodal de Intranet y de subredes. La transición a IPv6 en la Internet troncal será la parte más compleja de probar. En la Internet troncal inicialmente se entunelarán paquetes, encapsulando IPv6 en IPv4, o bien se usará el protocolo Multi Protocol Label Switching (MPLS) para que viajen paquetes IPv6 por el troncal de Internet de una manera transparente a la infraestructura IPv4 desplegada actualmente. Existen redes piloto que hacen la prueba de transportar paquetes IPv6 por el troncal de Internet y otras redes piloto están empezando a 6 novática / upgrade nº 174 marzo-abril 2005

6 IPv6 - Más que un protocolo El despliegue de IPv6 deberá afrontar algunos retos tecnológicos y de negocio VPN VPN NAT-Cortafuegos-AAA Figura 1. Modelo de seguridad actual. interconectarse desde diferentes regiones geográficas, lo cual es bueno para poder probar un paradigma de la Internet troncal. En la página web del IPv6 Forum, < se puede ver una lista de redes experimentales en los países que tienen subcapítulos de dicho foro. En el borde entre proveedor y cliente de las redes experimentales se están probando actualmente paquetes nativos IPv6 y túneles IPv6 sobre IPv4. Cuando no se emplea IPv6 nativo en la Internet troncal, lo que se hace es usar diversos mecanismos de transición a IPv6 para mover IPv6 a través de infraestructuras IPv4 mediante un método de doble pila (dual stack). Esto permite al mercado de PECN poder probar y verificar un modelo de despliegue que se ajuste a su requisito de negocio de dar soporte a una implantación densa o dispersa. El lado proveedor también puede usar IPv6 sobre MPLS con un troncal de Internet que lo soporte (independientemente de si admite IPv4 o IPv6). Esta aproximación se está usando en diversas redes experimentales. La implementación troncal o a nivel de subred dentro de una red piloto Intranet o PECN se está realizando tomando la dual stack tanto para los modelos de despliegue de IPv6 en forma dispersa como densa. En la forma dispersa (sparse view) sólo se actualizan los nodos o redes que necesitan funcionar con IPv6; en la forma densa (wide-use view) el enrutado IPv6 será predominante frente a IPv4 en los troncales de las Intranet y en las subredes.. 3. Despliegue de infraestructura de red El despliegue actual está verificando la infraestructura de red para dar soporte a la instalación de redes IPv6 en los mercados PECN. Dicha infraestructura incluye el hardware, el software y las aplicaciones necesarias para que una red IPv6 pueda empezar a transmitir datos y dar soporte a la implementación del conjunto de protocolos de Internet en una red y en la red troncal de Internet para comunicaciones extremo a extremo. El despliegue actual utiliza productos de diferentes fabricantes de diversos países y está demostrando que la infraestructura IPv6 puede proporcionar conectividad e interoperabilidad usando diferentes implementaciones. Se ha verificado la implementación de protocolos de enrutado para IPv6. Las aplicaciones de infraestructura de la red nodal se han utilizado y probado ampliamente así como las comunicaciones nodo a nodo para autoconfiguración, la configuración de parámetros de red para la red y los nodos, la transferencia de ficheros, men-sajería electrónica, acceso a Web y servicios. También se han verificado y probado las APIs (Application Program Interfaces) de IPv6, por lo que los proveedores de aplicaciones pueden migrarlas para dar soporte a IPv6. También se han implementado mecanismos de transición y han sido probados en redes IPv6, habiendo demostrado su capacidad para soportar diferentes combinaciones de interoperabilidad entre IPv4 e IPv6. Se han usado los modelos de despliegue denso y disperso en diversas redes piloto con interconexión IPv6 nativa (como Moonv6 < y < org>). El despliegue también ha verificado que los usuarios PECN tendrán una amplia variedad de opciones para la transición y que, dependiendo de su modelo de negocio o de su punto de vista tecnológico respecto a IPv6, podrán utilizar un amplio abanico de mecanismos de transición. El despliegue de infraestructura de red IPv6 para los mercados PCEN ofrece claramente las siguientes características: Existen y de forma comercial productos IPv6 dual stack. Soporte de comunicaciones IPv6 entre nodos en enlace o subred. Los enlaces y subredes IPv6 se pueden intercomunicar a través del troncal de Internet. IPv6 da soporte a las aplicaciones de la infraestructura de la red troncal IPv6. novática / upgrade nº 174 marzo-abril

7 IPv6 - Más que un protocolo Existen mecanismos de transición para soportar interoperabilidad entre IPv4 e IPv6. Las redes experimentales IPv6 han empezado a desplegar movilidad utilizando IPv6 y a comprobar las ventajas de IPv6 para redes móviles específicas (Mobile Ad Hoc) móviles y para movilidad ininterumpida (Seamless Mobility). Así pues, lo anteriormente comentado proporciona una base para un despliegue más amplio de IPv6 que podrá dar soporte al desarrollo de redes de nueva generación en los mercados PECN. 4. Aplicaciones, middleware y gestión para el despliegue de IPv6 En general, las aplicaciones y el middleware usados para verificar el despliegue de IPv6 han sido software libre y gratuito, y han demostrado que aplicaciones multimedia y servicios web pueden funcionar (y funcionan) eficientemente en una red IPv6. Sin embargo aún no han sido portadas (en el año 2005) aplicaciones de streaming, web proxy caches, aplicaciones de infraestructura de seguridad como prevención de intrusiones o infraestructura de clave pública, bases de datos, aplicaciones para fabricación y aplicaciones corporativas. Esto está frenando el despliegue de IPv6, por lo que es absolutamente necesario que para en todo este conjunto de aplicaciones estén disponibles para los mercados PECN de forma que puedan implementarse operativamente. Otro requerimiento funcional necesario para IPv6 que aún no ha sido verificado suficientemente son las aplicaciones de gestión de red IPv6 y la interoperabilidad entre IPv4 e IPv6. Se han programado aplicaciones para gestionar redes IPv6 usando SNMP (Simple Network Monitoring Protocol) pero no se han integrado con IPv4, algo que será necesario para el despliegue en redes en producción. Las aplicaciones para gestión de red existentes para IPv4 deberán ser portadas para soportar IPv6. 5. Despliegue de seguridad y retos de negocio para IPv6 Hoy en día, los usuarios que acceden a la red utilizan un modelo de seguridad donde la autenticación se hace basándose en un cortafuegos o bien en la implementación del conjunto de protocolos AAA (Authentication, Authorization, Accounting). Muchos usuarios están detrás de enrutadores Network Address Translation (NAT) que traducen las direcciones origen de la cabecera IP y mantienen el estado de dichas direcciones para comunicarse con nodos y aplicaciones remotas desde su red Intranet. Además, el acceso a la red por algunos usuarios se hace a menudo a través de túneles VPNs (Virtual Private Networks) donde la seguridad se localiza en el extremo de la red. En general, los modelos de seguridad de muchos usuarios se basan en que ésta se localiza en el extremo de la red (figura 1). Hoy día los usuarios se conectan a Internet confiando en un tercero, usualmente con un NAT en el extremo de su propia red. Las tecnologías emergentes como el protocolo IPsec (Secure Internet Protocol) para comunicación extremo a extremo, o redes Peerto-Peer (P2P) con cifrado, no pueden usarse con NAT, bien porque que estas aplicaciones utilizan la dirección IP como una clave para seguridad de la comunicación o bien porque requieren una dirección IP enrutable globalmente en una red Internet. El modelo actual no permite el modelo de confianza extremo a extremo, entre dos nodos, usuarios o aplicaciones, ya sean fijas o móviles. Además, NAT no permite que muchas aplicaciones que se basan en tecnología P2P funcionen cuando el nodo sale de la Intranet, impidiendo movilidad ininterrumpida a través de Internet. IPv6 restablecerá la posibilidad de usar aplicaciones en ambos modelos, pero esta misma evolución tecnológica tendrá ramificaciones rompen el modelo de seguridad que la operativa actual de Internet da por supuesto. Con IPv6 aparece un nuevo modelo que proporciona seguridad extremo a extremo, aunque queda por definir cómo se diseña, se administra, se despliega y se implementa operativamente. La figura 2 muestra una posible concreción. El modelo actualizado de la figura 2 da soporte a las funcionalidades del actual, pero prescinde del NAT para poder dar soporte a la evolución de las aplicaciones P2P así como a la seguridad extremo a extremo. Las VPNs aún están disponibles, pero el Gestor de Seguridad permite un modelo de confianza extremo a extremo para protocolos de seguridad como IPsec. El modelo actual de cortafuegos proporcionará un entorno de red seguro (dentro de un dominio) en los extremos de la red permitiendo diferentes modelos de seguridad. El Gestor de Seguridad incorporará un sistema de detección de intrusos (IDS, Intrusion Detection System) y, si existe un fallo de seguridad en la red, podrá cortar las comunicaciones extremo a extremo y forzar que todas las comunicaciones pasen por el perímetro del cortafuegos como un operación Intranet para las comunicaciones Internet. VPN VPN IPsec E2E IPsec E2E Gestor de Seguridad Extremo a Extremo (Cortafuegos, AAA, Movilidad ) Figura 2. Modelo de seguridad extremo a extremo. 8 novática / upgrade nº 174 marzo-abril 2005

8 IPv6 - Más que un protocolo El modelo extremo a extremo puede dar soporte a la tecnología inalámbrica Figura 3. Tecnología inalámbrica y seguridad extremo a extremo. Este modelo de seguridad considera la red como un todo, y no como un solo punto de entrada, dando soporte a una seguridad centrada en la red. Este modelo extremo a extremo puede también dar soporte a la tecnología emergente inalámbrica con movilidad ininterrumpida tal y como se muestra en la figura 3. La figura 3 muestra cómo el Gestor de Seguridad se puede usar con métodos de AAA para permitir el acceso seguro a las redes inalámbricas, además del cifrado soportado por IEEE i,que permite el cifrado de los paquetes a nivel 2. El Gestor de Seguridad extremo a extremo con i dará soporte a movilidad segura conjuntamente con las extensiones de IPv6 móvil a la arquitectura IPv6 que se despliegue. El trabajo en curso con IEEE n para proporcionar mayor rendimiento reforzará el método seguro de acceso a redes inalámbricas i y dará aún mayor efectividad a este método emergente. La tecnología global necesaria para que las redes permitan un modelo de seguridad extremo a extremo y P2P ya está definida, pero el despliegue de la misma será profundamente disruptivo para el mercado. La evolución tendrá un impacto en los actuales métodos operativos de las redes y en las prácticas de negocio de Internet. Un ejemplo de los retos técnicos a los que nos deberemos enfrentar es que los cortafuegos, filtros e IDS actuales dan por supuesto que pueden acceder a los datos del protocolo de transporte. Sin embargo, según el nuevo modelo éstos no estarán accesibles para las implementaciones cuando los datos se envíen cifrados (por ejemplo con IPsec o i). Sólo la cabecera IP estará expuesta en los extremos de la red en este modelo. Desde el punto de vista de los negocios, el despliegue y los modelos operacionales actuales para Internet se suelen basar en cifrado en el extremo de la red. El modelo de seguridad extremo a extremo será disruptivo, pero también proporcionará un modelo superior, más eficiente para las comunicaciones P2P y para las redes que tienen como requerimientos un modelo de confianza extremo a extremo. Este modelo también tiene un mayor rendimiento y ventajas de gestión operativa, una vez que se ha creado la infraestructura para dar soporte a un entorno seguro para aplicaciones P2P, que crecerá guiado por la evolución de la comunicación móvil ininterrumpida, y para la aparición de a una sociedad móvil para los negocios y para la gente en general. Este nuevo modelo puede ser también un estímulo económico para nuevos negocios, para los que quieran adoptar esta tecnología lo antes posible y para proveedores que proporcionen productos y servicios para la transición hacia un modelo de seguridad extremo a extremo, y los primeros que lo adopten serán los que saquen los mayores beneficios de esta nueva tecnología. Además, con IPv6 tenemos la posibilidad de hacer descubrimiento de nodos y operaciones de red, facilidades que proporcionarán mayores beneficios para las redes de nueva generación y para la movilidad. No obstante, en una red inalámbrica los nodos y la infraestructura que den soporte a estas nuevas posibilidades deberán también afrontar los nuevos problemas de seguridad de red que conllevan estos mecanismos. El actual despliegue ha comenzado a probar IPsec extremo a extremo, y el modelo de seguridad comentado anteriormente se está diseñando para ser implantado en diversas redes experimentales. Las aplicaciones de seguridad para IPv4 deberán migrarse a IPv6 para su despliegue masivo en redes de producción. Agradecimientos El autor quiere agradecer la información compartida y dar las gracias a los miembros del IPv6 Forum, a los Grupos de Trabajo de IPv6, a empresas, fabricantes, representantes de las Admnistraciones Públicas y personas que le han proporcionado la información sobre el despliegue actual que se presenta en este artículo. novática / upgrade nº 174 marzo-abril

9 IPv6 - Más que un protocolo Albert Cabellos Aparicio, Jordi Domingo Pascual Dept. d Arquitectura de Computadors, Universitat Politècnica de Catalunya Visión general del protocolo IPv6 <{acabello,jordid}@ac.upc.edu> 1. Introducción IP significa Internet Protocol y fue desarrollado en la década de los 70 con el propósito de interconectar tecnologías de red heterogéneas. IP fue un gran éxito, e hizo posible la Internet de hoy en día. Actualmente Internet funciona con la versión 4 (IPv4) [1] del protocolo IP, sin embargo el gran crecimiento experimentado por Internet lo esta llevando a sus límites. Durante la década de los 90, en la Internet Engineering Task Force (IETF) [2] se empezaron a identificar varios problemas relacionados con el protocolo IPv4. Éste utiliza 32 bits para identificar interfaces de red (comúnmente conocidos como "dirección de Internet"). 32 bits eran suficientes en la época en que IPv4 fue diseñado y, de hecho, jamás se pensó en soportar una red tan grande como Internet. Sin embargo, para la Internet de hoy en día, la capacidad de direccionamiento de 32 bits resulta escasa y esto ha conllevado la aparición del Network Address Translation (NAT) y otros mecanismos que, a pesar de permitir conectarse a Internet usando una sola dirección IPv4, rompen con los principios de Internet. La arquitectura de Internet se basa en el principio extremo a extremo [3] que dice que dos nodos cualesquiera de Internet deben poder comunicarse sin impedimento alguno. Esta restricción frena el crecimiento de Internet así como la creación de nuevos servicios y aplicaciones. Por estos y otros motivos, a IETF diseñó un substituto para IPv4: IPv6. IPv6 [4] es la nueva versión del Internet Protocol y tiene substanciales mejoras. Tiene un espacio de direccionamiento mucho más amplio que el de IPv4, concretamente 128 bits. Con IPv6 tenemos muchísimas direcciones (3.4 x ), podemos conectar innumerables dispositivos a Internet sin romper el principio de comunicación extremo a extremo, podemos crear una compleja jerarquía de direcciones y conseguir una autoconfiguración mucho más simple. IPv6 también proporciona un formato de cabecera más eficiente y los enrutadores son capaces de procesarla más rápidamente. Resumen: IP significa Internet Protocol y fue diseñado en los setenta con el propósito de interconectar redes con tecnologías heterogéneas. IP fue un gran éxito e hizo posible la Internet actual. Hoy en día, Internet funciona básicamente con la versión 4 del protocolo IP (IPv4); sin embargo, el propio éxito de Internet esta llevando IPv4 a sus límites. La IETF (Internet Engineering Task Force) diseñó IPv6 como substituto a IPv4. Este nuevo protocolo, al margen de tener nuevas funcionalidades, soluciona la mayoría de problemas de IPv4. Este artículo presenta una visión general del protocolo IPv6, el formato de su cabecera, el protocolo Neighbour Discovery y uno de los aspectos más críticos de IPv6: su transición. Se presentan una serie de mecanismos de transición que proporcionan comunicación entre IPv4 e IPv6. Palabras clave: cabeceras de extensión, direccionamiento IPv6, formato cabecera IPv6, IPv6, Mecanismos de Transición, Neighbour Discovery. Autores Albert Cabellos Aparicio es estudiante de doctorado en el Dept. d Arquitectura de Computadors de la Universitad Politècnica de Catalunya (UPC). Allí recibió el título de Ingeniero en Informática (2001). Sus principales temas de investigación son movilidad, gestión y provisión de Calidad de Servicio y transición a IPv6. Actualmente está trabajando con diversos protocolos de movilidad. Simultáneamente al inicio de la tesis Doctoral también está desempeñando tareas de soporte a la investigación al Centro de Comunicaciones Avanzadas de Banda Ancha (CCABA). Aparte también ha formado parte en proyectos IST, como por ejemplo LONG, < y en proyectos del Ministerio de Ciencia y Tecnología como SABA y SAM. Actualmente participa en E- NEXT y EuQoS. Para información más detallada se puede consultar < Jordi Domingo Pascual es Ingeniero de Telecomunicación (ETSETB UPC), Doctor en Informática (FIB UPC), Catedrático de Universidad del Dept. d Arquitectura de Computadors (UPC). Promotor y fundador del Centro Específico de Investigación de Comunicaciones Avanzadas de Banda Ancha (CCABA) de la UPC. Participación en proyectos de investigación: Technology for ATD, EXPLOIT, InfoWin, MICC, IMMP, LONG, ENET, E-NEXT y EuQoS. Participación como responsable en proyectos financiados por la CICYT: PLANBA, AFTER, TR-1, SABA, SABA2, SAM. Participación en proyectos financiados por la CICYT: TIC C02-02, CASTBA, MEHARI, MIRA. Otros proyectos de I+D: Internet2 Catalunya (i2cat), responsable de la infraestructura de comunicaciones de banda ancha (proyecto GigaCAT). Participación en proyectos de cooperación: Programa Erasmus/ Socrates, Leonardo, COST237 (Multimedia Telecommunication Services), COST264 (Enabling Networked Multimedia Group Communication), COST263 (Quality of Future Internet Services). Temas de investigación en los que ha publicado: conmutación ATM, redes ATM, encaminamiento ATM, control de admisiones ATM, caracterización de tráfico en redes ATM, comunicaciones de Banda Ancha, multicast, provisión de calidad de servicio en redes IP, servicios avanzados de red (multicast, IS, DS, MPLS, movilidad, IPv6), análisis de tráfico IP, coexistencia IPv4-IPv6 y mecanismos de transición. Más información en < y < Las opciones en IPv4 son simplemente parches (como la movilidad y la seguridad) pero en IPv6 las opciones se integran más eficientemente (utilizando las nuevas cabeceras de extensión). En resumen, Internet será aún más escalable con IPv6 de lo que ya lo es con IPv4. Internet aún está usando IPv4, sin embargo IPv6 se está empezando a desplegar en redes experimentales. En el futuro, es previsible que Internet sea sólo IPv6, pero hasta ese momento IPv4 e IPv6 deben coexistir. El despliegue de IPv6 no puede interrumpir la actual Internet, ya que muchos servicios y aplicaciones dependen hoy en día de ella. Esto se consigue usando mecanismos de transición que permiten la comunicación entre el mundo IPv4 y el IPv6. Se han especificado, diseñado e implementado multitud de mecanismos de transición pero o bien proporcionan un enrutamiento menos eficiente que la comunicación nativa (IPv4 con IPv4 o IPv4 con IPv6) y en general son difíciles de desplegar. 2. El protocolo IPv6 2.1 El formato de la cabecera de IPv6 El nuevo formato de cabecera de IPv6 tiene una longitud fija de 40 octetos, mientras que en IPv4 el tamaño de cabecera era de 20 octetos más opciones (si es que son necesa- 10 novática / upgrade nº 174 marzo-abril 2005

10 Version Traffic Class Flow Label Payload Length Figura 1. Formato de cabecera de IPv6. rias). La figura 1 muestra el formato de la cabecera IPv6. Version (4 bits) La versión del protocolo, un "6" para IPv6 y un "4" para IPv4. Este campo es idéntico en IPv4. Traffic Class (8 bits) Una etiqueta usada para Calidad de Servicio, similar al campo "Type of Service" de IPv4. Flow Label (20 bits) Este campo es nuevo, y se usa para etiquetar flujos que los enrutadores podrán tratar de forma homogénea.. Payload Length (16 bits) La longitud del campo de datos (los bits siguientes a la cabecera IPv6) en octetos. Un paquete IPv6 puede transportar hasta octetos. Next Header (8 bits) El tipo de cabecera siguiente a la de IPv6. Este campo es similar al campo Protocol de IPv4, aunque incorpora la identificación de las cabeceras de extensión. Hop Limit (8 bits) El valor de este campo se decrementa al pasar por cada enrutador, y cuando llega a cero el paquete se descarta. Este campo es similar al campo Time to Live del protocolo IPv4. Source Address (128 bits) La dirección del nodo originador del paquete. Destination Address (128 bits) La dirección destino del paquete. La cabecera IPv6 tiene menos campos que la cabecera IPv4. El "checksum se considera que no es rlevante ya que la probabilidad de que un fallo en la transmisión provoque el descarte del paquete es muy baja. La campos usados para la fragmentación en IPv4 (Identification y Fragment Offset) también han sido eliminados, ya se decidió que, para conseguir mayor eficiencia, en IPv6 un paquete no puede ser fragmentado en ruta y IPv6 - Más que un protocolo Internet será aún más escalable con IPv6 de lo que ya lo era con IPV4 Next Header Hop Limit IPv6 Source Address IPv6 Destination Address por tanto sólo el nodo originador del paquete puede implementar la fragmentación usando una cabecera especial. Esto obliga a que cuando un nodo decide comunicarse con otro debe conocer cuál es la MTU (Maximum Transfer Unit) del camino [5] y enviar los paquetes con el tamaño correcto, o utilizar la MTU mínima garantizada de 1280 bytes. Tal y cómo se ha comentado, la cabecera IPv6 tiene una longitud fija y los octetos van alineados a 64 bits para conseguir una mayor eficiencia en los nuevos procesadores de red de 64 bits 2.2 Cabeceras de extensión de IPv6 En IPv6, la información opcional de la capa de red se codifica en unas cabeceras al margen de la propia de IPv6. Estas cabeceras se colocan entre la de IPv6 y la del protocolo de transporte. La figura 2 muestra cómo se codifican estas cabeceras de extensión dentro del paquete IPv6. Estas cabeceras proporcionan una gran flexibilidad en el protocolo. Usándolas, el protocolo puede extender sus funcionalidades de una manera sencilla y eficiente. La IPv6 Header TCP Header Data NextHeader TCP IPv6 Header NextHeader RH Routing Header NextHeader FH Fragment Header NextHeader TCP Figura 2. Cabeceras de extensión de IPv6. cabecera IPv6 mide 40 octetos, y en el campo Next Header apunta a la siguiente cabecera, que puede ser la del protocolo de transporte (TCP, UDP ) o bien una cabecera de extensión. El estándar de IPv6 define seis tipos de cabeceras de extensión que salvo una excepción (Hop-by-Hop) no son examinadas ni procesadas por ningún enrutador en el camino hasta el destino. En IPv4 las opciones vienen limitadas por el tamaño de la cabecera IPv4, mientras que en IPv6 no existe una limitación virtual. En general, en IPv6 se ha tratado de optimizar el rendimiento de forma que no se procesan salvo que sea el momento de ser usadas. Las opciones del protocolo IPv4 se usan escasamente y muchas de las nuevas funcionalidades (como movilidad o seguridad) de IPv6 basan su funcionamiento en las cabeceras de extensión. 3. Funcionamiento del protocolo IPv6 3.1 Direccionamiento IPv6 Las direcciones IPv6 son campos de 128 bits de extensión que identifican únicamente una o más interfaces de red. Es más, podemos asignar una o más direcciones IPv6 a una interfaz de red. IPv6 tiene tres tipos de direcciones: Unicast Este tipo de direcciones identifican únicamente una sola interfaz de red, son el tipo de direcciones más comunes. Multicast Identifican un conjunto de interfaces de red, usualmente pertenecientes a diferentes nodos. Si un paquete se envía a una dirección multicast, éste se entregará a todas las interfaces de red identificadas por esa dirección en concreto. Anycast Este tipo de direcciones se asigna a más de una interfaz de red y, si un TCP Header Data novática / upgrade nº 174 marzo-abril

11 IPv6 - Más que un protocolo Direcciones en notación CIDR ::/128 ::1/128 ::/96 ::FFFF:0:0/96 FE80::/10 FF00::/8 Significado Dirección no especificada. Se usa cuando la interfaz aún no tiene ninguna dirección asignada. La dirección de loopback, se corresponde con la dirección IPv Las direcciones compatibles IPv4 usadas por SIIT (ver abajo). Las direcciones compatibles IPv4, también usadas por SIIT (ver abajo). El prefijo para las direcciones Link-Local. Direcciones multicast. Tabla 1. Direcciones IPv6 especiales. paquete se envía a una dirección Anycast el paquete se enrutará a la interfaz más cercana (en términos de distancia de enrutado). Las direcciones IPv6 se representan como una cadena de caracteres en el formato xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx donde xxxx es un número de 16 bits en hexadecimal. La figura 3 muestra algunos ejemplos. Algunas direcciones IPv6 pueden contener largas cadenas de ceros, en este caso se puede usar "::" que indica uno o más grupos de 16 bits de ceros. Por ejemplo, la dirección "2001:0145:4556:0000:0000:0000: 0000:0002" se puede representar como "2001: 145:4556::2" (también se eliminan los ceros que están antes de los dígitos hexadecimales significativos) de una manera más simple. La figura 4 muestra la estructura básica de las direcciones unicast actualmente utilizadas en IPv6. La representación textual de los prefijos de red IPv6 es similar a CIDR (Classless Interdomain Routing) para IPv4 y la notación utilizada para expresar un prefijo es la de "Dirección IPv6/Longitud del prefijo". La longitud del prefijo es un valor decimal que especifica cuántos bits contiguos de la parte izquierda de la dirección forman parte del prefijo de red a un nivel de encaminamiento dado. Por ejemplo, "2001:0145:4556::2/48" representa el prefijo de 48 bits "2001:0145:4556". Dependiendo del ámbito de una dirección unicast, ésta puede pertenecer a un subtipo diferente; si el ámbito es Internet, se denominan Global Unicast Addresses y si el ámbito es simplemente un enlace se conocen como Link- Local IPv6 Unicast Addresses. El primer tipo de direcciones unicast tienen un "prefijo de subred" subdividido en Global Routing Prefix, donde su valor es asignado a un dominio, y el Subnet IP, que identifica un enlace en ese dominio. Las direcciones tipo Link-Local se han diseñado para ser usadas en el enlace y su propósito es, entre otros, la autoconfiguración de IPv6. El estándar IPv6 define algunas direcciones especiales, siendo mostradas las más importantes en la tabla Neighbour Discovery en IPv6 Este protocolo [7] soluciona el conjunto de problemas relacionados con la interacción entre nodos conectados al mismo enlace, definiendo mecanismos para descubrir enrutadores, autoconfigurarse y resolver direcciones de nivel de enlace entre otros. El protocolo IPv6 Neighbour Discovery (ND) es similar al protocolo ARP (Address Resolution Protocol) de IPv6, sin embargo tiene más funcionalidades. Además, ND se basa en el protocolo ICMPv6 (Internet Control Message Protocol version 6) [8] que usa multicast a nivel de red, mientras que ARP depende de las diferentes implementaciones del nivel de enlace. Cuando dos nodos pertenecientes al mismo enlace desean enviarse paquetes, deben conocer sus respectivas direcciones de nivel de enlace, típicamente una dirección MAC (Machine Address Code) Ethernet. En este caso, el nodo que inicia la comunicación envía un mensaje especial ICMPv6 Neighbour Solicitation a una dirección multicast, preguntando por la dirección MAC del nodo. El otro nodo, al recibir este mensaje, responde con un mensaje Neighbour Advertisement anunciando su dirección MAC. Dirección IPv6 Multicast: En IPv6 los nodos se suelen configurar automáticamente. Los enrutadores IPv6 tienen un prefijo de red configurado manualmente en sus interfícies y envían mensajes de Router Advertisement periódicamente. En estos mensajes incluyen dicho prefijo y algunos otros parámetros importantes para la autoconfiguración. Los nodos, al arrancar, configuran una dirección Link-local IPv6 basándose en su propia dirección de nivel dos en todas sus interfaces de red. Esta dirección la pueden usar para comunicarse en ese mismo enlace. Una vez asignada esta dirección, deben configurar una dirección Global Unicast Address para poder comunicarse con otros nodos que no estén conectados a su mismo enlace. El nodo crea un identificador de interfaz (64 bits), basándose de nuevo en la dirección de nivel 2 [9] y, añadiendo el prefijo obtenido gracias a los mensajes Router Advertisement, genera una Global Unicast Address. Este tipo de configuración se denomina Stateless Autocon-figuration. IPv6 también soporta Stateful Autoconfiguration, donde los nodos se configuran usando DHCPv6 (Dynamic Host Configuration Protocol for IPv6) [10], y configuración manual. 3.3 Arquitectura de direccionamiento de IPv6 IPv6 se esta desplegando ampliamente en redes experimentales y la IANA (Internet FEDC:BA98:7654:3210:FEDC:BA98:5678:3321 Dirección IPv6 Unicast: 2001:0145:4556:0000:0000:0000:0000:0002 Figura 3.Representación en formato texto de las direcciones IPv6. 12 novática / upgrade nº 174 marzo-abril 2005

12 IPv6 - Más que un protocolo Assigned Numbers Authority) a través de los RIRs (Regional Internet Registries) está asignando direcciones IPv6. RIPE (Réssaux IP Européens) es el RIR encargado de Europa y está asignando direcciones IPv6 a ISPs (Internet Service Providers) y otras entidades. La actual política de asignación de direcciones IPv6 [11][12][13] define que el bloque de direcciones 2000::/3 será el primero en ser asignado. Los RIRs asignarán prefijos /32 a los ISPs, a su vez, los ISPs asignarán /48 a redes finales (como universidades) y a los usuarios finales (como subscriptores DSL) se les asignarán bloques /64. Finalmente, si un usuario sólo requiere una dirección (como usuarios móviles) y no necesitarán más direcciones en el futuro, se les asignará un prefijo /128. IANA y los RIRs asignarán bloques de direcciones adyacentes siempre que sea posible. En febrero de 2005 se han asignado cerca de millones de prefijos de /48 bits (a centros de educación, ISPs comerciales ), siendo más de la mitad asignados por RIPE [14]. 4. Mecanismos de Transición No es previsible que IPv6 se despliegue de manera rápida. Actualmente existe una gran infraestructura IPv4 desplegada y funcionando, y, por lo tanto, el despliegue de IPv6 debe ser tan poco disruptivo como sea posible. Esto significa que, aunque IPv4 e IPv6 no son compatibles, deberán coexistir por un periodo de tiempo indeterminado. Los mecanismos de transición proporcionan comunicación entre nodos IPv4 e IPv6, y aunque Longitud Variable Prefijo Subred IPv6 Figura 4. Estructura de las direcciones unicast. IPv6 IPv6 Datos Dual Stack Extremo Túnel IPv4 Túnel IPv4 IPv6 Longitud Variable ID Interfaz IPv6 se han definido varios, la IETF se está centrando en unos pocos. Los mecanismos de transición se pueden dividir en tres clases: Doble pila Se instalan ambos protocolos (IPv4 e IPv6) en nodos y enrutadores. Si se desea comunicación IPv4 se usa la infraestructura IPv4 y lo mismo sucede si se desea una comunicación IPv6. Entunelamiento Los paquetes IP se encapsulan en otros paquetes IP creando un enlace virtual. Se pueden encapsular paquetes IPv6 en paquetes IPv4 y atravesar redes IPv4 o viceversa. Mecanismos de traducción Las cabeceras IPv4 se traducen a cabeceras IPv6 y viceversa siguiendo unas reglas predefinidas Doble pila La doble pila es el mecanismo de traducción más simple, proporciona comunicación entre todos los nodos, sin necesitar encapsulación ni traducción (que en general son procesos costosos). Sin embargo existen inconvenientes: los administradores de sistemas deben mantener dos infraestructuras y no se reduce la demanda de direcciones IPv Entunelamiento Existen diferentes tipos de mecanismos de transición basados en el entunelamiento: Configured Tunnels [15], Automatic Tunnels y 6to4 [16]. En general, el principal objetivo es permitir comunicación entre nodos o redes IPv6 asiladas atravesando redes IPv4. Extremo Túnel Datos Dual Stack Figura 5. Dos redes IPV6 se comuncian usando una red IPv4. IPv6 IPv6 Datos La figura 5 muestra un ejemplo. Dependiendo en qué tipo de túneles se usen, la configuración se hace automáticamente (a través de direcciones IPv6 especiales, bajo demanda por el usuario o bien usando vínculos predefinidos entre direcciones IPv4 e IPv6) o manualmente (por los administradores). En general los mecanismos de transición basados en entunelamiento son fáciles de desplegar, son transparentes para los nodos IPv6. Sin embargo, deben enviarse dos cabeceras IP, en algunos casos configurar los túneles manualmente o usar direcciones IPv4 (lo que sigue sin reducir la demanda). Esta aproximación al problema de la transición ha sido probada con éxito en la red del 6BONE [17] o la del proyecto LONG [18] entre otras. Este mecanismo ha sido definido para las etapas iniciales del despliegue de IPv6, donde la infraestructura IPv6 existente es escasa y la IPv4 abundante. 4.3 Mecanismos de traducción Los mecanismos de traducción proporcionan comunicación entre nodos IPv4 e IPv6 traduciendo las cabeceras de los paquetes IP/ICMP. El algoritmo que se sigue es Stateless IP/ICMP Translation Algorithm (SIIT) [19] que especifica cómo debe hacerse esa traducción; las reglas pueden verse en la tabla 2. NAT-PT (Network Address Translation - Protocol Translation) [20] se basa en NAT y utiliza las reglas de SIIT para traducir el paquete, aunque presenta algunas diferencias respecto a cómo se traducen las direcciones. En efecto, mientras SIIT requiere de algún mecanismo complejo de asignación y encaminamiento temporal de direcciones IPv4 a nodos IPv6, en NAT-PT se puede hacer una asignación de direcciones disponibles (de un conjunto dado) más sencilla. Puede proporcionar comunicación bidireccional entre nodos IPv4 y nodos IPv6 siendo transparente para éstos, además ya existe una gran experiencia en la configuración de dispositivos basados en NAT. Sin embargo, la traducción es un proceso costoso, hereda algunos de los problemas de NAT (no puede proporcionar comunicación extremo a extremo y si el protocolo de transporte envía la dirección IP se requiere algún sistema específico para ese determinado protocolo) y, finalmente, no soporta cabeceras de extensiones. Por lo tanto, muchas de las nuevas funcionalidades de IPv6 (como la movilidad) no son soportadas por NAT-PT. A pesar que NAT-PT ha sido usado intensamente en redes experimentales, la IETF se esta planteando prescindir de la especificación debido a su baja aplicabilidad. 5. Sumario IPv6 es la versión 6 del Internet Protocol, IETF lo ha diseñado como el substituto novática / upgrade nº 174 marzo-abril

13 IPv6 - Más que un protocolo Tabla 2. Reglas de SIIT para traducir cabeceras IPv4 a IPv6 y viceversa. natural de IPv4. Éste jamás fue diseñado para soportar una red tan grande como Internet y, a pesar que ha demostrado su escalabilidad, el actual crecimiento de Internet lo esta llevando a sus limites. Este artículo presenta una visión general del protocolo IPv4, mostrando el formato de su cabecera y su modo de funcionamiento. También se presenta el protocolo Neighbour Discovery y su arquitectura de direccionamiento. Uno de los mayores problemas de IPv6 es su transición desde IPv4. El artículo explica el funcionamiento de diferentes mecanismos de transición existentes definidos por la IETF. IPv6 esta preparado para un despliegue global --cerca de 1500 millones de prefijos de / 48 bits han sido asignados por IANA-- y la IETF ha finalizado la estandarización del protocolo (tan solo quedan por definir aspectos puntuales). Los fabricantes ya disponen de implementaciones experimentales de IPv6 y los principales sistemas operativos ya disponen de soporte para IPv6. Agradecimientos Este trabajo ha sido parcialmente financiado por el MCyT (Ministerio Español de Ciencia y Tecnología) bajo el contrato FEDER-TIC C04-02 y el CIRIT (Consell Interde-partamental de Recerca i Innovació Tecnològica) bajo el contrato 2001-SGR Referencias [1] J. Postel. "Internet Protocol", RFC 791, septiembre [2] The Internet Engineering Task Force (IETF). < [3] David D. Clark. "Rethinking the design of the Internet: The end to end arguments vs. the brave new world", ACM Transactions on Internet Technology, Vol 1, No 1, agosto [4] S. Deering, R. Hinden. "Internet Protocol Version 6 (IPv6) Specification", RFC [5] J. McCann, S. Deering, J. Mogul. "Path MTU Discovery for IP version 6", RFC [6] P. Fransson, A. Jonsson. "End-to-End measurements on performance penalties of IPv4 options", Global Telecommunications Conference, diciembre [7] T. Narten, E. Nordmark, W. Simpson. "Neighbor Discovery for IP Version 6 (IPv6)", RFC [8] A. Conta, S. Deering. "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC [9] S. Thomson, T. Narten. "IPv6 Stateless Address Autoconfiguration", RFC [10] D. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, julio [11] D. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, julio [12] APNIC, ARIN, RIPE NCC. "IPv6 Address Allocation and Assignment Policy", ripe-267, enero [13] R. Hinden, S. Deering. "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, abril [14] RIPE IPv6 Allocation, Statistics. < [15] R. Gilligan, E. Nordmark. "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, abril [16] B. Carpenter, K. Moore. "Connection of IPv6 Domains via IPv4 clouds", RFC 3056, febrero [17] 6BONE, testbed for deployment of IPv6. < [18] LONG (Laboratories over Next Generation Networks), IST < upc.edu>. [19] E. Nordmark. "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, febrero [20] G. Tsirtsis, P. Srisuresh. "Network Address Translation Protocol Translation (NAT-PT)", RFC 2766, febrero novática / upgrade nº 174 marzo-abril 2005

14 Eva M. Castro Barbero 1, Tomás P. de Miguel Moro 2, Santiago Pavón Gómez 2 1 Universidad de Alcalá de Henares (UAH); 2 Universidad Politécnica de Madrid (UPM) IPv6 - Más que un protocolo La migración de aplicaciones a IPv6 <eva@aut.uah.es>, <{tmiguel,spavon}@dit.upm.es> 1. Introducción Durante los primeros 90, se comenzó la revisión del protocolo IP (Internet Protocol) para atender las nuevas necesidades de Internet. La nueva versión IPv6 [1] aborda el problema del tamaño de la red proponiendo una nueva estructura de direcciones y un nuevo esquema de encaminamiento. Además, el nuevo modelo ofrece capacidades para resolver las necesidades de la nueva generación de servicios, integrando soluciones de seguridad, movilidad y calidad de servicio. La mayor parte de las nuevas capacidades de IPv6 hacen incompatible al protocolo actual IPv4 con el nuevo. Dado que todos los nodos de la red no pueden estar preparados para IPv6 al mismo tiempo, no se puede hacer una sustitución de un protocolo por otro de forma instantánea. En consecuencia, la migración se plantea como un proceso de transición lento en el que durante largo tiempo van a tener que convivir ambos protocolos. En principio, en el cambio de la versión del protocolo IP sólo deberían verse afectados los elementos relacionados directamente con este protocolo, es decir, las funciones de direccionamiento y encaminamiento propias del nivel de red. Sin embargo, la incompatibilidad de las dos versiones del protocolo IP alcanza a las aplicaciones. Las aplicaciones diseñadas para IPv4 no pueden operar directamente con el protocolo IPv6 [2] y por tanto deben ser revisadas y adaptadas adecuadamente. La interfaz que utilizan las aplicaciones --API (Application Program Interface)-- para la programación de funciones de intercambio de información con otras entidades hace visible a las aplicaciones los detalles de la versión de IP utilizada, provocando que éstas sean dependientes de la versión de IP. Debido a que el proceso de transición a IPv6 va a ser lento, será necesario revisar las aplicaciones actuales y diseñar las nuevas, no sólo para que puedan operar con el nuevo protocolo sino incluso para que puedan comunicarse con otras versiones antiguas que sólo soportan IPv4 durante el largo periodo que durará la transición. La transición a IPv6 se convierte en un problema general para el que se debe prestar atención a la red y a las aplicaciones conjuntamente [3]. Resumen: el nuevo protocolo IPv6 (Internet Protocol version 6) ha sido desarrollado recientemente para responder a las necesidades planteadas por los nuevos servicios Internet. Sin embargo, aunque se trata de protocolos del nivel de red, las aplicaciones no son ajenas al cambio. Para completar la transición a IPv6 es necesario revisar las aplicaciones. El proceso de migración no se puede hacer de forma instantánea y en consecuencia, durante el período de transición surgirán escenarios donde aplicaciones IPv4 e IPv6 tendrán que coexistir e incluso interoperar. En este artículo se exponen los escenarios de aplicación que son sensibles al cambio del protocolo IP y las posibles soluciones para que las aplicaciones funcionen en entornos heterogéneos de red, con diferentes versiones de IP. Palabras clave: coexistencia, direccionamiento, interoperabilidad, IPv6, sockets,transición a IPv6. Autores Eva M. Castro Barbero es Dra. Ingeniera de Telecomunicación por la Universidad Politécnica de Madrid en Actualmente trabaja como Profesora Titular interina de la Universidad de Alcalá de Henares. Desde 1997 ha participado en proyectos nacionales e internacionales relacionados con tele-educación e IPv6. En los últimos años ha colaborado activamente dentro del grupo de trabajo v6ops del IETF para la definición de un documento para la transición de aplicaciones a IPv6. Tomás P. de Miguel Moro es Profesor Titular de Universidad en el Depto. de Ingeniería de Sistemas Telemáticos de la Universidad Politécnica de Madrid desde Recientemente ha participado o dirigido proyectos nacionales (6SOS, SAMURAI) e internacionales (Tecodis, LONG, Euro6IX) en el diseño de servicios avanzados de colaboración, redes móviles, arquitecturas y protocolos de comunicaciones para Internet. Como subdirector de infraestructuras ha dirigido el despliegue de IPv6 en la ETSIT-UPM. Santiago Pavón Gómez es Ingeniero de Telecomunicación por la Universidad Politécnica de Madrid en 1987, Doctor por la misma universidad en 1990 y Titular de Universidad en la Escuela Técnica Superior de Ingenieros de Telecomunicación en Desde 1987 ha participado en proyectos nacionales e internacionales relacionados con técnicas de descripción formal, redes de comunicaciones, tele-educación y multimedia. Existen dos formas de abordar la interoperabilidad entre aplicaciones diseñadas para protocolos diferentes [4]. Una primera opción consiste en utilizar mecanismos de transición que permitan a las aplicaciones IPv4 comunicarse utilizando IPv6; la segunda opción consiste en modificar el código fuente de las aplicaciones para que utilicen IPv6 de forma nativa [5], utilizando incluso las nuevas funciones y estructuras de datos de la interfaz de programación de IPv6 [6]. Aunque es preferible la segunda opción es decir, que las aplicaciones funcionen de forma nativa con IPv6 en algunos casos no es la más adecuada; ya que no siempre se dispone del código fuente de la aplicación o no se dispone de recursos suficientes para llevar a cabo el trabajo. En el presente artículo se presenta la problemática de la interoperabilidad de las aplicaciones que utilizan diferentes versiones del protocolo IP y se describen las dos formas de adaptación para resolver la comunicación durante el periodo de convivencia de los dos protocolos. Finalmente, se concluye con una descripción de un conjunto de escenarios de transición para la coexistencia de aplicaciones IPv4 e IPv6. 2. Dependencias de las aplicaciones respecto a la versión de IP Aunque IP es un protocolo de red, las aplicaciones manejan direcciones IP para identificar los nodos con los que se comunican. En el modelo clásico de comunicación cliente/ servidor, las aplicaciones cliente necesitan la dirección IP del servidor para poder establecer la conexión. Esta dirección IP normalmente se proporciona como una cadena de caracteres como formato de presentación de la dirección en la aplicación. En el formato de presentación de IPv4 se utiliza la notación decimal separada por puntos (.) para representar los 32 bits y en IPv6 se utiliza la notación en hexadecimal separando cada pareja de octetos por el carácter dos puntos (:). Para que una aplicación sea compatible con IPv6 es necesario novática / upgrade nº 174 marzo-abril

15 IPv6 - Más que un protocolo que las funciones que trabajan con el formato de presentación, como por ejemplo los parser de direcciones, sean compatibles con la nueva versión. Un caso particular de este problema es el manejo de direcciones en los localizadores (URL, Uniform Resource Locator). Se sobrecarga la utilización del carácter :, pues éste se usa para la separación de cada pareja de octetos de la dirección IPv6 y también para separar el número puerto donde espera las conexiones el servidor Web. Esta ambigüedad se resuelve utilizando corchetes para diferenciar la dirección IP y el número de puerto [7], por ejemplo: /[direcciónipv6]:80/index.html Por otra parte, las aplicaciones que necesitan comunicarse a través de la red utilizan el API de comunicaciones que proporciona el sistema operativo. Normalmente, las aplicaciones implementan un módulo de comunicaciones que es el encargado de establecer y gestionar dichas comunicaciones con otras aplicaciones y por tanto, utiliza las principales características del API: Almacenamiento de las estructuras de datos que contengan las direcciones IP: la cantidad de memoria necesaria para almacenar una dirección IPv4 es 32 bits, lo que es insuficiente para almacenar una dirección IPv6 de 128 bits. En ocasiones, también se manejan direcciones IP específicas, como por ejemplo la dirección de loopback, utilizadas directamente en el código fuente y cuyas dependencias deberán eliminarse para conseguir la adecuada compatibilidad. Funciones para la apertura, cierre y gestión de las comunicaciones: afortunadamente, en el caso del API de sockets de BSD (Berkeley Software Distribution) estas funciones hacen uso de una estructura de datos genérica para el manejo de las direcciones IP. Este diseño permite mantener las mismas funciones para el acceso a las comunicaciones IPv4 e IPv6, y sólo será necesario cambiar el contenido de esta estructura de datos genérica para que almacene direcciones de un tipo o de otro. Opciones para la configuración de los parámetros de la comunicación: estas opciones definen diferentes modos de entrada/ salida, tipos de operaciones (por ejemplo, bloqueante o no), que son diferentes para IPv4 e IPv6. Desde el punto de vista de las aplicaciones, el proceso de resolución entre nombres de máquina y direcciones IP es una tarea independiente. Las aplicaciones utilizan un conjunto de funciones que permiten consultar esta asociación entre direcciones IP y nombres de máquina. Para el caso de IPv6, se han desarrollado nuevas funciones para la consulta de la resolución de nombres y direcciones IP. Estas nuevas funciones actúan independientemente de la versión del protocolo IP con la que se esté trabajando y por tanto, pueden utilizarse con cualquier tipo de dirección, ya sea IPv4 o IPv6. Aunque normalmente las dependencias respecto de la versión IP son las citadas previamente, existen algunas aplicaciones que muestran otro tipo de dependencias debidas a la utilización de las direcciones IP con significados específicos para dichas aplicaciones. Las más habituales son: Intercambio de las direcciones IP como datos del nivel de aplicación. Por ejemplo, los protocolos FTP (File Transfer Protocol) o SIP (Serial Interface Protocol). Utilización de las direcciones IP en el nivel de aplicación para identificar nodos, usuarios u otras características de la aplicación. En algunos casos incluso se registran y se almacenan para utilizarlas dentro de sistemas de autenticación. Utilización de las direcciones IP como parámetros de entrada para la aplicación. En estos casos, el intérprete de los parámetros de entrada dependerá de la versión de IP utilizada. Como consecuencia de todo esto, para completar la transición a IPv6 es necesario la adaptación de las aplicaciones al nuevo escenario, pero se trata de un proceso lento y, como hemos visto, no se reduce a sustituir una biblioteca de comunicaciones por otra. Además, en muchos casos obliga a realizar una revisión exhaustiva de gran parte del código. Sin embargo, durante el proceso de transición es necesario que las aplicaciones definidas para ambos protocolos puedan operar entre sí. El paradigma establecido para ello es la doble pila (double stack). La doble pila consiste en ofrecer la capacidad para poder operar simultáneamente con IPv4 e IPv6 en los nodos que ejecutan las aplicaciones. La aplicación utiliza la pila IPv4 del nodo donde se ejecuta cuando opera con un nodo IPv4 y la pila IPv6 cuando se trata de uno IPv6. 3. Comunicaciones IPv6 sin modificar el código fuente de las aplicaciones No obstante, el paradigma de la doble pila no es suficiente para garantizar la capacidad de una aplicación para operar sobre ambas plataformas. Por ejemplo, cuando la aplicación pide una conexión con un nodo IPv4 se debe utilizar la plataforma IPv4 y, del mismo modo, para IPv6 la plataforma a utilizar debe ser IPv6. Sin embargo, una aplicación IPv4 no puede establecer directamente comunicaciones IPv6, por lo que es preciso adaptarla previamente; pero cuando no es posible revisar el código de la aplicación es necesario interponer soluciones de adaptación que permitan seleccionar en cada caso la plataforma adecuada. Estas soluciones están basadas en mecanismos de transición instalados en los nodos finales que ejecutan las aplicaciones IPv4, permitiendo la coexistencia entre dichas aplicaciones y redes IPv6. En esta línea existen dos mecanismos experimentales desarrollados por el IETF (Internet Engineering Task Force) que realizan una traducción entre IPv4 e IPv6 en el nodo donde se está ejecutando la aplicación IPv4: Bump In the Stack (BIS) [8] y Bump In the API (BIA) [9]. BIS realiza la traducción en la pila IP y BIA realiza la traducción en la interfaz de programación de las aplicaciones, en el API. El mecanismo BIS intercepta los paquetes IP al salir del nivel IP de la máquina, antes de enviarlos a la tarjeta de red, y realiza la traducción entre IPv4 e IPv6 según los paquetes sean entrantes o salientes. BIA sigue un funcionamiento análogo a BIS, salvo que la traducción de paquetes se realiza antes de construir el paquete, en la propia interfaz de programación de aplicaciones. Por tanto, BIA es un mecanismo de transición más ligero ya que no necesita realizar una traducción del paquete, sino que construye el paquete IPv6 a partir de las funciones del API IPv4, véase la figura 1. Figura 1. Mecanismos de transición BIS y BIA. Ambos mecanismos requieren, para que realice la traducción, la instalación de un módulo específico, ya sea BIS o BIA, en el nodo que ejecuta las aplicaciones IPv4. Desafor- 16 novática / upgrade nº 174 marzo-abril 2005

16 tunadamente esta solución no siempre puede aplicarse, ya que no se dispone de una implementación de estos mecanismos para todos los sistemas operativos del mercado. 4. Comunicaciones IPv6 modificando el código fuente Los mecanismos presentados en la sección anterior permiten que las aplicaciones IPv4 existentes puedan funcionar en redes IPv6. Sin embargo, si se dispone del código fuente de las aplicaciones, lo más recomendable es modificar las aplicaciones para que éstas puedan comunicarse de forma nativa en IPv6, sin necesidad de hacer una traducción de protocolos. La adaptación de las aplicaciones para que den soporte a IPv6 puede llevarse a cabo seleccionando una de las dos opciones posibles: obtener una aplicación sólo IPv6 o desarrollar una aplicación dual Aplicaciones sólo IPv6 Las aplicaciones sólo IPv6 son las que están desarrolladas para funcionar utilizando sólo IPv6 y necesitarán ejecutarse en nodos que tengan instalada al menos la pila IPv6. Para conseguir aplicaciones sólo IPv6 partiendo de las aplicaciones IPv4 existentes es necesario modificar todas aquellas llamadas del API que son relativas a IPv4 por sus correspondientes en IPv6 [5]. El proceso de adaptación consiste en una exploración exhaustiva de todas las dependencias con IPv4 y transformarlas a dependencias con IPv6. Existen herramientas de exploración automáticas que ayudan a la Figura 2. Direcciones especiales IPv6: IPv4- mapped. IPv6 - Más que un protocolo Las aplicaciones duales son las desarrolladas para funcionar utilizando ambos protocolos búsqueda de las dependencias dentro del código fuente: scrubber [10] y checkv4 [11]. Siguiendo este método, el proceso de adaptación de la aplicación es relativamente sencillo y se necesita poco tiempo para realizarlo. Sin embargo, este método proporciona una aplicación sólo IPv6. En entornos heterogéneos de red, que son los característicos del período de transición, será necesario convivir con aplicaciones que se comuniquen utilizando ambos protocolos. Por tanto, normalmente las dos versiones de la misma aplicación deberán estar operativas: una para IPv4 y la otra para IPv6. Este modo de funcionamiento crea problemas de mantenimiento en ambas versiones y problemas para el usuario, que necesita algún mecanismo de selección para ejecutar la aplicación que se requiera en cada situación Aplicaciones duales Las aplicaciones duales son las desarrolladas para funcionar utilizando ambos protocolos. Según el tipo de nodo donde se ejecuten, las aplicaciones duales funcionarán utilizando uno u otro protocolo. En los nodos sólo IPv4 y sólo IPv6, se utilizará IPv4 e IPv6 respectivamente. En los nodos duales, que tienen instaladas ambas pilas, se podrán utilizar ambos protocolos. En estos últimos nodos, el uso de uno u otro protocolo vendrá fijado por otros factores, por ejemplo, la red que esté instalada, o el nodo o la aplicación remota con la que se desea intercambiar información. Para obtener aplicaciones duales, es necesario, normalmente, rediseñar la aplicación permitiendo la comunicación con cualquiera de los protocolos, independientemente del tipo de nodo en donde se ejecute. Este método requiere un análisis más profundo de la aplicación para entender completamente su comportamiento y decidir la mejor estrategia para convertirla en una aplicación dual, eliminando, si es posible, todas aquellas dependencias respecto a la versión de IP Recomendaciones para la adaptación de las aplicaciones a IPv6 Como se ha mencionado anteriormente, lo más recomendable es adaptar las aplicaciones IPv4 para conseguir aplicaciones duales, es decir, que funcionen independientemente de la versión del protocolo IP. Siguiendo con este objetivo, a continuación se resumen las recomendaciones básicas en la adaptación de las aplicaciones para obtener aplicaciones duales: Utilizar nombres en vez de direcciones al identificar un nodo. Al utilizar nombres se evita la diferenciación en el formato de presentación para las direcciones IPv4 e IPv6; ya que los nombres siguen el mismo formato en ambos protocolos y su resolución a direcciones IP se delegará en el servicio de DNS (Domain Name Server). Utilizar las funciones del API de comunicaciones y estructuras de datos para el almacenamiento de direcciones que sean independientes de la versión de protocolo IP. Por ejemplo, en el caso del API de sockets de BSD, previendo la coexistencia entre ambos protocolos, se han diseñado funciones y estructuras de datos genéricas que pueden utilizarse igualmente para IPv4 y para IPv6. 5. Escenarios de transición gradual El hecho de que las dos versiones del protocolo IP sean incompatibles provoca que los sistemas que utilicen diferentes versiones no puedan comunicarse entre sí directamente y será necesario que los sistemas que vayan a establecer una comunicación adopten uno u otro protocolo para poder intercambiar información. Durante el proceso de transición es necesario definir para cada escenario de uso el protocolo más conveniente. A continuación se clasifican los escenarios de coexistencia más comunes que se pueden presentar durante el período de transición [4] y algunas recomendaciones para mantener la interoperabilidad entre IPv4 e IPv Aplicaciones IPv4 en nodos duales Este escenario se presenta cuando la pila IPv6 se ha añadido a un nodo pero éste mantiene sus aplicaciones IPv4. En principio, las aplicaciones IPv4 sólo podrán establecer comunicaciones IPv4. En este escenario el problema de interoperabilidad surge si la aplicación IPv4 necesita comunicarse utilizando IPv6. Para resolverlo, sería necesario instalar los mecanismos BIS y BIA mencionados anteriormente, que permitirán a las aplicaciones IPv4 establecer comunicaciones IPv Aplicaciones IPv6 en nodos duales novática / upgrade nº 174 marzo-abril

17 IPv6 - Más que un protocolo En este escenario se presentan aplicaciones sólo IPv6 que se ejecutan en nodos que tienen instalada la doble pila. El problema de interoperabilidad surge si estas aplicaciones necesitan comunicarse utilizando IPv4. La mayoría de los nodos duales permiten un modo de funcionamiento en el que las aplicaciones sólo IPv6 pueden intercambiar paquetes IPv4. Este modo de funcionamiento se consigue cuando las aplicaciones IPv6 utilizan direcciones IPv6 especiales, las direcciones IPv4-mapped que tienen el siguiente formato: "::FFFF:x.y.z.w", donde "x.y.z.w" es una dirección IPv4 válida de un nodo remoto, véase la figura 2. Cuando las aplicaciones IPv6 utilizan este tipo de direcciones, el nodo dual extrae la dirección IPv4 "x.y.z.w" de la dirección IPv4- mapped y construye paquetes IPv4 con dicha dirección destino. El uso de este tipo de direcciones especiales por parte de las aplicaciones IPv6 permite solventar este problema de interoperabilidad Aplicaciones duales en nodos duales Cuando se modifica el código fuente de una aplicación para que sea compatible con IPv6, lo más recomendable es diseñar estas modificaciones para convertirla en una aplicación dual, es decir, que pueda funcionar con cualquiera de las dos versiones del protocolo IP. Este escenario en el que las aplicaciones duales se ejecutan en nodos duales es el que permite una mayor interoperabilidad, ya que tanto las aplicaciones como el propio nodo pueden funcionar tanto con IPv4 como con IPv6. En estos casos, las aplicaciones deberían contemplar como comportamiento por defecto utilizar comunicaciones IPv6 y si éstas fallan utilizar la versión IPv Aplicaciones duales en nodos sólo IPv4 Una vez que las aplicaciones IPv4 se han modificado para que sean duales, puede llegar a ocurrir que tengan que continuar ejecutándose en nodos en los que sólo se tenga instalada la pila IPv4. Este escenario puede presentarse en aquellos casos en los que no se quiera mantener dos versiones de la misma aplicación, una versión IPv4 para los nodos sólo IPv4 y otra dual para el resto de los nodos. Los problemas de interoperabilidad en este escenario pueden surgir si la aplicación dual no ha sido diseñada para ejecutarse en nodos que no tengan instalada la pila IPv6. La solución a este problema se encuentra en el desarrollo de aplicaciones duales que no realicen ningún tipo de suposición sobre la versión del protocolo IP que van a utilizar para comunicarse. 6. Conclusiones El despliegue de la nueva versión de protocolo IP es un proceso que se está realizando de forma gradual, actualizando tanto los dispositivos de red como las aplicaciones. Aunque a largo plazo se disponga de entornos puros IPv6, durante el período de transición es necesario tener presente la coexistencia de ambos protocolos tanto en el nivel de red como en el nivel de aplicación. Desde el punto de vista de las aplicaciones, los escenarios que permiten mayor interoperabilidad están basados en la utilización de aplicaciones duales que permitan el intercambio de información con las dos versiones del protocolo IP. Desafortunadamente no siempre es posible modificar el código fuente de las aplicaciones y en estos casos será necesario utilizar mecanismos de transición que faciliten la coexistencia entre ambos protocolos. Agradecimientos Este trabajo ha sido financiado en parte por los proyectos: "EURO6IX European IPv6 Internet Exchanges Backbone" (IST ) de la Comunidad Económica Europea (CEE-IST-5FP) e "Infraestructuras para el desarrollo de software ubicuo" del Ministerio de Ciencia y Tecnología (TIN C02-02). Referencias [1] S. Deering, R. Hinden. "Internet Protocol Version 6 (IPv6) Specification". RFC 2460, IETF, diciembre [2] T. Miguel, E. Castro. "Programming Guidelines on transition to IPv6". Technical report, IPv6 Forum, enero [3] E. Castro. "Contribución al estudio y definición de una metodología de transición gradual de IPv4 a IPv6". Tesis doctoral, Escuela Técnica Superior de Ingenieros de Telecomunicación de la Universidad Politécnica de Madrid, septiembre [4] M. Shin, Y. Hong, J.I. Hagino, P. Savola, E. Castro. "Application Aspects of IPv6 Transition". IETF Draf: draft-ietf-v6ops-application-transition- 03.txt, Junio 2004 (aprobado, pendiente de publicación como "Informational RFC"). [5] R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. "Basic Socket Interface Extensions for IPv6", RFC 3493, IETF, febrero [6] W. Stevens, M. Thomas, E. Nordmark, T. Jinmei. "Advanced Sockets Application Program Interface (API) for IPv6". RFC 3542, IETF, mayo [7] R. Hinden, B. Carpenter, L. Masinter. "Format for Literal IPv6 Addresses in URL s". RFC 2732, IETF, diciembre [8] K. Tsuchiya, H. Huguchi, Y. Atarashi. "Dual Stack Hosts using the Bump-In-the-Stack Technique (BIS)". RFC 2767, IETF, febrero [9] S. Lee, M. Shin, Y. Kim, E. Nordmark, A. Durand. "Dual Stack Hosts using Bump-in-the-API (BIA)". RFC 3338, IETF, octubre [10] "IPv6 Socket Scrubber". < [consultado en mayo 2004]. [11] "Using the Checkv4.exe Utility". < msdn.microsoft.com/library/default.asp?url=/ library/en-us/winsock/winsock/usingthecheckv4 exeutility2.asp> [consultado en mayo 2004]. 18 novática / upgrade nº 174 marzo-abril 2005

18 IPv6 - Más que un protocolo Rüdiger Geib 1, Eduardo Azañón Teruel 2, Sandra Donaire Arroyo 2, Aurora Ferrándiz Cancio 2, Carlos Ralli Ucendo 2, Francisco Romero Bueno 2 1 T-Systems International, 2 Telefónica Investigación y Desarrollo <Ruediger.Geib@t-systems.com>, <{teruel,sandrad,afc03,ralli,frb327}@tid.es> 1. Introducción El protocolo IPv6 (Internet Protocol version 6) ha sido ampliamente desarrollado en redes académicas y los primeros servicios comerciales aparecieron a principios de 2004, una vez que la mayoría de sistemas operativos de hosts y routers así como el hardware han incorporado este protocolo. Uno de los mayores beneficios que IPv6 ofrece a los usuarios de Internet es el restablecimiento del modelo de comunicación extremo a extremo permitiendo servicios escalables basados en P2P Peer-to-Peer), señalización SIP (Serial Interface Protocol) o servicios 3G basados en la arquitectura IMS (IP Multimedia Subsystem) y convergencia de red. Además, IPv6 facilita el despliegue de conceptos avanzados de red tales como la seguridad, movilidad y calidad de servicio (QoS, Quality of Service). Actualmente, la mayoría de esfuerzos en torno a IPv6 están centrados en el desarrollo de aplicaciones y en pruebas de los nuevos servicios con usuarios beta-testers para descubrir los servicios a definir más atractivos para todos los actores de Internet. Este artículo incluye dos secciones relacionadas con la plataforma de gestión de red diseñada y desarrollada por Telefónica Investigación y Desarrollo, y una tercera describe un escenario de calidad de servicio dentro de un servicio de Voz sobre IP (VoIP, Voice over Internet Protocol) basado en señalización SIP diseñado y desarrollado por T-Systems International. Todas las herramientas descritas en este artículo están siendo desarrolladas y probadas en el Backbone Pan Europeo de IPv6 nativo desplegado por el Consorcio de Euro6IX, cuya intención es ser un escenario de prueba precomercial compartido por varias organizaciones industriales y académicas. 2. MAGALIA: monitorización en tiempo real para NOCs MAGALIA es una plataforma de monitorización diseñada y desarrollada para obtener información en tiempo real de los nodos de la red, enlaces y servicios (ver figura Desarrollo de servicios en redes IPv6 y experiencia en redes pre-comerciales Resumen: en este artículo se detallan tres desarrollos realizados en el marco de la implantación de servicios de red precomerciales en el proyecto Euro6IX que están íntimamente ligados a la infraestructura IPv6 (Internet Protocol version 6) implantada. En primer lugar, una herramienta de gestión de red pensada para un entorno multiproveedor, en la que se facilita la cooperación de varias entidades administrativas distintas. En segundo lugar, una herramienta de detección de intrusos adaptada a IPv6. Finalmente, una aplicación de comunicación de VoIP (Voice over IP) cie que se basa en la Calidad de Servicio (QoS, Quality of Service) implantada en la red Euro6IX. Palabras Clave: Euro6IX, gestión de red, IPv6, SIP, QoS (calidad de servicio), VoIP. Autores Rüdiger Geib se graduó por la Universidad de Darmstadt (Alemania) en Se incorporó a la División de Investigación de Deustche Telekom en 1991 donde ha participado activamente en proyectos internacionales de innovación desde Desde 1998, su actividad ha estado centrada en temas de calidad de servicio en Internet. Como experto senior cubre aspectos de la calidad de servicio en arquitecturas de Internet punto a punto. Eduardo Azañón Teruel es Ingeniero Técnico de Informática por la Universidad Politécnica de Madrid (UPM) desde Se incorporó a Telefónica Investigación y Desarrollo en 1990 como desarrollador de Servicios y Sistemas de Conmutación Telefónica. Actualmente participa en el proyecto de Euro6IX como desarrollador de la aplicación MAGALIA y otros desarrollos y migraciones relacionados con IPv6 como ayuda a otras actividades del proyecto. Sandra Donaire Arroyo es Ingeniera Técnica de Telecomunicación por la Universidad de Alcalá desde Se incorporó a Telefónica Investigación y Desarrollo en 2003 como desarrolladora. Dentro de Euro6IX ha sido la responsable de desarrollar la aplicación MoneyPenny. Aurora Ferrándiz Cancio es Ingeniera Informática por la Universidad de Granada desde Se incorporó a Telefónica Investigación y Desarrollo en 2000 participando en varias actividades de desarrollo, hasta que en 2002 se incorporó a Euro6IX. Dentro de Euro6IX coordina el diseño y desarrollo software así como actividades de documentación dentro del equipo de desarrollo software de Euro6IX en Telefónica Investigación y Desarrollo. Carlos Ralli Ucendo es Ingeniero de Telecomunicación por la Universidad Politécnica de Madrid desde Se incorporó a Telefónica Investigación y Desarrollo en 1997 trabajando con diferentes tecnologías de acceso y transporte de red. Actualmente dirige varias actividades de investigación incluyendo el proyecto EuroIX (proyecto enmarcado en el 5º Programa Marco de la IST), en el cual Telefónica Investigación y Desarrollo actúa como prime contractor. Francisco Romero Bueno es Ingeniero Informático por la Universidad Politécnica de Madrid desde Se incorporó a Telefónica Investigación y Desarrollo en 2001, participando desde 2002 en el proyecto Euro6IX como desarrollador de aplicaciones. Su trabajo se ha centrado principalmente en el desarrollo de la aplicación TOPAZ. 1). La aplicación es una herramienta flexible y distribuida que permite a los administradores y operadores de la red conocer el estado de los diferentes elementos gracias a mapas contextuales modificados en tiempo real. Esta herramienta funciona sobre PCs con sistema operativo Linux, aunque en versiones preliminares también se probó en estaciones SUN/Solaris, y ha sido desarrollada bajo licencia GPL (General Public License). Los principales componentes de MAGALIA son: un interfaz gráfico (XGES), un núcleo de aplicación (kernel) y un conjunto de módulos (figura 2). 2 Estos componentes pueden ser instalados en un solo nodo o diseminados en diferentes nodos formando una plataforma distribuida que incrementa la configurabilidad de las actividades de monitorización (un operador IPv6 puede monitorizar nodos únicamente accesibles por IPv4) y la seguridad (un servicio RADIUS, novática / upgrade nº 174 marzo-abril

19 IPv6 - Más que un protocolo Figura 1. MAGALIA: ejemplo de un papa contextual mostrado por XGES. Remote Access Dial-In User Service, que permite conexiones IPv6 y tiene funcionalidades de proxy IPv6 autentica los usuarios en el kernel). Los administradores de la red pueden crear y modificar tantos mapas gráficos como deseen, así como propiedades de elementos concretos en dichos mapas usando XGES, mientras que los operadores únicamente podrán realizar actividades de monitorización. MAGALIA es también una herramienta extensible que permite la definición de nuevos elementos, servicios o propiedades mediante el desarrollo de nuevos módulos. Actualmente, cualquier elemento o función que se pueda monitorizar sobre IP, es susceptible de ser integrado en MAGALIA. XGES Kernel Magalia Figura 2. Diseño de la arquitectura de MAGALIA. Graphic Interface: Authentication, Contextual Maps. Kernel: Communications & Process. IPv6 Radius server. Monitoring Modules: SNMP & WEB Servers info 2.1. Funcionalidades del sistema A continuación detallamos las funciona lidades más sobresalientes que ofrece MAGALIA: Edición gráfica distribuida de mapas: dos o más administradores remotos pueden trabajar en el mismo mapa de una manera coherente y sincronizada. El sistema permite modificar localmente un mapa y con sólo pulsar un botón, almacenarlo y transmitirlo tanto al kernel como a otras instancias de XGES para que muestren el mismo mapa contextual. Configuración gráfica de los componen- tes de MAGALIA: para hacer la instalación y configuración de la plataforma más sencilla, se han desarrollado un conjunto de scripts gráficos en TCL/Tk (Tool Command Language/Tool Kit) que sirven para configurar RADIUS, el kernel y los parámetros necesarios para la ejecución de los módulos de una manera intuitiva. Monitorización de nodos: el módulo hostlive realiza constantemente consultas ICMP (Internet Control Message Protocol) IPv4 o IPv6 para obtener el estatus (vivo/ muerto) de los nodos. Al editar un mapa contextual, el usuario asocia un icono al estado vivo (nodo alcanzable) y otro es asignado al estado muerto (nodo no alcanzable). Monitorización de enlaces: el módulo snmp realiza constantemente consultas SNMP (Simple Network Management Protocol) a ciertos nodos que son procesadas y mostradas por XGES en el mapa contextual la información obtenida. Concretamente, estos datos son utilizados para colorear los enlaces de acuerdo con el flujo de tráfico medido y según varias situaciones de error: fallo físico, cortes del enlace administrativos y SNMP timeout. Monitorización de servicios: el módulo ServGeneric realiza consultas en la capa de servicio comparando el resultado obtenido con una respuesta predefinida. El mapa contextual de servicios también puede ser creado por el administrador. Por ejemplo, un conjunto de servicios distribuido entre varias sedes junto con la infraestructura que une cada localización pueden ser monitorizados de un vistazo a través de un único mapa contextual. Con esta configuración, los operadores pueden detectar fallos de los enlaces, fallos en los servidores, o una mala configuración del servicio. Alarmas de seguridad: un módulo específico conecta MAGALIA con TOPAZ (Sistema de Detección de Intrusos para redes IPv6, descrito en la siguiente sección de este artículo). Cuando TOPAZ descubre una aler- 20 novática / upgrade nº 174 marzo-abril 2005

20 IPv6 - Más que un protocolo Los administradores pueden crear y modificar tantos mapas gráficos como deseen Figura 3. Mapa del estado global del backbone de Euro6IX. ta de seguridad, informa a XGES de que activa en el mapa un icono de alerta en el lugar en donde esta se ha producido. Monitorización compartida: esta funcionalidad avanzada permite que diferentes dominios administrativos --cada uno ejecutando una instancia de MAGALIA diferente-- compartan información de monitorización, siendo XGES capaz de dibujar un único mapa que englobe el estado de la red. Por ejemplo, en el contexto de Euro6IX, cada operador encargado de un intercambiador IPv6 (IX, Internet Exchange) ejecuta una instancia de MAGALIA que comparte información con otros operadores del consorcio. Como resultado de todo lo anterior, un mapa del estado general del backbone Europeo puede ser mostrado en cualquier localización. La figura 3 muestra este mapa visto desde el intercambiador de Madrid (MAD6IX). En este mapa se puede observar el estado del enlace Berlín-Londres sin realizar ninguna consulta SNMP desde Madrid a los routers de Berlín o Londres. Figura 4. Encaminamiento definido para el protocolo de comunicación MSIP entre MAGALIAs. La información de la Monitorización Compartida no es directamente adquirida desde los routers pertenecientes a otros dominios administrativos sino desde otro kernel de MAGALIA. De este modo, y gracias a este seguro y flexible mecanismo, es posible mostrar mapas globales de estado, ya que el acceso a las redes de gestión o al árbol de SNMP de otros dominios está en contra de novática / upgrade nº 174 marzo-abril

21 IPv6 - Más que un protocolo las políticas comunes entre redes de diferentes dominios organizativos. Desde un punto de vista de implementación técnica, la información de la gestión compartida es intercambiada usando un protocolo específico, el MSIP (MAGALIA Shared Information Protocol), que diferencia entre lo que es información pública y privada así como la información de encaminamiento considerando las diferentes instancias de MAGALIA como nodos dentro de una red. Esto último evita que el administrador tenga que definir una malla completa entre todos los MAGALIAs. En el caso de Euro6IX, la red y el sentido de la comunicación entre MAGALIAs está reflejada en la figura 4. Alertas por correo: un módulo específico permite al administrador definir casos de alerta (fallo y solución de los mismos) que serán enviados por correo a destinatarios definidos. Monitorización por Web: aunque MAGALIA ha sido definida para ser usada por los operadores de los NOCs (Network Operation Centers), los mapas también son capturados y enviados a un servidor web para permitir el acceso a la aplicación a otro tipo de usuarios, en general de forma restringida, pero sin necesidad de instalarse aplicaciones extra. Un módulo específico genera dinámicamente la página capturando los mapas y añadiendo enlaces sobre puntos predefinidos hacia otros mapas contextuales, páginas de estadísticas, etc. Servicio de comunicación de Voz sobre IP entre NOCs: un módulo específico permite establecer comunicaciones de Voz sobre IP activadas desde un mapa contextual de XGES. Sensors Tree Detection Logic File Window TOPAZ GUI KERNEL SENSOR CONNECT Alerts Messages Window SENSOR CONFIG DETECTION LOGIC SENSORS MONEYPENNY ALERTS Figura 5. Diseño de la arquitectura de componentes de TOPAZ. 3. TOPAZ: Sistema de Detección de Intrusos basado en análisis de tráfico TOPAZ es la propuesta de Telefónica Investigación y Desarrollo dentro del marco del proyecto Euro6IX para desarrollar un Sistema de Detección de Intrusos de Red (Network Intrusion Detection System, NIDS), con el objeto de detectar de manera pasiva patrones de tráfico sospechoso que correspondan a posibles ataques a la red. TOPAZ supone una primera aproximación al estudio y detección de patrones de ataque basados en tráfico IPv6, a su sincronización con el análisis del tráfico IPv4, y al análisis y estudio del propio tráfico IPv6, algo que hasta el momento en el que se inició el desarrollo de TOPAZ no existía. Tal como se muestra en la figura 5, los componentes de la plataforma de TOPAZ son cuatro: Sensores. Kernel. Interfaz Gráfico o Consola. MoneyPenny Sensores La misión de los sensores de TOPAZ es capturar las tramas Ethernet para realizar un análisis de los paquetes IP buscando la posible ocurrencia de secuencias asociadas con ataques sobre la red o sobre un servicio concreto. Los sensores intercambian mensajes con el Kernel de la aplicación usando un protocolo de alertas definido en las especificaciones de TOPAZ. La arquitectura software de los sensores se compone de dos módulos independientes: Gestor de alertas: cuando se detecta un patrón sospechoso, este módulo es el encargado de enviar al Kernel un mensaje de tipo XGES Kernel Magalia MAGALIA ALERT, un protocolo definido para la ocasión, a través de un puerto TCP (Transmission Control Protocol) exclusivo. Desde el punto de vista técnico, este módulo usa una interfaz de captura basada en las librerías pcap para C/C++ disponibles para plataformas Windows/Linux. Gestor de configuraciones: se encarga de gestionar las conexiones del sensor al kernel y la recepción de la lógica de detección inicial así como de posibles actualizaciones de la misma. Un sensor es identificado unívocamente usando dos parámetros: un identificador dado por el administrador de la red y la dirección IP (IPv4/IPv6) del equipo final en el que se está ejecutando. Para establecer una conexión con éxito, el sensor debe estar registrado en el kernel con todos los parámetros correctamente configurados. En caso contrario, el administrador debe aceptar explícitamente la conexión del nuevo sensor o rechazar la conexión. En caso de pérdida de la conexión con el kernel, los sensores tratan de reconectarse. El resultado de la ejecución de un sensor son dos ficheros de salida: las tramas de red capturadas en formato ASCII (American Standard Code for Information Interchange) y un fichero que contiene todos los mensajes intercambiados con el kernel. Los sensores son elementos pasivos y no toman ninguna acción sobre la red, cortafuegos o servicios en caso de ataque. Su único propósito es notificar al kernel de la presencia de patrones sospechosos, que son aquéllos que cumplen las condiciones especificadas en la lógica de detección El kernel de TOPAZ El kernel centraliza toda la información intercambiada por los componentes de TOPAZ tales como informes de alertas generados por los sensores, el envío de las lógicas de detección y la configuración de los sensores. Para conseguir sus objetivos, el kernel se divide en dos módulos independientes: Gestor de Configuraciones: actúa como un servidor que escucha las peticiones de conexión hechas por los sensores, interfaces y los módulos de conexión con MAGALIA. recibe y reenvía la información de configuración entre los sensores y los interfaces de acuerdo a las siguientes reglas: - Cuando un sensor se conecta, se le envía su lógica de detección particular. Si no se ha especificado ninguna todavía, se le manda una definida por defecto por el administrador de la red. - Cuando se conecta un interfaz de usuario (una consola, cuyas funcionalidades se describirán en el siguiente punto), toda la información disponible sobre los sensores y las lógicas de detección de cada uno, se envían a la consola. 22 novática / upgrade nº 174 marzo-abril 2005

22 IPv6 - Más que un protocolo Los proveedores y redes cliente están interesadas en este tipo de servicios de valor añadido Detection Logic File W indow orden de cambiar el icono del nodo afectado dentro de un mapa contextual por otro icono que denote que ese nodo está siendo atacado (por defecto, una explosión). Sensors Tree Figura 6. Consola gráfica de TOPAZ. - Cuando se registra un sensor o se borra, se comunica a todos los interfaces conectados. - Cuando se modifica una lógica de detección, ésta es enviada a todos los interfaces conectados así como al sensor afectado por dicha modificación. - Cuando un sensor se desconecta, se informa de este evento a todos los interfaces conectados. Alerts Messages Window Gestor de Alertas: este módulo recibe las alertas de los ataques detectados por los sensores y los reenvía a todos los interfaces conectados y al módulo de MAGALIA. El módulo de MAGALIA envía las alertas de seguridad detectadas por los sensores de Topaz al componente de seguridad de MAGALIA, de forma que XGES recibe una Como salida se genera un fichero de registro, incluyendo todos los mensajes intercambiados con los sensores Interfaz de usuario o consola La consola de TOPAZ es el punto de interacción del usuario con la plataforma de monitorización de la seguridad. Dependiendo del perfil del usuario, la consola permite monitorizar las alertas en tiempo real, registrar y configurar nuevos sensores así como definir una lógica de Detección por defecto y particularizarla para un sensor concreto. La consola de Topaz se divide en tres ventanas (figura 6): Árbol de Sensores (parte superior izquierda): Aquí se listan los sensores mostrando su estatus y sus propiedades. También desde aquí se pueden modificar dichas propiedades. Lógica de Detección (parte superior derecha): Aquí se muestra la Lógica de Detección particular del sensor seleccionado en formato <?xml version="1.0"?> <!DOCTYPE DETECTION_LOGIC SYSTEM "DETECTION_LOGIC.dtd"> <DETECTION_LOGIC> <RULE> <NAME>R0</NAME> <MES>"530 Login incorrect." telnet detection</mes> <CON PROT="Telnet" FLD="Message" TYPE="STRING" TREAT="MATCH" OFFSET="0">530 Login incorrect.</con> <CON PROT="TCP" FLD="Source port" TYPE="DEC" TREAT="MATCH" OFFSET="0">23</CON> </RULE> </DETECTION_LOGIC> Figura 7. Edición de lógicas de detección (XML y editor gráfico de reglas). novática / upgrade nº 174 marzo-abril

23 IPv6 - Más que un protocolo de recursos estrechamente controlado por la red. Esta funcionalidad podría ofrecerse en los routers de borde de la infraestructura central de red para preservar el rendimiento al dejar que los equipos más internos a esta infraestructura ofrezcan simplemente mecanismos de QoS basados en DiffServ. Figura 8. MoneyPenny: consola de TOPAZ para PDAs. XML (un editor gráfico de las reglas puede ser lanzado desde aquí). Ventana de Alertas (parte inferior): Aquí se muestran las alertas recibidas en tiempo real Lógica de detección Una lógica de detección es una descripción formal de las reglas usadas por los sensores de TOPAZ para detectar secuencias sospechosas de paquetes. Las Lógicas de Detección de TOPAZ se almacenan internamente en formato XML (extensible Markup Language) aunque también pueden ser editadas gráficamente usando el editor gráfico de reglas. En la figura 7 se muestra un ejemplo de regla que controla los accesos vía Telnet, con la condición de ser un acceso incorrecto hecho por un usuario root. En la imagen vemos el editor gráfico de reglas y su resultado en XML MoneyPenny: consola gráfica para PDAs MoneyPenny es una consola gráfica de TOPAZ para PDAs (Personal Digital Assistants) desarrollada con Microsoft Embedded Visual C (figura 8). Esta aplicación se conecta con un kernel de TOPAZ por IPv4/IPv6 para recibir y mostrar las alertas de seguridad. Desde esta aplicación no se puede modificar ninguna lógica de detección ni configuración. Esta aplicación se ha probado dentro del marco del proyecto Euro6IX en ipaqs 5550 con MS Pocket PC 2003 dentro de redes WiFi (Wireless Fidelity) sobre IPv6. 4. Voz sobre IP con un cliente de SIP usando calidad de servicio bajo demanda. Después de haber presentado un conjunto de aplicaciones que permiten gestionar apropiadamente redes IPv6 en entornos multiproveedor (multihoming), presentamos la implementación de un servicio de Voz sobre IP cuyo ámbito de despliegue es este tipo de infraestructuras. Como parte de la arquitectura de Euro6IX, se ha definido una arquitectura de provisión de calidad de servicio extremo a extremo que funciona bajo demanda, con todos los protocolos y funcionalidades de un operador de Voz Sobre IP aplicando ancho de banda IP bajo demanda, empezando en el nivel de aplicación y terminando con las características de interacción entre puntos neutros (Internet Exchanges) [1]. Los proveedores y redes clientes están interesadas en este tipo de servidos de valor añadido. No obstante, la señalización, la seguridad y los mecanismos de AAA (Authentication, Authorization, Accounting) requieren routers capaces de negociar y mantener un gran número de estados por sesión, generando problemas de rendimiento en la red, ya que cuanto más alto es el número de sesiones más alto será el número de estados que mantener. La investigación realizada a principios de esta década, estaba dirigida a obtener redes con gran rendimiento en la transmisión de paquetes, por lo que la arquitectura de transporte de calidad de servicio preferida actualmente resulta ser DiffServ con asignación estática de recursos y sin mantenimiento requerido por los routers del backbone [2]. Aunque la provisión de calidad de servicio bajo demanda (en vez de con asignaciones estáticas) añade valor a la transmisión de paquetes, el acceso a este servicio debería ser autorizado y el consumo Para implantar este modelo, Euro6IX propone la combinación de un mecanismo de Control de Acceso basado en Sistemas Finales (End System based Acces Control, EAC) con una política de limitadores jerárquicos (Hierarchichal Token Bucket) en el backbone, como se describirá a continuación. El EAC se basa en un procedimiento de medida extremo a extremo de los recursos disponibles en la red que está documentado en el Control de Admisión Basado en Paquetes (Packet Based Admisión Control) [3] y el Esquema de Promoción de Prioridades (Priority Promotion Scheme) [4]. Las aproximaciones basadas en medidas han demostrado ser una buena estimación para aplicaciones que usan redes no orientadas a conexión con encaminamiento dinámico, siendo TCP un buen ejemplo. TCP mide constantemente el tráfico recibido adaptando en consecuencia el tráfico de salida. Mientras que TCP es adecuado para compartir recursos disponibles de una manera correcta entre aplicaciones elásticas, las aplicaciones en tiempo real exigen un mínimo de ancho de banda para proveer una buena calidad de comunicación, por lo que la gestión de los recursos requerirá algún tipo de control de admisión. Para su implantación, los mecanismos de Control de Admisión Basado en Paquetes y el Esquema de Promoción de Prioridades proponen el uso de paquetes de medida para comprobar si la red es capaz de proveer el ancho de banda requerido por la aplicación. Los paquetes de medida se marcan con un Diffserv Code Point (DSCP) que ofrece un servicio peor que el que se desea para los paquetes que se enviarán a continuación. Si los paquetes de medida sufren pérdidas por debajo de un umbral predefinido, esto significa que hay suficientes recursos para cursar el tráfico de la aplicación (véase [4][3]). La ventaja de la administración de recursos de Figura 9. Arquitectura de calidad de servicio bajo demanda extremo a extremo de Euro6IX. 24 novática / upgrade nº 174 marzo-abril 2005

24 Internet basada en la medida en comparación con esquemas como RSVP (ReSerVation Protocol) extremo a extremo es doble. Primero, los recursos son distribuidos en función de la carga actual de los enlaces, favoreciendo la multiplexación. Segundo, es independiente de los cambios en las rutas Los esquemas orientados a la conexión como el punto-a-punto de RVSP tienen peor rendimiento en los dos aspectos anteriores. Comparado con [4] y con [3], la implementación en Euro6IX introduce como cambios importantes el uso de un selector de políticas Hierarchichal Token Bucket para IPv6 - Más que un protocolo Todos los desarrollos realizados son libres y se pondrán a disposición de la comunidad de investigación Dado que el servicio de CLS basado en PBAC está integrado dentro de una aplicación de Voz sobre IP utilizando señalización SIP, SIP puede transportar la información de autenticación si el proveedor de red es parte de servicio de Voz. En las redes de acceso, el servicio CLS puede solicitarse mediante un protocolo de señalización basado en la reserva para calidad de servicio. RSVP es una opción, pero la elegida aquí ha sido el protocolo NSLP (NSIS Signaling Layer Protocol, donde NSSI significa Next Steps in Signaling) desarrollado en el grupo de trabajo NSSI QoS de IETF (Internet Engineering Task Force) [5]. Los protocolos de señalización para calidad de servicio también proporcionan medios para autorizar el acceso al CLS. red reservados en ambas direcciones extremo a extremo. El soporte de PBAC se indica mediante un pseudo módem anunciado de la forma m = x-eac en SDP. Si el cliente correspondiente no indica el mismo pseudo módem, se supone que es un cliente SIP sin las nuevas características. En este caso, la llamada se completará sin activar ninguna característica de Calidad de Servicio utilizando transmisión best-effort. El cliente SIP con PBAC habilitado es por tanto compatible con versiones anteriores. En Euro6IX al principio integró la funcionalidad PBAC en un cliente SIP. Esta función fue demostrada durante el evento Figura 10. Integración del PBAC dentro de SIP. controlar el tráfico de medida y el admitido. El Esquema de Promoción de Prioridades (Priority Promotion Scheme, PPS [4]) propone la implantación de un Control de Admisión Basado en Paquetes (Packet Based Admisión Control, PBAC) como medio para ofrecer un Servicio de Carga Controlada (llamado en lo sucesivo CLS, Controlled Load Service; ver RFC 2211). No obstante, la transmisión de la información con garantías de pérdidas y retardo aporta un valor añadido a la comunicación. El acceso a este servicio debería ser posible bajo demanda sólo para usuarios autorizados. Cuando se accede a la red, el usuario se autentica y recibe una autorización simbólica por medio de un token. Este token se puede utilizar para volver a autenticar cuando los usuarios acceden a servicios de valor añadido. La RFC 3312 define cómo integrar la señalización para calidad de servicio dentro de SIP. En Euro6IX se ha especificado cómo integrar una versión de QoS NSLP dentro de la pila SIP, integrando una fase de decisión de admisión extremo a extremo basada en PBAC. La RFC 3312 y el QoS NSLP han sido reducidos a la mínima funcionalidad requerida. La llamada de Voz sobre IP es bidireccional por defecto y sólo se establece si no se detectan pérdidas durante la fase de medición. La figura 9 muestra la arquitectura del servicio extremo a extremo. La llamada básica se implementa como se describe en la RFC 3312 (texto levemente cambiado): Por defecto, una llamada de Voz sobre IP de Euro6IX es bidireccional. El cliente SIP origen O solicita el soporte de PBAC en el SDP (Session Description Protocol) del INVITE inicial. El cliente D no debe ser alertado hasta que haya recursos de IST Una sesión SIP se establece únicamente si no existen pérdidas durante las medidas del enlace en las direcciones directa e inversa (figura 10). La implementación de la señalización para calidad de servicio dentro de un cliente SIP con PBAC habilitado y un router está previsto realizarla en marzo de El router es una máquina Linux y debe proporcionar todas las funcionalidades de calidad de servicio para un router de acceso. Los mensajes de señalización son intercambiados entre el cliente SIP y el router utilizando la implementación GoCASP (Gottingen Cross-Application Signaling Protocol) [6]. El acceso al servicio de Euro6IX de calidad de servicio bajo demanda es controlado por una autorización de la red (véase [7]). La comunicación entre el cliente SIP, el sistema de red que provee el servicio y el servidor de novática / upgrade nº 174 marzo-abril

25 IPv6 - Más que un protocolo Figura 11. Re-autorización durante el establecimiento de calidad de servicio. AAA se basa en el Protocolo de Autenticación Extensible (EAP, Extensible Authentication Protocol). El cliente SIP se autentica con su primer acceso a la red y es autorizado por el servidor AAA. El servidor AAA devuelve un token de autorización. Cada token de autorización. Cada petición de reserva de Calidad de Servicio del cliente debe ser re-autorizada. Para permitirlo, se incluye el token de re-autorización en el mensaje de Reserva de Calidad de Servicio NSLP. El router de acceso chequea la validez del token con el servidor AAA. El router de acceso sólo continúa con la señalización para la calidad de servicio y con la asignación de recursos una vez que el servidor AAA confirma que el cliente está autorizado para el CLS (figura 11). Euro6IX espera demostrar una implementación preliminar de la re-autorización para el acceso a Calidad de Servicio (QoS) alrededor del fin de marzo de La demostración de la interacción deberá ser posible al final de Todos los desarrollos realizados son libres y se pondrán a disposición de la comunidad de investigación. Referencias [1] R. Geib. "On demand end-to-end QoS" (trabajo en curso), IST Euro6IX, noviembre [2] S. Blake et al. "An Architecture for Differentiated Services", RFC 2475, IETF, diciembre [3] G. Karlsson, I. Más, H. Lundqvist. "Singleservice quality differentiation", en Proc. of the 12th IWQoS, (Montreal, Canada), IEEE, junio Ver < [4] Naotaka Morita, Gunnar Karlsson. "Framework of Priority Promotion Scheme". IETF draft-moritatsvwg-pps-01.txt, (trabajo en curso), octubre [5] S. Van den Bosch et al. "NSLP for Quality-of- Service signalling", IETF draft-ietf-nsis-qos-nslp- 03.txt (trabajo en curso), mayo [6] H. Schulzrinne, H. Tschofenig, X. Fu, A. McDonald. "CASP - Cross-Application Signaling Protocol", Draft-schulzrinne-nsis-casp-01.ps, expirado en agosto de < informatik.uni-goettingen.de/~casp/draftschulzrinne-nsis-casp-01.pdf>. [7] P. Pujante, D. Martínez, A. Gómez, I. Marín. "PLC QoS management and integration for IPv6 applications and services", ISPLC 2005, < conferences. ece.ubc.ca/isplc2005/>. 26 novática / upgrade nº 174 marzo-abril 2005

26 IPv6 - Más que un protocolo Latif Ladid 1, Jimmy McGibney 2, John Ronan 2 1 Presidente del IPv6 Forum, Coordinador del Grupo de Trabajo Europeo de IPv6; 2 Telecommunications Software & Systems Group, Waterford Institute of Technology (Irlanda) <latif.ladid@ipv6forum.com>, <{jmcgibney,jronan}@tssg.org> 1. Introducción Internet ofrece una infraestructura genérica de comunicación basada en la conmutación de paquetes. Muchas redes cliente utilizan esta infraestructura pública para intercambian tráfico de negocios o de otro tipo. Esta infraestructura está basada en un conjunto preacordado de protocolos, habitualmente conocidos como TCP/IP (Transmission Control Protocol/Internet Protocol) [4][5], en referencia a los dos protocolos más significativos de ese conjunto. Actualmente, la versión 4 del protocolo IP (conocida como IPv4, Internet Protocol version 4) es el estándar de facto para la conectividad de Internet. Los estándares de Internet surgieron del trabajo de investigación realizado en los Estados Unidos bajo el patrocinio de DARPA (Defense Advanced Research Projects Agency), una agencia de investigación de los EE.UU. TCP/IP se hizo popular en las universidades y fue incorporado a la familia de sistemas operativos UNIX. Con el tiempo, TCP/IP se convirtió en la base de una red global de conectividad entre las universidades y las organizaciones de investigación, y en la ulterior semilla del Web. La infraestructura IPv4 ha sufrido una serie de ataques, tanto en sistemas finales como en nodos intermedios, debido al diseño del protocolo y a su implementación, que han dado lugar a sustanciales pérdidas económicas. Para cubrir los requisitos de seguridad a nivel de red, IPv4 se ha complementado con el conjunto de protocolos IPsec. La nueva versión del protocolo IP, IPv6 [13], por el contrario, ha sido desarrollada con la exigencia de ofrecer funcionalidades de tipo IPsec (Secure Internet Protocol) como parte de su diseño básico. IPsec ofrece tanto privacidad como integridad en la transmisión de datos a través de Internet, así como garantías sobre la autenticidad del origen de los datos. Siguiendo las definiciones de Unión Internacional de Telecomunicaciones [2], el término seguridad describe tradicionalmente requisitos como privacidad (la protección de la asociación Seguridad con IPv6 Traducción: Alberto García Martínez (Dpto. de Ingeniería Telemática, Universidad Carlos III de Madrid). Resumen: este artículo presenta una justificación de cómo la implantación de IPv6 (Internet Protocol version 6) puede actuar como un elemento clave para restaurar el modelo extremo a extremo de Internet, y cómo esto impacta en la provisión de seguridad de red. Se introduce IPsec (Secure Internet Protocol), se discute su impacto, y los beneficios que ofrece, y se comentan brevemente algunos aspectos de seguridad de la coexistencia entre IPv4 e IPv6. Palabras Clave: IPsec, IPv6, seguridad Autores Latif Ladid preside actualmente preside el Grupo de Trabajo Europeo de IPv6, es presidente del IPv6 Forum, miembro del consejo de la Internet Society (ISOC) e investigador en múltiples proyectos IST de la Comisión Europea centrados en las tecnologías de nueva generación. Ha ocupado responsabilidades de gestión y marketing en Nixdorf Computers en Alemania, y Hewlett-Packard en Oriente Medio, además de ser Gestor de Ventas Internacionales de ComputerLand Europe en Luxemburgo y Director de Gestión en ComputerLand Suiza. De 1992 a 1998 ocupó el puesto de Vicepresidente de Ventas y de Desarrollo de Negocio en DEVELCON, empresa canadiense especializada en Internet y redes de comunicaciones. En 1998 se incorporó a Telebit Communications A/S como Vicepresidente y responsable de Ventas en Europa, Medio Oriente y África. También ha presidido Global-ISDN de 1996 a Estudió Comercio y Administración de Empresas en Francia e hizo un postgrado en Negocios y Administración en el Reino Unido. Jimmy McGibney es profesor de Computación Aplicada en el Waterford Institute of Technology (Irlanda), en donde da cursos de seguridad y sistemas distribuidos, investigando con el Grupo de Software y Sistemas de Telecomunicación. Está realizando su Doctorado en el University College de Dublín (Irlanda) en modelos de servicio para la detección de intrusiones. Recibió su título de grado en 1992 en el University College de Dublín y su Master en 1995 en Dublin City University. Entre 1994 y 2000 ha trabajado para la industria de las telecomunicaciones como desarrollador de software e investigador en proyectos colaborativos. John Ronan es investigador en el Grupo de Software y Sistemas de Telecomunicación en el Waterford Institute of Technology (Irlanda). Recibió su título de grado en el Waterford Institute of Technology en 1998 y su Master en Desde entonces ha colaborado en proyectos europeos y del gobierno irlandés en las áreas de seguridad de red, IPv6, tecnologías inalámbricas, escenarios de prueba de red y sistemas avanzados de grid, y en el desarrollo de sistemas de tarificación y seguridad para servicios IP. También da clases en el Depto. de Redes y Comunicaciones del citado instituto. entre la identidad de los usuarios y las actividades realizadas por ellos), confidencialidad (protección frente a acceso no autorizado a los datos), autenticación (prueba de que la identidad invocada por una entidad es cierta), integridad (seguridad de que los datos no han sido alterados de una forma no autorizada) y disponibilidad (protección frente a denegación de accesos autorizados). IPsec ofrece al nivel de red los cuatro primeros. Consecuentemente, IPv6 también satisface estos requisitos. Este artículo tiene la siguiente estructura: la sección 2 razona cómo la implantación de IPv6 actúa como un elemento clave para la restauración del modelo extremo a extremo y cómo podrá, de forma muy probable, incrementar la demanda de nuevas e innovadoras aplicaciones y servicios. La sec- ción 3 ofrece un breve resumen de la actual situación en el área de la seguridad en redes de comunicaciones, de forma que IPv6 pueda ser encuadrado en este contexto. En la sección 4 se describe IPsec, así como un resumen del estado actual de la seguridad en IPv6 y de las ventajas que se aportan sobre IPv4. Presentamos en la sección 5 una breve discusión sobre los aspectos de seguridad de la coexistencia IPv4-IPv6 y, finalmente, extraemos algunas conclusiones en la sección IPv6, movilidad y el principio extremo a extremo La principal motivación de IPv6 fue la extensión del rango de direcciones de 32 bits a 128 novática / upgrade nº 174 marzo-abril

27 IPv6 - Más que un protocolo bits. No obstante, es cierto que utilizando una infraestructura basada en NATs (Network Address Translation) [15][16], IPv4 puede continuar funcionando en el corto plazo en Europa Occidental y en el mundo desarrollado. En este ámbito geográfico disponemos de suficientes direcciones IPv4 en los Proveedores de Servicio de Internet (ISPs) como para poder asignar direcciones a los sistemas que serán públicamente accesibles. En Asia la asignación de direcciones IPv6 es percibida culturalmente como más neutra y esencial para superar los actuales problemas de direccionamiento. Esto se debe al control que EE.UU. ha tenido sobre la asignación de direcciones IPv4 y la percepción de que esta asignación había favorecido a las economías occidentales. La argumentación a favor de IPv6 hasta ahora no se ha dirigido a los dispositivos móviles. Cuando éstos se introducen en la ecuación, las escalas de tiempo se acortan y un rango suficiente de direcciones se hace aún más importante, ya que existe el potencial de disponer de múltiples dispositivos por persona (más que sólo uno o dos: un ordenador de sobremesa y un portátil). El reconocimiento de este hecho fue el mayor factor en la selección de IPv6 por el consorcio 3GPP (3rd Generation Partnership Project) como el protocolo para la implantación global de la red UMTS (Universal Mobile Telecommunications System) de telefonía de tercera generación. Por tanto, no hace falta otro argumento: en una red global móvil basada en protocolos IP, tiene más sentido usar IPv6 que IPv4. El contra argumento respecto a IPv6 es relativamente simple: qué es lo que ofrece IPv6 que forzaría a usuarios y proveedores a una transición a este nuevo protocolo? La respuesta para muchos es nada. Mientras todavía haya direcciones, muchos podrán sobrevivir con los actuales rangos de direcciones, especialmente en Europa y América del Norte, y utilizar NAT para ofrecer acceso a Internet a redes con direccionamiento privado cuando sea necesario. Estos contra argumentos tienen mucho que ver con la justificación financiera para actualizar infraestructuras corporativas. Mientras tanto, los países más poblados, en los que las cuestiones que IPv6 resuelve resultan ser más críticas, pueden adelantar a Europa y Norte América en IPv6. Si esta predicción es correcta, esto significa que habría una justificación de negocio para crear productos dirigidos a la implantación en países en desarrollo, que son por definición grandes mercados, lo que supondría un impulso para IPv6 en general. Hay otras razones por las que IPv6 resulta ser la elección obvia. Por un lado, IPv4 necesita una infraestructura considerable para permitir la asignación de direcciones en la red, ya que requiere un router y un servidor DHCP (Dynamic Host Configuration Protocol), En IPv6 la autoconfiguración [14] es parte de la infraestructura básica, provista por los propios routers. La gestión es cercana a cero, ya que una vez que el router conoce el prefijo de red, las direcciones para los dispositivos son asignadas automáticamente. Incluso si no hay un router disponible, el dispositivo se puede configurar con una dirección Link Local, pudiendo establecer túneles sobre una red IPv4. Mientras que estas direcciones pueden ser útiles para tráfico local, especialmente para clientes, no son útiles como un identificador global genérico para dispositivos, perdiéndose uno de los beneficios clave de IPv6 (el uso de la dirección con único identificador global de un extremo de la comunicación). La tendencia en varias áreas de la computación distribuida ha sido que cada nodo sea un servidor además de un cliente (especialmente en sistemas peer-to-peer) y esto plantea el problema de identificar al servidor de forma unívoca, potencialmente en un contexto global. 3. Desafíos en seguridad A medida que la informática y las comunicaciones basadas en computadoras van teniendo un mayor peso en nuestra vida diaria, la seguridad se va volviendo una necesidad más acuciante. El ámbito de la seguridad maneja conceptos como la autenticación (incluyendo identificación y confianza), confidencialidad, integridad, disponibilidad, control de acceso y no repudio. La Unión Internacional de Telecomunicaciones utiliza estos conceptos para definir los servicios de seguridad. En general, estos requisitos de seguridad son críticos para empresas que utilizan para sus negocios diarios Internet o infraestructuras análogas a Internet. Es evidente que existe una tensión constante entre aquellos que gestionan los sistemas y aquellos que desean atacarlos. El acceso a Internet es relativamente fácil y barato, y los usuarios disponen de un alto grado de anonimato si lo desean. En general, los que desean romper las medidas de seguridad tienen todos los ases en la manga: Los estándares de los protocolos básicos de Internet son públicos. Esto significa que los atacantes saben mucho más sobre cómo funciona Internet que si la red fuera propietaria. Aunque el número y la diversidad de los sistemas conectados se incrementa, así como su complejidad, el nivel de sofisticación técnica requerida para llevar a cabo ataques está disminuyendo [3]. Los sistemas modernos están implementados habitualmente en varias capas y resultan ser muy complejos. La complejidad suele ser en general mala para la seguridad. El enorme número de formas bajo las cuales puede ser usado un sistema hace extremadamente difícil completar pruebas exhaustivas y los sistemas en producción acaban presentando de forma inevitable agujeros de seguridad. La velocidad de implantación de Internet ha sido muy elevada. Esto significa que una gran cantidad de software fue desarrollada sin considerar los aspectos de seguridad inherentes a la funcionalidad implementada. Los sistemas más seguros son aquellos para los que la seguridad se ha tenido en cuenta desde el principio. IPv4, por ejemplo, no fue diseñado con la seguridad como prioridad. La tendencia hacia la movilidad de código que se experimentó en la década pasada ha significado todo tipo de oportunidades para el desarrollo de virus y gusanos, que actúan como agentes autónomos que, una vez liberados, pueden reproducirse a gran escala. Estos ataques se manifiestan como suplantación de personalidad, pérdida de privacidad, pérdida de integridad en los datos (por ejemplo, detalles de una transacción con una tarjeta de crédito pueden ser modificados en tránsito), monitorización de comunicaciones y denegación de servicio. Los ataques son resultado del descubrimiento de puntos débiles en el diseño de protocolos (por ejemplo WEP, Wired Equivalent Privacy, en IEEE , también conocido como WiFi, Wireless Fidelity) o por la incorrecta implementación de protocolos, aplicaciones y sistemas operativos (por ejemplo, no promoviendo el uso de cifrado fuerte en una red WiFi o seleccionando un cifrado débil en un enlace de comunicaciones). La explotación de estas debilidades continuará mientras existan implementaciones. Las defensas disponibles para los encargados de la gestión de sistemas implicarán la aplicación estricta de una completa política de seguridad (no se puede obviar la importancia de disponer de una política, y de aplicarla sistemáticamente), evitar cuando sea posible tecnologías y protocolos inseguros, y mantener al día la información relacionada con la seguridad, especialmente actualizando los sistemas cuando se descubre una debilidad. De la misma forma que los atacantes comparten información rápidamente acerca de los agujeros, la información y los parches debe fluir de forma inmediata entre los administradores. 4. Seguridad a nivel de red 4.1. Introducción a IPsec El término IPsec se refiere a un conjunto de protocolos de IETF (Internet Engineering Task Force) que ofrecen cifrado y autenticación a nivel de red para comunicaciones basadas en IP. El objetivo de IPsec es 28 novática / upgrade nº 174 marzo-abril 2005

28 IPv6 - Más que un protocolo IPsec ofrece tanto privacidad como integridad en la transmisión de datos a través de Internet autenticar y/o cifrar todo el tráfico a nivel IP. La forma en que opera a nivel IP es independiente de los niveles de transporte o aplicación. IPsec surgió de un encuentro patrocinado por el Internet Architecture Board (IAB) en 1994 sobre seguridad en la arquitectura de Internet, cuyas recomendaciones fueron publicadas en la RFC Las especificaciones de IPsec se encuentran en: RFC 2401 (arquitectura de seguridad) RFC 2402 (autenticación) RFC 2406 (cifrado) RFC 2408 (asociaciones de seguridad y gestión de claves) El principal uso actual de IPsec es el establecimiento de redes privadas virtuales para la conexión de oficinas y usuarios a las sedes utilizando Internet pública, para accesos remotos de bajo coste para teletrabajadores (a través de una llamada local a un proveedor) y para conectividad de tipo extranet (comunicación segura con socios, proveedores, etc.). IPsec se implementa por medio de dos cabeceras de extensión alternativas. La primera, la Cabecera de Autenticación (Authentication Header, AH, [9]), ofrece autenticación pero no privacidad. La segunda, la Cabecera de Seguridad en la Encapsulación (Encapsulating Security Paylodad, ESP, [10]), ofrece cifrado y, opcionalmente, autenticación. AH añade una cabecera al tradicional paquete IP, habitualmente un código de autenticación del mensaje (cifrando un hash del paquete de datos). Con ESP, el contenido del paquete es cifrado y encapsulado a continuación de la cabecera. Para utilizar IPsec, un par de sistemas finales tienen que negociar una Asociación de Seguridad (Security Association, SA). Ésta actúa como una conexión virtual, manteniendo varios atributos, tales como el tipo de protección, las claves y los algoritmos criptográficos a usar. Una SA especifica una relación en un sentido, por lo que se requieren dos SAs para poder establecer una comunicación dúplex. Una SA puede servir tanto para AH como para ESP. IPsec puede implantarse bien en modo transporte o en modo túnel. El modo transporte es utilizado típicamente para comunicación extremo a extremo y protege sólo el cuerpo del mensaje una consecuencia de esto es que el patrón de tráfico entre equipos finales no está protegido, aunque a cambio no es necesaria la implicación de sistemas intermedios (que no tendrían por qué ser fiables). El modo túnel, en contraste, se utiliza típicamente para conectar de forma segura nodos intermedios (como firewalls o routers) y protege el paquete completo, incluyendo la cabecera. Una ventaja significativa del modo túnel es que los equipos finales no tienen por qué disponer de IPsec, lo que suele ser habitual en entornos mixtos IPv4-IPv6. La gestión de claves es un asunto muy relevante para IPsec: cómo generar y distribuir claves secretas? Dentro de una organización pequeña, el administrador puede hacer esto de forma manual, pero esta solución no escala bien. Se han propuesto varias aproximaciones automáticas, de entre las que destacan Internet Security Association and Key Management Protocol (ISAKMP) [11] e Internet Key Exchange (IKE) [12]. Aunque el objetivo de la introducción de mecanismos de seguridad como IPsec es el ofrecer privacidad y autenticidad; el uso de estos mecanismos no tiene por qué sustituir a la seguridad en otras capas (aplicación, transporte, etc.) para la provisión de seguridad extremo a extremo. El marco ofrecido por IPsec es suficientemente genérico como para poder ser complementado con otros mecanismos de seguridad, como PGP (Pretty Good Protection), S/MIME (Secure/ Multipurpose Internet Mail Extensions), etc. Concluyendo, se puede decir que IPsec ofrece seguridad para aplicaciones y sistemas finales, y permite la implantación de nuevas aplicaciones y la adición de sistemas finales en una misma administración sin necesidad de ninguna configuración adicional. También permite la adición de nuevos usuarios de otras administraciones. Un beneficio adicional de IPsec es que la arquitectura es independiente de los métodos criptográficos que se utilicen, y nuevos y mejores algoritmos pueden ser incorporados en el futuro. Nótese que IPsec no ofrece autenticación a nivel de usuario, sino autenticación dependiente de la fuente del paquete (del equipo final que lo genera). Esto no tiene por qué ser un problema si el usuario utiliza, por ejemplo, un sistema Windows, pero lo puede ser para un sistema operativo multiusuario. Es conveniente destacar que, aunque IPv6 exige el soporte de IPsec, algunas implementaciones en las que el rendimiento es clave podrían escoger no utilizar IPsec, o utilizar sólo las funcionalidades de autenticación. La seguridad siempre implica algún tipo de compromiso; por ello, los beneficios de IPsec deberían ser contrapuestos en cada situación con el descenso en la cantidad de tráfico cursado, o la sobrecarga de procesamiento Seguridad con IPv6 Como ya se ha dicho, IPsec es requerido en las implementaciones como parte del protocolo IPv6. Para usar IPsec de forma efectiva se necesita la implantación de un marco de gestión de claves (ISAKMP e IKE). Este mecanismo de gestión de claves, aunque utilizado ampliamente por IPsec, no forma parte de IPv6. Como consecuencia, son necesarias Infraestructuras de Clave Pública (Public Key Infrastructures, PKIs) para la implantación a gran escala. Las PKIs actúan como fuentes con autoridad para claves certificadas de sistemas finales y servicios en Internet, siendo de alguna una forma similares operativamente al DNS (Domain Name Service). Todavía no hay un estándar aceptado para PKI, y es poco probable que vaya a haber una única PKI para toda la Internet, ya que no resulta ni aceptable operacionalmente, ni encaja con la filosofía de Internet. Por ello, las implementaciones actuales utilizan claves asignadas estáticamente y un intercambio de claves manual. Una alternativa para la provisión de autenticación mediante clave pública para direcciones IP sin requerir la confianza en terceras partes, PKI, u otra infraestructura global, es el uso de Direcciones Generadas Criptográficamente (Cryptographically Generated Addresses, CGAs). Las CGAs, actualmente investigadas en el IETF, ofrecen un nivel intermedio de seguridad inferior a la autenticación con clave pública, y superior a seguridad basada en encaminamiento. La idea es obtener los 64 bits inferiores de una dirección IPv6, el identificador de interfaz, a partir del cómputo de un hash de 64 bits de la clave pública del sistema final. El receptor ejecuta a su vez el hash de la clave pública y lo compara con el identificador de interfaz de la dirección IP fuente recibida novática / upgrade nº 174 marzo-abril

29 IPv6 - Más que un protocolo antes de verificar la firma de los datos transmitidos. Esto impide que otro nodo excepto el legítimo pueda enviar datos con su propia dirección. Como sólo las direcciones IPv6 disponen de un identificador de 64 bits, las CGAs sólo se pueden utilizar con IPv6. En muchos casos, un identificador de 64 bits es utilizado para formar una dirección global IPv6 (a partir del mecanismo de autoconfiguración sin estado que ofrece IPv6). Si las transferencias seguras no están utilizando el modo túnel, las direcciones IPv6 de fuente y destino son visibles, dando lugar a que los datos básicos de la sesión sean accesibles a la inspección en un elemento intermedio. En los casos en los que los dispositivos se mueven resulta posible rastrear el movimiento del dispositivo y las sesiones en las que participa. Esto se considera una seria amenaza a la privacidad, especialmente para usuarios móviles. En [17] se propone cuna solución a este problema, solución que implica el uso de un identificador de interfaz que cambie con el tiempo, basándose en un número pseudoaleatorio. Esto dificulta que los fisgones puedan establecer correspondencias entre usuarios y actividad basándose en la dirección, y hace extremadamente difícil (si no imposible) que se pueda detectar o rastrear a un determinado dispositivo (y con ello potencialmente a un usuario). Un sutil aspecto de la seguridad en IPv6 tiene que ver con la expansión en el rango de direcciones. En IPv4 obtener las direcciones de los equipos finales de una red es trivial: se obtiene la dirección de la red y se prueban correlativamente todas las direcciones disponibles. Con herramientas muy populares, tales como nmap, se puede obtener en muy poco tiempo un listado de los sistemas activos, sus sistemas operativos y los servicios que están corriendo, incluyendo proxies, servicios poco seguros o puertas traseras. Además de ataques manuales, muchos ataques automatizados utilizan esta técnica; en particular, gusanos recientes como Blaster o Slammer se han propagado rastreando correlativamente direcciones para buscar puertos vulnerables específicos a través de los que ganar acceso al sistema. El motivo de la rapidez de este ataque en IPv4 es el pequeño rango de direcciones a rastrear. Por el contrario, con IPv6 este tipo de rastreo por "fuerza bruta" es en la práctica imposible. Si las direcciones se distribuyen de forma dispersa sobre el rango de direcciones asignado, el elevado número de direcciones asignadas a un segmento de red origina que cualquier herramienta de rastreo se quedará atascada buscando una dirección que responda. Esto es una protección frente a ataques de gusanos. 5. Transición IPv4-IPv6 La transición de IPv4 a IPv6 no ocurrirá, por supuesto, de un día para otro. Las organizaciones que están adoptando IPv6 lo están haciendo poco a poco, principalmente debido a la necesidad de dar soporte a aplicaciones y sistemas antiguos. Como con la adopción de cualquier nueva tecnología, es prudente proceder con cautela y seleccionar inicialmente zonas piloto para la transición de la red. El efecto es que IPv4 e IPv6 necesitan coexistir por un periodo de tiempo considerable. Esto implica una aproximación del tipo de doble pila de protocolos (dual-stack), así como un extenso uso de túneles para el transporte de paquetes IPv6 sobre redes IPv4 (y viceversa). Esta fase de coexistencia presenta varios desafíos de seguridad. Uno de los principales enemigos de la seguridad es la complejidad. En general, cuanto más complejo es un sistema, más riesgo hay de un fallo humano, y más oportunidades se dan para que triunfe un ataque. Por ejemplo, los routers de doble pila de protocolos requieren más configuración que routers que son sólo IPv4 o sólo IPv6. [1] registra un incremento del 50% en el número de líneas de una configuración típica de un firewall cuando se añade IPv6. Cuanto mayor es la configuración, mayor es también la posibilidad de una error en la misma. Adicionalmente, ahora hay dos protocolos distintos que pueden ser atacados, en vez de sólo uno. Los sistemas IPv4 actuales cuentan con sistemas de seguridad que son bien comprendidos. Con el paso del tiempo, los problemas se han ido solventando acumulativamente a través de la experiencia ganada. Se requiere pues un estricto control de los cambios realizados en la difusión de IPv6, teniendo en cuenta que los desarrollos de forma experimental puede no respetar salvaguardas clásicas. De hecho, es difícil proteger nuevas redes IPv6 mientras mecanismos de protección tales como detectores de intrusos no estén soportados en esta versión. 6. Conclusión Todos los modelos extremo a extremo todavía implican inherentemente seguridad por encima de la capa de transporte. PGP, S/ MIME y SSL (Secure Sockets Layer) tratan los objetos de capas superiores y los pasan a las capas inferiores. Por otro lado, mecanismos de seguridad a nivel de enlace aseguran privacidad salto a salto. IPsec en IPv6 implica seguridad en el nivel de red y complementa a los mecanismos de seguridad de otras capas sin eliminar su necesidad. Los usuarios se están convirtiendo en móviles y demandan una mayor flexibilidad, haciendo que la seguridad perimetral (firewalls, etc.) sea menos efectiva. En un mundo en el que las aplicaciones se implementan cada vez más sobre servicios Web y las técnicas de tunelado se hacen más populares, los firewalls, antes vistos como críticos para la seguridad de los sistemas, empiezan a ser percibidos como obstáculos [19]. Las aplicaciones del ámbito de los negocios pueden beneficiarse de las ventajas de la infraestructura de seguridad de IPv6. En ese ámbito hay una necesidad implícita de confidencialidad y de autenticación. Las ventajas de IPsec para un escenario de negocios serían la autenticación de los datos y confidencialidad basadas en las fuentes de los datos. Dado que en este escenario se dispondrá muy probablemente de una PKI para uso propio, la implantación de IPsec con PKI resultará simplemente una cuestión de integración. Los datos relativos a la gestión de red son recogidos para analizar y monitorizar el tráfico. Esta información es estratégica para la toma de decisiones en las entidades corporativas, de cara a provisionar la red para el crecimiento futuro. Estos datos pueden percibirse como sensibles comercialmente, por tanto puede haber una necesidad de asegurar dichos datos. Desde la perspectiva del proveedor de servicios, la capacidad de recolectar datos para la tarificación es crucial. Estos datos tienen que ser auténticos, o por el contrario la tarificación podría ser inexacta o inexistente, con las consiguientes pérdidas económicas en ambos casos (esto se percibe de forma especial en el contexto de la telefonía de 3ª generación). Para asegurar que cualquier sesión extremo a extremo es privada en el sentido real de la palabra, se requieren importantes recursos. Una infraestructura pública (PKI) es necesaria para ofrecer claves públicas certificadas a cualquier sistema final IPv6. Un sistema final IPv6 que desee comunicarse de forma segura con un elemento remoto requerirá disponer de la última clave pública disponible antes de comenzar la comunicación segura. Alternativamente, con el uso de CGAs, IPv6 puede ofrecer un cierto nivel de seguridad incluso sin esas infraestructuras de soporte. En el actual escenario de Internet, políticas restrictivas en la asignación de direcciones junto con asimetrías en el tipo de usuario han dado lugar a un amplio uso de dispositivos de traducción. Los NATs han roto el modelo de comunicación igual a igual en el que se basaba Internet. Con la gran cantidad de espacio de direccionamiento de IPv6, se espera que se regenere la transparencia extremo a extremo de las aplicaciones y servicios sobre Internet. La seguridad jugará un papel vital en el mantenimiento de este atributo. 30 novática / upgrade nº 174 marzo-abril 2005

30 IPv6 - Más que un protocolo Ninguna tecnología de seguridad es una panacea Merece la pena concluir con dos notas finales. En primer lugar, a pesar de la promesa de un mundo seguro de dispositivos móviles IPv6 comunicándose extremo a extremo, de la que IPsec es responsable, es importante reconocer que ninguna tecnología de seguridad es una panacea; más aún, las tecnologías de seguridad son sólo útiles en el contexto más general de una buena política de seguridad que sea frecuentemente actualizada. Por ejemplo, disponer de una conexión IPsec con elevados parámetros de seguridad no protegerá a un sistema frente a gusanos que hayan penetrado en la red corporativa [20]. El gusano utilizará tranquilamente el canal asegurado e intentará infectar el siguiente equipo final. Y en segundo lugar, debería reconocerse que no puede alcanzarse una seguridad perfecta pues siempre existe la necesidad de equilibrar los requisitos de seguridad con las demandas de flexibilidad y libertad de los usuarios. La clave para una seguridad efectiva está en comprender cómo se establece este equilibrio. Referencias [1] S. Convery, D. Miller. "IPv6 and IPv4 Threat Comparison and Best-Practice Evaluation", v1.0, Cisco Systems Technical Report, marzo [2] ITU-T. Security in Telecommunications and Information Technology, International Telecommunication Union, Geneva, [3]C. Manikopoulos, S. Papavassiliou. "Network Intrusion and Fault Detection: A Statistical Anomaly Approach", IEEE Communications Magazine, octubre [4] J. Postel. "Internet Protocol", RFC 791, septiembre [5] J. Postel. "Transmission Control Protocol", RFC 793, septiembre [6] R. Braden et al. "Report of IAB Workshop on Security in the Internet Architecture", RFC 1636, febrero [7] Y. Rekhter et al. "Address Allocation for Private Internets", RFC 1918, febrero [8] S. Kent, R. Atkinson. "Security Architecture for the Internet Protocol", RFC 2401, noviembre [9] S. Kent, R. Atkinson. "IP Authentication Header", RFC 2402, noviembre [10] S. Kent, R. Atkinson. "IP Encapsulating Security Payload (ESP)", RFC 2406, noviembre [11] D. Maughan et al. "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, noviembre [12] D. Harkins, D.Carrel. "The Internet Key Exchange (IKE)", RFC 2409, noviembre [13] S. Deering, R. Hinden. "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, diciembre [14] S. Thomson, T. Narten. "IPv6 Stateless Address Autoconfiguration", RFC 2462, diciembre [15] P. Srisuresh, M. Holdrege. "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, agosto [16] P. Srisuresh, K. Egevang. "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, enero [17] T. Narten, R. Draves. "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, enero [18] R. Hinden, S. Deering, E. Nordmark. "IPv6 Global Unicast Address Format", RFC 3587, agosto [19] A. Singer. "Life without firewalls", USENIX;login: magazine, diciembre [20] A. Vives, J. Palet, P. Savola. "IPv6 Security Problem Statement", draft-vives-v6ops-ipv6- security-ps-02.txt, octubre novática / upgrade nº 174 marzo-abril

31 IPv6 - Más que un protocolo Marcelo Bagnulo Braun, Alberto García Martínez, Arturo Azcorra Saloña Depto. de Ingeniería Telemática, Universidad Carlos III de Madrid Herramientas para la provisión de multihoming en IPv6 <{bagnulo,alberto,azcorra}@it.uc3m.es> 1. Introducción En la actual infraestructura IPv4 (Internet Protocol version 4) son cada vez más populares configuraciones en las que una red obtiene conectividad a Internet a través de dos o más proveedores distintos [1]. Estas configuraciones son conocidas como multihoming o multiproveedor. El mayor atractivo que presenta el uso de multihoming es el ofrecer una buena tolerancia a fallos, aunque también permite obtener capacidades adicionales tales como la gestión del tráfico entrante y saliente a través los distintos proveedores (ingeniería de tráfico). La principal solución actualmente disponible para multihoming en IPv4 se implementa a nivel de encaminamiento interdominio, y consiste en la inyección en el sistema de encaminamiento de BGP (Border Gateway Protocol) de los prefijos que agrupan a las direcciones de la red multihomed [2], tal y como se muestra en la figura 1. 1 Si ocurre un fallo en alguno de los caminos pero existe una alternativa válida, el sistema de encaminamiento la encontrará. Convertir una red en multihomed implica añadir en la tabla de encaminamiento global a los prefijos que describen las direcciones contenidas en esa red, entradas que anteriormente no eran necesarias ya que se propagaba la alcanzabilidad mediante un agregado de un proveedor de mayor tamaño. La adición de nuevas entradas en la tabla de encaminamiento global se considera indeseable, ya que da lugar a problemas de escalabilidad en el tratamiento de las rutas de BGP que, entre otros efectos, incrementan el tiempo de convergencia del sistema de encaminamiento [3]. Para limitar el número de entradas propagadas en BGP, ciertos proveedores imponen restricciones de facto filtrando los prefijos de redes con pocas direcciones, impidiendo a redes pequeñas y a usuarios residenciales el acceso a los beneficios de multihoming. Aunque esto no fuera así, la necesidad de configurar y mantener estable el complejo sistema de rutas BGP serían suficiente obstáculo para que estos usuarios no dispusieran de multihoming. Para estos casos, todavía es posible utilizar soluciones basadas en la reescritura dinámica de direcciones (NAT, Network Address Translation) entre las direcciones IPv4 asignadas por los distintos proveedores (figura 2) 2 para obtener limita- Resumen: la disponibilidad de dos o más proveedores de conectividad (multihoming, o multiproveedor) permite mejorar la tolerancia a fallos y ofrecer capacidades de ingeniería de tráfico. Las soluciones disponibles para IPv4 (Internet Protocol version 4) tienen limitaciones en la escalabilidad, o son soluciones parciales basadas en tecnologías NAT (Network Address Translation). En este artículo presentamos un conjunto de herramientas que permiten a redes IPv6 (Internet Protocol version 6) beneficiarse del multihoming, aprovechando que estas redes reciben direcciones distintas por cada proveedor. El artículo se centra en dos escenarios: el establecimiento de nuevas comunicaciones y el mantenimiento en caso de fallo de comunicaciones ya establecidas. Palabras clave: IPv6, multihoming, seguridad en las comunicaciones, tolerancia a fallos. Autores Marcelo Bagnulo Braun es Profesor Ayudante en el Depto. de Ingeniería Telemática de la Universidad Carlos III de Madrid. Está realizando su Tesis Doctoral en la implantación de multihoming en IPv6. Actualmente está participando en varios proyectos de investigación relacionados con IPv6, tanto internacionales (6Link) como nacionales (Optinet6, SAM). Ha publicado varios artículos y drafts de Internet en su área de especialidad. Alberto García Martínez es Ingeniero de Telecomunicación por la Universidad Politécnica de Madrid. Obtuvo su doctorado en 1999, en el Depto. de Ingeniería Telemática de la misma universidad. Actualmente es Profesor Titular en el Depto. de Ingeniería Telemática de la Universidad Carlos III de Madrid. Ha participado en varios proyectos de investigación sobre IPv6, incluyendo proyectos IST (Information Society Technologies) europeos como LONG (Laboratories over Next Generation Networks), o 6LINK, y proyectos financiados por el Plan Nacional de I+D como SAM (Servicios Avanzados con Movilidad) y SABA2 (Nuevos Servicios para la Red Académica de Banda Ancha). Recientemente ha publicado varios artículos en relación con su tema de investigación actual, multihoming en IPv6. Arturo Azcorra Saloña es Catedrático en el Depto. de Ingeniería Telemática de la Universidad Carlos III de Madrid. Ha sido investigador responsable de un gran número de proyectos relacionados con protocolos y servicios de nueva generación, cubriendo temas tales como IPv6, movilidad, calidad de servicio, redes activas, etc. Entre otros méritos, es coordinador de la Red de Excelencia E-NEXT, financiada por el 6º Programa Marco de la Unión Europea. Es autor de más de 100 artículos tanto nacionales como internacionales. das capacidades de tolerancia a fallos e ingeniería de tráfico [4]. No obstante, además de los problemas inherentes al uso de NAT [5][6], esta configuración no preserva las comunicaciones establecidas en caso de fallo en alguno de los proveedores, ya que estas comunicaciones se interrumpirían con un cambio de direcciones (considérese, por ejemplo, una conexión TCP, Transmission Control Protocol). Para la implantación de IPv6 (Internet Protocol version 4) hay un consenso en mantener el número de entradas en la tabla de encaminamiento tan bajo como sea posible, por lo que no es aceptable una solución como la ofrecida en IPv4. En IPv6, los grandes proveedores reciben la asignación de bloques de direcciones de los que saldrán las direcciones que, a su vez, asignarán a clientes de menor tamaño. Estos grandes proveedores utilizan BGP para intercambiar entre sí la información de encaminamiento. Una red de mediano o pequeño tamaño que quiera beneficiarse del multihoming (por ejemplo, un usuario residencial con dos proveedores de conectividad) recibirá bloques de direcciones distintos por cada uno de los proveedores a los que se conecte. Consecuentemente, los sistemas finales de esta red serán configurados con direcciones construidas a partir de los prefijos de cada proveedor disponible. A esta configuración se la conoce como multidireccionamiento. Existen varios problemas para un sistema en el que se han configurado direcciones de múltiples prefijos. En primer lugar, la posibilidad de establecer una comunicación con un elemento remoto no está garantizada ni 32 novática / upgrade nº 174 marzo-abril 2005

32 IPv6 - Más que un protocolo El mayor atractivo que presenta el uso de multihoming es el ofrecer una buena tolerancia a fallos Figura 1. Provisión de multihoming mediante la inyección de rutas BGP en IPv4. siquiera en ausencia de fallos. En efecto, muchos proveedores ejecutan un filtrado de origen (ingress filtering) eliminando por motivos de seguridad aquellos paquetes que envían sus clientes con direcciones de origen que no pertenecen al rango de direcciones que se le ha asignado a los clientes. Si un sistema en un entorno de multidireccionamiento envía por un proveedor A paquetes que han sido generados con direcciones origen provenientes del proveedor B, los paquetes serán descartados por el filtrado de origen. Si se solucionara este problema, todavía habría que incorporar algunas funcionalidades de red para asegurar que se encuentra un camino válido para una comunicación que se inicia después de que haya ocurrido un fallo. Finalmente, resaltamos que hacen falta modificaciones más complejas para mantener comunicaciones que fueron establecidas antes de un fallo en la comunicación. En este artículo presentamos unas herramientas que permiten el establecimiento de nuevas comunicaciones en una configuración de multidireccionamiento, así como el mantenimiento en caso de fallo de comunicaciones previamente establecidas. Para el establecimiento de nuevas comunicaciones, se propone la implantación en las redes multihomed de sistemas de encaminamiento basados no sólo en la dirección IP (Internet Protocol) de destino de los paquetes, sino también en la dirección origen, junto con un barrido de diferentes pares <dirección destino, dirección origen> en caso de fallo. Para el mantenimiento de las comunicaciones establecidas, proponemos una nueva subcapa a nivel de red que gestione dinámicamente, mediante un protocolo específico, los múltiples localizadores por proveedor disponibles en el esquema de multidireccionamiento. Esta solución requiere de una serie de herramientas que están siendo discutidas actualmente en el marco del IETF (Internet Engineering Task Force) [7]: herramientas para la gestión de los localizadores, herramientas para la detección de fallos, herramientas para encontrar caminos alternativos y forzar su uso, y herramientas para identificar un flujo independientemente del camino utilizado. El artículo está estructurado de la siguiente forma: en la sección 2 se discuten las herramientas necesarias para el correcto establecimiento de nuevas conexiones en un entorno de multidireccionamiento; consideraremos los problemas que pueden ocurrir en un escenario sin fallos así como las herramientas para poder escoger caminos válidos cuando algunos han fallado. En la sección 3 se presentan las herramientas que permiten mantener una comunicación en caso de fallo. Finalmente, se presentan las conclusio- nes. 2. Establecimiento de nuevas comunicaciones en un entorno de multidireccionamiento Como ya se ha presentado en la introducción, un entorno de multidireccionamiento puede sufrir problemas de conectividad sin haberse siquiera producido un fallo. Para ilustrarlo, supondremos un ejemplo (figura 3) 3 en el que un equipo Equipo1desea comunicarse con otro Equipo2, ambos en redes multihomed. Lo normal es que Equipo1 acceda al DNS (Domain Name Server) para obtener las múltiples direcciones IPv6 en las que Equipo2 puede ser accesible. Equipo1 aplicará el procedimiento de Selección de Direcciones por Defecto [8] para, a partir de todas las direcciones de Equipo2 obtenidas en el DNS y el conocimiento local de las direcciones Equipo1, obtener un par <dirección origen, dirección destino> con el que intentar la comunicación. Aunque que no haya fallo en la infraestructura, puede ocurrir que la comunicación no sea posible debido a la implantación de filtrado de origen (ingress filtering) [9] en los proveedores. Este filtrado se realiza para evitar que usuarios utilicen con fines maliciosos direcciones que no les corresponden (usurpación de direcciones o address spoofing). La motivación es la siguiente: ai un usuario utiliza como dirección origen una dirección usurpada, en particular una que no corresponda topológicamente al lugar de la red en el que obtiene conectividad, podría realizar ataques de forma anónima, dado que la localización real del atacante será Figura 2. Provisión de multihoming mediante arquitectura con NAT en IPv4. novática / upgrade nº 174 marzo-abril

33 IPv6 - Más que un protocolo Repitiendo este proceso, se pueden resolver fallos en los caminos cercanos a Equipo2 si existe al menos un camino válido hasta el destino, con el coste, en tiempo de establecimiento de la comunicación, de tener que esperar al vencimiento de un temporizador por cada uno de los caminos explorados. Figura 3. Redes IPv6 multihomed con multidireccionamiento. difícil de obtener. Nótese que si el atacante no se encuentra en el camino entre el nodo atacado y la red de la que ha tomado indebidamente una dirección, podrá mandar paquetes pero no podrá interceptar las respuestas, que se dirigirán a la red de la que ha usurpado la dirección. No obstante, en esta situación todavía podría realizar ataques de denegación de servicio, inundando de tráfico bien la red a la que dirige sus paquetes, o bien la red de la que toma las direcciones indebidamente (si el tráfico de respuesta generado ante la petición del atacante es elevado). Una forma de protegerse frente a la amenaza de la usurpación de direcciones es la implantación del mecanismo de filtrado de origen en los proveedores, consistente en el filtrado de aquellos paquetes que se reciben de un cliente que tengan direcciones de origen que no pertenecen al rango de direcciones que se le ha asignado. Si volvemos al escenario de multihoming, un paquete generado por Equipo1, con una dirección de origen legítima obtenida del ProveedorA, será descartado si el encaminamiento dirige el paquete a través del ProveedorB. Nótese que al elegir Equipo1 una dirección origen, ha forzado el proveedor por el que le llegarán paquetes desde Equipo2 (y por tanto, parte del camino de recepción de paquetes), así como el proveedor por el que podrán salir los paquetes sin ser filtrados. De forma análoga, la dirección de destino también establece un camino particular por el que llegarán los paquetes a Equipo2, así como el camino de vuelta. Por tanto, podemos decir que, en un escenario basado en multidireccionamiento, el nodo que inicia la comunicación define la salida y entrada de los paquetes de dicha comunicación hacia ambos extremos. Para evitar que el mecanismo de filtrado de origen dé lugar a pérdidas de paquetes, se propone la implantación en la red multihomed de un esquema de encaminamiento intradominio en el que se tenga en cuenta también la dirección fuente para el reenvío de paquetes [10] [11]. Para ello, en los routers de la red multihomed se añadirán tantas tablas de encaminamiento como proveedores distintos de conectividad haya. Para el reenvío de un paquete, se tomará en primer lugar la dirección de origen para seleccionar la tabla de encaminamiento correspondiente al proveedor desde el que ha sido delegada la dirección dada (o una tabla por defecto, si el paquete viene del exterior y la dirección origen no se corresponde con ninguna de las direcciones de la red multihomed). Como resultado, un paquete dirigido hacia el exterior de la red se enviará hacia el proveedor apropiado. Una configuración especialmente sencilla ocurre cuando un único router realiza la conexión con todos los proveedores, caso que puede ser habitual en entornos residenciales. Una vez resueltos los aspectos básicos de conectividad, es conveniente analizar el establecimiento de nuevas conexiones en caso de fallos. Si el fallo se produce en uno de los proveedores o enlaces cercanos a Equipo2 (por ejemplo en ProveedorK), y Equipo1 inicia la comunicación, puede ocurrir el siguiente caso: Equipo1 accede al DNS para obtener las direcciones de Equipo2. El procedimiento de Selección de Direcciones por Defecto [8] escoge un par <dirección origen, dirección destino> tomando como datos las direcciones recibidas. Supongamos que la dirección destino pertenece al rango de direcciones delegadas por ProveedorK. La aplicación intenta establecer la comunicación con esos parámetros, pero no es posible, y se percata de ese suceso (bien porque el nivel de transporte indica un fallo en el establecimiento de la conexión, o porque expira un temporizador en la propia aplicación). En este caso, el comportamiento recomendado para las aplicaciones será probar con otra dirección de destino de las obtenidas de la petición al DNS. Si el fallo ocurre en las cercanías del Equipo1, la exploración de caminos alternativos se consigue variando las direcciones origen. Esto implicaría adaptaciones en el mecanismo de Selección de Direcciones por Defecto que están siendo discutidas actualmente. Nótese que en el esquema propuesto los sistemas finales implicados en la comunicación no disponen de otra información para la detección de fallos que la expiración de temporizadores y esta información no les permite determinar si el fallo se produce en equipo remoto (p.ej. porque está apagado), en la cercanía del destino (solucionado con cambios en la dirección de destino) o en la cercanía del origen (solucionado con cambios en la dirección de origen). Es más, pueden ocurrir fallos múltiples que hacen que sólo ciertas combinaciones de direcciones origen y destino sean válidas. Como consecuencia, sólo la exploración de todos los pares posibles <dirección origen, dirección destino> garantiza la conectividad en cualquier caso. La exploración secuencial de estas alternativas puede ser lenta, mientras que la exploración en paralelo puede ser costosa en ancho de banda así como requerir cambios en las aplicaciones o en su interfaz con las funcionalidades de red del sistema operativo. 3. Mantenimiento de comunicaciones en un entorno de multidireccionamiento Tras haber discutido en la sección anterior cuestiones básicas de establecimiento de comunicaciones en entornos multihomed con multidireccionamiento, abordamos en esta sección cómo mantener comunicaciones establecidas en caso de fallo en la infraestructura de red (por ejemplo, aunque no exclusivamente, una conexión TCP). Uno de los requisitos que serían deseables para una solución a este problema es que se provea esta funcionalidad de forma transparente a las aplicaciones, es decir, que no sea necesario ningún cambio en las aplicaciones para que se beneficien de este servicio. Teniendo en cuenta esta consideración, y añadiendo la conveniencia de que una solución de este estilo también pueda ser utilizada de forma transparente por cualquier protocolo de nivel de transporte (TCP, UDP -- User Datagram Protocol -- u otros), se ha propuesto que la solución se implemente a nivel de red. Las consideraciones que hare- 34 novática / upgrade nº 174 marzo-abril 2005

34 IPv6 - Más que un protocolo Una solución de multihoming a nivel de red se encargaría de gestionar cambios en las direcciones IP que se utilizarán para reenviar los paquetes mos a continuación están desarrolladas a partir de la información disponible en los documentos de trabajo [12] [13][14][15]. Una solución de multihoming a nivel de red se encargaría de gestionar cambios en las direcciones IP que se utilizarán para reenviar los paquetes, de forma que se escojan aquellas direcciones que definen caminos válidos para la comunicación. A las direcciones incluidas en los paquetes IP y utilizadas para el encaminamiento en la red las llamaremos localizadores. Por otro lado, el nivel de transporte utiliza habitualmente las direcciones IP dentro de los parámetros básicos que identifican una comunicación. TCP, por ejemplo, utiliza la dirección IP de origen y de destino, además de puerto origen y destino, para identificar de forma unívoca a una conexión. Estas direcciones son provistas por lo general por la aplicación del equipo que inicia la comunicación, y también pueden ser utilizadas por las aplicaciones para identificar la comunicación. A las direcciones IP utilizadas de esta forma las llamamos identificadores. Tras haber establecido una comunicación de manera análoga a como se ha comentado en la sección anterior, una solución de multihoming se ocupará de gestionar los distintos localizadores de forma que se garantice la conectividad entre los extremos en caso de fallo, presentando un único par de identificadores para las capas superiores. La gestión de identificadores y localizadores se realizará en una nueva entidad, que se incorporará al nivel de red como una subcapa que llamaremos de identificación. Esta subcapa intercambiará información de los localizadores disponibles para una comunicación dada en cada uno de los equipos extremos, de forma que puedan ser utilizados en caso de fallo. Siguiendo el ejemplo que presentábamos en la sección anterior, una vez establecida la comunicación entre Equipo1 y Equipo2, cualquiera podría iniciar un intercambio en el que informara al otro de todos los localizadores de los que dispone localmente, y viceversa. Esto se hará a través de un protocolo específico para el soporte de multihoming y se generará un nuevo estado para los participantes. A partir de aquí, si se detectara un problema en la comunicación cuando se está utilizando un par de localizadores dado, cualquiera de los equipos podría modificar dicho par para encontrar un camino válido. Es importante disponer de herramientas que permitan identificar un flujo a pesar de haber cambiado los localizadores. Para ello, puede ser necesario incorporar en los paquetes un identificador de flujo que puede haber sido preacordado entre los dos extremos mediante el protocolo específico para multihoming. Este identificador de flujo puede viajar en una cabecera de extensión de IPv6. Para detectar un fallo, existen varias alternativas [14]. En primer lugar, hay mecanismos para detectar si existen problemas locales, tales como que una interfaz ya no está operativa. Además, podemos confiar en información provista por los niveles superiores, de forma que si hay una notificación explícita de problemas, o faltan confirmaciones de que todo va bien durante un cierto tiempo, deduzcamos que la comunicación no se está realizando correctamente. TCP, por ejemplo, puede indicar a la capa de red que no se ha recibido una confirmación en un cierto tiempo. Finalmente, podemos añadir procedimientos específicos de señalización para multihoming, enviando paquetes que permitan conocer si existe alcanzabilidad con un par de localizadores dados. Este procedimiento puede ser análogo a un ping ICMP (una solicitud de eco con su consiguiente respuesta) y se puede utilizar para comprobar el estado del par de localizadores actualmente en uso, de forma paralela al intercambio de datos. Un temporizador comprobará si las respuestas llegan en el momento apropiado y de no ser así se arrancará un proceso de selección de nuevos localizadores. El procedimiento de selección de un nuevo par incluye la comprobación de alcanzabilidad para diferentes pares candidatos. Una vez escogido, el par será utilizado en los sucesivos envíos de datos. Al recibir el nodo remoto paquetes con nuevos localizadores, iniciará a su vez un proceso de comprobación de alcanzabilidad tomando como localizadores candidatos los recibidos del nodo que ha iniciado el procedimiento de cambio. La posibilidad de cambiar localizadores mientras una comunicación está teniendo lugar abre las puertas a nuevos problemas de seguridad. Como criterio para el análisis de la seguridad ofrecida por nuevas soluciones de multihoming, se suele requerir el evitar la aparición de amenazas que no son posibles con la infraestructura actual de IPv4 [16]. Con el desarrollo que hemos realizado hasta ahora, podemos presentar ataques que no son posibles en el entorno actual. El ataque de redirección consiste en abusar del mecanismo de correspondencia entre identificador y localizador que implementa multihoming para crear una correspondencia falsa. Esto puede hacerse, por ejemplo, para asociar un localizador de un atacante al identificador de una víctima que se pretende suplantar. De esta forma, cuando una víctima manda paquetes a un destino dado, realmente estaría mandando los paquetes a un atacante. La principal dificultad en definir un mecanismo para la gestión de múltiples localizadores en entornos multihoming ha sido la provisión de la adecuada seguridad. Se han propuesto mecanismos que se basan en criptografía y direcciones generadas criptográficamente para asegurar la identidad de un interlocutor [17] [18], pero adolecen del elevado coste computacional de las soluciones basadas en clave asimétrica. Este coste puede ser intolerable en ciertas situaciones tales como la de un servidor atendiendo a un gran número de clientes por segundo. Recientemente se ha propuesto un mecanismo, las Direcciones Basadas en Hash (Hash Based Addresses, HBA [19]), que garantiza la ligazón de un conjunto de localizadores con una identidad sin incurrir en grandes costes computacionales. En esta propuesta, un nodo multihomed Equipo1, situado en una red que cuenta con varios prefijos correspondientes a proveedores distintos, genera identificadores de interfaz (los 64 bits menos significativos de la dirección) para dichas direcciones a partir de un hash de los prefijos disponibles. novática / upgrade nº 174 marzo-abril

35 IPv6 - Más que un protocolo De esta forma, todas sus direcciones cuentan con una firma obtenida a partir de los prefijos asignados al equipo. Cuando un interlocutor Equipo2 establece una comunicación con una dirección del Equipo1 (obtenida p. ej. mediante acceso al DNS), y Equipo2 recibe mediante el protocolo de multihoming los localizadores alternativos del Equipo1, Equipo2 puede comprobar que estos localiza-dores son legítimos. Esta comprobación se realiza obteniendo un hash de los prefijos de los localizadores, que debe ser igual al identificador de interfaz de la dirección inicialmente utilizada para establecer la comunicación. Un atacante requerirá del orden de 2^63 operaciones (debido al número de bits del hash) para obtener unos prefijos distintos de los originalmente especificados que cumplan los requisitos especificados y que incluyan un localizador del atacante. 4. Conclusiones En este artículo se han presentado los mecanismos que están actualmente en discusión para el soporte de multihoming en redes IPv6. La gran disponibilidad de direcciones en IPv6 permite configuraciones basadas en multidireccionamiento, evitando así los problemas de escalabilidad que presentan las soluciones actuales en IPv4. Se han abordado dos subproblemas: el establecimiento de nuevas comunicaciones en un entorno multihoming, bien sin fallos o con ellos, y el mantenimiento de comunicaciones ya establecidas en caso de fallo. Para el primer caso se ha propuesto una modificación en el encaminamiento de las redes multihomed que evite el descarte de paquetes por ingress filtering, así como variaciones en el mecanismo de Selección de Direcciones por Defecto para explorar diferentes pares <dirección origen, dirección destino> en caso de fallos. Para el mantenimiento de comunicaciones ya establecidas se requieren cambios mayores, tales como un modelo en el que se separan identificadores y localizadores, la definición de un nuevo protocolo, nuevos estados y la implantación de mecanismos de detección de fallos en los caminos. Los 128 bits de longitud de la dirección IPv6 permiten incorporar dentro información criptográfica, o hash de información relevante, que permitan realizar las operaciones de redirección de localizadores con suficiente seguridad. En contra de lo que ocurre en IPv4, IPv6 permite beneficiarse del multihoming a redes pequeñas e incluso usuarios residenciales. Si bien no se ha encontrado todavía la killer application o aplicación rompedora que puede hacer definitivamente atractiva a la tecnología IPv6, el soporte de multihoming que IPv6 puede ofrecer le dará sin duda un impulso que en modo alguno debe despreciarse. Agradecimientos Este trabajo ha sido financiado parcialmente por el proyecto Servicios Avanzados con Movilidad (SAM, TIC C04-03). Referencias [1] G. Huston. Commentary on Inter-Domain Routing in the Internet. RFC 3221, diciembre [2] J. Abley, K. Lindqvist, E. Davies, B. Black, V. Gill. IPv4 Multihoming Practices and Limitations. draft-ietf-multi6-v4-multihoming-03, enero [3] C. Labovitz, A. Ahuja, A. Bose. Delayed Internet Routing Convergence, 2000, SIGCOMM [4] F. Guo, J. Chen, W. Li, T. Chiueh. Experiences in Building a Multihoming Load Balancing System. IEEE Infocom [5] T. Hain. Architectural Implications of NAT. RFC 2993, noviembre [6] M. Holdrege, P. Srisuresh. Protocol Complications with the IP Network Address Translator. RFC 3027, enero [7] Sitio web "Multihoming in IPv6". < archivo de la lista de correo en < lists/multi6>. [8] R. Draves. Default Address Selection for Internet Protocol version 6 (IPv6), RFC 3484, febrero [9] P. Ferguson, D. Senie. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. RFC 2267, enero [10] M. Bagnulo, A. García Martínez, J. Rodríguez, A. Azcorra. The Case for Source Address Dependent Routing in Multihoming, Proceeding of the First Workshop on QoS Routing, octubre [11] C. Huitema, R. Draves, M. Bagnulo. Ingress filtering compatibility for IPv6 multihomed sites. Internet draft, octubre [12] Multihoming L3 Shim Approach. E. Nodmark, M. Bagnulo. draft-ietf-multi6-l3shim-00.txt, enero [13] M. Bagnulo, J. Arkko. Functional decomposition of the M6 protocol. draft-ietf-multi6- functional-dec-00, diciembre [14] J. Arkko. Failure Detection and Locator Selection in Multi6. draft-ietf-multi6-failuredetection-00, enero [15] E. Nodmark. Multi6 Application Referral Issues. draft-ietf-multi6-app-refer-00.txt, enero [16] J. Abbley, B. Black, V. Gill. Goals for IPv6 Site-Multihoming Architectures. RFC 3582, agosto [17] R. Moskowitz P. Nikander P. Jokela, T. Henderson. Host Identity Protocol. draft-ietf-hipbase-00, junio [18] T. Aura. Cryptographically Generated Addresses (CGA). draft-ietf-send-cga-06, abril [19] M. Bagnulo. Hash Based Addresses (HBA). draft-ietf-multi6-hba-00, diciembre novática / upgrade nº 174 marzo-abril 2005

36 IPv6 - Más que un protocolo Carlos Jesús Bernardos Cano 1, Ignacio Soto Campos 1, María Calderón Pastor 1, Dirk von Hugo 2, Emmanuel Riou 3 1 Dpto. de Ingeniería Telemática. Universidad Carlos III de Madrid; 2 T-Systems International GmbH, Technology Centre Darmstadt (Alemania); 3 Edge Mobile Networking Lab (EMNL) Centre de Recherche Motorola, Paris (Francia) <{cjbc,isoto,maria}@it.uc3m.es>, <Dirk.Hugo@t-systems.com>, <emmanuel.riou@motorola.com> 1. Introducción El interés de los usuarios por la movilidad es claramente visible por el éxito de las redes de comunicaciones móviles celulares. Estas redes están evolucionando para ofrecer no sólo su tradicional servicio de voz sino también servicios de datos. IP (Internet Protocol) se está posicionando como la tecnología base de las redes del futuro, para ofrecer todo tipo de servicios y a través de todo tipo de accesos, tanto fijos como móviles. Sin embargo, IP no se diseñó pensando en la posible movilidad de sus usuarios y terminales, y de hecho no la soporta; esto es cierto tanto para IPv4 (Internet Protocol version 4) como para IPv6 (Internet Protocol version 6). El IETF (Internet Engineering Task Force) ha definido unos protocolos de nivel IP que proporcionan movilidad de terminales en redes IPv4 [1] e IPv6 [2]. Sin embargo estos protocolos no permiten una situación en que lo que se mueve no es un único terminal, sino toda una red, que cambia su punto de unión a la infraestructura fija: la movilidad de redes. El IETF creó un grupo de trabajo llamado NEMO, de Network Mobility, encargado de extender las soluciones de movilidad de terminales para el soporte de la movilidad de redes en IPv6. La movilidad de redes tiene interesantes aplicaciones como el acceso a Internet desde medios de transporte colectivos o la conexión a Internet de redes de área personal. En este artículo se describirán las distintas propuestas para el soporte de movilidad de redes en IPv6, incluyendo los trabajos que en este terreno se están llevando a cabo en el proyecto europeo DAIDALOS (Designing Advanced network Interfaces for the Delivery and Administration of Location independent, Optimised personal Services). El artículo se organiza como sigue: en la sección 2 se explicarán las aplicaciones de la movilidad de redes, las dificultades para conseguir dicha movilidad en redes IPv6, y la NEMO: movilidad de redes en IPv6 Resumen: en la actualidad, los usuarios solicitan el acceso a Internet en escenarios cada vez más heterogéneos. Particularmente ha surgido como necesidad el poder acceder a Internet desde plataformas móviles como pueden ser trenes, autobuses, o aviones. En el seno del IETF (Internet Engineering Task Force) se ha formado el grupo de trabajo NEMO (NEtwork MObility Working Group) que tiene como objetivo el proponer mecanismos que permitan gestionar la movilidad de una red como un todo, permitiendo que vaya cambiando su punto de conexión a una infraestructura fija basada en IP (Internet Protocol), sin que con ello se interrumpan las comunicaciones ya establecidas. En este artículo se describe la solución básica para el soporte de movilidad en redes IPv6 (Internet Protocol version 6) desarrollada por el grupo NEMO y se analizan sus limitaciones. Asimismo se presentan las diversas aportaciones a la problemática de movilidad de redes desarrolladas en el marco del proyecto europeo DAIDALOS (Designing Advanced network Interfaces for the Delivery and Administration of Location independent, Optimised personal Services). Palabras clave: DAIDALOS, movilidad de redes, movilidad IP, Mobile IPv6, optimización de rutas. Autores Carlos Jesús Bernardos Cano está estudiando el doctorado en Tecnologías de las Comunicaciones en la Universidad Carlos III de Madrid. Es Ingeniero de Telecomunicación por la misma universidad,en la cual es profesor ayudante desde Ha estado involucrado en proyectos de investigación internacionales relacionados con redes de 4ª Generación, como por ejemplo IST MOBY DICK y actualmente IST DAIDALOS. Sus líneas de investigación actuales se centran en protocolos de movilidad basados en IP. Ignacio Soto Campos es Ingeniero de Telecomunicación por la Universidad de Vigo en 1993, y Doctor Ingeniero de Telecomunicación por la misma universidad en el año Ha sido profesor contratado en la E.T.S.I. de Telecomunicación de la Universidad de Valladolid desde 1993 hasta En 1999 se incorporó a la Universidad Carlos III de Madrid donde actualmente es Profesor Titular de Universidad dentro del Departamento de Ingeniería Telemática. Entre sus líneas de investigación se encuentran la movilidad en redes de comunicaciones, las redes inalámbricas, y las redes de altas prestaciones. En estas líneas ha participado en distintos proyectos de investigación nacionales y europeos. Cuenta con numerosas publicaciones en revistas y congresos, tanto nacionales como internacionales. María Calderón Pastor es Profesora Titular en el Depto. de Ingeniería Telemática de la Universidad Carlos III de Madrid. En 1991 recibió el título de Ingeniero en Informática y en 1996 el titulo de Doctor en Informática, ambos por la Universidad Politécnica de Madrid (UPM). Ha publicado en relevantes revistas y conferencias más de 20 artículos en distintos temas de comunicaciones avanzadas, tales como protocolos de multipunto fiable, redes programables y movilidad en IPv6. Ha estado involucrada en diferentes proyectos de investigación tanto nacionales como internacionales. Su investigación actual se centra en protocolos avanzados en Internet, en particular en movilidad de redes en IPv6 y en redes sin infraestructura. Dirk von Hugo recibió los títulos de licenciado y doctor en Física Aplicada por Technische Hochschule de Darmstadt (Alemania), en 1984 y 1989 respectivamente. Trabaja actualmente en T-Systems International GmbH, Technology Centre Darmstadt (Alemania) como experto en el campo de comunicaciones móviles inalámbricas. Sus intereses principales son las comunicaciones radio terrestres y por satélite, especialmente en aspectos de la interfaz aire y la arquitectura de red. Ha participado en varios proyectos de investigación nacionales alemanes y europeos, y actualmente trabaja en investigación de mecanismos de provisión de movilidad en niveles L2/L3 y en aspectos de convergencia de redes fijas y móviles. Emmanuel Riou recibió el título de Licenciado en Informática por la EPITA (Ecole pour l informatique et les Techniques Avancées) en En ese mismo año entró en Centro de Investigación de Motorola (CRM) en París, como miembro del Edge Mobile Networking Lab (EMNL). Sus intereses incluyen la gestión de la movilidad de dispositivos en IPv4 e IPv6 y especialmente aquellos aspectos relacionados con la movilidad de una red IP completa. solución básica que el grupo NEMO ha desarrollado para proporcionarla; en la sec- ción 3 describiremos las limitaciones de la solución básica para proporcionar movilidad de redes en IPv6; la sección 4 analiza en detalle el tratamiento de la movilidad de redes en el proyecto europeo DAIDALOS; terminaremos con la sección 5, en la que se indican las conclusiones del trabajo y se destacan cuáles pueden ser las direcciones novática / upgrade nº 174 marzo-abril

37 IPv6 - Más que un protocolo Figura 1. Escenario de red móvil. en las que vayan las soluciones para redes móviles en IPv6. 2. Movilidad de redes en IPv6 Las redes IP no fueron pensadas para entornos de movilidad. Tanto en IPv4 como en IPv6, las direcciones IP cumplen dos papeles. Por un lado son un localizador que indica, en base a un sistema de encaminamiento, cómo llegar al terminal que la está usando. El sistema de encaminamiento mantiene información de cómo llegar a conjuntos de direcciones que comparten un prefijo de red. Esta agregación de direcciones en el sistema de encaminamiento sirve para garantizar su escalabilidad. Pero por otro lado, las direcciones IP también actúan como parte de los identificadores de los puntos extremos de una comunicación y los niveles superiores usan los identificadores de los dos extremos de una comunicación para identificarla. Este doble papel de las direcciones IP impone restricciones a la movilidad, pues al mover un terminal de una parte de la red (una subred IP) a otra, querríamos por un lado mantener la dirección IP asociada al terminal que se mueve (a una de sus interfaces de red) para no cambiar el identificador que los niveles superiores están usando en sus sesiones (comunicaciones) abiertas, pero por otro lado necesitamos cambiar la dirección IP para utilizar una que sea topológicamente correcta para la nueva localización del terminal en la red y que permita así al sistema de encaminamiento llegar a él. El problema de movilidad de terminales en redes IP lleva bastante tiempo en estudio dentro del IETF y existen soluciones a nivel IP tanto para IPv4 [1] como para IPv6 [2] que permiten la movilidad de terminales manteniendo abiertas la sesiones que el terminal tuviese establecidas. Estas soluciones incluso están siendo completadas con propuestas para mejorar la eficiencia de la solución general, en particular en situaciones de micromovilidad [3][4]. El tema de la movilidad de terminales en redes IP ha sido recientemente analizado en [5]. El soporte de la movilidad de terminales en redes IP es un primer paso para adaptar estas redes a las necesidades de los usuarios en este terreno. Pero existe también la necesidad de soportar el movimiento de toda una red que cambia su punto de acceso a la infraestructura fija, manteniendo las sesiones de todos los dispositivos que están en la red: es lo que se conoce con el nombre de movilidad de redes IP. En este caso la red móvil contará al menos con un router que se conecte a la infraestructura fija y a través de él obtendrán la conectividad hacia el exterior los dispositivos de la red móvil (figura 1). La solución de movilidad de terminales en redes IP por sí sola no soporta la movilidad de redes. Por ello se creó el grupo NEMO del IETF [6] que está estudiando soluciones a nivel IP para soportar movilidad de redes en redes IPv6. En la terminología que usa el grupo NEMO [7] a un router que da conectividad a la red móvil se le denomina Mobile Router (Router Móvil o MR). Los dispositivos pertenecientes a la red móvil y que obtienen la conectividad a través del MR se denominan Mobile Network Node (Nodo de la Red Móvil o MNN) y pueden ser de varios tipos: Local Fixed Node (Nodo Local Fijo o LFN) que es un nodo que no tiene software específico de movilidad; Local Mobile Node (Nodo Móvil Local o LMN) que es un nodo que implementa el protocolo de movilidad IP de terminales y tiene su red hogar en la red móvil; y Visiting Mobile Node (Nodo Móvil Visitante o VMN) que es un nodo que implementa el protocolo de movilidad de terminales, tiene su red hogar fuera de la red móvil y está visitando la red móvil. Existen numerosas aplicaciones de la movilidad de redes; algunos ejemplos son el acceso a Internet en: Medios de transporte colectivos. Es decir, que los usuarios de trenes, aviones, barcos, etc. puedan subir con sus propios terminales (portátiles, teléfonos, PDAs o Personal Digital Assistants, etc.) y obtener acceso a Internet a través del MR proporcionado por el medio de transporte, que es el que se encargará de la conectividad con la infraestructura fija. Redes Personales. Los dispositivos electrónicos que los usuarios pueden llegar a llevar encima: PDAs, cámaras de fotos, etc. pueden obtener conectividad a través de un teléfono móvil que actuaría como MR de la red personal. 38 novática / upgrade nº 174 marzo-abril 2005

38 IPv6 - Más que un protocolo Las redes IP no fueron pensadas para entornos de movilidad Redes de sensores en un vehículo. Los sensores podrían controlar múltiples aspectos del funcionamiento del vehículo y su interacción con el entorno, y comunicarse con el exterior a través de un MR. El primer paso para el grupo NEMO ha consistido en desarrollar una solución básica al problema de la movilidad de redes en IPv6, extendiendo la solución para movilidad de terminales en IPv6 (MIPv6) lo mínimo necesario para poder conseguir que la solución valiese para la movilidad de redes. Sin embargo, la solución debía ser lo suficientemente flexible como para tratar con distintas configuraciones de redes móviles, en particular, redes formadas por varias subredes, es decir la red móvil tiene más routers además del MR; y anidamiento de redes móviles, es decir, una red móvil que está dando acceso a la infraestructura fija a otras redes móviles. Un ejemplo de aplicación de esto último es un usuario que entra en un vehículo con su red de área personal (red móvil 1) y esa red se une, a través de un MR por ejemplo una PDA con acceso WiFi (Wireless Fidelity), a la red del vehículo (red móvil 2) que a su vez se une a la infraestructura fija de la red. La solución básica (figura 2) para el soporte de movilidad de redes en IPv6 [8] es conceptualmente similar a la de movilidad de terminales. Se basa en la creación de un túnel bi-direccional entre el MR y su Home Agent (Agente del Hogar o HA). El HA está situado en la red hogar de la red móvil, es decir en un punto donde el direccionamiento de la red móvil es correcto topológicamente. Todo el tráfico destinado a la red móvil llega a su HA, que lo envía por el túnel hacia el MR. El MR elimina la cabecera del túnel y reenvía el tráfico hacia su destinatario dentro de la red móvil. El tráfico que sale de la red móvil es enviado por el MR a través del túnel hacia el HA, el HA elimina la cabecera del túnel y reenvía los paquetes hacia su destino. El MR es el encargado de detectar el movimiento de la red móvil. La forma básica de hacerlo es mediante el mismo procedimiento que los terminales en la solución de MIPv6, es decir, escuchando Router Advertisements en la interfaz que une el MR a la infraestructura. También utiliza los Router Advertisement recibidos para configurar una dirección topológicamente correcta en el punto donde se ha unido a la infraestructura, esta dirección (Care-of Address) es el extremo del túnel en el MR. Para informar al HA de que la red móvil se ha movido, el MR envía un mensaje de registro al HA. El procedimiento de registro es idéntico al de MIPv6 y, por lo tanto, se usa un mensaje de Binding Update protegido con IPsec ESP (Secure Internet Protocol Encapsulating Security Paylodad). La única modificación es que se utiliza un bit de información en la cabecera del mensaje que permite indicar que el registro es de una red, lo Internet MR HA IPv6-in-IPv6 bidirectional tunnel Home Network CN Visited Network HA AR CN: Correspondent Node AR: Access Router MR: Mobile Router HA: Home Agent MNN: Mobile Network Node MR MNN Figura 2. Funcionamiento del protocolo básico de soporte de movilidad de redes. novática / upgrade nº 174 marzo-abril

39 IPv6 - Más que un protocolo Home Network 2 Internet Home Network 1 HA 2 HA 1 Visited Network CN MR 1 HA 1 IPv6-in-IPv6 bidirectional tunnel AR MR 1 MR 2 HA 2 IPv6-in-IPv6 bidirectional tunnel CN: Correspondent Node AR: Access Router MR : Mobile Router HA: Home Agent MNN: Mobile Network Node MR 2 Mobile network 1 MNN Mobile Network 2 Figura 3. Funcionamiento del protocolo básico de soporte de movilidad de redes con anidamiento. cual indica al HA que no debe reenviar el tráfico solo de la Home Address del MR sino de todo el prefijo de la red móvil (Mobile Network Prefix o MNP). Existen varias formas para que el HA averigüe el MNP: configuración estática, incluyéndolo en una opción del Binding Update, o ejecutando un protocolo de encaminamiento dinámico con el MR a través del túnel. 3. Limitaciones de la solución básica para la movilidad de redes en IPv6 La solución básica para el soporte de movilidad de redes (figura figura 2) 2 obliga a que, siempre que la red móvil esté fuera de su red hogar, todo el tráfico con destino a un nodo de la red móvil tenga que pasar por su HA y ser reenviado a la red móvil por el túnel establecido entre el MR y el HA. El mismo trayecto, pero en sentido inverso, es seguido por el tráfico originado en la red móvil. Esta configuración, conocida como encaminamiento triangular, impone ciertas ineficiencias tanto en latencia como en caudal, que pueden no ser aceptables para algunas aplicaciones. Estos problemas de rendimiento se ven amplificados en el caso de que la red móvil esté anidada (figura 3) 3 pues el tráfico pasará por todos los HAs involucrados (tantos como redes móviles atravesadas), problema conocido como encaminamiento pinball. Adicionalmente, los paquetes, en el camino entre el último HA y el primer MR, tendrán tantas cabeceras adicionales como redes atravesadas: cada MR atravesado desencapsulará una de las cabeceras. Ocurre lo mismo en el sentido inverso, siendo en este caso los HAs los que desencapsulan las cabeceras de los túneles (figura 3). El caso de un VMN (Visiting Mobile Node, un nodo que implementa el protocolo de movilidad IP de terminales) que está visitando una red móvil puede verse como un caso particular de red anidada. El tráfico con origen y destino en el VMN pasará tanto por el HA de dicho VMN como por el HA de la red móvil que está siendo visitada y será encapsulado en un doble túnel, situación análoga a una red móvil anidada con dos niveles de anidamiento. En redes móviles anidadas existe otra fuente de ineficiencias: los terminales de distintas redes móviles que pertenezcan al mismo anidamiento se comunican a través de sus HAs, cuando se comunicarían de forma mucho más eficiente directamente. Además, si hay algún problema en la comunicación con alguno de los HAs, la comunicación entre las redes móviles se interrumpiría y sin embargo podría continuar si se estuviesen comunicando de forma directa. Para entender la importancia de este escenario piénsese en dos personas que con sus respectivas redes de área personal entran en un mismo tren y quieren jugar entre ellas o intercambiarse documentos. Diversas propuestas conocidas genéricamente como soluciones de optimización de rutas (Route Optimisation, RO) tratan de extender la solución básica con el fin de mejorar los problemas de rendimiento descritos. Este conjunto de propuestas son muy diversas y cada una de ellas trata de dar solución a uno 40 novática / upgrade nº 174 marzo-abril 2005

40 o varios de los problemas planteados anteriormente. Una taxonomía de las soluciones de optimización de rutas que han sido propuestas puede encontrarse en [9]. 4. Movilidad de redes en DAIDALOS Las aportaciones al problema de la movilidad de redes dentro del proyecto Europeo DAIDALOS (IST ) [10] tienen tres vertientes distintas que serán desarrolladas a continuación Soporte Básico de NEMO y su modelado En un proyecto tan complejo como DAIDALOS, las actividades de modelado se consideran esenciales para garantizar el éxito de las fases de desarrollo y de integración. En DAIDALOS se ha escogido UML 2.0 (Unified Modelling Language) para modelar el protocolo básico de soporte de NEMO. La razón es que el lenguaje permite el modelado de protocolos y aplicaciones de tiempo IPv6 - Más que un protocolo Piénsese en dos personas que con sus respectivas redes de área personal entran en un mismo tren y quieren jugar entre ellas o intercambiarse documentos real gracias a un nuevo medio de comunicación entre clases denominada señal (signal). Básicamente, las señales permiten el envío asíncrono de mensajes entre clases activas, algo indispensable para el modelado de protocolos. Cada entidad del protocolo (ej. el MR) se modela usando una clase activa. Cada entidad de clase instancia una interfaz de protocolo que describe los mensajes del protocolo que la entidad puede recibir de otras clases. Estos mensajes se modelan usando señales. Una entidad puede también instanciar una interfaz IPC (InterProcess Communications, o comunicación entre procesos) que describe las IPCs públicas que la clase es capaz de manejar. Se utilizan cuatro diagramas UML para proporcionar diferentes vistas del sistema. Los diagramas de paquetes muestran las relaciones entre paquetes lo que permite la estructuración del modelo (paquetes de protocolos, entidades, e IPC). Los diagramas de clases se utilizan para describir las relaciones entre las entidades (asociaciones, herencia, ). Los diagramas de secuencia permiten describir escenarios que muestran la interacción entre los objetos (instanciación de las entidades), mientras que los diagramas de estado se utilizan para describir el comportamiento interno de cada entidad. La figura 4 muestra los aspectos clave del modelo, en concreto, una clase activa, dos interfaces, y dos señales con relaciones de herencia Optimización de rutas para flujos unicast La solución de optimización de rutas para flujos unicast de DAIDALOS se denomina MIRON (MIPv6 Route Optimization for NEMO) [11]. MIRON es un protocolo de Figure 4. Diagrama UML 2.0 del Protocolo de soporte básico de NEMO. novática / upgrade nº 174 marzo-abril

41 IPv6 - Más que un protocolo optimización de rutas que aborda dos de las problemáticas planteadas en la sección 3, por un lado el problema del encaminamiento triangular y, por otro, los múltiples túneles y el encaminamiento pinball que aparecen en las redes anidadas. El problema del encaminamiento triangular no es propio de las redes móviles sino que también se da en el caso de un terminal móvil operando con MIPv6. Para resolver esta ineficiencia, MIPv6 incluye un procedimiento de optimización de rutas: cuando se establece una comunicación entre un terminal móvil y cualquier otro sistema final de la red IP (denominado en terminología MIPv6 Correspondent Node, CN), inicialmente todo el tráfico, tanto de ida como de vuelta, pasa por el HA, sin embargo el terminal móvil puede iniciar un procedimiento de optimización de rutas, enviando directamente información de localización al CN (le envía mensajes de Binding Update, BU). Como ya se ha comentado, los BUs enviados al HA se protegen con IPsec, sin embargo este procedimiento no parece viable en el caso de BUs enviados a los CNs, ya que no parece razonable asumir que el terminal móvil va a disponer de una relación de confianza con todos los potenciales CNs de la red IP. De ahí que para el caso de los BUs enviados a los CNs se propone un procedimiento alternativo denominado Return Routability (RR). Este método se basa en verificar que el nodo alcanzable a través de la Home Address es el mismo que el nodo alcanzable a través de la Care-of Address (CoA). La aproximación seguida en MIRON para evitar el encaminamiento triangular en el caso de una red móvil es hacer que el MR actúe de proxy y realice el procedimiento de optimización de rutas con el CN en nombre de los nodos de la red móvil. De este modo el MR envía al CN información de localización que asocia la dirección del nodo de la red móvil con la CoA del MR. MIRON tiene como gran ventaja el permitir un rápido despliegue del soporte de optimización de rutas en una red IP como por ejemplo Internet. Esto se debe esencialmente a dos razones: la optimización de rutas es transparente a los nodos de la red, característica que tiene especial relevancia en el caso de nodos del tipo LFN (Local Fixed Node), nodos que no disponen de software específico de movilidad, y, segundo, permite utilizar el soporte para la optimización de rutas de MIPv6, ya disponible en los CNs. La solución propuesta para el caso de que la red móvil sea una red anidada consiste esencialmente en hacer que no sólo el MR-raíz (MR más alto en la jerarquía de redes anidadas) sino todos los MRs dispongan de una CoA que sea topológicamente correcta. Cumplen esta condición las direcciones de la subred a la que se ha conectado el MR-raíz (la red visitada por el MR-raíz). El disponer de una CoA topologicamente correcta permite a los MRs poder hacer el procedimiento de optimización de rutas descrito anteriormente en nombre de los nodos de su subred y, por lo tanto, la comunicación sería directa evitando el uso de túneles o paso por HAs, independientemente del nivel de anidamiento de la red móvil. Consecuentemente, MIRON habilita un mecanismo que permite al MR pedir una CoA que pertenezca al espacio de direcciones de la red visitada por el MR-raíz. Para saber cómo encaminar hacia estas CoAs dentro del anidamiento, los MRs aprenden de los mensajes de DHCP (Dynamic Host Configuration Protocol) que se usan para solicitar/delegar la CoA cuál es el siguiente salto hacia ella Soporte multipunto Para cursar tráfico multicast (multipunto) en redes móviles, el MR puede usar el túnel bi-direccional (BT) entre el HA y la CoA que el MR ha configurado en la red visitada. Alternativamente se puede realizar una suscripción remota (RS, Remote Subscription) al grupo multicast en la red visitada tal como se describe en MIPv6 [2]. Con respecto al tráfico multicast hacia y desde las redes móviles, la aproximación mediante BT puede ser ineficiente por el encaminamiento triangular, la pérdida de la naturaleza multicast del flujo y la escalabilidad limitada. Por otro lado, la principal desventaja de la aproximación mediante RS para servicios multicast con fuente o destino la red móvil, es que requiere una reconstrucción frecuente del árbol multicast, especialmente si la fuente del tráfico se está moviendo rápido, resultando en latencias altas y gran sobrecarga en el tráfico. La aproximación considerada en el proyecto DAIDALOS consiste en la combinación de ambos métodos, dependiendo de parámetros actualizados del entorno y la comunicación. Cuando un nodo de una red móvil se suscribe a un grupo multicast, o el nodo es fuente de tráfico multicast, el MR reenvía la solicitud de suscripción o el tráfico hacia el HA utilizando el protocolo MLD (Multicast Listener Discovery) [12]. Como consecuencia, el tráfico de datos correspondiente o los mensajes de control de grupos, se reenvían desde el HA hacia el MR. Esta funcionalidad de proxy del HA es descrita en [13]. En el caso de movilidad reducida de la red móvil (detectada como velocidad de handovers --cambio de CoA-- baja), el MR inicia el encaminamiento del tráfico multicast a través del punto de acceso remoto haciendo una suscripción remota. Las simulaciones indican las ventajas de esta aproximación y se está desarrollando una implementación en Linux-2.6. En las futuras fases del proyecto está prevista la introducción de un agente multicast intermedio. 5. Conclusiones En este artículo se han presentado diversos escenarios que motivan la necesidad de mecanismos que permitan la movilidad de una red como un todo. También se ha presentando la solución básica para el soporte de movilidad de redes en IPv6 desarrollada por el grupo NEMO del IETF. Esta solución tiene como principal ventaja su simplicidad y que la introducción del protocolo impone cambios en un número relativamente pequeño de dispositivos de red. Requiere una relativamente pequeña actualización de los HA operando MIPv6 e introduce unos dispositivos nuevos (los MRs, al menos uno por red móvil) que son los que habilitan la movilidad de la red como un todo. Estas características simplifican el despliegue del protocolo. Asimismo se han presentado las principales limitaciones e ineficiencias de dicha solución básica y se ha motivado la necesidad de investigar en protocolos de optimización de rutas que puedan coexistir con los protocolos ya desplegados en las redes IP. Por último se ha presentando el trabajo en movilidad de redes que se está realizando en el proyecto DAIDALOS. En este marco se ha desarrollado MIRON, un protocolo de optimización de rutas para flujos unicast en el que el MR realiza la optimización de rutas en nombre de los nodos de la red móvil, lo que hace que puedan beneficiarse de las funciones de optimización nodos de la red móvil que no tienen soporte de movilidad (software específico de movilidad). Al mismo tiempo MIRON no impone ninguna modificación en los CNs, característica que simplifica enormemente su despliegue en redes IP tales como Internet. También en este entorno se propone una solución para el tratamiento del tráfico multicast, solución que utiliza dos métodos actuando de la forma más adecuada a las características de velocidad de movimiento de la red móvil. Existe otro tipo de soluciones para la optimización de rutas que requieran modifi- 42 novática / upgrade nº 174 marzo-abril 2005

42 IPv6 - Más que un protocolo MIRON tiene como gran ventaja el permitir un rápido despliegue del soporte de optimización de rutas en una red IP como por ejemplo Internet caciones en los terminales de la red móvil y en los CNs, y que están empezando a estudiarse [9]. Estas soluciones pueden tratar más sencillamente algunos escenarios pero a costa de modificaciones en un gran número de nodos. Una combinación de ambos tipos de soluciones es previsible al menos inicialmente. Agradecimientos Los tres primeros autores quieren agradecer a Marcelo Bagnulo sus múltiples ideas y comentarios. El trabajo descrito en este artículo está basado en resultados del proyecto Europeo IST FP6 DAIDALOS [10]. DAIDALOS recibe financiación para la investigación del Sexto Programa Marco de la Comunidad Europea. Aparte de esto, la Comisión Europea no tiene ninguna responsabilidad del contenido de este artículo. La información del mismo se proporciona tal y como está y no se ofrece garantía alguna de que la información se adecue a ningún propósito particular. El lector por lo tanto utiliza la información bajo su propio riesgo y responsabilidad. Referencias [1] C. Perkins, editor. "IP Mobility Support for IPv4", RFC 3344, agosto [2] D. Johnson, C. Perkins, J. Arkko. "Mobility Support in IPv6", RFC 3775, junio [3] Rajeev Koodli, editor. "Fast Handovers for Mobile IPv6", IETF Internet draft, draft-ietf-mipshopfast-mipv6-03.txt, trabajo en curso,ooctubre [4] Hesham Soliman, Claude Catelluccia, Karim El Malki, Ludovic Bellier. "Hierarchical Mobile IPv6 mobility management (HMIPv6)", IETF Internet draft, draft-ietf-mipshop-hmipv6-04.txt, diciembre [5] J. Mangues, A. Cabellos, R. Serral, J. Domingo, A. Gómez, T. de Miguel, M. Bagnulo, A. García. Movilidad IP: macromovilidad, micromovilidad, calidad de servicio y seguridad, Novática 167 (enero-febrero 2004) pp. 28:32; UPGRADE, Vol. V, issue no. 1, February 2004, pp [6] IETF Network Mobility (NEMO) Working Group. < [7] T. Ernst, H-Y. Lach. "Network Mobility Support Terminology", IETF Internet draft, draft-ietf-nemoterminology-02.txt, octubre [8] Vijay Devarapalli, Ryuji Wakikawa, Alexandru Petrescu, Pascal Thubert. "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, enero [9] C. Ng, P. Thubert, H. Ohnishi, E. Paik. "Taxonomy of Route Optimization models in the NEMO Context", IETF Internet draft, draft-thubertnemo-ro-taxonomy-03.txt, octubre [10] DAIDALOS, sitio web. < [11] C. J.Bernardos, M. Bagnulo, M. Calderón. MIRON: MIPv6 Route Optimization for NEMO, 4 th IEEE Workshop on Applications and Services in Wireless Networks, agosto [12] R. Vida, L. Costa (editores). "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, junio [13] C Janneteau et al. "IPv6 Multicast for Mobile Networks with MLD-Proxy", IETF Internet Draft, draft-janneteau-nemo-multicast-mldproxy-00.txt, trabajo en curso, abril novática / upgrade nº 174 marzo-abril

43 IPv6 - Más que un protocolo Jordi Palet Martínez CEO/CTO, Consulintel <jordi.palet@consulintel.es> Estado de IPv6 en el mundo y los Grupos de Trabajo de IPv6 1. Introducción En las Conclusiones de la Presidencia [1] del Consejo Europeo de Barcelona, bajo la Presidencia Española, en marzo de 2002, IPv6 (Internet Protocol version 6) fue considerado como uno de los pilares para la competitividad europea, y nuevamente resaltado, junto con Banda Ancha y 3G (tercera generación), en el plan e-europe 2005, aprobado en la cumbre de Sevilla, en junio de Este hecho, de gran relevancia, es resultado de una estrategia política bien definida, desarrollada desde el año 2001 a través de diferentes tipos de acciones, que han sido básicamente de dos tipos: Grupos de Trabajo (Task Forces) para favorecer la implantación de IPv6, denominados IPv6 Task Forces, y un conjunto de proyectos de Investigación y Desarrollo en diversos aspectos relacionados con IPv6 y tecnologías afines. Los proyectos europeos, financiados por la Comisión Europea, permiten la participación de entidades industriales de todo tipo (grandes, pequeñas y medianas empresas), así como de entidades de investigación (universidades y otras). La financiación de la Comisión generalmente es del 100% para las universidades y del 50% para el resto de las organizaciones. El primer Grupo de Trabajo de IPv6 fue el europeo, al que le siguieron grupos análogos en diversos países y regiones. Las siguientes secciones detallan la historia de estos Grupos de Trabajo de IPv6 y algunos de los resultados obtenidos. 2. El Grupo de Trabajo europeo de IPv6 El Grupo de Trabajo europeo de IPv6 (EC IPv6 TF), en lo que se ha denominado 1ª fase, fue lanzado el 23 de abril de 2001, como resultado de una llamada abierta a la industria realizada por el entonces Comisario Europeo de Empresas, Erkki Liikanen. Como hemos indicado anteriormente, el objetivo básico era promover el despliegue de IPv6 en Europa por medio del análisis de su impacto en diversos sectores y acelerar la capacitación de las diversas partes implicadas de modo que se incremente su competitividad. Se establecieron cuatro grupos de trabajo que en enero de 2002 produjeron sus infor- Resumen: este artículo proporciona una visión general del estado actual de IPv6 (Internet Protocol version 6) en Europa y el resto del mundo. En él se introducen las diversas actividades que han sido iniciadas por los Grupos de Trabajo (Task Forces) de IPv6, principalmente en Europa, así como las actividades realizadas por otras entidades análogas en el resto del mundo. En diversos documentos y presentaciones públicas disponibles en los sitios web de dichos Grupos de Trabajo, < y < está disponible una perspectiva más completa. Palabras Clave: Comité Ejecutivo del Grupo de Trabajo de IPv6, despliegue de IPv6, Europa, Grupos de Trabajo internacionales de IPv6, Grupos de Trabajo nacionales de IPv6, IPv6. Autor Jordi Palet Martínez es actualmente CEO/CTO de la empresa Consulintel, Madrid, y ha desarrollado su actividad profesional en los últimos 20 años alrededor de ordenadores, redes y telecomunicaciones. Antes de su actual función estuvo ligado a tareas técnicas, marketing y dirección de producto en diversas compañías. Se involucró en el IPv6 Forum desde su fundación, como responsable del grupo de trabajo de Educación y Divulgación, y miembro del Directorado Técnico. En 2003 fue galardonado con el IPv6 Forum Internet Pioneer Award. Es también miembro del comité del IPv6 Logo, responsable del programa «IPv6 Ready». Participa activamente en organizaciones sin ánimo de lucro para la divulgación de tecnologías y Telecomunicaciones/Internet. Asimismo es miembro activo del Grupo de Trabajo europeo de IPv6, del español y del Comité Ejecutivo del Grupo de Trabajo de IPv6. Coopera con diversos Grupos de Trabajo de IPv6 y con otras entidades análogas en todo el mundo. Ha estado involucrado en diversos proyectos de Investigación y Desarrollo, siendo responsable del diseño, preparación de las propuestas y su posterior negociación con la CE, de los proyectos Euro6IX y 6POWER, de los cuales es además su coordinador científico. Ha estado directamente involucrado en otros proyectos europeos, incluyendo 6QM, Eurov6, IPv6 TF-SC, 6LINK y el IPv6 Cluster. mes finales: Infraestructuras de Internet [2]. Movilidad inalámbrica [3]. Aplicaciones de siguiente generación [4]. Plataforma de pruebas [5]. Un equipo editorial redactó un documento a modo de resumen y conclusiones, denominado "Main IPv6 Task Force Report" [6], que fue enviado a la Comisión Europea para su consideración. Como consecuencia directa de este documento final, se produjo un Comunicado de la Comisión Europea al Consejo y Parlamento Europeos, "Next Generation Internet Priorities for action in migration to the new Internet protocol IPv6" [7], hecho publico en Febrero de Además, como ya hemos indicado en la introducción, en las Conclusiones de la Presidenciadel Consejo Europeo de Barcelona, bajo la Presidencia Española, en marzo de 2002, IPv6 fue considerado como uno de los pilares para la competitividad Europea, y nuevamente resaltado, junto con Banda Ancha y 3G, en el plan e-europe 2005, aprobado en la cumbre de Sevilla, en junio de Una de las acciones indicadas en estos documentos fue la continuación del trabajo del EC IPv6 TF, en lo que sería su 2ª fase, así como el establecimiento de iniciativas similares en cada uno de los estados miembros. IPv6 ya no es una utopía, está aquí y está despertando en todos los campos de negocio, con un progreso lento pero firme, y todas las iniciativas nacionales, internacionales y regionales han sido claves para esta evolución La coordinación del Grupo de Trabajo de IPv6 Para facilitar la coordinación del Grupo de Trabajo europeo de IPv6 (EC IPv6 TF) y de actividades análogas nacionales y regionales, la Comisión Europea decidió en mayo de 2004 financiar un pequeño proyecto, el "IPv6 Task Force Steering Committee" (Comité Ejecutivo del Grupo de Trabajo de IPv6 de 2004, también conocido por sus siglas IPv6 TF-SC). Este proyecto asumió la misión de continuar el trabajo inicial, consiguiendo en la 2ª fase la creación de Grupos de Trabajo nacionales europeos de IPv6, desde septiembre de 2002 hasta mayo de En la 1ª fase del EC IPv6 TF varios miembros del proyecto ha- 44 novática / upgrade nº 174 marzo-abril 2005

44 IPv6 - Más que un protocolo El primer Grupo de Trabajo de IPv6 fue el europeo Figura 1. Relaciones de pertenencia entre el IPv6 TF-SC y otras actividades. bían liderado de forma voluntaria y no financiada diversos grupos de trabajo. La idea original del proyecto fue la de aportar una pequeña ayuda financiera a los miembros del IPv6 TF-SC, para permitir la continuación de su trabajo, aunque el proyecto dispuso de muy limitados recursos. La finalización del proyecto "IPv6 Task Force Steering Committee" marca el final de la 2ª fase y el comienzo de una 3ª, con un renovado proyecto del Comité Ejecutivo. El trabajo voluntario de los miembros de los Grupos de Trabajo nacionales de IPv6 en Europa, junto con el de los participantes del proyecto "IPv6 Task Force Steering Committee", y la amplia y extensa cooperación internacional de todo el mundo, han tenido un importante efecto en la activación del despliegue de IPv6, que está comenzando a ser una realidad en todos los sectores industriales. Se han realizado una serie de acciones con la finalidad de mejorar la coordinación y la continuación del trabajo realizado en la 2ª fase del EC IPv6 TF. Con la asistencia de la Comisión, el IPv6 TF-SC invitó a la participación de aquellos sectores económicos e industriales aún no representados y que pueden verse afectados por IPv6, incluyendo representantes de entidades relacionadas con IPv6 tanto regionales como nacionales de Estados candidatos a pertenecer a la Unión Europea. El IPv6 TF-SC ha trabajado junto con otras iniciativas nacionales e internacionales equivalentes, con importantes logros hacia el establecimiento del esfuerzo de un Grupo de Trabajo global de IPv Los orígenes Es esencial una clara diferenciación entre los diversos participantes en el entorno IPv6 europeo. Los siguientes párrafos tienen como objetivo la clarificación de la relación entre el EC IPv6 TF), el IPv6 TF-SC, los Grupos de Trabajo nacionales de IPv6 y los Comités nacionales, el IPv6 Cluster y los proyectos IPv6 europeos. El EC IPv6 TF es un equipo de unos 70 miembros, que fundamentalmente interactúan por medio de una lista de correo dedicada, pero que también se han reunido en diversas ocasiones en los plenarios de los Grupos de Trabajo nacionales europeos. Originalmente la intención fue que el EC IPv6 TF debía monitorizar e implementar las acciones resultantes de la 1ª fase. Estaba previsto que esto fuera llevado a cabo por parte de los miembros de dicho grupo (no por parte del proyecto IPv6 TF-SC), durante la existencia del proyecto y con la asistencia de éste. Sin embargo, sólo unos pocos participantes del EC IPv6 TF continuaron participando activamente después de la primera fase y, por tanto, el trabajo terminó recayendo sobre el propio IPv6 TF-SC. Aun cuando la idea original era la continuación del trabajo del EU IPv6 TF, este punto de vista tuvo que ser ligeramente modificado a favor de activar más participantes a niveles nacionales. Los miembros del IPv6 TF-SC han dedicado un importante esfuerzo a divulgar la idea del EU IPv6 TF y otras actividades de IPv6 en Europa. Los Grupos de Trabajo regionales de IPv6 tienen sus propios Comités Ejecutivos y colaboran con las actividades del proyecto. El objetivo fue la coordinación de los siguientes pasos con los Grupos de Trabajo nacionales. Dado que estos no tienen financiación, la carga de trabajo ha de ser limitada y depende fundamentalmente del entusiasmo y voluntad de los participantes. Esto requiere un importante esfuerzo, pero los resultados son visibles y prometedores, con alguna cobertura en prensa, una red de expertos e ideas para trabajo en común. La idea es que al final se realicen ciertas acciones comunes de coordinación y despliegue de IPv6. El diálogo entre el EU IPv6 TF, los Comités Ejecutivos nacionales y los proyectos de IPv6 europeos es más efectivo para incrementar el empuje que tomar iniciativas individuales. La figura 1 resume los niveles de interacción entre las diferentes entidades. El IST IPv6 Cluster (y 6LINK, el proyecto que lo soporta) es una actividad europea diferente, que facilita el intercambio de conocimiento entre los diversos proyectos IPv6 europeos, buscando sinergias, previniendo la duplicación en los esfuerzos y ayudando a descubrir temas no cubiertos. Hay una interacción directa con el IPv6 Cluster y novática / upgrade nº 174 marzo-abril

45 IPv6 - Más que un protocolo Figura 2. Relaciones de pertenencia entre el IPv6 TF-SC y otras actividades. además, diversos participantes del IPv6 TF- SC son también miembros activos de 6LINK, por lo que se mejora la coordinación. Igualmente ocurre con los grandes proyectos IPv6. Las compañías participantes en el proyecto IPv6 TF-SC son también miembros activos de varios proyectos europeos de IPv6. BT, Consulintel, DT y la Universidad de Southampton (Reino Unido) son participantes de Euro6IX; la Universidad de Southampton es también participante de 6NET. Otros proyectos actuales y ya terminados también incluyen participación de los miembros del IPv6 TF-SC, por ejemplo Moby Dick, 6INIT, 6WINIT. En el sitio web IST IPv6 Cluster [8] existe una relación completa de todos los proyectos. La figura 2 muestra las relaciones de pertenencia entre las diversas actividades europeas y el IPv6 TF-SC. 3. Resultados de la coordinación El trabajo del EC IPv6 TF en la 1ª y 2ª fase ha sido continuado activamente en los Grupos de Trabajo regionales de IPv6. Algunos miembros del EC IPv6 TF son de hecho también miembros activos en sus respectivos Grupos nacionales y regionales. Sin embargo, éste es un proceso continuo, tendente a mantener activas las redes de expertos del EC IPv6 TF en cada posible ocasión, para permitir la continuación del debate acerca de los pasos siguientes. A través de los Grupos de Trabajo nacionales de IPv6, la membresía ha crecido desde aproximadamente 70 participantes en la reunión plenaria del 2003 en Bruselas, a más de 400 compañías (aproximadamente 500 individuos), por lo que la actividad de los Grupos de Trabajo europeos de IPv6 ha adquirido relevancia en los últimos meses. El nivel de interés se puede valorar también a través del incremento del número de visitas a los sitios web de IPv6 europeos (incluyendo la web del EC IPv6 TF y del IPv6 Cluster), que han llegado a triplicar sus visitas en los últimos 9 meses. La lista de participantes y compañías se encuentra en los diferentes sitios web de los diversos Grupos de Trabajo nacionales de IPv6, o a través de las personas de contacto de cada uno de ellos. Además, más de individuos, representando 500 compañías o entidades, están involucradas mundialmente en las actividades de los Grupos de Trabajo de IPv6 regionales o iniciativas similares Los Grupos de Trabajo nacionales de IPv6 en Europa Los siguientes Grupos de Trabajo nacionales de IPv6 han sido creados en Europa como resultado de esta coordinación: España (mayo de 2002), Finlandia (agosto de 2002), Francia (septiembre de 2002), Luxemburgo (noviembre de 2002), Reino Unido (enero de 2003), Portugal (febrero de 2003), Suiza (abril de 2003), Alemania (abril de 2003), Dinamarca (mayo de 2003), Suecia (mayo de 2003), Bélgica (junio de 2003), Italia (octubre de 2003), Austria (marzo de 2004), Irlanda (abril de 2004). Otros países, incluyendo Holanda, Noruega, Polonia, Grecia, Eslovaquia y Rusia, entre otros, seguirán el mismo proceso en los meses siguientes Resultados clave de los Grupos de Trabajo nacionales Aproximación y Misión Los diversos Grupos de Trabajo nacionales de IPv6 han utilizado aproximaciones similares. Muchos de ellos tienen una buena mezcla de participación industrial y académica. Tienen estatutos con objetivos tendentes a la introducción de IPv6 en la respectiva región o país. La mayoría de los miembros tienen contactos con agencias gubernamentales, incluso algunos han logrado apoyo directo (no financiero) de algún ministerio (caso de España y Francia). Otras agencias gubernamentales han sido proactivas en otros aspectos, o bien no están totalmente al corriente de las actividades del Grupo de Trabajo de IPv6. Un problema fundamental es que la actual situación económica reduce las posibilidades de obtener financiación para el soporte de las actividades de divulgación. En estos casos los Grupos de Trabajo de IPv6 pueden buscar sinergias con la promoción de otras tecnologías, como por ejemplo, la promoción de banda ancha. Debido al carácter voluntario de los Grupos de Trabajo nacionales de IPv6, el poder de los mismos depende de la disponibilidad de carga de trabajo de los participantes. Todos ellos tienen como uno de sus objetivos principales la divulgación y la implantación de IPv6, y por tanto la cohesión entre ellos es muy fuerte. Uno de los objetivos del IPv6 TF-SC ha sido la transmisión de información entre los planes nacionales para evitar la duplicación de trabajo entre ellos Alcanzando la masa crítica Una importante cuestión es la relativa a cómo atraer a más organizaciones/industrias y especialmente a los principales actores a cada una de los Grupos de Trabajo nacionales de IPv6. Las posibilidades para atraer a dichos actores dependen en gran medida de las actividades de los propios grupos y de sus conexiones. Donde hay una red fuerte de expertos, la situación del Grupo de Trabajo es generalmente mejor que donde sólo hay ingenieros con pocas posibilidades de incrementar su alcance. Algunos grupos han conseguido un importante impacto en la prensa. Habitualmente hay limitaciones en la visibilidad de los Grupos de Trabajo nacionales, dado que generalmente no disponen de re- 46 novática / upgrade nº 174 marzo-abril 2005

46 cursos financieros para actividades de divulgación y por tanto de los medios para dirigirse a comunidades más amplias. Ninguno de los grupos puede por tanto dirigirse a todas las industrias y, en cualquier caso, éste no parece ser un objetivo relevante. Algunos grupos han buscado la calidad de sus miembros y su predisposición a contribuir, en lugar de un número elevado de participantes silenciosos Los países de la ampliación de la EU Hasta ahora, el foco principal han sido los países con mayor impacto económico y aquellos donde había buenas posibilidades de alcanzar los objetivos. Ello implica que aún existe la necesidad de dirigirse a aquellos países donde no hay una actividad reconocida al respecto de IPv6. Los recursos para alcanzar este objetivo son muy limitados para el IPv6 TF-SC en este momento, y por tanto sería preciso soporte adicional para alcanzar este objetivo Evento "Global IPv6 Service Launch" Uno de los eventos clave que han sido organizados en cooperación con el EU IPv6 TF fue el "Global IPv6 Service Launch" [9], celebrado en Bruselas el de enero de 2004 (figura 3). 3 El evento fue financiado y auspiciado por la Comisión Europea, junto con los proyectos 6NET y Euro6IX, y algunas contribuciones de otros, incluido GÉANT. Su objetivo era influir en los responsables de políticas, expertos líderes y responsables de Figura 3. Logo del evento "Global IPv6 Service Launch". IPv6 - Más que un protocolo El foco principal han sido los países con mayor impacto económico Investigación, Industria y Negocios activos en el área de IPv6 y la investigación de redes de todo el mundo. El evento incluyó diversas demostraciones orientadas al usuario final, una conferencia de prensa, apariciones en el canal EuroNews y una ceremonia de inauguración virtual para celebrar la disponibilidad de conectividad Global con IPv6. Estuvieron presentes representantes de la Dirección de Informática (Telecomunicaciones y Redes) de la Comisión Europea, con la intención de prepararse para la adopción interna de IPv6, con el soporte del IPv6 TF-SC (figura 4). 4 Para más información, véase el informe completo "Report on the Global IPv6 Service Launch Event" [10]. 4. Puesta en común de los Grupos de Trabajo nacionales de IPv6 Tras el periodo inicial de puesta en marcha y habiendo alcanzado una masa crítica y representación razonables, el Task Force Europeo de IPv6 ha comenzado a poner en común los resultados de las diversas iniciativas, combinando los resultados propios de cada país para permitir la consecución del éxito global Logros Muchos de los Grupos de Trabajo nacionales de IPv6 han tenido éxito en: Divulgación y reuniones de trabajo. Establecimiento de diversos grupos con tareas concretas. Establecimiento de sitios web, ftp, listas de correo y los correspondientes archivos. Generación y difusión de notas de prensa y artículos. Participación de industrias clave, educación, grupos de investigación y gobierno. Redes Nacionales de Investigación y Educación conectadas a GÉANT con IPv6 (mayoritariamente de forma nativa), y oferta de servicios IPv6 a su comunidad. Pilotos en diversos sectores de negocio. En algunos casos, los Intercambiadores de Internet (Internet exchange, IX también conocidos como Puntos Neutros) han incorporado IPv6 o están en proceso de hacerlo. Sin embargo sólo un par de países ha implantado servicios IPv6 en el correspondiente NIC, o Network Information Center (por ejemplo, Francia con AFNIC, Association Française pour le Nommage Internet en Coopération), aunque varios lo han planificado. Sólo un reducido número de ISPs (Internet Service Providers, Proveedores de Servicio de Internet), en algunos países, ha comenzado sus ofertas comerciales de servicios IPv6, pero generalmente varios tienen planes concretos para comenzar dicho despliegue. Se espera que se alcance una importante base de clientes durante el Estado del despliegue de IPv6 en Europa y acciones precisas Como resultado de un encuentro en Milán (Italia), en octubre de 2003, y del trabajo e iniciativas desarrolladas por el EC IPv6 TF y los Grupos de Trabajo nacionales de IPv6 durante la primer mitad de la 2ª fase, se ha documentado la situación actual del despliegue de IPv6, y se ha actualizado la llamada a la acción, incluyendo una nota de prensa [11]. Este informe, "IPv6 Deployment Status in Europe and Required Actions", está públicamente disponible [12] y realiza una serie de recomendaciones para los países miembro de la Unión Europea (UE), la Comisión Europea (CE) y la industria. La prensa ha divulgado ampliamente este mensaje, incluyendo artículos y entrevistas a algunos de los actores clave [13] Desafíos Existe consenso acerca de los siguientes desafíos: Falta de compromiso oficial por parte de gobiernos. Falta de reconocimiento estratégico de la importancia de IPv6. Falta de nuevas aplicaciones con IPv6. Falta de modelos de negocio concretos. Falta de demanda por parte de clientes (los clientes quieren servicios, no protocolos). Falta de líderes industriales europeos. Falta de respuestas técnicas simples y claras. Falta de financiación para las actividades de los Grupos de Trabajo nacionales de IPv6. Falta de financiación para la 'ignición' de IPv6 en ISPs y en la industria en general. Falta de mediciones realistas del grado de despliegue de IPv6. Es también interesante observar que, en diversos países, muchos de los logros no han sido divulgados de forma generalizada, ni reconocidos por los medios. Por ejemplo, al menos en un país, diversas entidades publicas y privadas han confirmado que exigen IPv6 en sus nuevas políticas de aprovisiona- novática / upgrade nº 174 marzo-abril

47 IPv6 - Más que un protocolo Figura 4. El Comisario Erkki Liikanen en una ceremonia del evento "Global IPv6 Service Launch". miento; sin embargo, generalmente esto no ha sido publicitado suficientemente y ha pasado inadvertido. En muchos casos, las organizaciones no desean hacer públicos sus planes tecnológicos futuros. Uno de los más importantes fabricantes de routers tan sólo hizo público su soporte de IPv6 en su hoja de ruta con una antelación de tres meses al lanzamiento del código de producción, mientas otros han publicado de forma gratuita el código beta con muchos meses de anticipación. Por supuesto, ahora todos los grandes fabricantes de routers ofrecen soporte IPv6 de producción, pero el ejemplo anterior demuestra cómo la publicidad de los productos y servicios puede ocultar verdaderos progresos en los siguientes meses. Aunque el apoyo gubernamental ha sido evidente en la mayoría de los países para la puesta en marcha de los Grupos de Trabajo nacionales de IPv6, existe una falta de compromiso real (y financiero) que permita marcar el ritmo. Existen soluciones técnicas relativamente simples para activar IPv6 en las plataformas de servidores web más comunes (versiones actuales de Apache e IIS en Linux y Windows Server 2003), pero ninguno de los sitios web de la CE o sitios web gubernamentales europeos lo han activado hasta ahora. En cualquier caso, hay cierto progreso en este sentido en diversas entidades europeas y se esperan resultados visibles en pocos meses. Uno de los problemas en este caso es que dichos sitios web generalmente están externalizados y, por tanto, los cambios tecnológicos pueden conllevar cierta demora. La problemática de la externali-zación es muy amplia, afectando muchas organizaciones gubernamentales y del sector público (incluyendo servicios de educación y salud) Siguientes pasos En general, existe acuerdo unánime acerca de impulsar la siguientes actividades: Continuar y fortalecer el trabajo y la cooperación de los diversos Grupos de Trabajo de IPv6, definiendo recomendaciones nacionales y europeas. Centrarse en el despliegue de IPv6 y en las oportunidades de aplicaciones. Continuar las actividades de promoción y divulgación, comunicando las mejores prácticas. Actualización de los sitios web de los Grupos de Trabajo y creación de un portal IPv6 europeo. Promocionar la creación de un centro de excelencia, que puede ser un punto de referencia independiente para aquellos que deseen diseñar, construir, desarrollar o desplegar productos IPv6. Convencer a las organizaciones públicas y privadas para que demuestren su compromiso, requiriendo IPv6 en sus concursos. Preparar los sitios web clave para que sean accesibles con IPv6. Reunir más actores industriales potenciales (PYMEs, integradores, ISPs, WISPs o Wireless Internet Service Providers, etc.). Trabajar en ejemplos de "modelos de negocio". Estudiar un detallado plan de despliegue. 5. El Grupo de Trabajo español de IPv6 La iniciativa fue la respuesta a la petición del autor de este artículo al Ministerio de Ciencia y Tecnología, como consecuencia de las recomendaciones del EC IPv6 TF y el plan e- Europe El grupo fue constituido como un grupo de trabajo abierto, de duración limitada, sin entidad jurídica, soportado por el Ministerio de Ciencia y Tecnología, y siendo su objetivo fundamental la elaboración de un documento público con las acciones a ser tomadas por las diversas organizaciones para desplegar IPv6 en función de las necesidades del mercado español. Inicialmente se establecieron cinco grupos de trabajo: Infraestructuras fijas y móviles. Movilidad y nuevas tecnologías inalámbricas. Seguridad y privacidad. Aplicaciones de siguiente generación (incluyendo domótica, GRIDs, QoS, Multicast, ). Investigación, Desarrollo e Innovación. Cada grupo de trabajo fue requerido para identificar sus propios sectores objetivos, y a considerar no sólo aspectos técnicos, sino también y como mínimo: Implicaciones para la Sociedad de la Información. Motivaciones de negocio. Propuesta para actividades de despliegue y medición. Impacto en programas de Investigación, Desarrollo e Innovación. Se estableció un sitio web [14], así como las correspondientes listas de correo y una nota de prensa para divulgar la reunión inicial. Gran parte del trabajo se lleva a cabo a través de correo electrónico, pero también mediante reuniones, generalmente 3-4 por año. La reunión inicial, el 16 de mayo de 2002, contó con la asistencia de unos 180 profesionales. El Grupo de Trabajo español de IPv6 eligió inicialmente un Comité Ejecutivo que actuó como equipo coordinador, en el que el Ministerio de Ciencia y Tecnología ha participado activamente, e incluso ha facilitado las instalaciones para las reuniones. En abril de 2003, la 1ª fase del trabajo se dio por concluida, proporcionando las siguientes recomendaciones, que fueron presentadas durante el "Madrid 2003 Global IPv6 Summit" [15]: Incrementar la presencia de la industria y la comunidad académica española en proyectos nacionales, europeos e internacionales relacionados con IPv6. Favorecer la difusión y formación en IPv6 en la comunidad académica y empresarial española. 48 novática / upgrade nº 174 marzo-abril 2005