1. Introducción

1. Introducción

Desde que surgió la idea de conectar dos ordenadores entre sí, se fueron presentando algunas necesidades de tipo funcional para poder llevar a cabo esta soñada tarea que revolucionaría el mundo de las comunicaciones. Pero antes de conectar los dos ordenadores había que definir una serie de normas, a modo de lenguaje universal para que todo los ordenadores se entendieran entre sí. De este modo surgieron los primeros estándares para desarrollar un protocolo para la comunicación de ordenadores, de cuya evolución surgió el actual IP.

En el año 1973, la DARPA inició un programa de investigación de tecnologías de comunicación entre redes de distintas características, que se basaba en la transmisión de paquetes de información. Para comunicar las redes se desarrollaron varios protocolos: el protocolo de Internet y los protocolos de control de transmisión. Posteriormente estos protocolos se englobaron en el conjunto de protocolos TCP/IP.

En el año 1980, se incluyó en el UNIX 4.2 de BERKELEY, lo que ayudó a su distribución por todo el mundo, ya que este sistema operativo se distribuía libremente por las Universidades de todo el mundo y fue lo que ha contribuido de una forma notable a su actual desarrollo. En el año 1983 nació Internet, que también utiliza este protocolo para la interconexión de redes.

Además de su inteligente forma de distribución, algunos motivos como la independencia del fabricante, su capacidad de soportar múltiples tecnologías y su capacidad de funcionar en máquinas de cualquier tamaño, ayudaron al desarrollo de este protocolo que es el estándar en Estados Unidos desde el año 1983. Cuando este protocolo se desarrolló se marcaron una serie de objetivos como la independencia de la tecnología usada en la conexión a bajo nivel y arquitectura del ordenador, lo que permite la conectividad universal a través de la red.

Cuando la versión actual de este protocolo se desarrolló, no se tuvieron en cuenta todas las posibilidades reales que este nuevo medio de comunicación podía ofrecer, por otra parte muchas de ellas eran inimaginables en aquellos días, por lo que resulta lógico que no se tuvieran en cuenta. En las fechas actuales, es tal el desarrollo de Internet en el mundo que la antigua versión de IP se está quedando pequeña y para determinadas actividades y servicios resulta bastante pobre, por lo que se estaba haciendo necesario una revisión de este protocolo para no limitar las enormes posibilidades que la conexión global del planeta nos puede ofrecer. Es por este motivo por lo que se pensó hacer una nueva versión de este protocolo, para adaptarse a los nuevos tiempos: “Renovarse o morir” y una vez que se vieron todas las posibilidades (y el dinero) que ofrecía Internet, resultaba muy duro tener que morir.

En los sucesivos apartados de este trabajo se muestran los principales aspectos de Ipv6 y cuáles son las características que hacen de él un protocolo compacto, robusto que le convierten en el protocolo estándar del nivel de red para un futuro a corto plazo, mejorando infinitamente a su predecesor.

2. Antecedentes

La capa de red en Internet es un conjunto de subredes o AS (Autonomous System o Sistema Autónomo) interconectados. Lo que mantiene unida la red de Internet es el protocolo de Internet, IP. A diferencia de los anteriores protocolos existentes este se diseñó para soportar una interconexión de redes. Su trabajo es proporcionar un transporte de datagramas adecuado desde el origen a su destino sin importar el nivel de red que exista por debajo, aunque sean muy diferentes las redes interconectadas.

2.1. Evolución del protocolo IP.

2.1.1. Estructura de los datagramas IP

El datagrama IP más general consta de una cabecera de 20 bytes, a veces con una parte opcional, y una parte de texto. El formato de cabecera es:

• El campo versión lleva a cabo el registro para ver a quien pertenece el datagrama. Dado que la longitud de la cabecera no es fija se incluye el campo IHL, para indicar la longitud en palabras de 32 bits.

• El campo tipo de servicio TOS: permite al host indicar a la subred que tipo de servicio quiere. Indicando con ello la confiabilidad y la velocidad. Por ejemplo para transferencia de datos de vídeo o audio interesa una entrega de datos rápida más que precisa. Para la transferencia de archivos es más importante, la transmisión sin errores que una transmisión rápida.

El mismo campo contiene un campo de precedencia; tres indicadores: D, T, R, y dos bits no usados. Este campo es una prioridad de 0 a 7. Los tres bits indicadores permiten especificar el retardo (delay), el rendimiento (throughput), confiabilidad (reliability). Estos campos permiten a los enrutadores o routers tomar decisiones sobre enlace por satélite de alto rendimiento y alto retardo, o escoger bajo rendimiento y poco retardo. Actualmente los enrutadores ignoran este campo.

• El campo longitud total: nos indica la longitud de todo el datagrama; tanto la cabecera como los datos. La longitud máxima es de 65.535 bytes.

• El campo identificación: es necesario para identificar a qué datagrama pertenece el fragmento recién llegado. Todos los fragmentos de un datagrama llevan el mismo identificador, en el caso que el datagrama haya sufrido fragmentación.

• El campo Flags (banderas): está relacionado con la fragmentación, sabemos si lo que recibimos es un trozo de un datagrama o todo uno. Consta de tres bytes, uno de ellos es DF (don´t fragment) es una orden que indica a los enrutadores que no fragmenten, porque el destino es incapaz de juntar y aunarlas. El bit DF el transmisor sabe que llegará en una pieza.

• El campo desplazamiento de fragmento: Indica que lugar ocupa dentro de la fragmentación. Todos los fragmentos del datagrama deben tener un múltiplo de 8 bytes, excepto el último, es una unidad de fragmentación elemental.

• El TTL (time to live): es un contador que sirve para la vida del paquete, permite una vida alrededor de 255 segundos debe disminuirse en cada salto, en la práctica cuenta los saltos. Cuando el contador llega a 0, el paquete se descarta y se envía un mensaje a la estación. Se evita la explosión de paquetes, de esta manera.

• El campo identificador de protocolo: indica la capa de transporte a la que debe entregarse. TCP es una posibilidad pero también está UDP, etc.

• Secuencia de verificación de cabecera: verifica tan sólo la cabecera, es posible detectar errores generadas por ejemplo por palabras de memoria erróneas en un router. La secuencia de verificación de cabecera debe comprobarse en cada salto debido que algunos campos como el TTL y para detectar el fallo.

• La dirección de origen y destino: indica el número de red y el número de la estación.

• El campo de opciones: Se creó para que se incluyeran mejoras, permitir probar nuevas ideas y asignación de bits de cabecera. Las opciones son de longitud variable, se rellena a veces para que sea múltiplo de 4 bytes. Las opciones actuales ofrecidas son:

Opción	Descripción
Seguridad	El grado de importancia del datagrama
Encaminamiento estricto desde el origen	Indica el camino que se va a seguir.
Encaminamiento libre desde el origen	Lista de los routers por los que pasa.
Registrar o grabar la ruta	Cada router pone su dirección IP.
Marcar el tiempo	Cada router pone su dirIP. y su marca de tiempo.

La opción seguridad indica como de secreta es la información, por ejemplo visto en clase que interesa que ciertos datos desde EEUU lleguen a la India sin pasar por Irak.

La opción de encaminamiento estricto desde el origen da la trayectoria que sigue el paquete, es un conjunto de dir_IP. Se utiliza para especificar una ruta en concreto sobre las demás posibles debido que es un tráfico de emergencia por ejemplo, a veces se utiliza para hacer medidas en el tiempo.

La opción encaminamiento libre desde el origen; el paquete debe pasar pon unos puntos en específicos pero se le permite para o pasar por otros routers. Esto es muy útil cuando las consideraciones políticas o económicas obligan a pasar por ciertos países.

La opción registrar ruta indica a los routers que añadan su dirección su IP al campo opción, esto permite a los administradores encontrar fallos en los algoritmos de encaminamiento. Al establecer primeramente ARPANET, ningún paquete pasaba por más de 9 routers, por lo que 40 bytes eran más que suficientes para el campo de opción. Actualmente es muy poco.

La marca de tiempo es como la opción registrar la ruta sólo que aquí se pide que además de registrar la dir_IP del router, se añada la marca del tiempo en el momento que le llega el paquete, es un número de 32 bits. Esta opción también es usada para la detección de fallos en los algoritmos de encaminamiento.

2.1.2. IPv6

Debido al auge sufrido en Internet en los últimos años, el IPv4 quedó obsoleto a causa de ciertos problemas. IETF (Internet Engineering Task Force) comenzó a trabajar en 1990 en una versión nueva del IP, debido principalmente a que el número de direcciones disponibles en el IPv4 era pequeño a causa de la gran demanda.

Los objetivos que debería cumplir el nuevo protocolo eran:

Manejar miles de millones de estaciones o host, aún con espacio de direcciones suficiente.

Reducir las tablas de encaminamiento.

Simplificación de la cabecera para que el protocolo sea más sencillo y se pueda procesar más rápido.

Proporcionar una mayor seguridad de los datos, la cual, la anterior versión, no podía garantizar a este nivel. Para ello se utiliza una verificación de autenticidad y confidencialidad.

Prestar más atención al TOS especialmente con datos en tiempo real.

Ayudar al multicast, permitiendo la especificación de alcances.

Posibilitar que una estación sea móvil sin que con ello tenga que cambiar de dirección.

Permitir que el protocolo evolucione.

Permita pruebas a escala global, 6bone será comentado más adelante.

QoS en internet: servicios integrados y diferenciados.

El nuevo protocolo podría convivir con la antigua versión.

