IPv6. el nuevo protocolo de Internet. La próxima generación de protocolos Internet: consecuencias para ABB. Revista ABB 1/2003

Transcripción

1 La próxima generación de protocolos Internet: consecuencias para ABB Niels D. Aakvaag, Nils A. Nordbotten v6 el nuevo protocolo de Internet Casi 30 años después de su presentación, el protocolo de Internet el conocido está a punto de sufrir su primera gran remodelación. Un nuevo protocolo, denominado v6, más potente y eficaz que su predecesor, ha sido elegido para el transporte de paquetes de información en la Internet del futuro. Aunque ABB no será ni debería serlo un importante actor en este campo, para nuestra compañía es importante seguir atentamente el desarrollo de esta nueva tecnología, conocer sus posibilidades y prepararse para adoptar el v6 en sus ofertas de productos. 30

2 Internet está entre nosotros desde hace casi 30 años, pero sol durante los últimos diez años hemos empezado a considerarla como una herramienta indispensable en nuestra vida. Hoy ha llegado a ser la portadora de información, la suministradora de servicios básicos de los que todos dependemos, tales como el correo electrónico, los datos de voz y las previsiones de Web, además de proporcionar una infraestructura esencial para la comunicación industrial. El estándar generalizado hoy en día para la transmisión de datos en Internet se conoce como Protocolo de Internet Versión 4, o v4. Ya con una antigüedad de 20 años, el protocolo v4 ha demostrado tener una gran flexibilidad. Su estructura ha hecho posible que nuevos protocolos operen conjuntamente con él v6 con todo detalle v6, Protocolo de Internet Versión 6, fue recomendado por los miembros de la Internet Engineering Task Force (IETF) en su encuentro de Toronto en En 1998, el núcleo de los Protocolos del v6 se convirtió en una propuesta de norma IETF. v6 es una nueva versión del protocolo de Internet () que ha sido diseñada como paso evolutivo de v4, la versión del protocolo de Internet en uso hoy en día. El protocolo Ipv6, que puede instalarse como una mejora normal de software en dispositivos conectados a Internet, puede interoperar con v4. Los usuarios podrán mejorar sus ordenadores centrales instalando v6 y los operadores de redes podrán desplegarlo en los encaminadores con una mínima coordinación entre ellos. V6 resuelve diversos problemas que se están produciendo con v4, tales como la limitación del número de direcciones disponibles, y ofrece mejoras en áreas tales como el encaminado y la configuración de redes. Se espera que el protocolo v6 vaya sustituyendo gradualmente al v4, aunque ambos coexistirán durante varios años en un periodo de transición. Se está desarrollando la implantación del protocolo v6 para muchos encaminadores y sistemas operativos de ordenadores centrales. Muchas aplicaciones normales de Internet ya funcionan con v6, muchas otras están empezando a hacerlo.. Si desea más información sobre v6 visite para suministrar servicios tales como soporte para tareas críticas en el tiempo, capacidad para dirigirse a personas en movimiento y aseguramiento de la comunicación, tareas para las cuales, en realidad, no se había diseñado Internet. Pero el tiempo no pasa en balde: el cambio de las pautas de comportamiento de los usuarios, y el aumento del tráfico están imponiendo nuevos requisitos a Internet. Qué tiene de nuevo v6? Revisión de la cabecera Comparar las cabeceras de los protocolos v6 [1] e v4 es un buen punto de partida para discutir las cualidades de la versión anterior 1. Las diferencias más obvias son el aumento de longitud de las direcciones en v6 y las modificaciones en los demás campos. Se han eliminado diversos campos definidos en v4 que han perdido gran parte de su utilidad. Se han eliminado, por ejemplo, el campo Longitud (la cabecera del v6 tiene siempre la misma longitud), todos los campos de alguna forma asociados a la fragmentación (el protocolo v6 no permite la fragmentación en la red, sino sol en los nodos terminales), la Suma de Comprobación y el campo Opcional. Este último campo estaba incluido en el v4 para disponer en la misma cabecera de información sobre todas las funciones imaginables. En el v6 se ha resuelto este problema con la posibilidad de extensión de cabeceras, de modo que a la cabecera actual se añade una nueva solo cuando es necesaria. Es de esperar que estos cambios aumenten notablemente la velocidad de procesamiento. Espacio de direcciones El mayor impulso para el desarrollo del v6 proviene de la creciente carencia de direcciones Internet; con el campo de dirección de 32 bits en el v4, solo eran posibles cerca de cuatro mil de millones de direcciones. El problema se agrava por la poca eficiencia del espacio de direcciones disponible y por la irregular distribución del mismo. Los Estados Unidos, por ejemplo, ocupan una parte desproporcionadamente grande del espacio disponible, mientras que Asia se está quedando sin direcciones. El remedio, hasta ahora, ha sido utilizar las llamadas Network Address Translations, o NATs, donde numerosas máquinas se ocultan detrás de una puerta de Internet. Sin embargo, en este caso se producen al menos dos problemas: de un lado, las máquinas ocultas detrás de una puerta NAT no disponen de direcciones globales exclusivas; el segundo problema, relacionado con el primero, es que el uso de las puertas NAT complica la seguridad de un extremo a otro. El v6 resolverá este problema ampliando el campo de dirección a 128 bits, lo cual significará, en la práctica, disponer de un número ilimitado de direcciones globalmente exclusivas. Autoconfiguración En el protocolo v4 las direcciones se establecen manualmente o utilizando un protocolo conocido como DHCP. El v6, por el contrario, permite autoconfigurar las direcciones, lo que simplifica enormemente la gestión de la red. La dirección autogenerada del v6 combina un identificador de red local y un identificador generado por el nodo en la forma enchufar y utilizar. Este procedimiento automatizado simplifica el mantenimiento de redes de grandes dimensiones con dispositivos sencillos, tales como sensores y actuadores, y prepara el camino para la implantación a gran escala de la tecnología de Internet en entornos industriales. De hecho, este es un requisito absolutamente necesario si algún día se va a hacer realidad el desarrollo hasta las bombillas. Soporte para el tráfico en tiempo real La cabecera del protocolor v6 contiene dos campos destinados específicamente a las aplicaciones en tiempo real: Clase de Tráfico y Etiqueta de Flujo. Clase de Tráfico es un campo de 8 bits que permite a los encaminadores distinguir paquetes de diferentes clases o prioridades. Una de las posibilidades de este campo, similar a Tipo de Servicio de v4, es utilizarlo en combinación con DiffServ (Servicios Diferenciados). Aunque hasta ahora no se ha especificado el uso exacto de este campo, ya se están realizando estudios para precisar su funcionamiento. 31

