Transmisión de datos. Redes IPV6

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.
1
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
2
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
3
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
4
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.
5
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)
6
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:
7
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:
8
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).
9
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
10
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:
11
• 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).
12
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).
13
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.
14
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
15
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.
16
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
17
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).
18
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
19
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 :
20
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).
21
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.
22
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).
23
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
24
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
25
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)
26
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
27
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
28
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
29
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)
30
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
31
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
32
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.
33
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
34
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
35
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
36
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
37
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
38
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
39
M
0 8 16 29 31 32
MF
OFFSET
RESERVADO
SIGUIENTE CABECERA
IDENTIFICACIÓN DEL DATAGRAMA
40
41