Paquete IPv6

El encabezado de extensión Opciones salto a salto puede ser examinado y modificado por todos los nodos en la ruta del paquete, incluidos los nodos emisor y receptor. (Para la autenticación, los valores de las opciones que puedan cambiar a lo largo de la ruta se ignoran). El encabezado de extensión Opciones de destino solo debe ser examinado por el o los nodos de destino. Ambos encabezados de extensión tienen un tamaño mínimo de 8 octetos; si hay más opciones de las que caben en ese espacio, se agregan repetidamente bloques de 8 octetos, que contienen opciones y relleno, al encabezado hasta que se representen todas las opciones.

Siguiente encabezado : 8 bits

Especifica el tipo de encabezado siguiente.

Longitud de extensión de la cabecera : 8 bits

Longitud de este encabezado en unidades de 8 octetos, sin incluir los primeros 8 octetos.

Opciones y relleno : variable

Contiene una o más opciones y campos de relleno opcionales para alinear las opciones y lograr que la longitud total del encabezado sea un múltiplo de 8 octetos. Las opciones están codificadas en TLV .

El encabezado de extensión de enrutamiento se utiliza para dirigir un paquete a uno o más nodos intermedios antes de enviarlo a su destino. El encabezado tiene un tamaño mínimo de 8 octetos; si se necesitan más datos específicos del tipo de los que caben en 4 octetos, se añaden bloques de 8 octetos al encabezado repetidamente, hasta que se hayan colocado todos los datos específicos del tipo . ^{[ 1 ]}

Siguiente encabezado : 8 bits

Indica el tipo de encabezado siguiente.

Longitud de extensión de la cabecera : 8 bits

La longitud de este encabezado, en múltiplos de 8 octetos, sin incluir los primeros 8 octetos.

Tipo de enrutamiento : 8 bits

Un valor entre 0 y 255, según lo asignado por IANA . ^{[ 13 ]}

Segmentos restantes : 8 bits

Número de nodos que este paquete aún tiene que visitar antes de llegar a su destino final.

Datos específicos del tipo : variable

Datos que pertenecen a este tipo de encabezado de enrutamiento.

Para enviar un paquete que sea mayor que la MTU de la ruta , el nodo emisor divide el paquete en fragmentos. El encabezado de extensión Fragment contiene la información necesaria para reconstruir el paquete original (sin fragmentar). ^{[ 1 ]}

Siguiente encabezado : 8 bits

Identifica el tipo del siguiente encabezado.

Reservado : 8 bits ; Reservado == 0

Inicializado a cero.

Desplazamiento del fragmento : 13 bits

Desplazamiento, en unidades de 8 octetos, con respecto al inicio de la parte fragmentable del paquete original.

Reservado2  (Res) : 2 bits ; Res == 0

Reservado; inicializado a ceros.

Bandera M  (M) : 1 bit

1 significa que siguen más fragmentos; 0 significa el último fragmento.

Identificación : 32 bits

Valor de identificación del paquete, generado por el nodo de origen. Necesario para el reensamblaje del paquete original.

El encabezado de autenticación y la carga útil de seguridad encapsulada forman parte de IPsec y se utilizan de forma idéntica en IPv6 y en IPv4. ^{[ 19 ] [ 20 ]}

El campo de longitud de carga útil de IPv6 (e IPv4 ) tiene un tamaño de 16  bits, capaz de especificar una longitud máxima de65 535 octetos para la carga útil. En la práctica, los hosts determinan la longitud máxima de carga útil utilizable mediante el descubrimiento de MTU de ruta (obteniendo la MTU mínimaa lo largo de la ruta desde el remitente al receptor), para evitar tener que fragmentar los paquetes. La mayoría de los protocolos de capa de enlace tienen MTU considerablemente más pequeñas que65 535 octetos.

Una característica opcional de IPv6, la opción de carga útil jumbo en un encabezado de extensión de opciones de salto a salto , ^{[ 8 ]} permite el intercambio de paquetes con cargas útiles de hasta un octeto menos de 4 GB (2 ³² − 1 =    4 294 967 295 octetos), mediante el uso de un campo de longitud de 32 bits. Los paquetes con tales cargas útiles se denominan jumgramas .