Para conseguir un resultado óptimo IETF pidió proyectos en el RFC 1550. Una propuesta fue ejecutar el TCP sobre CLNP, que con sus direcciones de 160 bits habría solucionado el problema del acotamiento de las direcciones. De entre todas las propuestas se escogió en 1993 la de Deering y Francis, llamada ahora SIPP (Simple Internet Protocol Plus, protocolo simple de Internet mejorado, y se le dio la asignación de IPv6(el IPv5 estaba siendo usado como protocolo experimental de flujos en el tiempo real).

El IPv6 cumple los objetivos impuestos bastante bien, pero en general no es compatible con el IPv4 pero lo es con los demás protocolos de Internet, tales como: TCP, UDP en el caso de RIP, ICMP, IGMP, OSPF, BGP Y DNS.

El IPv6 tiene direcciones más grandes que el IPv4, son de 16 bytes de longitud, lo que resolvía el problema entonces existente, así prácticamente se daba una capacidad ilimitada de direcciones IP.

Con el IPv6 se consigue una simplificación en la cabecera, que contiene solamente 7 campos frente a los 13 del IPv4. Este cambio permite a los routers procesar los paquetes mucho más rápido que con antiguas versiones, mejorando así el rendimiento.

Se mejora también las opciones, campos que antes eran obligatorios ahora son opcionales, es más sencillo para los routers haciendo caso omiso a las que no van dirigidos a ellos.

IPv6 mejora la seguridad, de los datos, asegurando un tráfico seguro e importante. Las verificaciones de autenticidad y la confidencialidad permiten esta mejora.

Se presta más atención al TOS (type of service) en esta nueva versión. El IPv4 tiene un campo de 8 bits dedicado a este asunto, pero el crecimiento esperado en el tráfico de multimedia requiere mucho más.

2.1.3. Evolución de cabecera de IPv4 a IPv6

Vamos a ver un resumen y comentarios entre las diferencias entre las cabeceras del IPv4 y IPv6. El campo IHL se quitó porque la cabecera del IPv6 tiene una longitud fija.

El campo de protocolo se retiró porque el campo de siguiente cabecera indica lo que sigue a la última cabecera de IP, por ejemplo un segmento de UDP o TCP.

Se retiraron todos los campos relacionados con la fragmentación, puesto que el IPv6 tiene un enfoque distinto frente a la fragmentación. Cuando una estación manda un paquete de IPv6 demasiado grande, en lugar de fragmentarlo, el router que es capaz de reenviarlo devuelve un mensaje de error. Este mensaje indica a la estación que divida todos los paquetes antes de enviarlos a ese destino. Es más eficiente que la estación origen fragmente los paquetes y los mande ya con un tamaño correcto, que hacer que el router los fragmente sobre la marcha.

Por último el campo de secuencia de verificación de trama desaparece porque su cálculo disminuye las prestaciones para la cual fue creada; con las redes fiables de hoy y el hecho que la capa de enlace y la de transporte tengan ya sus propios campos respectivos a esta materia, la utilización de otra secuencia de verificación de trama SVT, su comprobación empeoraba los costos y prestaciones.

Al tener en cuenta todo los problemas que debería solventar este protocolo, y considerando todas estas características ha resultado un protocolo de capa de red compacto y robusto. Por tanto la meta del IPv6 es la de conseguir una mayor rapidez y flexibilidad con bastante espacio de direcciones, y todos estos requisitos se han cumplido.

2.2. Problemas despertados por la evolución del IPv6

Muchas de las decisiones tomadas para el IPv6 fueron tema de fuertes diferencias y controversias dentro del mundo de las telecomunicaciones.

Se ha comentado ya, lo relacionado a la decisión de aumentar la capacidad de longitud de las direcciones, a 16 bytes, de longitud fija, la cual dio lugar a discusiones.

El límite de saltos también fue tema de pelea, unos querían meter un límite de 255 saltos, eso implicaba usar un campo de 8 bits, era un error, pues actualmente las trayectorias más comunes apenas llegan a los 32 saltos, se descarta que en el futuro aumente el número de saltos, pues empeoraría la capacidad de servicio y aumentaría la probabilidad de error en la transmisión. Para todas estas disputas hubo una solución, que era que todos los campos llevasen argumentos que les permitieran aumentar en tamaño si fuese necesario, lo que llevaría a una cabecera aumentada en gran medida. También debe observarse que el campo número saltos fue creado para que los paquetes no vaguen durante demasiado tiempo por ahí, por tanto 65.535 saltos expuestos eran demasiados saltos, debido a que cada vez se hacen enlaces a mayor distancia, con lo que comunicarse de un país a otro muy alejados entre si, apenas llevará media docena de saltos. Si se requieren más de 125 saltos para llegar de origen a destino a sus pasarelas internacionales, es que algo está mal, los de 8 bits ganaron esta partida.

Otro motivo de discordia fue el tamaño del paquete, la comunidad de las supercomputadoras quería paquetes de más 64 Kbytes. Ya que cuando transmitían no querían ser interrumpidas sus transferencias cada 64 KB, pero tenía un argumento en contra, el tamaño demasiado grande de los paquetes podría traer problemas derivados de su excesiva longitud. Por ejemplo paquetes de tamaño de 1MB en una línea de transmisión de 1.5Mbps, el paquete bloqueará la línea durante 5 segundos, con lo que produciría un retardo notorio en la transmisión. Se llegó a la conclusión de que el tamaño de los paquetes fuera de 64KB para paquetes normales, pero utilizando la cabecera de extensión de salto por salto, se pueden construir “jumbogramas” o supertramas. (Ver cabecera de opciones salto a salto).

Una tercera disputa fue la supresión de la SVT del IPv5, para algunos representaba un suicidio informático. Quitarlo puede aumentar ciertamente la rapidez de procesado, pero pueden ocurrir por ello eventos inesperados en la red. El argumento en contra de la SVT fue que a cualquier aplicación que verdaderamente le importa la integridad de sus datos, de todos modos tiene que tener una SVT para el nivel de transporte, por lo que tener otra en el IP (además de tener otra en el nivel de enlace) era excesivo. Además se comprueba que SVT en el IPv4 era demasiado costoso su comprobación. El bando en contra de la SVT ganó la partida y no tiene.

Las estaciones móviles fueron tema también de discusión. Si una computadora portátil volara a otro lado del mundo, ¿podría utilizar en el destino la misma dir_IP de IPv6 ó debe de utilizar otros métodos diferentes?. Las estaciones móviles crean asimetría en el sistema de encaminamiento, por lo que una computadora pequeña puede escuchar a un router estacionario grande pero que dicho router no le llegue la señal débil de la computadora. Para ello algunas personas propusieron un reconocimiento explícito de las estaciones móviles en el IPv6, pero no se llevó a cabo.

Era evidente la necesidad de un protocolo que proporcionase un nivel de seguridad superior al que ofrecía IPv4. Existían serias controversias en cómo implementar este servicio debido a los problemas que plantean las leyes en contra del cifrado en ciertos países. Otros puntos de discusión eran qué algoritmos utilizar y si había que implementarlo en el nivel de red o en un nivel superior. El resultado final fue la solución aportada por IPv6 que veremos con mayor profundidad en el apartado dedicado a la seguridad.

Donde no hubo problemas fue en el tránsito del IPv4 a IPv6, ya que todos eran conscientes que ese paso no podría ser inmediato, se hicieron “islas” en un principio para el IPv6 comunicadas por túneles (iniciativa 6bone). A medida que vaya aumentando el uso del IPv6 de irán incrementando esas islas. Tarde o temprano todas esas islas se habrán integrado e Internet habrá sido convertida por completo al formato de IPv6, pero debido a la extensión del IPv4 deberán convivir ambas durante algún tiempo.

3. IPV6

El protocolo IP en su versión 6 (llamado IPv6 o IPng), surge como un sucesor de la versión 4, que pronto se quedará corta debido al crecimiento exponencial de Internet, como ya hemos explicado en el apartado anterior.

A continuación volvemos a recordar los cambios que introduce IPv6 respecto a su anterior versión IPv4, de forma resumida:

1.- Expansión de las capacidades de direccionamiento.

IPv6 incrementa el tamaño de las direcciones de 32 bits (IPv4) a 128 bits, para soportar más niveles en la jerarquía de direccionamiento, un número mayor de nodos direccionables, y un sistema de autoconfiguración de direcciones. Se añade un nuevo tipo de dirección, la llamada anycast, de forma que es posible enviar un paquete a cualquier nodo entre un grupo de ellos.

2.- Simplificación de la cabecera.

Algunos campos de la cabecera del IPv4 son eliminados o pasan a ser opcionales, tanto para reducir el coste de procesamiento como el tamaño de la cabecera.

3.- Mayor flexibilidad para extensiones y nuevas opciones.

En IPv6 no existe un campo opciones, como tal. (ver el apartado datagrama IPv6). La gestión de opciones se realiza por un campo siguiente cabecera ( next header), eliminando así las limitaciones de tamaño en la cabecera, e introduciendo una gran flexibilidad en el desarrollo de nuevas opciones.

4.- Capacidades de control de flujo.

Se añaden capacidades que permiten marcar los paquetes que pertenezcan a un determinado tipo de tráfico, para el cual el remitente demanda una calidad mayor a la especificada por defecto o servicios en tiempo real.

5.- Capacidades de autenticación y privacidad de datos.

IPv6 provee extensiones para soportar autenticación, e integridad y confidencialidad de datos.

Por lo demás, IPv6 mantiene la filosofía de IPv4 en cuanto a que ofrece un servicio de datos basado en datagramas no fiable, no orientado a conexión, etc. (ver apartado anterior). Cuando al desarrollar las características más importantes de IPv6 nos encontremos con alguna diferencia con respecto a IPv4 la expondremos en mayor profundidad.

A continuación estudiaremos la composición del datagrama IPv6 y la función de cada uno de sus campos, excluyendo los dedicados a direccionamiento y seguridad, que se tratarán en los siguientes apartados.

3.1. Formato de los datagramas IPv6

La unidad de datos de protocolo (PDU) de IPv6 tiene el siguiente aspecto:

Figura 1. Forma general de una PDU de IPv6

Como puede apreciarse en la figura, el paquete (como se suele llamar a la unidad de datos de protocolo) consta básicamente de una cabecera de 40 octetos (aparecen ya las primeras diferencias con IPv4, puesto que la cabecera del mismo tenía una extensión de 20 octetos) y un campo para la PDU del nivel superior (Transport-level PDU, PDU del nivel de transporte). Los campos “extension header” (cabeceras extendidas) pueden existir o no, y se trata básicamente de otras cabeceras que proporcionan una información adicional a la suministrada por la cabecera principal. Se definen las siguientes cabeceras extendidas:

• Cabecera de opciones “Salto a Salto” (Hob-by-hop options header): Define opciones especiales que requieren procesado hop-by-hop (salto a salto).

• Cabecera de Encaminamiento (Routing header): Proporciona una ruta extendida, similar al encaminamiento de fuente de IPv4.

• Cabecera de Fragmetación (Fragment header): Contiene información de fragmentación y reensamblado.

• Cabecera de Verificación de Autenticidad (Authentication header): Permite la autenticación e integridad del paquete.

• Cabecera de carga útil cifrada de seguridad (Encapsulating security payload header): permite privacidad.

• Cabecera de Opciones de Destino (Destination options header): Contiene información adicional a examinar por el nodo destino.

El estándar de IPv6 recomienda que cuando se utilicen múltiples cabeceras extendidas, éstas aparezcan en el siguiente orden:

• Cabecera IPv6. Siempre debe aparecer primero, obligatoriamente.

• Hop-by-hop options header.

• Destination options header: para las opciones que han de ser procesadas por el primer destino que aparece en el campo de dirección de destino de IPv6 más los subsiguientes destinos listados en la routing header.

• Routing header.

• Fragment Header.

• Authentication header.

• Encapsulating security payload header.

• Destination options header: para las opciones que sólo tiene que procesar el destino final del paquete.

Por medio de estas cabeceras extendidas, IPv6 consigue hacer de una forma más eficiente lo que IPv4 pretendía implementar con el campo opciones que seguía a la cabecera IPv4. Éste es un campo no demasiado estandarizado (de hecho tiene longitud variable) que se usa en IPv4 para cosas como grabar en él una ruta, hacer encaminamiento de fuente, etc.

IPv6 por contra utiliza múltiples cabeceras para éstas funciones, y tiene la ventaja que ya están definidas tanto su orden como su función, Además estas cabeceras utilizan para facilitar la tarea del nodo el campo de próxima cabecera. La cabecera IPv6 y cada cabecera extendida tiene un campo (próxima cabecera) en el que se indica el tipo de la cabecera que sigue a continuación. Si la próxima cabecera es una cabecera extendida, entonces este campo contiene el identificador de tipo de esa cabecera; en otro caso (cuando ya no hay más cabeceras), este campo contiene el identificador de protocolo del protocolo de nivel superior que esté usando IPv6 (que generalmente será un protocolo de nivel de transporte), usando los mismos valores que el campo de protocolo de IPv4.

Podemos apreciar esto en el siguiente ejemplo, en el que el protocolo de nivel superior que está utilizando IP es TCP. Por tanto, la PDU del nivel superior consiste en una cabecera TCP seguida de un bloque de datos de aplicación:

Figura 2. Paquete IPv6 con todas las cabeceras extendidas.

A continuación estudiaremos cada una de las cabeceras por separado, exceptuando las cabeceras extendidas Encapsulation security payload header y Authentication header, que veremos en el apartado de seguridad.

3.1.1. Cabecera IPv6.

Tiene longitud fija: 40 octetos, mientras que la cabecera de IPv4 tenía solo 20 octetos. Sin embargo el número de campos en IPv6 es menor (ocho contra doce), por lo que los routers tienen que procesar menos datos por cabecera, con lo que en teoría se aumenta la velocidad de encaminamiento. Estos son los campos que podemos encontrar en una cabecera de IPv6, como se aprecia en la figura 3:

Figura 3. Cabecera IPv6

• Versión (Version) (4 bits): Número de la versión de IP; el valor es 6.

• Prioridad (Priority) (4 bits): Valor de prioridad. Abordaremos este tema más adelante.

• Etiqueta de flujo (Flow label) (24 bits): Puede utilizarse por un host para etiquetar aquellos paquetes que requieren un especial manejo dentro de la red por parte de los routers, como veremos más adelante.

• Longitud de carga útil (Payload length) (16 bits): Longitud del resto del paquete IPv6 exceptuando la cabecera, en octetos. Es decir, es la longitud total de las cabeceras extendidas más la PDU del nivel de transporte (a esta porción del paquete es lo que llamaremos carga útil).

• Próxima cabecera (Next header) (8 bits): Como ya hemos mencionado, identifica el tipo de la cabecera inmediatamente siguiente a la cabecera principal.

• Límite de Saltos (Hop limit) (8 bits): El número restante de saltos permitidos para este paquete. El número máximo de saltos es elegido por la fuente, y ésta pone este campo a ese valor máximo. Este número se decrementa en uno por cada nodo que atraviesa el paquete. El paquete se descarta si el límite de saltos llega a cero. Esta es una simplificación de la idea del campo TTL (time-to-live, tiempo de vida) de IPv4. La idea original de este campo era llevar la cuenta del tiempo que esta el paquete en la red, pero el esfuerzo extra que implicaba llevar la cuenta de intervalos de tiempo en IPv4 no añadían una ventaja significativa al protocolo. De hecho los routers IPv4, como norma general, tratan el campo TTL como un campo de límite de saltos. Por ello IPv6 ya parte de esta idea: identificar el tiempo de vida de un paquete con el número de saltos que da dentro de la red, sin dejar espacio a complicadas contabilizaciones de intervalos temporales.

• Dirección Origen (Source address) (128 bits): La dirección del origen del paquete. Nótese que las direcciones son de 128 bits, no de 32 bits como eran en IPv4. Más adelante veremos esto con mayor profundidad, en el capítulo de direccionamiento.

• Dirección Destino (Destination address) (128 bits): La dirección del destino deseado del paquete. Esta dirección puede no ser de hecho la del destino último del paquete, si una cabecera de encaminamiento está presente, como veremos más adelante.

3.1.1.1. Campo de prioridad

Este campo consta de 4 bits que permiten a la fuente identificar la prioridad de un paquete a transmitir respecto a otros paquetes de la misma fuente. De hecho, este campo permite identificar dos prioridades distintas en cada paquete. En primer lugar, los paquetes se clasifican como parte de un tráfico para el cual la fuente esta ofreciendo control de congestión o no; en segundo lugar a cada paquete se le asigna uno de los ocho niveles de prioridad relativa dentro de cada clasificación anterior (con 4 bits tenemos de 0 a 15 etiquetas de prioridad. Las 8 primeras se referirán al primer tipo de tráfico, y las otras al segundo).

a) Tráfico con Control de Congestión: (Congestion-Controlled-Traffic) - se refiere al tráfico para el cual la fuente reacciona a la congestión; un ejemplo es TCP. Veamos lo que esto significa. Si existe congestión en la red, los segmentos TCP tardarán un tiempo mayor que el habitual en llegar a su destino. Como consecuencia de esto los asentimientos de éste también se retrasarán. Según aumenta la congestión, se hace necesario descartar los paquetes en algún punto de su camino: el descarte puede hacerse por un router cuyo buffer se haya desbordado o puede hacerse en una red individual, cuando un nodo de conmutación dentro de la red se congestiona. Ya sea un segmento de datos o bien un asentimiento, el efecto es que la unidad TCP de la fuente no recibe el asentimiento de su segmento transmitido. Entonces TCP responde retransmitiendo el segmento y disminuyendo el flujo de segmentos que genera (para aliviar la congestión).

La naturaleza del tráfico con control de congestión es tal que se acepta una cantidad variable de retardo en el recorrido de los paquetes, e incluso que esos paquetes lleguen fuera de orden. IPv6 define las siguientes categorías de tráfico con control de congestión, en prioridad decreciente (de 7 a 0):

• Tráfico de control de Internet (Internet control traffic): Es el tráfico más importante a distribuir, especialmente en momentos de alta congestión. Por ejemplo protocolos de encaminamiento como OSPF (Open Shortest Path First) y BGP necesitan recibir actualizaciones referentes a las condiciones de tráfico para que puedan ajustar sus rutas para intentar evitar la congestión. Los protocolos de gestión como SNMP (Simple Network Management Protocol) necesitan ser capaces de informar de la congestión a las aplicaciones de gestión de la red, realizar una reconfiguración dinámica, alterando los parámetros necesarios para hacer frente a esa congestión.

• Tráfico Interactivo (Interactive traffic): Después del tráfico de control de Internet, es el tráfico más importante, como las conexiones en línea usuario-a-host. La eficiencia para el usuario depende críticamente de la velocidad de respuesta de sus sesiones interactivas, por lo que el retardo debe minimizarse.

• Transferencia de muchos datos atendidos (Attended bulk transfer): Son aplicaciones que pueden involucrar la transferencia de gran cantidad de datos; durante éstas, el usuario como norma general está esperando a que se complete la transferencia. Esta categoría se diferencia del tráfico interactivo en que el usuario es consciente de que se producirá un considerable retardo en llegada de los datos que solicitó durante un diálogo interactivo. Un buen ejemplo de esto es la transferencia de ficheros (FTP, File Transfer Protocol). Otro ejemplo puede ser el conocido protocolo de transferencia de hipertexto (HTTP, Hypertext Transfer Protocol), que soporta la interacción servidor-Navegador Web.

• Transferencia de datos desatendididos (Unattended data transfer): Son aplicaciones que el usuario inicia pero que no se espera que se atiendan inmediatamente. Como norma general, el usuario no espera a que se complete la transferencia, sino que realiza otras tareas. El mejor ejemplo de este tipo de tráfico es el correo electrónico.