3 1 4 bits Version Cabeceras correspondientes a v6 e v4. Se ha aumentado la longitud de las direcciones de v6 (abajo) y se han eliminado los campos definidos en v4 (arriba) que han perdido utilidad. 4 bits IHL 16 bits Identification 8 bits Type of service 8 bits TTL 8 bits Protocol 16 bits Header checksum 32 bits Source address 32 bits Destination address 4 bits Flags 16 bits total length 12 bits Fragment offset de su paradero. Cuando un nodo se identifica y establece en una red externa, un módulo de software, conocido con el nombre de agente en el extranjero (FA), proporciona una dirección provisional e informa de ella a la red doméstica o al agente doméstico (HA). Con v6, el agente en el extranjero ha sido llevado al nodo móvil como parte del propio protocolo. Esto permite, en principio, el libre movimiento de todos los nodos habilitados por v6, independientemente del software que esté instalado en las redes visitadas. (Debe tenerse en cuenta que con v4 también es posible una movilidad total si se utiliza un software, disponible comercialmente, que soporta el estándar de movilidad. Esta red ha sido instalada en el Centro de Investigaciones de Noruega, donde facilita la movilidad interna a los nodos seleccionados). 4bits Version 8 bits Traffic class 16 bits Payload length Etiqueta de Flujo es una etiqueta de 20 bits que identifica los flujos. La especificación de v6 describe el flujo como una secuencia de paquetes enviados desde una fuente concreta hasta un destino concreto (simple o múltiple), para los cuales la fuente desea un tratamiento especial, que en este caso consiste en obtener un servicio de calidad sin fallos o un servicio en tiempo real. Las etiquetas de flujo pueden, por ejemplo, utilizarse conjuntamente con un protocolo N bits Optional and padding 128 bits Source address 128 bits Destination address 20 bits Flow label 8 bits Next header 8 bits Hop limit de reserva de recursos, como es el RSVP. La Etiqueta de Flujo parece tener un gran potencial, pero su utilidad tampoco está muy clara. Soporte para mejorar la movilidad El marco definido por el protocolo v4 facilita la movilidad de los nodos. El concepto se basa en la idea de que cada nodo dispone de una red doméstica que realiza un seguimiento de los lugares en los que se encuentran, es decir, Mayor seguridad La arquitectura de seguridad del Protocolo de Internet, conocida como SEC, proporciona las herramientas (encriptado, autentificación y negociación de claves) necesarias para crear redes privadas virtuales (VPN) y permitir así que los empleados trabajen desde sus casas (o cualquier otro lugar) sin poner en peligro la seguridad. Mientras que en el protocolo v4 la SEC se encuentra disponible como extensión, en el v6 es parte integrante del protocolo, lo cual garantiza su disponibilidad en todos los nodos v6. Recientemente, sin embargo, se han despertado algunas dudas sobre la seguridad en Mv6, la parte de v6 que reúne los aspectos de la movilidad. En caso de fallo de la seguridad, un usuario mal intencionado podría desviar el tráfico de un nodo. Actualmente, el comité de normalización está investigando este importante problema. Mejores medios para el doble soporte A medida que se generaliza la celebración on-line de seminarios, conferencias y otras aplicaciones análogas será mayor la necesidad de doble soporte si se mantiene la anchura de banda de la red. En v4, la duplicidad de servicio se basa en el protocolo IGMP (Internet Group Management Protocol), que especifica sus propios tipos de mensaje. 32

