Fragmentación IP
La fragmentación IP es un mecanismo que permite separar (o fragmentar) un paquete IP entre varios bloques de datos, si su tamaño sobrepasa la unidad máxima de transferencia (Maximum Transfer Unit - MTU) del canal.[1] Luego, el RFC 815 describe un algoritmo simplificado de reensamblaje.[2]
Fondo
En el caso más fácil el datagrama entero entra en un bloque de datos física y consigue así la eficiencia más alta. Sin embargo no hay normas fijas para el tamaño del datagrama. Además el tamaño máximo del datagrama depende de los componentes de infraestructura utilizados, ya que por cada técnica de switching los tamaños máximos del datagrama son diferentes.
El campo Identification, y los campos de offset Fragment así como los indicadores ("flags") Don't Fragment y More Fragment en el encabezado del protocolo IP se usan para la fragmentación y reemsamblaje de los datagramas IP.
Objetivo
El objetivo de la fragmentación IP era la ocultación de la infraestructura IP para las capas más altas (véase Modelo OSI) para plantar la implantación de protocolos independiente del hardware.
Modo de trabajar
Cuando la capa IP obtiene un datagrama para enviar, si el tamaño del datagrama es más grande que la MTU por esta capa, la capa IP divide el datagrama disponible en varios datagramas más pequeños. Este proceso es denotado como fragmentación. La fragmentación puede tener lugar en el emisor inicial o en los routers que están entre el emisor y el receptor. Si un datagrama es fragmentado, no será ensamblado(desfragmentado) de nuevo hasta llegar al receptor. (Excepción: Un reassembly de Cortafuegos intercalados antes de transmitir los datos) Si es necesario, un paquete ya fragmentado puede ser fragmentado otra vez (por ejemplo durante un cambio de método de transmisión).
Cada fragmento del datagrama original obtiene en vez del datagram header (cabecera de datagrama) del paquete original un denominado fragment header (cabecera de fragmento) que contiene entre otras cosas el offset que indica la porción de datos enviado en este paquete en relación al paquete original. El fragment offset (13 bit en el IP header) está indicado en bloques de 64 bits. Todos los fragmentos menos el último tienen el more fragments flag con valor "1". El campo de longitud en el IP header contiene la longitud del fragmento, y se calcula la suma de verificación para cada fragmento apartadamente, mientras que el resto del header corresponde al header original.
El receptor es el responsable de reensamblar todos los fragmentos en el orden correcto para obtener el datagrama original y entregarlos al protocolo de nivel superior. El reensamblaje se espera que ocurra en el equipo receptor, pero en la práctica puede ocurrir también en routers intermedios, por ejemplo, NAT puede necesitar reensamblar fragmentos para traducir flujos de datos, e.g. el protocolo de control de FTP, como se describe en el RFP 2993.[3]
Efectos
Aunque el objetivo es una implementación para capas más altas (por ejemplo TCP/UDP) este no está conseguido en dos puntos:
- La fragmentación puede tener una gran influencia negativa en la actuación y en el flujo de datos.
- Si se pierde un fragmento, hay que retransmitir todos los fragmentos del paquete original. Sin embargo IP no tiene mecanismos de seguridad o de timeout y es dependiente de las funciones de seguridad de las capas más altas como TCP.
Por las razones arriba mencionadas se intenta de evitar la fragmentación siempre que sea posible.[4]
Campos IP Afectados
Los campos de la cabecera IP afectados por el proceso de fragmentación son los siguientes:
- Opciones
- Flags, more fragment flag, especifica que le pueden seguir o no más fragmentos
- Fragment Offset
- Tamaño de Cabecera
- Longitud
- Suma de Control de Cabecera (Checksum)
IPv6
IPv6 ya no permite a los routers fragmentar los paquetes. El emisor siempre está informado con un mensaje ICMP cuando una fragmentación será necesaria. Así el emisor puede bajar su tamaño de paquete para esta conexión y la fragmentación ya no es necesaria. En caso de requerirse una fragmentación; el host, es quien debe hacerla.
Referencias
- RFC 791, Internet Protocol, Information Sciences Institute (Septiembre 1981)
- RFC 815, IP Datagram Reassembly Algorithms, David D. Clark (Julio 1982)
- RFC 2993, Architectural Implications of NAT (Noviembre 2000)
- Christopher A. Kent, Jeffrey C. Mogul. . Archivado desde el original el 19 de julio de 2011.
Enlaces externos
- RFC 1191 Path MTU Discovery
- The Never-Ending Story of IP Fragmentation (en inglés)
- Packet Fragmentation (en inglés)