• Tráfico de relleno (Filler traffic): Es tráfico que de tratará en segundo plano, cuand ya se hayan entregado otras formas de tráfico. Como ejemplo podemos citar los mensajes USENET.

• Tráfico no caracterizado (Uncharacterized traffic): Si la aplicación del nivel superior no le entrega a IPv6 información sobre la prioridad de un tráfico, entonces este es asignado a este valor de prioridad mínimo.

Así por ejemplo, el estándar de IPv6 da el 1 para las noticias, 4 para FTP y 6 para conexiones Telnet, porque el retardo en estos casos es de algunos segundos y apenas es perceptible, aunque no el retardo de Telnet si lo es.

b) Tráfico sin control de congestión (Non-Congestion-Controlled Traffic) - Es tráfico para el cual se desea una tasa de transmisión de datos constante, así como un retardo también constante, o al menos con una variación relativamente pequeña en ambos. Los ejemplos más claros de este tipo de tráfico son las reproducciones de video y/o audio en tiempo real, para los cuales no tiene sentido retransmitir los paquetes descartados. Es más, es importante que se mantenga un flujo de entrega cercano a lo constante. Para este tipo de tráfico se permiten también ocho niveles de prioridad, que van desde el nivel con prioridad más baja, 8 (en el que más se permite descartar) al de prioridad mayor (menos descartes). En general, el criterio que se sigue es determinar cuanto afectan los paquetes perdidos a la calidad del tráfico recibido. Por ejemplo al sonido de baja fidelidad, (como la voz de una conversación telefónica) se le asignará una alta prioridad, debido a que la pérdida de unos pocos paquetes es apreciable en la línea en forma de clicks y zumbidos. En el otro lado está una señal de video de alta fidelidad, que contiene una considerable cantidad de redundancia, y probablemente no se aprecie tanto la pérdida de algunos paquetes; por ello a este tráfico se le asigna una prioridad relativamente baja.

Es necesario hacer notar que no existe una relación entre las prioridades del tráfico con control de congestión y las del tráfico sin control de congestión. Las prioridades son relativas sólo dentro de cada categoría.

3.1.1.2. Campo de etiqueta de flujo

El estándar IPv6 define un flujo (flow) como una secuencia de paquetes enviados desde un particular origen a un particular destino (ya sea unicast o multicast), secuencia para la cual la fuente desea un tratamiento especial por parte de los router que intervienen en la comunicación entre origen y destino. Un flujo está unívocamente determinado por la combinación de la dirección de fuente y una etiqueta de flujo de 24 bits distinta de cero. De este modo, todos los paquetes que formen parte del mismo flujo tienen asignada la misma etiqueta de flujo por parte de la fuente.

Desde el punto de vista de la fuente, un flujo será típicamente una secuencia de paquetes generados desde una aplicación de la fuente y que requieren los mismos servicios de transferencia. Un flujo puede constar de una conexión TCP única o incluso múltiples conexiones TCP; un ejemplo de este uso de múltiples conexiones TCP es una aplicación de transferencia de ficheros, que debería tener una conexión de control y múltiples conexiones de datos. Una sola aplicación puede generar un flujo único o múltiples flujos. Nuevamente un ejemplo del uso de múltiples flujos es una conferencia multimedia, la cual debería tener un flujo para el sonido y otro para las ventanas gráficas, cada uno de los cuales tiene distintos requisitos de transmisión en cuanto a la tasa a la que van los datos, el retardo, la variación del retardo, etc.

Desde el punto de vista del router, un flujo es una secuencia de paquetes que comparten ciertos atributos, que afectan al modo en el que el router manejará esos paquetes. Estos atributos incluyen el camino, reparto de recursos, requisitos de descarte (cuando debe descartar esos paquetes y cómo), cuenta, y atributos de seguridad. El router puede tratar los paquetes que pertenecen a diferentes flujos de formas muy dispares, entre lo que se incluye almacenarlos en buffers de diferentes tamaños, darles diferente prioridad a la hora de reencaminarlos por la red o solicitando para ellos diferentes calidades de servicio de las subredes.

La etiqueta de flujo no tiene un significado especial; en vez de ello la forma especial de manejar los paquetes de ese flujo debe declararse de otra forma. Por ejemplo, una fuente podría negociar o solicitar de los routers un trato especial en cuanto al tiempo, por medio de un protocolo de control, o a la vez que se transmite por medio de cierta información en una de las cabeceras extendidas del paquete, como por ejemplo la cabecera de opciones salto a salto. Ejemplos de tratos especiales requeridos para ciertos flujos pueden incluir la petición de alguna clase de calidad de servicio distinta de la predefinida y de alguna forma de servicio en tiempo real.

En un principio, todos los requisitos de un usuario hacia un flujo particular podrían definirse en una cabecera extendida e incluirse en cada paquete. Si se desea dejar el concepto de flujo abierto a la posibilidad de incluir un extensa variedad de requisitos, este diseño desembocaría en cabeceras muy grandes en los paquetes. La alternativa adoptada por IPv6 consiste en la etiqueta de flujo, en la cual los requisitos para un flujo se definen de forma previa al comienzo del flujo, y se asigna una única etiqueta de flujo al mismo. En este caso, el router debe guardar la información acerca de los requisitos negociados para cada flujo.

Las siguientes reglas se aplican a la etiqueta de flujo:

• Los hosts o routers que no soporten o reconozcan el campo de etiqueta de flujo deben poner ese campo a cero cuando originan un paquete, saltarse ese campo sin cambiarlo cuando lo que hacen es reencaminar por la red un paquete e ignorar ese campo cuando reciben un paquete.

• Todos los paquetes que se originan en la misma fuente con la misma etiqueta de flujo (y que ésta sea distinta de cero, obviamente) deben tener la misma dirección de destino, dirección de fuente, prioridad, los mismos contenidos de la cabecera de opciones salto a salto (si esta cabecera está presente) y los mismos contenidos de la cabecera de encaminamiento (si está presente). La intención es que el router pueda decidir como encaminar y procesar el paquete simplemente examinando la etiqueta de flujo en una tabla, sin examinar el resto de la cabecera.

• La fuente asigna una etiqueta de flujo a un flujo. Pueden elegirse nuevas etiquetas de flujo de forma (pseudo-) aleatoria y uniforme en el rango 1 a 224 ­p; 1, sujeto a la restricción que nos dice que una fuente no puede reutilizar una etiqueta de flujo para otro flujo nuevo mientras siga existiendo el flujo actual.

Este último punto requiere una explicación algo más profunda. El router debe mantener la información acerca de todos los flujos activos que pueden pasar por él, presumiblemente en alguna clase de tabla. Para que los paquetes puedan reenviarse por la red de una manera eficiente y rápida, el acceso a la información de esa tabla debe ser eficiente. Una alternativa es tener una tabla con 224 (sobre 16 millones) de entradas, una para cada etiqueta de flujo; esto implica una carga de memoria innecesaria en el router. Otra alternativa es tener una entrada en la tabla por cada flujo activo, incluir la etiqueta de flujo que le corresponde a cada entrada, obligando de este modo al router a buscar por la tabla entera cada vez que llega un paquete. La consecuencia es que se produce un excesivo procesado en el router. En lugar de esto, la mayoría de los routers se diseñan para utilizar una tabla de tamaño moderado en la que cada entrada se obtiene aplicando un función sobre la etiqueta de flujo. Esta función puede ser simplemente la identidad sobre los bits menos significativos de la etiqueta (unos diez o doce), es decir, coger los bits menos significativos, o bien puede ser algún tipo de cálculo sobre los 24 bits de la etiqueta. A partir del resultado de aplicar esa función sobre cada etiqueta de flujo obtenemos la entrada a la tabla donde se guarda la información de ese flujo. En cualquier caso la eficiencia de este sistema como norma general depende de que las etiquetas de flujo se distribuyan uniformemente sobre su rango; de ahí el tercer requisito indicado anteriormente.

3.1.1.3. Direcciones

(Ver apartado de direccionamiento en IPv6).

3.1.2. Cabeceras extendidas

Figura 4. Cabeceras extendidas

3.1.2.1. Cabecera de Opciones Salto a Salto

Lleva información adicional que, si está presente, debe ser examinada por cada router a lo largo del camino que recorre el paquete. Esta cabecera consiste en (ver figura 4-a):

• Próxima cabecera (Next Header): Identifica el tipo de la cabecera inmediatamente siguiente a ésta.

• Longitud de la Cabecera Extendida (Header extension length): Longitud de esta cabecera en unidades de 64 bits, sin incluir los primeros 64 bits.

• Opciones (Options): Un campo de longitud variable que consta de una o más definiciones de opciones. Cada definición está formada por tres subcampos:

• tipo de opción (type opcion) (8 bits): identifica la opción.

• Longitud (length) (8 bits), que especifica la longitud del campo de datos de opción en octetos.

• Datos de opción (option data), que consiste en la especificación de la opción (longitud variable).

En realidad son los cinco bits menos significativos del campo tipo de opción los que se usan para especificar una opción particular. Los dos bits más significativo indican la acción que debe llevar a cabo un nodo que no reconoce el tipo de opción, como sigue:

00 ­p; Sortear esta opción y continuar procesando la cabecera.

01 ­p; Descartar el paquete.

10 ­p; Descartar el paquete y mandar un ICMP (Internet Control Message Protocol) de Parameter Problem (problema con los parámetros), Código 2, esto es un mensaje a la dirección origen del paquete señalando el tipo de opción no reconocido.

11 ­p; Descartar el paquete y, solamente si la dirección destino del paquete no es una dirección multicast (esto es, a varias máquinas, ver direccionamiento), mandar un ICMP Parameter Problem, Código 2, (mensaje a la dirección origen del paquete, señalando el tipo de opción no reconocido).

El tercer bit más significativo indica si el campo de datos de opción puede cambiar (1) o no (0) en el camino recorrido entre el origen y el destino. Los datos que pueden cambiar deben excluirse del análisis de autenticación que se verá posteriormente.

Estas convenciones para el campo de opción de tipo también pueden aplicarse a la cabecera de opciones de destino.

En el estándar IPv6 sólo una opción está completamente especificada: la opción de los llamados “jumbogramas” (jumbo payload option). Esta opción es utilizada para enviar paquetes IPv6 con cargas útiles mayores que 216 (65536) octetos. El campo datos de opción de esta opción es de 32 bits, e indica la longitud del paquete en octetos (excluyendo la cabecera principal). En estos paquetes el campo de longitud de carga útil de la cabecera IPv6 (la principal) debe ponerse a cero, y no tiene que haber cabecera de fragmentación. Los “jumbogramas” tienen una longitud de hasta 4GB, que permiten transferencias más eficientes con pocas interrupciones en la comunicación. Con ello se facilita la transmisión de grandes paquetes de vídeo y permite que IPv6 pueda hacer el mejor uso posible de la capacidad de cualquier medio de transmisión (como puede ser por ejemplo fibra óptica, un medio óptico, medios que por norma general tienen gran capacidad, y en los que interesa que el tamaño del paquete sea mucho mayor para aprovechar mejor las características de los mismos, como se indicó anteriormente).

3.1.2.2. Cabecera de fragmentación

A diferencia de IPv4, en IPv6 la fragmentación sólo puede hacerse en los nodos origen, y no a lo largo de los nodos de la red. Esto tiene la ventaja evidente de que al no fraccionarse los paquetes en la red éstos no se pierden y se evita que un nodo tenga que almacenar muchos fragmentos, y todos los demás problemas derivados de la fragmentación en la red.

Obviamente para realizar la fragmentación desde el nodo fuente, éste deberá implementar un algoritmo descubridor de caminos (algoritmo de encaminamiento) que le permita conocer cual es la unidad de transmisión máxima (MTU) más pequeña de todas las subredes a lo largo de ese camino entre el nodo origen y el nodo destino. Es decir, el algoritmo le permite saber cual es la MTU del cuello de botella del camino (aquel punto donde la MTU es la más pequeña y se van a dar los problemas de fragmentación). Una vez que el nodo fuente sabe esto fragmentará sus paquetes IPv6 como se requiera (con el tamaño de la MTU hallada) para cada destino. Otra posibilidad es que el nodo origen limite todos los paquetes a 576 octetos, que es la mínima MTU que debe soportar cada subred.

La composición de la cabecera de fragmentación puede apreciarse en la figura 4-b, y consta de :

• Próxima cabecera (Next Header) (8 bits): Identifica el tipo de la cabecera inmediatamente siguiente.

• Reservado (Reserved) (8 bits): Para uso futuro.

• Contador de fragmento (Fragment Offset) (13 bits): Indica la posición a la que pertenece la carga útil de este fragmento dentro del paquete original. Se mide en unidades de 64 bits. Esto implica que los fragmentos (exceptuando el último) deben contener un campo de datos cuya longitud sea múltiplo de 64 bits

• Res (2 bits): Reservado para uso futuro.

• M Flag (1 bit): 1 = más fragmentos; 0 = último fragmento.

• Identificación (Identification) (32 bits): Tara de identificar unívocamente al paquete original. Todos los fragmentos que pertenezcan a un mismo paquete deben tener igual el campo de identificación. El identificador debe ser único para un paquete todo el tiempo que ese paquete permanezca en la interred.

El algoritmo de fragmentación es el mismo que el que se utiliza en IPv4. Lo veremos de forma más extensa en el apartado de fragmentación.

3.1.2.3. Cabecera de Encaminamiento

Esta cabecera contiene una lista de uno o más nodos intermedios por los que tiene que pasar el paquete en su camino hacia el nodo destino. Todas las cabeceras de enrutamiento comienzan por un bloque de 32 bits formado por cuatro campos de 8 bits, seguido de los datos específicos de encaminamiento dentro de un tipo de encaminamiento dado, como se aprecia en la figura 4-c. Los campos de 8 bits son los siguientes:

• Próxima cabecera (Next header): Como ya hemos comentado varias veces, identifica el tipo de cabecera que sigue.

• Longitud de la cabecera extendida (Header extension length): Longitud de esta cabecera en unidades de 64 bits, sin incluir los primeros 64.

• Tipo de encaminamiento (Routing type): Identifica una cabecera de encaminamiento particular dentro de las posibles variantes. Si un router no reconoce el valor del tipo de encaminamiento debe descartar el paquete.

• Segmentos restantes (Segments left): Número de nodos indicados explícitamente del camino que quedan por visitarse antes de alcanzar el destino final.