4 El equivalente del IGMP en v6, el llamado MLD (Multicast Listener Discovery), está basado en el ICMPv6, que debe ser implantado en cada uno de los nodos v6. Aunque el v4 ya facilita el soporte doble, esto supone una importante mejora del mismo. Por eso es necesario decir que esta funcionalidad básica, que en v6 es parte del protocolo mismo, ya existe como complemento en v4. 2 Redes de prueba aisladas, una de ellas con los en bucle (arriba) y la otra con paso de los paquetes por un encaminador (abajo). Estas redes, extremadamente sencillas, se utilizan para establecer las prestaciones del equipo v6 actual. Consecuencias para ABB Algunos atributos clave del protocolo v6 tienen un claro interés para ABB. Está claro que, a medida que Internet se vaya acercando al nivel de los dispositivos, la configuración y duplicación irán adquiriendo una gran importancia. Además, dado que con toda probabilidad se podrá concretar en un sistema un gran número de nodos, la extensa gama de direcciones da cierta garantía de que la escasez de direcciones ha pasado a la Historia. Finalmente, el soporte de tiempo real mejorado puede ser de gran interés dado que los requisitos de las aplicaciones industriales en tiempo real suelen ser muy rigurosos. Para evaluar el protocolo ABB comprobó en primer lugar las prestaciones del mismo en términos de retardo en el sistema. La mejora de la estructura de cabecera hace esperar una reducción del retardo. Por eso, con el fin de analizar las posibles implicaciones de v6 para ABB, consideramos una situación típica con autoconfiguración de una red de sensores sin hilos y grandes redes de buses de campo con anchura de banda relativamente pequeña, como EIB o LON. Evaluación de las prestaciones El objetivo inicial era determinar las prestaciones del equipo v6 actual. Las redes de prueba aisladas la primera con ordenadores personales en bucle y la segunda con encaminador a través del cual pasan los paquetes fueron preparadas en el laboratorio del Centro de Investigaciones de ABB en Noruega 2. Los utilizaban el sistema operativo Linux y software residente que implementaba un sistema v6. El encaminador era un Cisco 2514 con IOS mejorado para soportar la funcionalidad básica del v6. Dado que estas redes son extremadamente sencillas resulta fácil determinar en qué medida contribuye cada componente de la red al retardo observado. Se midió el tiempo de disparo total (RTT), tanto para v4 como para v6, con las dos configuraciones de red mostradas, con el fin de comparar el retardo o latencia del sistema en el software. Los resultados muestran que los dos protocolos funcionan de forma semejante cuando los dos están en bucle 1, aunque el v4 presenta una latencia ligeramente menor que el v6. Ambos sistemas son implementaciones de software y la diferencia entre las prestaciones puede explicarse por el hecho de que la solución v6 es un producto reciente, mientras que el v4 ha sido perfeccionado a lo largo de los años. Router Cuando los paquetes pasan por el encaminador, sin embargo, el RTT medido para el v6 era significativamente mayor que en el v4. Esta diferencia se debe a que el encaminador utiliza un hardware optimizado para el envío de paquetes v4, mientras que en v6 el envío de paquetes se sigue realizando en el software. La única conclusión posible a partir de estas observaciones es que las versiones actuales de v6 todavía se encuentran por debajo de lo óptimo y por tanto no reflejan todas las posibilidades de dicho protocolo. v6 es un protocolo de altas prestaciones con cabecera diseñada para la rapidez de procesamiento rápido, pero la solución de software utilizada no funciona tan bien como el hardware en el caso de v4. 33

