domingo, 16 de octubre de 2011

Tamaño del datagrama IPv6, unidad de transmisión máxima, fragmentación y reensamblado

Bueno, han pasado bastantes días desde la ultima publicación pero aquí vamos de nuevo. Visto que había dejado el asunto de las traducciones de la Guía TCP/IP bastante atrasado creo que la mejor manera de reiniciar es poniéndonos al día con la penúltima parte de IPv6 (pero hay mucho mas esta semana, y ya está hecho, así que ahora si pueden esperarlo). En los días que no hubo publicaciones sucedieron bastantes cosas pero no quería seguir sin dejar de mencionar el deceso el pasado dia 12 de Dennis MacAlistair Ritchie, era la clase de persona de las que solo nacen una en la historia,  huelgan los comentarios, descanse en paz señor y gracias por todo.  


Tamaño de datagramas IP, unidad de transmisión máxima (MTU), fragmentación y reensamblado. 
El trabajo del Protocolo de Internet es el de transmitir mensajes a través de una de las redes conectadas a Internet. Cuando los datagramas se envían entre hosts de redes lejanas son conducidos a lo largo de su viaje por los routers, un salto a la vez, durante muchos enlaces de la red física. En cada paso de este viaje el datagrama se codifica en un marco (frame) de la capa de enlace de datos para su transmisión.

Descripción del tamaño del datagrama IPv6 y la fragmentación
Para que un datagrama sea transportado con éxito a lo largo de una ruta, su tamaño debe ser lo suficientemente pequeño como para caber dentro del marco de la capa inferior en cada paso en el camino. El término unidad de transmisión máxima (maximum transmission unit MTU), describe el límite de tamaño para una determinada red física. Si un datagrama es demasiado grande para la MTU de una red, debe ser dividido en pedazos, un proceso conocido como fragmentación, a continuación, las piezas se re ensamblan en el dispositivo de destino. Este ha sido un requisito desde IPv4, y explicamos los conceptos y cuestiones relacionadas con el tamaño de datagrama, MTU, la fragmentación y el re ensamblado en detalle en una sección dedicada a estos asuntos en IPv4.
Todos estos problemas se aplican al envío de datagramas IPv6 igual a como lo hicieron en IPv4. Sin embargo, como en otras áreas del protocolo, han cambiado algunos detalles importantes de cómo la fragmentación y el re ensamblado se realizan. Estos cambios se hicieron para mejorar la eficiencia del proceso de enrutamiento, y también para reflejar la realidad actual de las tecnologías de redes: la mayoría puede manejar datagramas IP promedio sin necesidad de fragmentación.

Las diferencias más importantes entre IPv4 e IPv6 con respecto al tamaño del datagrama, MTU, la fragmentación y el re ensamblado son las siguientes:
  • El aumento de MTU por defecto: En IPv4, el mínimo MTU que se requería que los routers y los enlaces físicos manejaran era de 576 bytes. En IPv6, todos los enlaces debe manejar un tamaño de datagrama de al menos 1280 bytes. Esto es más del doble de tamaño y mejora la eficiencia al aumentar la proporción entre la carga útil máxima y la longitud de la cabecera, y reduce la frecuencia con la que es necesaria la fragmentación. 
  • Eliminación de la fragmentación en ruta: En IPv4, los datagramas pueden ser fragmentados, ya sea por el dispositivo de origen, o por los routers durante el camino. En IPv6, sólo el nodo de origen puede fragmentar; los routers no lo hacen. La fuente por lo tanto, debe fragmentar hasta el tamaño de la MTU más pequeña en la ruta antes de la transmisión. Esto tiene ventajas y desventajas, como veremos más adelante. El re ensamblado, por supuesto, todavía se hace sólo por el destino, al igual que en IPv4. 
  • Retro-alimentación de errores de tamaño de MTU: Ya que los routers no pueden fragmentar los datagramas, deben descartarlos si se ven obligados a tratar de enviar un datagrama demasiado grande sobre un enlace físico. Se ha definido un proceso de retroalimentación utilizando ICMPv6 que permite a los routers informar a los dispositivos fuente que están utilizando datagramas que son demasiado grandes para la ruta. 
  • Descubrimiento del camino MTU: Dado que los dispositivos de origen debe decidir sobre el tamaño correcto de los fragmentos, es útil disponer de un mecanismo para determinar cual debe ser este. Esta capacidad se proporciona a través de una técnica especial llamada Path MTU Discovery, que se había definido para IPv4, pero que ha sido refinada para IPv6. 
  • Movimiento de los campos de fragmentación del encabezado: Para reflejar la decreciente importancia de la fragmentación en IPv4, los campos permanentes relacionados con el proceso que se encontraban en la cabecera IPv4 se han arrendado a una cabecera de extensión de fragmentos, que sólo se incluye cuando es necesario.