Además de esta definición de la cabecera de encaminamiento más general, el RFC 1883 define la cabecera de encaminamiento Tipo 0 (ver figura 4-d). Esta cabecera incluye además de los cuatro campos de ocho bits, un mapa de bits formado por24 bits riguroso/relajado. Esta forma de llamar a los bits quiere decir lo siguiente: los 24 bits del campo se numeran de izquierda a derecha (desde el 0 al 23), donde cada bit corresponde a un salto. Según esto, cada bit indica si el correspondiente próximo destino debe ser un vecino de la dirección precedente (1= estricto, debe ser un vecino; 0 = relajado, no necesariamente debe ser un vecino).

Cuando se usa una cabecera de encaminamiento de tipo 0, el nodo fuente no coloca la dirección del destino final del paquete en el campo dirección destino de la cabecera IPv6. En lugar de ello esa dirección es la última dirección listada en la cabecera de encaminamiento (address [n] en la figura 4-d), y el campo correspondiente de la cabecera principal IPv6 contiene la dirección destino del primer router por el que se desea que pase el camino. La cabecera de encaminamiento no se examinará hasta que el paquete alcance el router señalado en la cabecera IPv6. Si esta dirección es la dirección definitiva (porque no hay cabecera de encaminamiento o porque se ha llegado a la dirección última de la misma) el router se queda con el paquete. En cambio si no es la dirección definitiva el paquete IPv6 y la cabecera de encaminamiento son actualizados y el paquete es reeenviado. La actualización consiste en colocar la dirección del próximo nodo a visitar en la cabecera IPv6 y decrementar a su vez el campo de segmentos restantes de la cabecera de encaminamiento.

Los nodos IPv6 también tienen que quedarse con las rutas que sigue un paquete para devolver el paquete al destino.

Teniendo en cuenta todo esto, veamos un ejemplo que aparece en R. Hinden, "IP Next Generation Overview," Connexions, Mar. 1995, en el cual tenemos dos hosts (H1 y H2) conectados por dos proveedores (P1 y P2) que a su vez están conectados por medio de una red de tipo wireless (sin cable). A esta red sin cable la llamaremos PR. En lo que sigue, las secuencias de direcciones se referirán con el siguiente formato:

SRC, I1, I2, ..., In, DST

donde SRC es la dirección listada en la cabecera IPv6, Ii es la i-ésima dirección intermedia y DST es la dirección última. Recordemos que si no hay cabecera de encaminamiento, DST aparece en la cabecera IPv6, mientras que si sí existe aparece en la última dirección de la misma. Nos hallamos en la situación en la que H1 manda paquetes a H2:

• No se usa cabecera de encaminamiento. H1 manda un paquete a H2 conteniendo la secuencia (H1, H2). H2 responde con un paquete que contiene (H2, H1). En este caso, cualquier proveedor puede utilizarse en cada trasferencia.

• H1 quiere que se cumpla una política según la cual todo el tráfico entre él y H2 sólo puede usar P1. Para ello construye un paquete con la secuencia (H1, P1, H2) y dicta un encaminamiento estricto (poniendo a 1 el bit correspondiente, como ya vimos). Esto asegura que cuando H2 responda a H1 utilizará la secuencia (H2, P1, H1) con encaminamiento estricto, debido a la política forzada por H1 de usar P1.

• H1 se convierte en móvil y cambia al proveedor PR. Podría mantener su comunicación con H2 (sin romper ninguna conexión TCP) por medio de mandar paquetes con la secuencia (H1, PR, P1, H2). Esto aseguraría que H2 cumpliera la política de usar P1 respondiendo con (H2, P1, PR, H1).

Este ejemplo ilustra las posibilidades que tiene IPv6 de seleccionar un proveedor particular, de mantener las conexiones mientras se está moviendo y de encaminar paquetes a nuevas direcciones dinámicamente. Con ello se aumentan las ventajas de IPv6 sobre IPv4, que no soportaba todas estas posibilidades, al menos directamente sobre el paquete IP.

3.1.2.4. Cabecera de Opciones de Destino.

La cabecera de opciones de destino lleva información opcional que, en el caso de existir, sólo es examinada por el nodo de destino del paquete. El formato de esta cabecera es el mismo que el de la cabecera de opciones salto a salto (figura 4-a).

3.2. Fragmentación

El problema surge cuando se desea enviar un paquete que es demasiado grande para ser manejado por alguna de las redes que se encuentran entre el origen y el destino de una comunicación. En estos casos nos veremos obligados a dividir el paquete en paquetes más pequeños, esto es, fragmentar el paquete original. Así cada uno de los fragmentos podrá ser manejado sin problemas por las redes intermedias.

Los principales problemas asociados a la fragmentación son los siguientes:

• Sobrecarga

Al necesitarse más cabeceras para los fragmentos, aumenta el número de datos que se transmitirán, lo cual supone una carga extra y tiempo que no utilizamos para transmitir datos útiles.

• Pérdida de fragmentos

Si se pierde uno de los paquetes fragmentados puede ser necesaria la retransmisión de todos los fragmentos.

Es por ello que, en la medida de lo posible, debe evitarse la fragmentación.

3.2.1. Fragmentación en IPv6

Una de las diferencias entre IPv4 y IPv6 es que en este último tan sólo la máquina origen puede fragmentar un paquete. Los routers que se encuentren a lo largo del camino no lo harán. Es una buena solución de cara a liberar al router de la carga de trabajo requerida por el proceso de fragmentación para que pueda atender un mayor número de datagramas por unidad de tiempo. Con esta medida se intentan solventar los problemas de los routers convencionales, en los que el uso de CPU puede alcanzar el 100% si fragmenta muchos de los datagramas que recibe.

Desde este nuevo punto de vista de IPv6, el proceso de fragmentación y reensamblado se lleva a cabo extremo a extremo, sin intervención de nodos intermedios.

IPv6 requiere que todos los nodos y routers tengan un MTU (unidad máxima de transferencia) de 576 bytes o superior. Esto hace que sea menos probable la fragmentación. De esta forma, antes de enviar un datagrama, el origen lo divide para que cada fragmento sea menor que el MTU. Se recomienda que los nodos IPv6 implementen el denominado Path MTU Discovery ([RFC 1191]) para poder aprovechar las ventajas de las rutas con un MTU superior a 576 bytes.

Cuando llega a un router un paquete IPv6 demasiado grande, se descarta y se devuelve un mensaje ICMP (protocolo de control de mensajes de Internet) del tipo Datagram Too Big al origen con información del máximo MTU que se puede utilizar. Con esta información, el host de origen sabrá que en futuros intentos deberá dividir el paquete en fragmentos más pequeños.

3.2.1.1. Cabecera de fragmentación (Fragment Header)

Si no queda otro remedio que utilizar la fragmentación, se debe utilizar una cabecera de extensión denominada cabecera de fragmentación de manera que podamos dividir el paquete en el origen y reensamblarlo correctamente en el destino.

Esta cabecera maneja la fragmentación de una manera similar a la del IPv4. La cabecera contiene el identificador del datagrama, el número de fragmento y un bit que indica si seguirán más fragmentos, de forma que, como se ha comentado anteriormente, es el destino final el encargado del proceso de reensamblado.

La cabecera de fragmentación se identifica con el valor 44 en el campo de siguiente cabecera (Next Header) de la cabecera anterior, y tiene el siguiente formato:

Los campos de mayor interés son:

• Offset indica el desplazamiento del fragmento respecto al origen del datagrama original. Con este dato se podrá conocer en que posición hay que colocarlo a la hora de reensamblar.

• El byte M indica si habrá más fragmentos o si, por el contrario, se trata del último fragmento de un datagrama.

• Para cada paquete fragmentado, el nodo origen genera un valor de identificación que ha de ser diferente que el de otros paquetes fragmentados enviados anteriormente (al menos en un tiempo igual al máximo tiempo de vida de un paquete) entre el origen y el destino.

Obsérvese que si fragmentamos un paquete, el tamaño del campo de datos se reduce a 528 bytes si nos ponemos en el mejor de los casos (576 del MTU menos 40 de la cabecera IPv6 y 8 de la cabecera de fragmentación).

¿Cómo se forman los fragmentos? El paquete original sin fragmentar consta de una parte fragmentable (cabeceras de extensión que sólo se procesan en el nodo final, cabecera del nivel superior y datos) y la parte no fragmentable (cabeceras de extensión que se procesan en los nodos intermedios). Los fragmentos se forman dividiendo la parte fragmentable en partes de longitud múltiplo de 8 bytes (excepto la última, que puede tener cualquier longitud) de forma que cada paquete fragmentado se componga de:

• La parte no fragmentable del paquete original

• Una cabecera de fragmentación

• El fragmento

3.2.2. Reensamblado

Se entiende por reensamblado la reconstrucción del paquete original a partir de sus fragmentos. Si todo funciona según lo esperado, en el destino los fragmentos son reensamblados correctamente obteniendo el paquete original. Para reensamblar los fragmentos se combinan los que tengan el mismo valor en los campos identificador, dirección origen, dirección destino y protocolo.

Sin embargo a continuación se citan algunas situaciones en las que se pueden producir errores y el paquete no se reensamblará correctamente en el destino:

Cuando pasan sesenta segundos tras la recepción del primer fragmento y no se han recibido suficientes fragmentos para completar el reensamblado, la operación se abandona y los fragmentos recibidos hasta ese momento se descartan. Si se ha recibido el primer fragmento, se envía un mensaje ICMP de tipo Time Exceeded al origen.

Ya que la longitud de todos los fragmentos excepto el último ha de ser múltiplo de 8 bytes, si se recibe un fragmento que no cumple ese requisito y no es el último fragmento (el byte M toma el valor 1), es descartado y se envía un mensaje ICMP del tipo Parameter Problem al origen.

Al obtenerse un fragmento cuya longitud y offset son tales que la longitud del paquete reensamblado supera los 65535 bytes (corresponden con la máxima carga útil de IP), se descarta el fragmento y se envía un mensaje ICMP de tipo Parameter Problem al origen.

3.3 Direcciones y encaminamiento en IPv6

3.3.1. Direcciones en IP Versión 6

3.3.1.1. Problemática y evolución hacia IPv6

Con el protocolo IPv4, cada máquina presente en la red dispone de una dirección IP de 32 bits. Ello supone más de cuatro mil millones de máquinas diferentes. Esa cifra, no obstante, es muy engañosa. El número asignado a un ordenador no es arbitrario, sino que depende de una estructura más o menos jerárquica (en especial, pertenece a una red), lo cual ocasiona que se desperdicie una enorme cantidad de direcciones. En 1.993 fue claro que con el ritmo de crecimiento sostenido de Internet hasta aquel momento exponencial), el agotamiento del espacio de direcciones era casi inminente, si se seguían utilizando las direcciones con formato IPv4.

Con IPv6, el número de direcciones diferentes se ha multiplicado de una manera exagerada. Teóricamente, es posible tener 2128 direcciones diferentes. Este numero quiere decir que se podrían llegar a tener 665.5703 793.3482 866.9431 898.599 direcciones por metro cuadrado en toda la Tierra, aunque si siguieran una jerarquía, este numero decrece hasta 1564 direcciones por metro cuadrado en el peor caso o tres trillones siendo optimistas.

El cambio más significativo en las direcciones respecto a IPv4 ha sido que, ahora, se refieren a un interfaz y no a un nodo, aunque como cada interfaz pertenece a un nodo, es posible referirse a estos mediante su interfaz.

El tipo específico de direcciones IPv6 es indicado por los primeros bits de la dirección. El campo de longitud variable que incluye estos primeros bits es llamado Format Prefix (FP). Esto soporta la asignación directa de proveedores de direcciones, direcciones de uso local y direcciones multicast. El espacio está reservado para direcciones NSAP, direcciones IPX, y direcciones de interconexión neutral. El resto del espacio de direcciones está sin asignar para utilizaciones futuras. Estas pueden ser utilizadas para la expansión del uso existente (por ejemplo, proveedor adicional de direcciones, etc.) o nuevos usos (por ejemplo., localizadores separados e identificadores).

El espacio de direcciones está dividido en NSAP, IPX, unicast basado en proveedor (provider), geográfico, direcciones de ámbito local y direcciones multicast. Esto es sólo el 15% de todo el espacio de direcciones. El resto está reservado para usos futuros.

3.3.1.2. Direccionamiento en IPv6

Las direcciones IPv6 son asignadas a interfaces, no a nodos. Cuando un nodo tiene más de un interfaz, el nodo puede direccionarse mediante la dirección de cualquiera de sus interfaces. Además, un interfaz puede tener asignada una o más direcciones, con dos excepciones :

• Un conjunto de interfaces puede tener asignada una sola dirección IPv6, esta agrupación elimina la posibilidad de que cada uno de los interfaces que comparten una dirección pueda tener asignada cualquier otra.

• Los routers pueden tener interfaces sin dirección asignada en enlaces PPP (Point to Point Protocol, Protocolo Punto a Punto). Los interfaces de enlaces PPP no necesitan dirección IP si no son origen o destino de datagramas IPv6.

3.3.1.3. Representación de direcciones

Existen 3 formas para representar direcciones IPv6 mediante cadenas de texto:

• La forma más indicada es mediante la estructura x:x:x:x:x:x:x:x, donde los valores x son los valores en hexadecimal de cada bloque de 16 bits de la dirección.

Ejemplos:

FEDC:BA09:6543:1234:FDCE:7564:BA98:7651

1080:0:0:0:8:800:200C:417A

• El segundo método permite agrupar largas series de 0's, para hacer más legibles las direcciones, el uso de "::" indica múltiples grupos de 16 bits a 0.

Ejemplos:

1080:0:0:0:8:800:200C:417A podría representarse como 1080::8:800:200C:417A

FF01:0:0:0:0:0:0:43 podría representarse como FF01::43

Sólo puede usarse "::" una vez en una dirección.

• El tercer método resulta el más indicado para representar direcciones IPv6 que contengan direcciones IPv4, los 2 últimos bloques de 16 bits se representan como 4 bloques de 8 bits mostrando sus valores en decimal, como en IPv4.

Ejemplos:

0:0:0:0:0:0:13.1.68.3 ó ::13.1.68.3

0:0:0:0:0:FFFF:129.144.52.38 ó ::FFFF:129.144.52.38

Los diferentes tipos de direcciones son especificados por los bits de mayor peso de la dirección. Cada tipo tiene asignado un prefijo, de longitud variable para cada tipo. Esto se asigna por medio de la máscara IP.

3.3.1.4. Tipos de direcciones

En el IPv6 existen tres tipos básicos de direcciones:

• Direcciones unicast: Están dirigidas a un único interfaz en la red. Actualmente se dividen en varios grupos, y existe un grupo especial que facilita la compatibilidad con las direcciones de la versión 4.

