La información siguiente ha sido extraída de la referencia detallada al final.
Esta nueva revisión del protocolo IP se numerará con la versión 6. No se la denominará versión 5 para evitar posibles confusiones, ya que anteriormente a esta revisión se hicieron algunas pruebas añadiendo extensiones a la versión 4. Estas extensiones experimentales no acabaron de formalizarse en una nueva versión del protocolo, con lo que para evitar posibles conflictos de numeración y/o confusión, se optó por elegir el número de versión 6.
Cabecera IPv4La nueva estructura de la cabecera del protocolo IP versión 6 se caracteriza
principalmente por dos particularidades:
1. Direcciones de 128 bits. Se ha creado una nueva estructura de direccionamiento que aumenta su tamaño de 32 bits a 128 bits. Este aumento es consecuencia del gran aumento que ha sufrido INTERNET en los últimos años, agotando el número de direcciones existentes y colapsando las tablas de encaminamiento de los routers.
2. Campos de longitud fija. Con el objetivo de minimizar el tiempo necesario para procesar y encaminar los datagramas por INTERNET, se adopta un formato fijo. De esta forma se agiliza el tráfico de datagramas y se suprimen opciones poco utilizadas. No obstante se mantiene la posibilidad de especificar opciones, pero ya sin formar parte de la cabecera IP como ocurría anteriormente.
El protocolo IP versión 6 sigue siendo al igual que las versiones anteriores, un protocolo no fiable y sin conexión. Esto continua siendo así debido a que la experiencia ha enseñado que este sistema funciona y da flexibilidad a la comunicación. Además permite que sean los protocolos de las capas superiores los encargados de mantener un estado de conexión o fiabilidad según crean necesario, manteniendo la estructura en capas del modelo TCP/IP.
El único campo que se mantiene en la misma posición y con el mismo significado que en formatos anteriores es el de versión, debido a que durante el tiempo de implantación de la nueva versión convivirán simultáneamente la versión 4 y 6. De esta forma, los routers podrán saber rápidamente si el datagrama que reciben es de una versión u otra.
Se han suprimido seis campos (tamaño de cabecera, tipo de servicio, número de identificación del datagrama, banderas, numero de byte del datagrama fragmentado y el checksum) respecto a la versión 4 del protocolo IP. Además se han redefinido los campos de longitud del datagrama, tiempo de vida y de tipo del protocolo.
La versión (4 bits) se sigue manteniendo como el primer campo del datagrama. Esto es así para mantener la compatibilidad con formatos anteriores y porque permite de una forma sencilla y rápida discriminar que versión de datagrama se recibe, facilitando a los routers el proceso de discriminar entre versión 4 y versión 6.
La clase (Class) es un número de 8 bits que hace referencia a la prioridad del
datagrama. Este campo es una de las nuevas aportaciones para conseguir algunos tipos de aplicaciones (videoconferencia, telefonía...) puedan realizarse en tiempo real.
El tipo de flujo (Flow Label) se compone de 16 bits, que permiten especificar que una serie de datagramas deben recibir el mismo trato. Esto es aplicable por ejemplo a una serie de datagramas que van del mismo origen al mismo destino y con las mismas opciones. Junto con el campo de clase (Class) permiten aplicaciones en tiempo real.
El tamaño de los datos (Payload Length) al igual que en la versión 4, es un número de 16 bits, lo que permite un tamaño máximo en principio de 2^16 = 65536 bytes (64K).
No obstante, a diferencia de la versión 4, este número hace referencia sólo al tamaño de los datos que transporta, sin incluir la cabecera (Si en IPv4 enviamos 100 bytes de datos utilizando TCP, tendríamos que el valor seria 100 bytes + 20 bytes de cabecera TCP + 20 bytes de cabecera IP versión 4 = 140. En IPv6 suponiendo los mismos valores nos darían un valor de 120. No se contaría el tamaño de la cabecera IP).
La siguiente cabecera (Next Header) es un valor de 8 bits que indica al router si tras el datagrama viene algún tipo de extensión u opción. Este campo substituye al campo de banderas (flags) de la versión 4. De esta manera, en lugar de complicar la cabecera IP con la interpretación de los diferentes bits de opciones, se sitúan fuera del datagrama básico. En la versión 6 del protocolo IP se definen una serie de cabeceras de extensión que se colocan justo después de los datos en forma de cadena (daisy chain) y que permiten al usuario personalizar el tipo de datagrama. De tal forma que podemos tener varias extensiones de cabecera tan solo indicando en el campo de siguiente cabecera de cada una de ellas el tipo de la cabecera que vendrá a continuación.
El alcance del datagrama (Hop Limit) es un número de 8 bits que indica el número máximo de routers que puede atravesar un datagrama hasta llegar a su destino. Este campo es el equivalente al tiempo de vida (TTL) de la versión 4. Cuando un datagrama llega a un router y es encaminado hacia otro ordenador, este campo es decrementado en una unidad. Este campo es necesario para evitar que los datagramas circulen infinitamente por la red, eliminándose al llegar a 0 (su valor máximo es de 2^8 = 256).
De este tamaño podemos deducir que para que exista comunicación entre dos
ordenadores conectados a INTERNET deben de estar alejados como máximo por 255 routers. Es sorprendente que aunque se haya ampliado considerablemente (de 32 bits a 128 bits) el número de ordenadores que pueden conectarse a INTERNET, se mantenga la esperanza de que la distancia entre dos ordenadores no crecerá por encima de este valor. Los protocolos de nivel superior (TCP, UDP...) pueden a su vez implementar algún tipo de control sobre los paquetes duplicados o huérfanos, utilizando por ejemplo
un sistema de control del tiempo usando relojes (timestamps).
Cabeceras del protocolo IP versión 6.
La cabecera IP versión 6 no contiene ningún tipo de opciones a diferencia de la versión 4. No obstante, en algunos casos se hace necesario poder especificar algunas características especiales a los routers intermedios para que traten el datagrama IP de una forma determinada. No todos los
datagramas son datos que circulan de un usuario a otro por INTERNET, algunos son mensajes entre los diferentes routers (Ejemplo: comunicar que está congestionado o fuera de servicio para que no le envíen mas datagramas).
Cabecera IPv6
Un ejemplo típico podría ser la necesidad de especificar por que routers debe circular el datagrama. Si queremos una ruta fija entre dos ordenadores, ya sea porque no nos fiamos de los demás o simplemente porque queremos medir el rendimiento entre dos puntos, necesitamos especificar por dónde encaminarlo, evitando que sean los routers intermedios los que tomen la decisión. La manera de hacerlo es indicar en el campo siguiente cabecera (Next Header) de datagrama IP el número correspondiente a la cabecera que colocaremos tras el datagrama de esta forma, el router sabe que antes de encaminar el datagrama, debe de tener en cuenta esa información extra.
La cabecera de encaminamiento (Routing Header) tiene la misma función que en la versión 4. Son cuatro bytes (valor máximo de cada opción 2^8 = 256) de cabecera a los que se añade una serie de direcciones de 128 bits que corresponden a los routers por los que debe pasar el datagrama hasta llegar a su destino. El primer campo es el de siguiente cabecera (Next Header), ya que la versión 6 utiliza un sistema de cadena (daisy chain) dónde se pueden especificar múltiples cabeceras. A continuación viene el tamaño de la cabecera (Header Extension Length) que es el tamaño total de la cabecera en palabras de 64 bits (incluyendo todas las direcciones especificadas). El tipo de encaminamiento (Routing Type) es la política que se debe seguir en el encaminamiento, actualmente sólo existe el tipo 0 (si el router aparece en la lista de direcciones especificadas, se quita de la lista, decrementa el campo de segmentos restantes y busca cual de la lista está mas cerca para
enviar el datagrama. Si no aparece en la lista, se limita a encaminarlo ignorando esta opción). El número de segmentos restantes (Segments Left) es un valor que indica el número de direcciones de encaminamiento que aún restan. De esta forma, al llegar a 0 significa que el datagrama ha alcanzado su destino.
La cabecera de fragmentación (Fragmentation Header) en la versión 6 se diferencia respecto a la de la versión 4 en que no existe un bit de fragmentación, ya que no se fragmentan los datagramas. La experiencia ha demostrado que todo y la gran versatilidad de la fragmentación implementada en la versión anterior (si un router recibe un datagrama de tamaño superior al que puede enviar, lo fragmentaba en varios datagramas de menor tamaño.
Estos datagramas se encaminaban independientemente, y por lo tanto, si uno sólo de ellos no llegaba a su destino o llegaba incorrecto, todo el datagrama original se desechaba y debía ser retransmitido.) era mas problemática que
beneficiosa debido a la gran variedad de redes conectadas a INTERNET y al coste de retransmisión de todo el datagrama. De esta forma, si a un router le llega un datagrama de tamaño superior al que puede transmitir, lo descarta y envía al origen un datagrama de error ICMP. No obstante existe una cabecera de fragmentación para que en el origen (y no los routers intermedios como en la versión 4) pueda fragmentar un tamaño de datos superior al soportado por su red (Maximun Transfer Unit, MTU) en varios de tamaño inferior que son independientes entre si y pueden ser reenviados por separados en caso de necesidad. El primer campo de siguiente cabecera (Next Header) indica el siguiente tipo (si hay) de cabecera que nos encontraremos. El siguiente campo también es un byte que actualmente esta reservado y debe ser puesto a 0. El campo de desplazamiento de fragmento (Fragment Offset) indica los 13 bits más significativos del desplazamiento, asumiendo pues que la fragmentación es en múltiplos de 64. En la versión 4 se usaban también 13 bits, pero eran los menos significativos, obligando a multiplicar por 8 para obtener el desplazamiento total del byte, cosa que ahora no se necesaria. Los 2 bits siguientes están reservados para futuros usos. Finalmente el último
bit es el bit de mas fragmentos (More), que es puesto a 1 en todos los fragmentos y a 0 en el último.
La cabecera de opciones de destino (Destination Options Header) nos permite añadir opciones extra a los datagramas para que sean procesadas únicamente
por el destinatario. Con este formato se permite que aquellos routers intermedios que no necesiten interpretarlas puedan evitarlas sin perder tiempo de proceso. El primer campo es como siempre el de siguiente cabecera (Next Header), que nos permite indicar la presencia de más cabeceras. A continuación tenemos el campo de tamaño de la cabecera (Extension Header Length) que en 8 bits especifica el tamaño de la cabecera en palabras de 64 bits sin incluir los primeros 64 bits. Esto permite tener un valor 0 en este campo, ya que si el tamaño cubriera toda la longitud, cada router debería examinar este campo para asegurarse que no es 0. Las opciones (options) son procesadas por el destinatario del datagrama, y su formato obliga a que sean múltiplos de 64 bits para poder ser especificadas en el campo de tamaño de la cabecera.
La cabecera de opciones entre saltos (Hop-by-hop Options Header) permite
especificar opciones que serán procesadas por todos los routers intermedios.
Su formato es el mismo que el de la cabecera de opciones de destino, aunque a diferencia de esta tan sólo es interpretada por el destinatario del datagrama. Cuando un datagrama llega una cabecera extra, especifica en el datagrama que tipo de cabecera le sigue con un código numérico.
La cabecera de autenticación (Authentication Header) es una de las novedades más importantes en la versión 6 del protocolo IP (ver figura 4-7). Debe estar situada entre la cabecera IP y los datos del datagrama. La presencia de una cabecera de autenticación no modifica de ninguna manera el comportamiento del resto de protocolos de nivel superior como TCP o UDP.
Esta cabecera tan solo proporciona una seguridad implícita del origen del datagrama. De esta forma los protocolos superiores deben rechazar los paquetes que no estén adecuadamente autenticados. El primer campo indica
la siguiente cabecera (Next Header) que nos encontraremos tras esta. A continuación nos encontramos el tamaño de los datos (Payload Length) especificado en palabras de 32 bits y un campo de 16 bits reservado que debe ser inicializado a 0. Después nos encontramos con el índice de parámetros de seguridad (Security Parameters Index) y el campo de número de secuencia (Sequence Number field) que ocupan 32 bits cada uno. Finalmente vienen los datos de autenticación (Authentication Data) que es un campo de longitud variable.
Tal y como se ha visto, un datagrama puede incluir mas de una cabecera. Esto no debería suponer ningún problema para los routers intermedios encargados de encaminarlo hasta su destino. De esta forma, las cabeceras son procesadas por los routers a medida que estas llegan, sin ineficiencias. Este sistema de proceso ha sido comparado con las distintas capas de una cebolla (onion-peeling), dónde cada cabecera es una capa. De todas formas es importante señalar que hay algunas cabeceras con mayor importancia que otras, como la cabecera de autenticación (Authentication Header) que obliga a descartar todo el datagrama si es incorrecta o la cabecera de fragmentación (Fragmentation Header) que obliga al reensamblamiento de datagramas.
Tenemos pues que el orden de las diferentes cabeceras es importante, y pese a no existir un formato rígido para establecer este orden, si que hay una recomendación en cuanto al orden adecuado de estas:
1. Cabecera IP versión 6 (IPv6 Header).
2. Cabecera de opciones entre saltos (Hop-by-hop Options Header).
3. Primera cabecera de opciones de destino (Destination Options Header).
4. Cabecera de encaminamiento (Routing Header).
5. Cabecera de fragmentación (Fragment Header).
6. Cabecera de autenticación (Authentication Header).
7. Segunda cabecera de opciones de destino (Destination Options Header).
8. Cabecera de protocolo de nivel superior (TCP, UDP...).
La presencia de cualquiera de estas cabeceras es opcional, con lo que por ejemplo no es necesario la especificación de una cabecera de opciones entre saltos (posición 2) si queremos insertar una cabecera de opciones de destino (posición 3).
Observamos que la cabecera de opciones de destino (Destination Option Header) se repite en dos posiciones distintas (3 y 7) esto es debido a que si necesitamos enviar datagramas encapsulados (tunneling) y queremos que estas opciones sean utilizadas por los routers intermedios debemos enviar estas opciones antes que las de encaminamiento.
Por otro lado, si queremos pasar información que sólo sea interpretada por el
destinatario del datagrama debemos colocar estas opciones justo antes de la cabecera del protocolo del nivel superior (posición 7).
Direccionamiento en IP versión 6.
Una de las características más relevantes de la versión 6 del protocolo IP es el aumento de las direcciones de 32 a 128 bits. Una manera sencilla de entender este aumento sería coger el sistema de direccionamiento utilizado en la versión 4 y aumentarlo simplemente añadiéndole más bits. Pero esto no seria cierto, puesto que uno de los motivos de este cambio es el de la ineficiente gestión de las direcciones, haciendo lento el encaminamiento por INTERNET. De esta forma, en la versión 6 se definen tres tipos de direcciones:
1. Unicast. Este grupo de direcciones se caracteriza por identificar un único
punto final de destino (point-to-point). Un datagrama enviado a una
dirección unicast será entregado a un solo punto de destino.
2. Multicast. Las direcciones multicast agrupan un conjunto de puntos finales
de destino. Un datagrama enviado a una dirección multicast será entregado a
un conjunto de destinos que forman parte de un mismo grupo.
3. Anycast. Este grupo de direcciones al igual que el multicast agrupa un
conjunto de puntos finales de destino. La diferencia principal con el
multicast está en sistema de entrega de datagramas. Un datagrama enviado a una dirección anycast es entregado solo a un punto de destino (el miembro
más cercano del grupo al emisor del datagrama). Este tipo de agrupación no
existía en la versión 4.
Las direcciones IP de la versión 6 están compuestas por 128 bits. Los diseñadores del protocolo optaron por representarlas en 8 agrupaciones de 16 bits. De esta forma se puede utilizar la notación hexadecimal, que permite una representación más compacta que una ristras de 128 unos y ceros. Todo y esta simplificación, continua siendo bastante complicada de manipular y recordar (es posible recordar que cc.uab.es tiene la dirección 158.109.0.4, pero es imposible recordar que le corresponde la dirección IP versión 6 3FFE:3326:FFFF:FFFF:FFFF:FFFF:FFFF:1). Curiosamente se destacó esta cualidad para impulsar el uso de los nombres (cc.uab.es) por los usuarios.
Para compactar estas direcciones tan voluminosas, se aceptaron una serie de
simplificaciones:
• Supresión de los ceros redundantes situados a la izquierda.
• Simplificación de los ceros consecutivos mediante el uso del prefijo ‘::’.
Este prefijo tan sólo puede ser utilizado una vez en una misma dirección.
• Para las direcciones IP versión 6 obtenidas añadiendo 96 ceros a la dirección
IP versión 4 (10.0.0.1 -> 0:0:0:0:0:0:A00:1) se permitirá el uso de la
notación decimal (::10.0.0.1).
• La especificación de un prefijo de direccionamiento en la versión 6 se
realizará mediante la forma dirección_ipv6/prefijo (Si tenemos el prefijo de
40 bits FEDC:BA98:76 en la dirección FEDC:BA98:7600::1 se especificará
como FEDC:BA98:7600::1/40). Se debe tener mucho cuidado con las
simplificaciones siempre que se indican prefijos, ya que puede pasar que con
el prefijo de 64 bits FEDC:BA98:0: y la dirección FEDC:BA98:0.
Después de la experiencia de observar cómo se van agotando las direcciones IP versión 4 sin poder ampliar o reestructurar el direccionamiento de una forma no traumática, los diseñadores de la versión 6 optaron por no consumir todo el espacio direccionable de los 128 bits, realizando una partición en subgrupos independientes para facilitar en un futuro la ampliación de tipos de direcciones o incluso un nuevo tipo de direccionamiento.
De esta forma, se han reservado algunos prefijos de direcciones para aquellos grupos específicos de direcciones (como direcciones compatibles NSAP o direcciones compatibles IPX) que se prevé que en un futuro pueden necesitar un rango de direcciones separado del resto de direcciones IP, incluso se ha reservado un rango de direcciones para un posible direccionamiento geográfico. Todo y esta partición del espacio de direcciones, aún queda más de un 70% del espacio total de direcciones sin asignar.
Fuente: "El Protocolo IPv6 y sus extensiones de seguridad IPSec" - Gabriel Verdejo Alvarez.
No hay comentarios:
Publicar un comentario
Muchas Gracias por tus comentarios ...