Dado que tanto TCP como UDP incluyen campos limitados a 16  bits (longitud, puntero de datos urgentes), la compatibilidad con jumbogramas IPv6 requiere modificaciones en la implementación del protocolo de la capa de transporte. ^{[ 8 ]} Los jumbogramas solo son relevantes para enlaces que tienen una MTU mayor que65 583 octetos (más de65 535 octetos para la carga útil, más 40 octetos para el encabezado fijo, más 8 octetos para el encabezado de extensión salto a salto ). Solo unos pocos protocolos de capa de enlace pueden procesar paquetes más grandes que65 535 octetos.

Un paquete que contiene el primer fragmento de un paquete original (más grande) consta de cinco partes: los encabezados por fragmento (los encabezados originales cruciales que se usan repetidamente en cada fragmento), seguidos del encabezado de extensión de fragmento que contiene un desplazamiento cero, luego todos los encabezados de extensión originales restantes, luego el encabezado de capa superior original (alternativamente el encabezado ESP) y una parte de la carga útil original. ^{[ 1 ]} Cada paquete subsiguiente consta de tres partes: los encabezados por fragmento, seguidos del encabezado de extensión de fragmento y por una parte de la carga útil original identificada por un desplazamiento de fragmento.

Los encabezados por fragmento se determinan según si el original contiene un encabezado de enrutamiento o un encabezado de extensión de salto a salto . Si no existe ninguno, la parte por fragmento consiste únicamente en el encabezado fijo. Si existe el encabezado de extensión de enrutamiento , los encabezados por fragmento incluyen el encabezado fijo y todos los encabezados de extensión hasta el de enrutamiento inclusive . Si existe el encabezado de extensión de salto a salto , los encabezados por fragmento constan únicamente del encabezado fijo y el encabezado de extensión de salto a salto .

En cualquier caso, el último encabezado de la parte por fragmento tiene su valor de Encabezado Siguiente establecido en 44 para indicar que le sigue un encabezado de extensión de fragmento . Cada encabezado de extensión de fragmento tiene su indicador M establecido en 1 (lo que indica que le siguen más fragmentos), excepto el último, cuyo indicador está establecido en 0. La longitud de cada fragmento es un múltiplo de 8 octetos, excepto, potencialmente, el último fragmento.

Históricamente, los encabezados por fragmento se denominaban la "parte no fragmentable", en referencia a la posibilidad, antes de 2014, de fragmentar el resto del encabezado. Ahora, ningún encabezado es realmente fragmentable. ^{[ 21 ]}

El nodo receptor reconstruye el paquete original recopilando todos los fragmentos, colocando cada uno en su posición indicada y descartando las cabeceras de extensión de fragmento de los paquetes que los contenían. Los paquetes que contienen fragmentos no tienen por qué llegar en secuencia; el nodo receptor los reorganizará.

Si no se reciben todos los fragmentos en 60 segundos tras recibir el primer paquete fragmentado, se abandona el reensamblaje del paquete original y se descartan todos los fragmentos. Si se recibió el primer fragmento (que contiene la cabecera fija) y faltan uno o más, se devuelve un mensaje de Tiempo Excedido ( ICMPv6 tipo 3, código 1) al nodo que originó el paquete fragmentado.

Cuando el nodo de reensamblaje detecta un fragmento que se superpone con otro, se interrumpe el reensamblaje del paquete original y se descartan todos los fragmentos. Opcionalmente, un nodo puede ignorar las copias exactas de un fragmento en lugar de tratarlas como superpuestas. ^{[ 1 ]}

Los hosts receptores deben intentar reconstruir los datagramas IP fragmentados que, tras su reconstrucción, contengan hasta 1500 bytes. Se les permite intentar reconstruir datagramas fragmentados de más de 1500 bytes, pero también pueden descartar silenciosamente cualquier datagrama una vez que se haga evidente que el paquete reconstruido superaría los 1500 bytes. Por lo tanto, los remitentes deben evitar enviar datagramas IP fragmentados con un tamaño total reconstruido superior a 1500 bytes, a menos que sepan que el receptor es capaz de reconstruir datagramas de ese tamaño.

Las investigaciones han demostrado que el uso de la fragmentación puede aprovecharse para eludir los controles de seguridad de la red . Como resultado, en 2014 se prohibió la autorización previa para desbordar la cadena de encabezados IPv6 más allá del primer fragmento, con el fin de evitar algunos casos específicos de fragmentación patológica. ^{[ 21 ]} Además, como resultado de las investigaciones sobre la evasión de Router Advertisement Guard , ^{[ 22 ]} el uso de la fragmentación con Neighbor Discovery está obsoleto y se desaconseja su uso con Secure Neighbor Discovery (SEND). ^{[ 23 ]}