5 Sensores alámbricos e inalámbricos y redes Consideremos el caso de una fábrica con una línea de montaje en la que continuamente entran y salen nuevos elementos. Es posible que a los sensores o etiquetas unidos a las partes móviles haya que asignarles una dirección cuando penetran en la zona cubierta por las estaciones base. En este caso podrían ser interesantes las propiedades de autoconfiguración del v6, ya que permiten asignar a los nuevos elementos una nueva dirección, que puede garantizarse que es única. En v4, sin embargo, tradicionalmente se utiliza el protocolo DHCP. Próximamente se presentará un estándar Si en los nodos se necesita movilidad, más seguridad o doble servicio, siempre existe la posibilidad de utilizar las partes correspondientes de la especificación del protocolo v4. En rigor, el v6 no es necesario (aunque seguramente es útil), ya que todos los elementos de la red se encuentran bajo nuestro control. Obviamente hay que preguntarse si disponer de estas opciones compensa las desventajas. Esta es una cuescapaz de generar automáticamente de direcciones locales de enlace en v4. En este escenario, sin embargo, cada nuevo módulo que se implemente deberá comprobar con los demás nodos de la red la posible existencia de colisión entre las direcciones. Pero para detectar las colisiones se deberían activar todos los nodos, lo que supondría consumir valiosa energía de las baterías de los sensores. La implantación del v6, por tanto, tendría la ventaja de reducir el consumo de energía de los sensores, que podrían permanecer en estado durmiente. Supongamos ahora que la red inalámbrica se implementa en la forma piconet o scatternet Bluetooth [2]. Aceptando que no se producen ni retransmisiones ni colisiones es posible establecer que el consumo medio de energía en cada sensor por causa de la detección de colisiones es una función lineal de la velocidad de entrada. Se ha observado también que la energía adicional consumida por la detección de colisiones de direcciones es relativamente pequeña. En conclusión, las ventajas del v6 en este caso particular son limitadas. En la parte alámbrica de la red puede haber fácilmente varios miles de nodos, como sucede en las aplicaciones para la edificación. En general, aunque no necesariamente, estos nodos son dispositivos baratos, con poca capacidad de procesamiento y una memoria limitada. Para este tipo de dispositivos los factores más importantes son la complejidad computacional y las necesidades de memoria. Como ya hemos visto, el protocolo v6 tiene algunas características propias que son opcionales en el v4, como el soporte de la movilidad y seguridad. Con bastante seguridad, la inclusión de estas características aumentará las dimensiones del sistema, precisamente lo que se trata de evitar. Por otra parte, la simplificación de la estructura de cabecera reduce la carga en el procesador. Otro importante aspecto en las redes con pequeña anchura de banda es la dimensión de los paquetes por transmitir. Las cabeceras del v6 son de 50 bytes, las del v4 de 20 bytes. Este aumento del número de bytes no tiene mayor importancia para las redes de gran capacidad, pero en los sistemas con anchura de banda limitada, como es el EIB (que funciona a 9,6 kbps), con pequeñas cargas útiles, este aumento es importante, ya que los sistemas se saturan rápidamente. 34