• Direcciones anycast: Identifican a un conjunto o grupo de interfaces de red. El paquete se enviara a cualquier interfaz que forme parte del conjunto. En realidad son direcciones unicast que se encuentran asignadas a varios interfaces. Un paquete IPv6 con una dirección destino anycast es encaminado a uno y sólo uno de los interfaces identificados por la dirección. El paquete será encaminado al interfaz más cercano, de acuerdo con las técnicas de medida de distancia de las estrategias de enrutamiento.

• Direcciones multicast: Identifican a un conjunto de interfaces de la red, de manera que cada paquete es enviado a todos y cada uno de ellos individualmente.

No existen direcciones broadcast en IPv6 (ver Direcciones especiales), su función es realizada por las direcciones multicast.

3.3.1.5. Direcciones Unicast

Existen múltiples formatos de dirección unicast. Un nodo en Internet puede tener mayor o menor conocimiento de la estructura de las direcciones, dependiendo del papel que juegue en Internet. Como mínimo, un nodo considerará una dirección IPv6 como un identificador sin estructura interna.

Usando el valor de la máscara IP, pueden indicarse prefijos de red de longitud variable:

Prefijo de red Identificador de interfaz

n bits (128-n) bits

Los nodos pueden tener un conocimiento más profundo de la jerarquía de direcciones, dependiendo del papel que desempeñen en la jerarquía de enrutamiento.

Ejemplos de direcciones unicast :

- Direcciones MAC (IEEE 802) para redes locales.

Prefijo de grupo Identificador de Identificador de

subred interfaz

n bits (80-n) bits 48 bits

Siendo `Identificador de interfaz' la dirección MAC del interfaz. Para redes locales que no usen direcciones MAC, se pueden utilizar otros tipos de direcciones del nivel de enlace.

- Para sistemas que requieran por su tamaño más niveles de jerarquía, la dirección puede dividirse en múltiples niveles, por ejemplo :

Identificador Identificador Identificador Identificador

de grupo de área de subred de interfaz

g bits a bits s bits (128-g-a-s) bits

- Para direcciones basadas en proveedor, tenemos la siguiente estructura :

010 Id. registro Id. proveedor Id. suscriptor Id.

Intra-Suscriptor

3 bits n bits m bits s bits (125-n-m-s) bits

Esta estructura refleja la jerarquía: un registro asigna las direcciones de un grupo de proveedores de servicios (p.e. backbones o redes regionales), que asignan direcciones a sus suscriptores (p.e. Sites o campus universitarios), etc.

3.3.1.5.1. Direcciones especiales unicast

• Dirección 0:0:0:0:0:0:0:0 : Esta dirección no puede ser asignada a ningún nodo. De hecho, indica la ausencia de dirección. Puede usarse, por ejemplo, como dirección origen al inicializar nodos, antes de que éstos conozcan su propia dirección IP. En ningún caso podrá aparecer como dirección destino.

• Dirección 0:0:0:0:0:0:0:1 : Dirección del bucle local. Puede ser usada por un nodo para enviarse un datagrama a él mismo. En ningún caso podrá aparecer como dirección origen. Un datagrama enviado a la dirección de bucle local no saldrá al medio. Puede ser usada, por ejemplo, para comunicación entre los procesos de un nodo.

3.3.1.5.2. Direcciones unicast IPv6 conteniendo direcciones IPv4

Existen dos formas de codificar direcciones IPv4 en direcciones IPv6.

La primera se usa en nodos que puedan gestionar ambos protocolos, tanto IPv6 como IPv4. Las direcciones se codificaran de la siguiente forma:

Todo a 0's Todo a 0's Dirección IPv4

80 bits 16 bits 32 bits

La segunda forma se usa para representar las direcciones de nodos que sólo soporten IPv4, antes de la conversión de IPv6 a IPv4, el datagrama llevará una dirección con la siguiente estructura:

Todo a 0's Todo a 1's Dirección IPv4

80 bits 16 bits 32 bits

3.3.1.5.3. Uso local de direcciones unicast IPv6

Existen dos tipo de direcciones IPv6 de uso local. Estos tipos son el enlace local (Link-Local) y el grupo local (Site-Local).

La estructura de dirección enlace local es la siguiente:

1111111010 Todo a 0's Identificador interfaz

10 bits n bits (118-n) bits

Las direcciones de enlace local son usadas para direccionar un sólo enlace, para diferentes propósitos, como autoconfiguración de direcciones, descubrimiento de vecinos, o cuando no existe un router.

La estructura de dirección grupo local es la siguiente:

1111111011 Todo a 0's Identificador Identificador

de subred de interfaz

10 bits n bits m bits (118-n-m) bits

Las direcciones Site-Local se usan en grupos de redes que no disponen de una conexión a Internet, no necesitando un prefijo de dirección para su direccionamiento en Internet. En el momento en que el grupo se conecte a Internet, el prefijo de Site-Local será sustituido por un prefijo que identifique al grupo en la estructura global de Internet.

3.3.1.6. Direcciones anycast

Una dirección IPv6 unicast es una dirección asignada a un grupo de interfaces, con la particularidad de que un paquete con una dirección unicast es llevado a sólo un interfaz, que será el mas cercano según las técnicas de medida de distancia en las estrategias de enrutamiento.

Las direcciones anycast usan los mismos formatos definidos para direcciones unicast, con la diferencia de que el campo identificador de interfaz estará todo a 0's.

Prefijo de subred Todo a 0's

n bits (128-n) bits

Una dirección anycast no podrá nunca aparecer como dirección origen en un paquete IPv6, ni podrá ser asignada a ningún host. Las direcciones anycast sólo podrán ser asignadas a un router.

3.3.1.7. Direcciones multicast

Una dirección IPv6 multicast identifica a un conjunto de nodos. Un nodo puede pertenecer a cualquier número de conjuntos multicast. Las direcciones multicast tienen la siguiente estructura :

11111111 Flags Ámbito Identificador de grupo

8 bits 4 bits 4 bits 112 bits

• Flags:

Este campo ocupa 4 bits, los tres bits de mayor peso. Deben ser inicializados a 0. El cuarto bit indica si la dirección es fija o no.

4º bit a 0 La dirección es fija.

4º bit a 1 La dirección NO es fija (transición).

• Ámbito.

Este campo ocupa 4 bits, e indica el ámbito del grupo multicast. Los valores son:

0 Reservado 8 Organización local

1 Nodo local. 9 Sin asignar

2 Enlace local. A Sin asignar

3 Sin asignar B Sin asignar

4 Sin asignar C Sin asignar

5 Site local D Sin asignar

6 Sin asignar E Global

7 Sin asignar F Reservado

• Identificador de grupo.

Este campo ocupa 112 bits, e identifica al grupo en el ámbito indicado, sea fijo o de transición. Las direcciones fijas tienen un significado independiente del ámbito que se indique.

3.3.1.8. Autoconfiguración de direcciones

Los datos de las redes son cada vez más complejos, y la necesidad de eliminar algunas dificultades convierte al "Plug and Play" (servicio inmediato) en algo cada vez más imprescindible. El usuario no tiene que conocer en detalle la arquitectura de la red, ni saber configurar el software de red de su estación de trabajo. En el caso ideal, cualquier usuario debería ser capaz de desembalar su nuevo ordenador, conectarlo a la red local y verlo funcionar sin la necesidad para él de introducir informaciones de "especialista". Ciertas preocupaciones de seguridad pueden limitar este nivel de transparencia de autoconfiguración de direcciones en algunos entornos, pero los mecanismos deben existir para soportar cualquier automatización en el que el entorno local estaría de acuerdo.

La primera exigencia de la operación "Plug and Play" es que una estación pueda ser capaz de adquirir una dirección de manera dinámica, ya sea cuando está conectada la primera vez a una red, o cuando la estación necesite ser reconfigurada por traslado o por que la identidad de la red ha sido modificada. Existen también otras funciones que necesitan un entorno de "plug and play". La mayoría de ellas se deben hacer fuera del protocolo IPv6, pero el protocolo de autoconfiguración de direcciones de una estación será ejecutado por IPv6.

Una estación IPv6 puede autoconfigurar dos tipos de direciones :

- Direcciones de intra-enlace (intra-link scope address).

- Direcciones de inter-enlace (inter-link scope address).

Una dirección de intra-enlace es autoconfigurable en ausencia de encaminador, mientras que una dirección de inter-enlace es autoconfigurable cuando un

encaminador está presente en el enlace.

Procedimientos de formación de las direcciones:

• Direcciones Intra-enlace:

Sólo existe una manera para formar una dirección de intra-enlace. Al inicializar la interfaz, una estación crea su dirección de intra-enlace concatenando un prefijo de intra-enlace a una ficha ("token") que es única para el enlace. Típicamente, la definición de una ficha es independiente de la capa de enlace. Por ejemplo, en el caso de una estación conectada a una red IEEE 802, la ficha es la dirección IEEE 802 del interfaz.

• Direcciones Inter-enlace:

Existe dos maneras para crear una dirección de inter-enlace. En el primer mecanismo, una estación obtiene su dirección de inter-enlace concatenando un prefijo de red indicado por un "Router Advertisement" a una ficha única por enlace. El otro mecanismo disponible para las estaciones es utilizar el protocolo de configuración dinámica de las estaciones para IPv6 (Dynamic Máquina Configuration Protocol - DHCP). La elección del protocolo a utilizar es propuesta por el encaminador, y la elección es configurable por el administrador del sistema.

El primer proceso de formación de la dirección de inter-enlace conviene para entornos donde ninguna gestión administrativa es deseable. Este protocolo está concebido especialmente para permitir una configuración sencilla de las direcciones. DHCPv6 es un protocolo más complejo que permite una asignación flexible de direcciones bajo el control del administrador del sistema. Este protocolo necesita sobre todo un gestor de sistemas (servidor y bases de datos) importante.

3.3.2. Encaminamiento

3.3.2.1.Planteamiento del problema y evolución

Internet representa el ejemplo paradigmático de las redes de datagramas o no orientadas a la conexión. En ella cada fragmento (paquete) de información es transmitido por la red de manera no fiable y sin mantener vínculo alguno, ni siquiera de orden, con el resto de los paquetes de la unidad de información intercambiada. Para que esto pueda ser así, cada paquete contiene en su interior (más explícitamente en su comienzo o cabecera) la identificación de su origen junto con la de su destinatario. Esta faceta del protocolo IP presenta la ventaja de facilitar la interconexión de subredes de diferente tecnología y es sin duda una de las claves del éxito de la Internet como red de redes en contraposición con otras tecnologías orientadas a la conexión como X.25 o ATM, basadas en el concepto de circuitos virtuales o canales fiables que asigna la red para la comunicación entre extremos de manera ordenada e íntegra.

El protocolo IP gobierna la estructura y la transmisión de los datagramas a través de los nodos de la red, sean éstos sistemas finales (ordenadores, con un punto de conexión a red) o intermedios (routers, con más de un punto de conexión). El recurso quizá más valioso de entre los que posee la red Internet es su espacio de direcciones o el conjunto de todos los identificadores que pueden ser asignados a los puntos de conexión a red y que está estrechamente ligado al concepto administrativo de encaminamiento.

El encaminamiento en la Internet se lleva a cabo bajo la suposición que todos los equipos que tienen identificadores con una misma parte de red son miembros de una misma unidad topológica sujeta a una estructura administrativa única, lo que permite inferir que el encaminamiento interno es homogéneo y completo. El resultado de todo esto es que todos los equipos de la red son vistos desde el exterior como un único elemento de cara al encaminamiento, lo cual reduce en gran manera la cantidad de información que deben mantener, almacenar y procesar los equipos encaminadores o routers. La parte de red de una dirección se denomina prefijo, y se utiliza para representar diferentes estructuras topológicas mediante la sintaxis `direccion IP (32-bits) - tamaño del prefijo'. Esto indica qué parte de la dirección es significativa en términos de encaminamiento. Se implementa mediante máscaras de red. Es importante resaltar la diferencia entre los procedimientos de encaminamiento internos a un dominio o intra-dominio, de los que ése dominio tiene respecto a los demás con los que tiene conexión directa o indirecta (inter-dominio). Existe una jerarquía de encaminamiento que se refleja en la mayor o menor generalidad de los prefijos empleados para anunciar el dominio.

IPv4 comenzó a dar síntomas de saturación en los routers de los backbones. Aumentó de forma explosiva el número de prefijos que los routers habían de mantener en sus tablas, llegándose a alcanzar los límites físicos impuestos por la capacidad de memoria y de proceso.

Esto llevó a una modificación de los protocolos exteriores de encaminamiento para soportar prefijos de red variables. Este método se conoce como CIDR (Classless Inter-Domain Routing) y consiste en la agregación de prefijos que son adyacentes para dar lugar a prefijos menores (y por tanto más generales), con lo que se reducía el número de entradas en las tablas de los routers.

Se realizó también el experimento de dividir una red en multitud de pequeñas subredes. Los resultados fueron alentadores, por lo que dicha técnica podría utilizarse para ampliar de nuevo el tiempo de vida de IPv4.

Para entender bien el problema hay que tener en cuenta que el periodo de tiempo en el que los fabricantes duplican la capacidad de proceso de sus equipos y la de sus memorias es de aproximadamente dos años. La capacidad de los routers que deben mantener en sus tablas una información completa o full-routing sobre la topología de la Internet (equipos conectados a los backbones principales o de dominios conectados a múltiples proveedores - multi-homed -) se habría hoy día superado, con el colapso consiguiente de la Internet, si CIDR no hubiese sido puesto en funcionamiento a primeros de 1994. Hay que tener en cuenta que hay más de 60.000 redes conectadas mientras que los equipos que soportan full-routing manejan del orden de los 30.000 prefijos, estando el límite de tecnología actual en torno a los 40.000 prefijos.

En cualquier caso, hay que entender que tanto CIDR como las políticas restrictivas de asignación de direcciones son sólo medidas temporales, dirigidas a afrontar problemas concretos y que no resuelven (en algunos casos hasta agravan) los problemas crónicos detectados en la Internet en gran parte debidos a su tremendo éxito. Así, se han llegado a plantear iniciativas como la devolución de direcciones, la obligatoriedad de cambiar de direcciones al cambiar de proveedor (en un mundo en el que los operadores telefónicos están considerando introducir mecanismos para que esto no ocurra con el número de teléfono cuando se cambie de compañía), la asignación dinámica de direcciones, el uso de traductores de direcciones (NAT) que transformen un espacio privado de direcciones en otro perteneciente al proveedor, o incluso el cobrar una cantidad elevada por cada prefijo (no perteneciente al espacio del proveedor) que un cliente desee que su proveedor anuncie.