Implicaciones de la regla "solo la fuente fragmenta" en IPv6
Encuentro los cambios en la fragmentación y el proceso de re ensamblaje interesantes. Mientras que muchos otros cambios en IPv6 representan un cambio en la "responsabilidad" para las funciones desde los hosts hasta los routers, esta en particular es lo opuesto. En IPv4, un nodo de origen realmente puede enviar un datagrama de cualquier tamaño que su enlace local pueda manejar, y dejar que los routers se ocupen de la fragmentación, según sea necesario. Este parece ser un modelo razonable, los nodos se comunican en una gran red "virtual" y los detalles de la división de los mensajes, según sea necesario para los enlaces físicos se manejan invisiblemente.
El problema con esto es que representa un lastre para el rendimiento de enrutamiento. Es mucho más rápido para un router reenviar un datagrama intacto de emplear tiempo fragmentándolo. En algunos casos, la fragmentación tendría que ocurrir varias veces durante la transmisión de un datagrama, y ??recuerde que esto debe ocurrir para cada datagrama en una ruta. Es mucho más eficiente para la fuente simplemente enviar los datagramas del tamaño adecuado en primer lugar.

Determinación del tamaño adecuado de datagramas
Por supuesto, hay un problema: ¿cómo la fuente sabe el tamaño adecuado? No tiene idea de las redes físicas que atravesarán los datagramas en su ruta a determinado destino, de hecho, no sabe ni lo que son las rutas! Tiene dos opciones:
  1. Usar una MTU por defecto: La primera opción es simplemente usar un MTU por defecto de 1280, que todas las redes físicas deben ser capaces de manejar. Esta es una buena opción, especialmente para las comunicaciones cortas o para el envío de pequeñas cantidades de datos. 
  2. Usar Path MTU Discovery: La alternativa es hacer uso de la función de Path MTU Discovery, que se describe a continuación. Este método, que se define en el RFC 1981, define un modo por el que un nodo envía mensajes a través de una ruta para determinar cuál es la MTU mínima general de la misma, en una técnica muy similar a como se hace en IPv4.
Ya que los routers no pueden fragmentar en IPv6, si un datagrama enviado por una fuente es demasiado grande para un router, deberá descartar el datagrama. A continuación, envía una retroalimentación a la fuente sobre el evento, en la forma de un mensaje ICMPv6 Packet too Big (paquete demasiado grande). Esto le dice a la fuente que su datagrama ha sido descartado y que debe fragmentarlo (o reducir el tamaño de sus fragmentos.)
Este mecanismo de retroalimentación se utiliza también en el descubrimiento del camino MTU. El nodo fuente envía un datagrama que tiene el MTU de su enlace físico local, ya que representa un límite superior a la MTU de la ruta. Si el datagrama pasa sin errores, entonces sabe que puede utilizar ese valor para los futuros datagramas con ese destino. Si recibe cualquier mensaje de Packet Too Big, intenta de nuevo con un datagrama de tamaño más pequeño. La ventaja de este método sobre el empleo del valor predeterminado de 1280 es que permite establecer comunicaciones mas largas con una MTU mayor lo que mejora mucho el rendimiento.

Uno de los inconvenientes de la decisión de "solo fragmenta la fuente" es que introduce problemas potenciales si hay más de una ruta entre los dispositivos o si cambian las rutas. En IPv4, la fragmentación es dinámica y automática, sucede por sí misma y se ajusta a medida que cambian las rutas. Path MTU Discovery es una buena característica, pero es estática. Requiere que el host mantenga un seguimiento de las MTU de las diferentes rutas, y las actualice con regularidad. Esto se hace ejecutando un nuevo Path MTU Discovery si el nodo recibe un mensaje de paquete demasiado grande desde una ruta para la que previamente ha realizado el Path MTU Discovery, pero esto lleva tiempo.

Concepto clave: En IPv6 la fragmentación se realiza sólo por el dispositivo que envía el datagrama, no por los routers. Si un router encuentra un datagrama demasiado grande para enviarlo a través de una red física con un pequeño MTU, el router envía un mensaje ICMPv6 de paquete demasiado grande a la fuente de los datagramas. Esto puede ser usado como parte de un proceso llamado Path MTU Discovery para determinar la MTU mínima de una ruta completa.