6 tión abierta, que depende de la aplicación, pero la respuesta es dudosa en circunstancias normales. En ocasiones, los requisitos de tiempo real de los nodos pueden ser bastante estrictos, del orden de los 20 ms. El v6 presta más atención al tiempo real, lo que podría ser una gran ayuda, pero en la sección anterior ya hemos indicado que el uso exacto de esta capacidad sigue estando irresuelto. Cabe la posibilidad de que llegue a ser un activo importante del v6 pero aún es demasiado pronto para asegurarlo. Únicamente las futuras especificaciones (y el uso real) decidirán si este es realmente el caso. p Probabilidad (p) de tiempos de disparo total (en ms, eje horizontal), medidos para v4 (negro) e v6 (azul) con las dos configuraciones de red de la figura 2. La autoconfiguración es necesaria en los casos en que el usuario ha de hacer frente a un gran número de nodos, de modo que esta característica del v6 tendría un valor claro. Pero, como ya hemos dicho, la autoconfiguración para el v4 se resolverá próximamente con una especificación de este protocolo, si bien causando determinados problemas de tráfico en la red. El argumento fundamental en favor de introducir el v6 es la ampliación de la gama de direcciones. Si es necesario que nuestros nodos dispongan de direcciones exclusivas a nivel global, dentro de unos años ya no tendremos otra opción, pues simplemente ya no habrá direcciones libres. p En resumen, del ejemplo estudiado no se deducen argumentos claros para inclinarse por introducir el v6, aparte de la ampliación de la gama de direcciones y la mejora de las prestaciones en tiempo real. Pero es que incluso estos argumentos pueden ser inseguros, ya que normalmente es posible ocultar la red detrás de una puerta NAT y, además, el tratamiento de las fuentes de tiempo real está sometido a incertidumbres. Conclusiones de ABB El estudio realizado por ABB acerca de las implicaciones del protocolo v6 muestra que sus prestaciones en términos de latencia son inferiores a las del La gráfica superior presenta aproximadamente los mismos resultados con los dos en bucle. Los resultados, muy diferentes, de la configuración con encaminador (abajo) se deben al hardware optimizado para enviar paquetes v4, mientras que los paquetes v6 se envían en el software. v4, pero previsiblemente mejorarán a medida de que vaya madurando su implantación. La mayor parte de las ventajas funcionales del v6 también puede conseguirse con el v4 en sistemas con nodos totalmente controlados. Este es frecuentemente el caso en las aplicaciones de automatización de fábricas. En redes más heterogéneas hay mejores razones para utilizar el v6. La ventaja más importante del protocolo v6 es la amplia gama de direcciones posibles, lo que basta para asegurar su utilización a gran escala en numerosas aplicaciones. Niels D. Aakvaag ABB AS Noruega niels.aakvaag@no.abb.com Nils A. Nordbotten University of Oslo Noruega nilsno@ifi.uio.no [1] S. Deering, R. Hinden: Internet Protocol Version 6 Specification. RFC 2460, December [2] Bluetooth specification, version 1.1. More information on Bluetooth can be found at 35