El encaminamiento propuesto permitirá la selección de proveedor por parte del origen así como la movilidad mediante el empleo de cabeceras de extensión de

encaminamiento en la que se especifique un camino elegido (que será recorrido a la inversa al regreso) mediante direcciones unicast o anycast.

La transmisión de información en tiempo real se podrá realizar mediante el empleo de dos campos en la cabecera IPv6. La prioridad, que distingue los diferentes tipos de datagramas según la clase de servicio y la etiqueta de flujo, que permite diferenciar y asignar distintos estados a distintos flujos originados por la misma fuente.

La transición hacia IPv6 ha de hacerse de forma gradual, sin afectar a los servicios que se prestan en la actualidad. En IPv6 el método propuesto se basa primordialmente en la coexistencia de ambos protocolos. Los nuevos sistemas que vayan incorporando IPv6 (ordenadores y routers) deberán mantener asimismo la plena capacidad de procesar paquetes IPv4. Para conectar las islas IPv6 que irán emergiendo mediante la infraestructura Internet actual se emplearán técnicas de encapsulado (túneles IPv6) en los datagramas IPv4 de forma similar a como funciona en la actualidad el Mbone. A medida que los routers vayan incorporando IPv6, los túneles se irán desmantelando para dar paso a una infraestructura ya basada en IPv6.

3.3.2.2. Política de enrutado

Tradicionalmente los datagramas se han encaminado atendiendo a criterios técnicos tales como el minimizar el número de saltos a efectuar, el tiempo de permanencia en la red, etc. Cuando la red pertenece a una única organización eso es lo ideal, pero en el nuevo entorno económico en el que diferentes proveedores compiten por el mercado las cosas no son tan simples. Es imprescindible que la fuente pueda definir por qué redes desea que pasen sus datagramas, atendiendo a criterios de fiabilidad, coste, retardo, privacidad, etc.

En Internet, cada nodo tiene una tabla de encaminamiento que contiene información sobre otros nodos de la red, de forma que los nodos pueden comunicar unos con otros referenciándose en la tabla. El encaminamiento en IPv6 trata las direcciones de una red como un conjunto de identificadores, y cada red requiere una entrada en la tabla de encaminamiento.

El problema reside, pues, en que la Internet crece. El encaminamiento se hace menos manejable con respecto a la eficiencia y requerimientos de memoria a medida que aumenta el número de direcciones IP. Para el objetivo de mantener la actual inversión en protocolos y aplicaciones de Internet, el encaminamiento de IPv6 es casi idéntico al de IPv4. Todo esto necesitará una transición muy controlada para que IPv6 sea operativo con los algoritmos similares a los que se usan en IPv4 (RIP, OSPF, IDRP, BGP,etc), en versiones para IPv6.

Las diferencias fundamentales residen en la longitud de las direcciones: 128 bit, en lugar de 32, lo que permite más niveles de jerarquía para reducir el tamaño de la tabla de encaminamiento y, como consecuencia, más eficiencia con menos memoria. También extensiones de encaminamiento que soportan nuevas funcionalidades de encaminamiento. Esto permite varias características nuevas:

Selección de proveedores: Una opción que permite a la máquina origen listar los nodos intermedios necesarios para alcanzar el destino. Esta opción viene en la base de la seguridad, prestaciones y coste.

Máquinas móviles: También llamadas plug-and-play. Esta función permitiría conectar una máquina a la red y poder alcanzar y ser alcanzada sin necesidad de configuraciones manuales. Las direcciones IP serían automáticamente asignadas y las tablas adecuadas debidamente actualizadas.

Redirección automática: El destino puede responder a la dirección origen invirtiendo la secuencia de direcciones, eliminando asi el proceso de encaminamiento.

3.3.2.3. Tipos de Máquinas y Encaminadores

Para entender el modelo de transición, es necesario conocer las diversas clases de máquinas y encaminadores. En el modelo existen cuatro tipos:

Nodos solamente IPv4 (IPv4-only-nodes)

Estos son máquinas y encaminadores que solamente reconocen IPv4.

Nodos IPv6/IPv4 (IPv6/IPv4-nodes)

Los encaminadores y máquinas de esta categoría tienen tanto IPv4 como la pila de protocolos de IPv6. Además tienen mecanismos como tunelado IPv6-sobre-IPv4. (IPv6-over-IPv4 tunneling) Estos nodos pueden interoperar directamente tanto con nodos IPv4 como IPv6, pero para una comunicación con nodos solamente IPv4 tienen que ser configurados con unas direcciones IPv6 compatibles con IPv4.

Nodos solamente IPv6 (IPv6-only-nodes)

Son máquinas y encaminadores que solamente conocen IPv6.

Encaminador traductor de cabeceras IPv6/IPv4 (IPv6/IPv4-header-translating-router)

Estos encaminadores traducen paquetes de IPv6 a paquetes de IPv4 y viceversa.

3.3.2.4. Renumeración de routers

Un cambio en proveedores significa un cambio en direcciones. Se evitan cambios manuales por ser indeseados y generar errores. Para ello existen mecanismos de expiración de direcciones en IPv6. Se usa un Prefix Control Operation (PCO) para cambiar el prefijo en distintas maneras. Los mensajes ICMP de cambio de numeración de router es enviado a todos los routers dependientes.

3.3.2.5. Mejoras

La gestión de Multicasting y Anycasting (IGMP) ha pasado a formar parte del nuevo ICMP. Para acelerar el cálculo del encaminamiento y atender las necesidades de las aplicaciones en tiempo real, cada datagrama puede contener un "identificador de flujo". Esos identificadores son, en cierta medida, equivalentes al concepto de circuitos virtuales, pero se trata de unos circuitos virtuales "suaves" que pueden ser desde ignorados hasta completamente vinculantes, según el diseño del sistema. Ello da un juego enorme. Éste es uno de los conceptos más novedoso e importante de IPv6.

3.4. Seguridad

Hasta hace pocos años, el uso de Internet estaba limitado a círculos técnicos, científicos y académicos. La gran mayoría de las personas no tenían acceso a la red o ni tan siquiera habían oído hablar de Internet.

En nuestros días Internet tiene influencia sobre todos los sectores de la sociedad, permitiendo desde el envío de correo electrónico hasta transacciones bancarias, pasando por todo tipo de compras, ventas, etc. servicios impensables hace un par de décadas.

Es por ello que surge la necesidad de implementar mecanismos para transmitir datos de forma segura entre máquinas. De esta manera evitaremos que cualquier persona pueda acceder, modificar, etc. la información confidencial que viaja por la red como pueden ser claves, ficheros personales, números de tarjetas de crédito...

3.4.1. Servicios de Seguridad

Existen tres servicios básicos que un sistema de seguridad debe cubrir:

• Confidencialidad

Sólo el destinatario de una determinada información debe poder entenderla.

• Integridad

Un mensaje no puede ser alterado durante la transmisión entre dos máquinas.

• Disponibilidad

El usuario ha de poder utilizar los servicios que ofrece la red en cualquier momento, sin que estos puedan ser degradados por un usuario ilegítimo.

Otras características deseables de un sistema de seguridad son ([RFC 1825]):

• Antirepudio

Una vez que un usuario realiza una acción, no puede negar el haberla realizado.

• Protección contra el análisis del tráfico

No debe ser posible monitorizar el flujo de información en una comunicación entre dos entidades.

Existen serias controversias acerca de dónde se deben situar los mecanismos de seguridad. Si estos se sitúan en la capa de red, se convierten en un servicio estándar que todas las aplicaciones podrían utilizar. El problema estriba en que una aplicación que pretenda ser segura no confiará en una implementación posiblemente defectuosa de la capa de red y deberá implementar la seguridad a nivel de aplicación, es decir, la aplicación destino descifrará lo que ha cifrado el origen.

3.4.2. Seguridad en IPv4

Hay dos opciones de seguridad en IPv4 que no han sido muy utilizadas y que muchos routers ignoran a la hora de encaminar los paquetes. Estas opciones están basadas en dividir a los nodos, datagramas y enlaces en cuatro diferentes categorías de seguridad. Un datagrama marcado con cierta categoría no debe ser enviado a través de un router o un enlace que tenga una categoría de seguridad inferior.

Este método presenta una ventaja ya que puede ser utilizado en lugares donde el uso de algoritmos de encriptado está regulado. Dos son las principales desventajas de este sistema de seguridad. En primer lugar, debemos confiar ciegamente en que los routers intermedios procesen y encaminen los paquetes correctamente. En segundo lugar, no proporciona los servicios básicos de seguridad descritos en el apartado anterior.

3.4.3. Opciones de seguridad en IPv6

La necesidad de disponer de servicios de seguridad por debajo de la capa de aplicación hace de IPv4 un sistema con ciertas carencias. El propósito de IPv6 es subsanar las mismas mediante dos opciones que proporcionan servicios de seguridad de forma que puedan ser utilizadas conjuntamente con otras dependientes de las necesidades de cada usuario en particular.

3.4.3.1. Cabecera de Verificación de Autenticidad (Authentication Header)

La cabecera de verificación de autenticidad ([RFC 1826]) es una cabecera de extensión que proporciona autenticidad e integridad pero no confidencialidad a los campos de los datagramas IP que no cambian durante el camino entre dos sistemas finales.

En una sesión de transferencia de datos segura, tanto el cliente como el servidor necesitan tener una clave que sólo ellos conocen (el tema de los protocolos de intercambio de claves es un problema que no concierne a IPv6). Cada comunicación tiene asignado un valor pseudo-aleatorio único denominado SPI (Security Parameter Index) de 32 bits. Antes de enviar un paquete se crea una suma de comprobación basada en la clave y combinada con el contenido del paquete. El valor de los campos que cambian durante la transferencia, como el Límite de Saltos, se toman con valor cero a efectos del cálculo de la suma de comprobación.

MD5 se ha propuesto como algoritmo por defecto para el cálculo de sumas de comprobación, lo cual no quiere decir que los usuarios no puedan definir sus propios algoritmos o utilizar otros como SHA o RSA, cada cual con sus ventajas y desventajas.

El valor de la suma de comprobación se recalcula en el receptor y se compara para asegurar que todo ha ido bien. Esta solución asegura que un paquete proviene del host indicado en el campo de la dirección origen y garantiza que los datos en el paquete no hayan sido modificados durante el trayecto por un tercero.

Con esta medida evitamos, por ejemplo, que un usuario malicioso pueda configurar una máquina para que genere paquetes con una dirección origen falsa, obteniendo ilícitamente acceso a una máquina, sus ficheros de datos, passwords, etc.

Naturalmente, el proporcionar autenticidad a los datos incrementa el tiempo de proceso, pero proporciona un nivel de seguridad muy elevado según [RFC1825]. Por lo tanto habrá que buscar un compromiso entre seguridad y velocidad de procesado.

La siguiente figura muestra el formato de una cabecera de verificación de autenticidad:

Tres son los campos que merece la pena comentar:

• El campo de datos de autenticidad (Authentication Data) contiene el valor de la suma de comprobación

• El campo de número de secuencia (Sequence Number) es un contador que se inicializa a cero cuando se establece el SPI.

• El campo SPI

3.4.3.2. Cabecera de extensión de carga útil cifrada de seguridad (Encapsulating Security Payload Header)

Esta opción proporciona, a través del encriptado, la confidencialidad que no ofrecía la cabecera de verificación de autenticidad para mensajes cuyo contenido no debe ser visible para cualquiera. Esta confidencialidad se ve limitada si no combinamos el encriptado con la autenticidad de los datos.

El encriptado se basa en la cabecera de extensión de carga útil cifrada de seguridad (ESP). El algoritmo DES-CBC (DES en modo de encadenamiento de bloque cifrado) se ha propuesto como estándar ([RFC 1829]) para el encriptado, aunque, al igual que ocurría con el algoritmo MD5 para el caso de la cabecera de verificación de autenticidad, no es obligatorio. Este mecanismo, no obstante, probablemente no sea tan exportable como la cabecera de verificación de autenticidad ya que hay países en los que existen leyes estrictas en lo que se refiere al cifrado de datos.

En la siguiente figura podemos ver la estructura de una cabecera de este tipo:

El significado de los campos SPI y el número de secuencia (Sequence Number) es el mismo en el caso de la cabecera de verificación de autenticidad.

El mensaje encriptado se incluye en el campo Payload Data. El uso de relleno (padding) esta justificado ya que algunos algoritmos de encriptado como DES requieren que el texto original sea múltiplo de un cierto número. Por ejemplo, el algoritmo DES opera con bloques de 64 bits ([RFC 1829]). El tamaño de la cabecera ESP ha de ser múltiplo de 32 bits lo que significa que también en este caso puede ser necesario el relleno para conseguirlo. Una tercera razón que justifica el relleno es que de esa forma se oculta el tamaño real del mensaje.

Por defecto, el relleno se hace con enteros de la forma 1, 2, 3, y así sucesivamente. Si se usa este tipo de relleno, el receptor lo comprueba. Se eligió este relleno por su sencillez y facilidad de implementación en hardware, aunque proporciona un nivel de protección algo menor.

El campo de datos de autenticidad (Authentication Data) contiene la suma de comprobación de los datos. Es opcional y se incluye sólo en el caso de que se haya elegido el servicio de autenticidad. Su longitud es variable y depende del algoritmo que se haya elegido para su cálculo.

Tanto la cabecera de autenticidad como la ESP se pueden utilizar de dos formas diferentes:

• Modo tunel (tunnel mode)

En este caso el datagrama completo es autentificado/encriptado, añadiendole una nueva cabecera IP.

• Modo transporte (transport mode)

De esta manera, tan solo los datos son autentificados/encriptados, no así la cabecera.

Para facilitar la detección de falsos paquetes, la comprobación de autenticidad se lleva a cabo antes que el desencriptado. Parece lógico ya que no nos interesan los paquetes cuyos datos puedan haber sido falsificados.

Es una buena característica el que la autenticidad esté separada del encriptado ya que de esta forma se puede comprobar la autenticidad de los datos en países donde existen estrictas leyes que regulan el encriptado de modo que está prohibido, limitado, o es demasiado caro utilizarlo (por ejemplo en Francia, Irak o los mismos Estados Unidos).

Conforme evolucionan las computadoras, los algoritmos de encriptado que parecen irrompibles se vuelven rompibles. Surge la preocupación de saber si los algoritmos por defecto son suficientemente seguros. Los avances en criptografía han mostrado las debilidades de MD5, mientras que el algoritmo DES ya no es lo suficientemente seguro como lo era cuando se creó en 1977. Este problema se soluciona dotando al usuario de capacidad de remplazar estos algoritmos por otros que él elija.