Proceso de fragmentación en IPv6
La mecánica real de la fragmentación en IPv6 es similar a la de IPv4, con el agravante de que las cabeceras extendidas deben manejarse con cuidado. A efectos de la fragmentación, los datagramas IPv6 se dividen en dos partes:

  • Parte no fragmentable: Esto incluye el encabezado principal del datagrama original, así como cualquier encabezado extendido que deba estar presente en cada fragmento. Esto significa el encabezado principal, y cualquiera de los siguientes encabezados si están presentes: Opciones Hop-by-hop, opciones de destino (para las opciones a ser procesadas por los dispositivos a lo largo de una ruta) y enrutamiento. 
  • Parte Fragmentable: Esto incluye la parte de datos de los datagramas, junto con otros encabezados extendidos si están presentes - encabezado de autenticación, Opciones de carga útil de seguridad encapsulada y/o destino (para las opciones a ser procesado sólo por el destino final).
La parte no fragmentable debe estar presente en cada fragmento, mientras que la parte fragmentable se divide entre todos los fragmentos. Así para fragmentar un datagrama, un dispositivo crea un conjunto de datagramas fragmentados, cada uno de ellos conteniendo lo siguiente, en orden:

  1. Parte no fragmentable: La parte no fragmentable completa del datagrama original, con su longitud de carga útil cambiada a la longitud del fragmento del datagrama. 
  2. Encabezado de fragmento: un encabezado de fragmento con el desplazamiento (offset) del fragmento, Identificación y banderas configuradas de la misma manera que se utilizan en IPv4. 
  3. Fragmento: Un fragmento de la parte Fragmentable del datagrama original. Tenga en cuenta que cada fragmento debe tener una longitud que es un múltiplo de 8 bytes, ya que el valor en el campo de desplazamiento del fragmento se especifica en múltiplos de 8 bytes.
Concepto clave: La fragmentación se hace en IPv6 de manera similar a la de IPv4, excepto que llos encabezados extendidos deben ser manejados de forma especial. Ciertos encabezados extendidos se consideran no fragmentables y aparecen en cada fragmento, mientras que otros están fragmentados junto con los datos.

Ejemplo de fragmentación en IPv6
Veamos un ejemplo para ilustrar cómo funciona la fragmentación en IPv6 (ver Figura 110). Supongamos que tenemos un datagrama IPv6 de exactamente 370 bytes de ancho, que consta de una cabecera IP de 40 bytes, cuatro encabezados extendidos de 30 bytes y 210 bytes de datos. Dos de los encabezados extendidos son no fragmentables, mientras que los otros dos son fragmentables. (En la práctica, no tendríamos que fragmentar un datagrama tan pequeño, pero estoy tratando de mantener los números simples.) Supongamos que necesitamos enviarlo sobre un enlace con una MTU de sólo 230 bytes. En realidad se requieren tres fragmentos, y no de dos como cabría esperar, debido a la necesidad de poner los dos encabezados extendidos de 30 bytes en cada fragmento, y el requisito de que cada fragmento tenga una longitud que sea múltiplo de 8. Así es como se estructurarán los fragmentos:


En esta ilustración, un datagrama IPv6 de 370 byte, que contiene cuatro encabezados extendidos de 30 bytes, se divide en tres fragmentos. El tamaño de los campos se muestran a escala. La parte no fragmentable, que se muestra en azul, inicia cada fragmento, seguida del encabezado de fragmento (abreviado como "FH" (Fragment Header) en la figura). A continuación, las porciones de la parte Fragmentable se colocan en cada fragmento de la secuencia. Los encabezados extendidos de autenticación y opciones de destino forman parte de la parte Fragmentable por lo que aparecen como parte del primer fragmento.
  1. Primer fragmento: El primer fragmento consistiría los 100 bytes de la parte no fragmentable, seguidos por un encabezado de Fragmento de 8 bytes y los primeros 120 bytes de la parte Fragmentable del datagrama original. Esto incluiría los dos encabezados extendidos fragmentables y los primeros 60 bytes de datos. Esto deja a 150 bytes de datos a enviar. 
  2. Segundo fragmento: Este también contiene 100 bytes de la parte no fragmentable, seguidos por un encabezado de fragmento y 120 bytes de datos (bytes 60 a 179). Esto dejaría a 30 bytes de datos restantes. 
  3. Fragmento tercero: El último fragmento que contiene la Parte de 100 bytes no fragmentable, un encabezado de fragmento y los últimos 30 bytes de datos.
La bandera "M" (Más Fragmentos) se establece a uno en los dos primeros fragmentos y a cero en el tercero, y el valor del desplazamiento del fragmento adoptaría un valor apropiado. Consulte el tema sobre fragmentación en IPv4 para más información sobre cómo se utilizan estos campos.

El dispositivo receptor reensambla tomando la parte no fragmentable del primer fragmento y luego ensamblando los datos fragmentados de cada fragmento de la secuencia.