4. Planes de introducción de IPv6

Vamos a comentar ciertos aspectos y características que se presentan a la hora de implementar el IPv6 sobre diferentes tipos de redes.

En este tipo de redes hay que atender a diferentes aspectos:

La MTU (unidad máxima de transferencia), algo así como la longitud máxima para los paquetes en cada uno de las diferentes redes. El tamaño de la MTU para paquetes de IPv6 es generalmente al igual que Ethernet (la red de área local más extendida en la actualidad) de 1500 octetos o bytes. El tamaño puede ser reducido por un router anunciante DISC el cual contiene una opción en el MTU, que especifica una MTU más pequeña si fuera necesario, o puede tener esa información manuales que poseen cada nodo.

Si un router anunciante percibe en Ethernet que tiene una opción especificando una MTU de más de 1500 octetos, esa opción del MTU puede ser llevada a un sistema manejador para ser tratada, pero puede también ser anulada o simplemente ignorada dicha opción.

Actualmente se están investigando diferentes caminos para soportar envíos en multimedia con una calidad adecuada, dentro de redes tales como Internet. El objetivo es desarrollar recursos de interconexión de redes desde conectores y routers a sistemas que pueden cumplir funciones en nombre flujos de corriente de sistemas finales.

La evolución de varios procesamientos en multimedia desde sistemas finales a redes tienen un número de ventajas implementadas con el IPv6.

IP sobre ATM

Este proyecto es investigando los problemas de funcionamiento del IPv6 a gran escala, servicios de redes de ATM, incluyendo en el IP previsiones de QoS calidad y servicio.

La comitiva de Lancaser está en ello desde 1992, utilizando el IPv6 han desarrollado dicha tecnología por toda Gran Bretaña.

Mobile IPv6

El proyecto RASCAL está investigando que características pueden ser usadas para construir móviles adaptados a sistemas capaces de manejar Internet desde dichos portátiles, sea cual sea su situación y el medio en el que se encuentre ofreciendo una calidad de servicio óptima.

Implementaciones de IP en diferentes compañías:

• Apple Computer y Mentat Inc.

En Octubre de 1995 Networld+interOp sacó a la luz un prototipo de implementación del IPv6 sobre Apple Open Transport. La demostración dejaba patente una flexibilidad del entorno de Open transport, con actuales aplicaciones de IPv4, tales como Fetch (buscador), Nestcape, y Web*Star llevado a cabo sobre soporte de IPv6, y enseñó los beneficios basados en la arquitectura conseguida, con una codificación más fácil. La demostración también incluyó pruebas básicas de interoperacionalidad, con implementaciones del prototipo de IPv6 pertenecientes a DEC y HP usando Ping y Telnet. Apple y Mentat continuarán trabajando juntos para asegurar una oportuna disponibilidad de IPv6 para MacOS una vez que el estándar haya sido completado.

• BSDI

Está trabajando en una implementación en IPv6. Está participando en el proyecto 6bone, que incluirá IPv6 en sus primeros servicios de Internet, todo esto se llevó a cabo alrededor de 1998.

• COMPAQ COMPUTER CORPORATION

Ha implementado versiones de IPv6 en Alpha Tru64 UNIX Alpha OpenVMS.

La implementación Tru64 UNIX soporta estaciones específicas para IPv6 y también puede cumplir como un router. Sus implementaciones se han desarrollado principalmente en 6bone y proporcionan Tru64 UNIX a los usuarios con kits binarios.

• BULL SA

Es soporte de sus máquinas AIX432 y ahora AIX 433. Contienen implementaciones de estación /router para IPv6, basadas en fuentes de DYADE(GIE INRIA-Bull) y también contiene IPSEC con IKEv6.

4.1. 6BONE

El 6bone es una extensión independiente del proyecto IPng del IETF (Internet Engineering Task Force) que surgió como resultado de la creación de los protocolos IPv6 que en un futuro, esperemos que muy cercano, sustituirá al actual protocolo de red de Internet IPv4. El 6bone es un proyecto en el que colaboran Norte América, Europa y Japón.

Una parte esencial para la transición entre IPv4 y IPv6 es el desarrollo de una cierta infraestructura que permita transportar paquetes de IPv6 sobre Internet. Al igual que ocurre con la red backbone de IPv4, el backbone de IPv6 estará compuesto por una serie de proveedores de servicios de Internet (ISP) y las redes de usuarios, todo ello debidamente interconectado. Pero hasta que todos los protocolos de IPv6 estén lo suficientemente comprobados y depurados, IPv6 no podrá sustituir a IPv4. Por este motivo, se necesita alguna manera de transportar paquetes de IPv6 de una forma organizada para comprobar su funcionamiento, para lo que se creó 6bone.

6bone es una red virtual implementada sobre la actual red basada en IPv4 que permite el encaminamiento de paquetes IPv6. Esta red está compuesta por “islas” que están adaptadas para soportar paquetes de IPv6, las cuales están interconectadas por enlaces punto a punto virtuales, denominados túneles. En la siguiente figura se representa este esquema. En RedIRIS hay instalados dos routers y un sistema final, mientras que en la Universidad de Murcia sólo hay un sistema final. Esta red tiene como vecina a la holandesa SURFNET y, a partir de ahí, se encuentra con el resto de 6bone.

El problema que surge a la hora de hacer la transición entre IPv4 e IPv6 es cómo transformar Internet sin interrumpir la existencia de la red operativa. Esta transición debe hacerse de una forma gradual y debe permitir la coexistencia durante un buen periodo de tiempo de ambas tecnologías y se ha planificado hacer en dos fases. Al término de la primera habrá tanto host y routers de IPv6 y al término de la segunda sólo debe haber host y routers de IPv6. Para realizar esta transición, se utilizan cuatro tipos de encaminadores y máquinas:

1. Nodos solamente IPv4 (IPv4-only-nodes)

Estos son máquinas y encaminadores que solamente reconocen IPv4.

2. Nodos IPv6/IPv4 (IPv6/IPv4-nodes)

Los encaminadores y máquinas de esta categoría tienen tanto IPv4 como la pila de protocolos de IPv6. Además tienen mecanismos como tunelado IPv6-sobre-IPv4. (IPv6-over-IPv4 tunneling), por lo que estos nodos pueden interoperar directamente tanto con nodos IPv4 como IPv6, pero para una comunicación con nodos solamente IPv4 tienen que ser configurados con unas direcciones IPv6 compatibles con IPv4.

3. Nodos solamente IPv6 (IPv6-only-nodes)

Estos son máquinas y routers que solamente conocen IPv6.

4. Router traductor de cabeceras IPv6/IPv4 (IPv6/IPv4-header-translating-router)

Estos routers traducen paquetes de IPv6 a paquetes de IPv4 y viceversa.

Por otra parte, se utilizan túneles que consisten en introducir los paquetes de comunicaciones IPv6 en paquetes de datos de la red actual, y de este modo se hace uso de la red sin afectarla en absoluto. Uno de los requisitos para el tunelado es que el comienzo y los extremos del túnel sean nodos IPv6/IPv4 con direcciones compatibles con IPv4. La idea del tunelado es que los paquetes IPv6 son introducidos en el campo de datos de un paquete IPv4 y enviados a través de áreas de red de IPv4, con la característica de que el extremo es un nodo IPv6/IPv4 que se encarga de desencapsular el paquete. Hay dos tipos de tunelado:

a) Tunelado Automático (Automatic Tunneling)

El tunelado automático es utilizado entre dos máquinas IPv6/IPv4. Es "end-to-end". Puede también utilizarse si un router va a enviar un paquete IPv6 a una máquina IPv6/IPv4 que esté conectado a la misma área de red de IPv4. Es importante que el extremo del túnel sea la máquina de destino.

b) Tunelado Configurado (Configured Tunneling)

El tunelado configurado se utiliza si la máquina de destino es diferente a la del extremo del túnel. En este caso, la dirección de destino para la cabecera de IPv4 (p.e: la dirección del endpoint del túnel) no podría ser simplemente mapeada de la dirección de destino IPv6. El endpoint del túnel tiene que ser configurado en el nodo IPv6/IPv4.

Con el paso del tiempo, se espera que 6bone desaparezca por acuerdo de todas las partes, para ser sustituido por ISP y redes de usuario que permitan el transporte de datagramas de IPv6.

6bone está enfocado para adquirir una experiencia temprana en esta arquitectura de comunicaciones, obteniendo conocimientos en todos los aspectos de ella: routing, DNS, uso de aplicaciones… De hecho, el deseo prioritario es incluir el mayor número de ISP y redes en 6bone para facilitar la transición a IPv6 y, además, colaborar en el desarrollo de los programas y protocolos.

Actualmente, el 6bone está formado por más de 500 sites repartidos en 42 países diferentes, y todos ellos están registrados en una base de datos (6bone Registry). En España hay 8 sites (CESCA, ENCOMIX, REDIRIS, REDIRIS-HQ, TELDAT, Univ. Murcia, Univ. Valencia, Univ. Valladolid). Cada site 6bone debe mantener las entradas relevantes en el registro, concretamente los siguientes campos deben aparecer para todos los sites, pNLA y pTLA:

• IPv6-site : Descripción del site

• Inet6num : Prefijo de su delegación.

• Mntner : Información de contacto para el mantenimiento del site o personal de administración.

Se pueden incluir otras entradas a voluntad de los sites, tales como descripción de la política de encaminamiento, personas, tareas, etc. El Mntner tiene que hacer referencia a una tarea o una persona, pero no es necesario que estén en el registro. Se pueden almacenar como cualquier campo del registro de Internet ARIN, APNIC, …).

Para ver la estructura de esta red virtual, es interesante ver cómo suscribirse a esta red, ya que, al mismo tiempo se hace un repaso de todos los componentes necesarios para estar conectado y las características que estos deben tener.

El primer paso consiste en unirse a la lista 6bone. Este paso es muy sencillo, ya que sólo hay que enviar un mensaje a majordomo@isi.edu, diciendo que deseas suscribirte. El equipo mínimo que se necesita es un dispositivo que actúe como router y otro que haga el papel de host. Aunque en teoría es posible que la misma máquina cumpla estas dos funciones, se recomienda que sean distintas para ayudar a obtener conclusiones en un entorno local.

Sobre los routers que se deben usar no existe ninguna recomendación específica, tan sólo se dice que sea un dispositivo dedicado exclusivamente a esta tarea, ya sea una estación de trabajo o un router real. En la actualidad se está trabajando sobre estos temas y diversas compañías están desarrollando routers para IPv6 y diversas implementaciones para utilizar las estaciones como routers. También es necesario que el router soporte RIPng o BGP4+ (Border Gateway Protocol)

No olvidemos que lo que se pretende es transmitir paquetes de una interfaz a otra, donde hay (en un lado) una estación que soporta IPv6 y una conexión a una subred que permite acceder a Internet usando un tunel al 6bone para transportar los paquetes de IPv6. Todas estas tareas se pueden realizar con sólo un interfaz, pero no se hace así porque resulta mucho más costoso y complicado depurar y controlar y puede resultar un problema bastante serio cuando el tráfico se multiplica en uno de los interfaces.

En lo que se refiere a las estaciones de trabajo, por ahora la mayoría de ellas son variantes de UNIX, pero también hay implementaciones en Windows 95/98 y Windows NT/2000.

Llegados a este punto, conocemos las características de los routers y de las estaciones de trabajo, pero para formar parte de 6bone hay que elegir un site al que conectarse, ya sea un pTLA (pseudo TLA 6bone backbone transit) o pNLA (pseudo NLA non-backbone transit). Con esto lo que se consigue es configurar un tunel basado en IPv4 desde el router IPv6 al punto de entrada al 6bone que se encargará de transportar los paquetes.

En principio se puede elegir cualquier punto de acceso al 6bone para que sea este el que soporte la conexión, pero se han considerado unas ciertas reglas prácticas para establecer este camino sobre IPv4, ya que esta ruta no está bajo nuestro control. Por ejemplo, si elegimos nuestro pTLA en Nueva Zelanda, nuestros paquetes de IPv6 seguirán cualquier ruta basada en IPv4 que exista desde aquí hasta Nueva Zelanda y desde allí ya seguirán una ruta hasta su destino final. Esto no parece muy lógico, y más si tenemos en cuenta que tenemos otros puntos de acceso más cercanos (físicamente), por lo que la ruta que seguirán (que no es controlada por nosotros) será más pequeña.

Por tanto, se debería buscar un punto de acceso al 6bone que esté lo suficientemente cerca teniendo en cuenta los caminos de IPv4 en Internet. Para encontrar ese punto, tan sólo hay que mirar el registro 6bone, del que ya se comento algo anteriormente, y usar la lista del 6bone pTLA junto con pings y traceroutes de IPv4. Con la lista de 6bone y pTLA conseguimos un vínculo entre el nombre del pTLA con su entrada en el Registro de 6bone. Los pTLA's se encuentran en una lista con su país o estado (en EEUU). Por lo tanto, alguien en Oklahoma puede usar MERIT/US-MI (que cubre el medio del país), por lo tanto debería ir a la entrada de Merit en el registro 6bone y obtener un túnel IPv4 y sacar su dirección IPv4 mediante ping y traceroute.

Esta tarea se puede realizar varias veces hasta dar con el pTLA óptimo, pero requiere obtener varias entradas en el registro.

Una vez que se obtiene una pequeña lista de todos los posibles pTLA/pNLA a los que conectarse mediante un túnel, usando la dirección de contacto en el registro (uno de los campos que es obligatorio) se solicita la conexión directamente vía e-mail. Una vez que nos confirman la conexión, ya formamos parte de 6bone y podemos pasar a otras tareas. La primera de ellas es actualizar el registro de 6bone con nuestra información, para que se nos pueda asignar una dirección y el resto de los registrados en el 6bone puedan contactar con nosotros para tratar de solucionar problemas y hacer consultas.

Como ya se comentó antes, los campos que se deben crear para introducir una entrada en el registro son: IPv6-site y person. En este último se da información de la persona que se encargará de todas las tareas relacionadas con 6bone. Estos campos de información se crean mediante un archivo de texto y se envía a auto-dbm@isi.edu. Además de estos dos campos, hay que solicitar a Bob Fink que cree un campo mntner para nosotros donde se de la información de contacto.

Llegados a este punto, sólo falta que nos proporcionen la dirección IPv66. Para esto, sólo hay que contactar con el pTLA/pNLA que soporta la conexión para pedirle que te asigne una dirección IPv6. La característica más importante de esta dirección es que están totalmente determinada por el proveedor/punto de acceso al 6bone. Consta de un prefijo de 48 bits que depende de la topología y especifica de forma jerárquica la ruta de nuestro site al 6bone. El resto de los 80 bits se usan para especificar otras direcciones, no siendo necesario justificar este espacio como se debe hacer para el caso de una dirección IPv4. Resumiendo, tenemos un campo de 16 bits para usar como indicador de una subred y otro de 64 para determinar las estaciones y router de esas subredes. Esto significa que con un podo de esfuerzo se pueden soportar hasta 65000 subredes distintas, cada una con todos los sistemas finales que se quieran. La única limitación en este número de sistemas finales está en la limitación de espacio físico y en la limitación del número de estaciones que se pueden conectar al medio físico de esa subred.

Con esta dirección, el proveedor del 6bone (pTLA/pNLA) creará el campo inet6num que faltaba en nuestra entrada del registro de 6bone para completar los campos obligatorios.

Ahora, el proveedor de 6bone se encargará de trabajar con nosotros para configurar el túnel para alcanzar el site. Esta información se debe añadir al campo de ip6-site para constatar que se ha hecho así. Estas especificaciones se usan para averiguar la topología de la red, para construir esquemas de la red para comprobar la fiabilidad, accesibilidad y comportamiento, por lo que es importante que estén actualizadas.

Para que todo funcione, además, es necesario tener un servidor de nombres que establezca las equivalencias entre los nombres y las direcciones IPv6. En la actualidad, todavía no existe un servidor DNS para IPv6, por lo que para hacerlo funcionar se implementa sobre un DNS de IPv4, de forma que el sistema que soporta IPv6 está ligado a la información de IPv4. Sin embargo, algunas de las implementaciones de DNS ya empiezan a soportar IPv6 (bind8 y bind9).

Para definir las extensiones del DNS para soportar IPv6, existen algunos documentos (RFC1886, Draft-ietf-IPngwg-dns-lookups-06 y RFC1912). Los dos primeros se encargan de definir el direccionamiento para IPv6, ya que no existe ninguna implementación disponible en la actualidad (bind9 lo hará, pero todavía está bajo desarrollo). Por otra parte, el RFC 1912 proporciona una serie de recomendaciones para instalar DNS sobre IPv4, insistiendo particularmente en la necesidad de crear ficheros de la zona local para minimizar la carga de los servidores del root. Para crear este fichero, se deben crear varias zonas: Una para los nombres de dominio válidos y las direcciones a las que enviarlo, otra (u otras) para los enlaces de la zona local y sus nombres correspondientes y, si fuera necesario, otra/s zonas si el site usa direcciones de organización local. De una forma análoga a la explicada en este RFC se hará para IPv6.

La plataforma recomendada para ejecutar DNS con IPv6 es BIND 8.2.2-P5, aunque algunas versiones anteriores también se pueden usar. Pero se recomienda 8.2.2-P5, porque es el código distribuido actualmente, porque IPv6 hace uso de actualizaciones dinámicas y otra serie de mejoras del protocolo DNS y por motivos de seguridad, entre otros.

4.2. Futuro de IPv6

A pesar de los inconvenientes que puedan surgir a la hora de utilizar este protocolo o al cambiarlo por su antecesor, se puede ver claramente que goza de una serie de ventajas que son de mucho mayor peso específico, por lo que la ganancia en el cambio de IPv4 a IPv6 es muy elevada, sobre todo teniendo en cuenta las actuales tendencias de los servicios ofrecidos a través de Internet y los servicios demandados por los usuarios. Dichos servicios son muy complicados, aunque no imposibles de realizar con la actual versión de IP (ya que cuando se ideó, por los años 60-70, las necesidades para la conexión de ordenadores eran otras) y siempre con una calidad de servicio no demasiado aceptable, aunque depende seriamente de la carga de la red, situación que debería tratar de evitarse en la medida de lo posible.

Las particularidades de IPv6 hacen que este protocolo sea lo suficientemente robusto como para soportar un transporte de datagramas con las características requeridas para los servicios demandados.

Uno de los servicios más demandados es el de las comunicaciones en tiempo real, tanto para grandes empresas (pueden ganar/perder mucho dinero por la falta de información), como para un usuario común que busca conocer gente de otros lugares del planeta para conversar con ellos. En la actualidad existen aplicaciones que necesitan realizar comunicaciones en tiempo real y para conseguirlo deben tener una serie de recursos reservados en la red. El protocolo que se encarga de desarrollar y estandarizar una serie de procedimientos de Internet para instalar para instalar y mantener esta reserva de recursos es el RSVP (ReSerVation Protocol).

Este protocolo se utiliza para solicitar una determinada calidad de servicio de la red para una cadena de datos de una aplicación llevando la solicitud por toda la red, visitando cada nodo por el que pasa la cadena de datos y haciendo una reserva de recursos para esa cadena. Para hacer la reserva RSVP se comunica con dos módulos de decisión locales: control de admisión y de política. El primero de ellos se encarga de determinar si existen los suficientes recursos para soportar la QoS (calidad de servicio) y el segundo para ver si el usuario tiene permiso administrativo para hacer la reserva.

Una característica de este protocolo es que llega hasta una gran cantidad de grupos de multidifusión porque usa peticiones de reserva orientadas por el receptor que se combinan durante el camino de multidifusión. La reserva para un único receptor no necesita viajar hasta el origen del árbol de multidifusión, sino que sólo viaja hasta que se alcanza la rama reservada del árbol. Aunque el protocolo RSVP se ha diseñado específicamente para aplicaciones de multidifusión, también puede hacer reservas de unidifusión. Además el diseño utiliza la robustez de los algoritmos de encaminamiento actuales de Internet para determinar dónde debe llevar las peticiones de reserva. RSVP funciona sobre IP, tanto IPv4 como IPv6 y suministra un transporte opaco para los mensajes de control de tráfico y control de política, suministrando operaciones transparentes a través de regiones que no lo soporten.

Por otra parte, como se comentó anteriormente, una de la características de IPv6 es que tiene la capacidad de hacer direccionamiento multicast, es decir, el destino es un conjunto de computadoras, posiblemente en múltiples localidades a las que se le entregará una copia del datagrama, siempre que empleen hardware de multidifusión si están disponibles. Por tanto, esto mejorará la eficiencia del protocolo RSVP, respecto a la utilización del protocolo IPv4, que no tiene esta posibilidad de hacer direccionamiento multicast (la tiene pero con matices importantes). Por si fuera poco, la utilización de este tipo de direccionamiento multicast también permite un encaminamiento más preciso para el tráfico de multidifusión, lo que permite reducir la congestión de la red y mejorar la seguridad.

Una aplicación concreta (WebTalk) de estas comunicaciones en tiempo real es la posibilidad de mandar mensajes a través de Internet para mantener una conversación, oyendo al interlocutor como si estuviese hablando por teléfono. Esta aplicación es muy parecida a los más conocidos chats o talk, que consisten en tener una conversación con otra u otras personas a través de Internet, en tiempo real y por escrito, aunque se diferencia de éstos en que incorpora sonido, por lo que se parece aún más a los sistemas telefónicos actuales, con la diferencia de que la transmisión de los datos se hace a través de Internet. Al igual que los chats o talk antes mencionados, sólo se necesita para tener un navegador de www y suficiente memoria, pero al incorporar sonido es necesario tener una tarjeta de sonido.

Otro de los servicios que se ofrecen es la videoconferencia a través de Internet, a pesar de que la transmisión de imágenes en movimiento es problemática porque saturan la red.

La Universidad de Cornell (New York) ha desarrollado un programa gratuito (CU-Seeme) que permite la transmisión de videoconferencia en las que pueden participar varias personas. Aunque RedIris ha recortado en España la posibilidad de crear sesiones con esta aplicación porque están totalmente incontroladas y colapsan la red.

La mejora con respecto IPv4 para este tipo de servicios es muy importante, ya que IPv6 permite tratar todos los paquetes pertenecientes a la videoconferencia como un flujo de paquetes eliminando considerablemente el retardo de procesamiento, al tener que procesar sólo el primer paquete del grupo. Si a esto le añadimos que etiquetando los paquetes con una cierta prioridad podemos conseguir que se descarten datagramas que no añaden nueva información, y con ello conseguimos no colapsar la red, esto nos da como resultado una tasa de transmisión prácticamente constante con un retardo muy pequeño, lo que lo hace ideal para las videoconferencias.

También se puede afirmara con toda rotundidad que IPv6 ayuda a mejorar los servicios tradicionales que ofrece IPv4. Las características de la nueva versión de IP, hacen que estos servicios que se ofrecen sean mucho más seguros, por ejemplo, en la transmisión de datos, mayor velocidad en los elementos audiovisuales y mejor forma en su contenido.

Además de mejorar los servicios existentes, IPv6 ha creado un nuevo mercado de productos sobre la red de redes, como la difusión de canales de televisión vídeo bajo demanda y telecontrol. En lo que se refiere a la difusión de canales de televisión, tiene la ventaja de contar con una serie de clientes fijos. La idea en la que se basa es la de tener los host de Internet un canal de difusión de televisión y vídeo, permitiendo que los nuevos televisores tengan conexión directa a Internet. Hoy día es un hecho que la diferencia entre un ordenador y un televisor es cada vez menor. Si a eso le añadimos que los costos de transmisión, control y adquisición son más bajos que los medios actuales de transmisión para televisión y que una empresa puede ofrecer sus servicios alrededor del mundo sin tener que invertir en canales de comunicación, se puede afirmar con seguridad que llegará un momento en el que se sustituirán las antenas por un cable de fibra óptica, por el que además circularán otro tipo de señales de otras comunicaciones. De hecho, el gobierno de los Estados Unidos tiene previsto tener cableados todos los hogares de su territorio con fibra óptica en un breve espacio de tiempo. Por otra parte, en Europa se avanza más lentamente y en España se calcula que para el presente año esté cableado algo menos del 50% del territorio nacional, siendo muy optimistas. En el momento en que llegue este cable a todos los hogares, desaparecerán todos los demás: el teléfono, el de la electricidad y el de las ondas de televisión, para convertirse en uno grande y único, lo que permitirá la transferencia de informaciones en muy poco espacio de tiempo, lo que supondrá un importante ahorro económico.

El otro de los mercados que toma fuerza con IPv6 es el mundo del tele-control. Este servicio consiste en tener control diario sobre los equipos electrónicos como equipos de iluminación, equipos de calefacción, motores y toda clase de equipos que se puedan controlar mediante switches tanto analógicos como digitales. Este mercado es grande y requiere soluciones simples y robustas a muy bajo costo, por lo que la potencia del pay-back en el control por redes sobre IPv6 es el medio para alcanzar este servicio, pero tampoco podría ser muy rentable este mercado si no fuera por la mejora en la seguridad que ofrece IPv6, de la que ya se habló con la suficiente extensión anteriormente.

Recientemente, ha empezado a generar interés un lenguaje que amplía las posibilidades del HTML: el Virtual Reality Modeling Language (VRML). Este lenguaje permitirá introducir las páginas web en el mundo de las imágenes tridimensionales. Esta herramienta tiene mucha importancia ya que en un futuro no muy lejano el www será el elemento integrador de todas las aplicaciones de Internet como lo es ya del ftp o del Gopher. Pero las aplicaciones que van apareciendo llevan una componente multimedia que www tiene que saber interpretar, por esto se ha desarrollado VRML y es aquí donde entra en juego IPv6, ya que ofrece mejoras importantes en la transmisión de información audiovisual y multimedia.

5. CONCLUSIONES

En los últimos años hemos vivido una serie de cambios en el mundo de las Telecomunicaciones que han hecho de Internet una herramienta imprescindible en la vida moderna.

Pero el éxito de Internet ha sido un arma de doble filo, porque a la par que iba creciendo, se ha hecho cada vez más necesario un nuevo protocolo cuya introducción no es nada sencilla. Estamos hablando de IPv6.

La introducción de IPv6 ha sido mucho más gradual de lo inicialmente previsto. El problema principal es que IPv6 es incompatible con la actual versión de IP. Para utilizar el nuevo protocolo, los administradores de red deberán cambiar el software de protocolos en todos los dispositivos conectados; no sólo hosts, sino también routers y servidores de DNS. Este cambio ha de ser gradual, no se puede dar de un día para otro.

A pesar de esas y otras dificultades, las posibilidades que nos ofrece este nuevo protocolo eran impensables hace apenas un par de décadas. Abarcan desde el manejo eficiente de sistemas en tiempo real (videoconferencias, telefonía bajo IPv6, canales de TV, vídeo bajo demanda…) hasta telecontrol, pasando por compras, ventas, etc. Se puede llegar a pensar en un futuro en el que casi todo sistema que se comunique opere bajo el protocolo IP.

Del mismo modo que se pensaba que IPv4 iba a ser un fracaso y el tiempo ha demostrado que no era así, es muy difícil vislumbrar que es lo que ocurrirá si IPv6 se llega a poner definitivamente en marcha.

En resumen, IPv6 ofrece una notable mejoría respecto a IPv4. Cuando este último se desarrolló, se cubrían las necesidades de las redes académicas, científicas y militares en que se utilizaba, y a las que tan sólo una minoría tenía acceso. Con el “boom” de Internet la versión actual de IP se queda pequeña por lo que se hace necesario crear IPv6 que, al igual que IPv4, se ha desarrollado para cubrir las necesidades actuales, pero en un futuro, ¿Pasará lo mismo con IPv6?

6. BIBLIOGRAFÍA

Las principales fuentes de información utilizadas son:

[1] A.S. Tanenbaum. Computer Networks. Prentice-Hall. Tercera edición. EE.UU. 1996

[2] http://www.cs-IPv6.lancs.ac.uk/IPv6/documents/papers/stallings

[3] http://www.dtek.chalmers.se/~d1buj/xjodbsrapport.pdf

[4] http://www.isa.eup.uva.es/Docs/Proyectos/CATV_Internet/dos/2-3.html

[5] http://www.vc.ehu.es/wuagacaj/manual/internet/int-global/futuro.html

[6] http://www.6bone.net/6bone_hookup.html

[7] http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Whois/bycountry.html

[8] http://www.faqs.org/rfcs/rfc1883.html

[9] http://aurora.rg.iupui.edu/doc/rfc/rfc-html/rfc2402.html

[10] http://www.rediris.es/rediris/boletin/41-42/ponencia6.html

[11] http://www4.uji.es/~al019803/Tcpip.htm

[12] http://www.ipv6.org/

1

IPv6 Transmisión de datos

1

1

M

0 8 16 29 31 32

MF

OFFSET

RESERVADO

SIGUIENTE CABECERA

IDENTIFICACIÓN DEL DATAGRAMA