Un paquete IPv6 es la entidad de mensaje más pequeña que se intercambia utilizando el Protocolo de Internet versión 6 (IPv6). Los paquetes constan de información de control para direccionamiento y enrutamiento y una carga útil de datos de usuario. La información de control en los paquetes IPv6 se subdivide en un encabezado fijo obligatorio y encabezados de extensión opcionales. La carga útil de un paquete IPv6 es típicamente un datagrama o segmento del protocolo de capa de transporte de nivel superior , pero puede ser datos para una capa de Internet (por ejemplo, ICMPv6 ) o una capa de enlace (por ejemplo, OSPF ).
Los paquetes IPv6 se transmiten normalmente a través de la capa de enlace (es decir, a través de Ethernet o Wi-Fi ), que encapsula cada paquete en una trama . Los paquetes también pueden transportarse a través de un protocolo de tunelización de capa superior , como IPv4 cuando se utilizan tecnologías de transición 6to4 o Teredo .
A diferencia de IPv4, los enrutadores no fragmentan los paquetes IPv6 que superan la unidad máxima de transmisión (MTU), sino que es responsabilidad exclusiva del nodo de origen. IPv6 exige una MTU mínima de 1280 octetos , pero se "recomienda encarecidamente" a los hosts que utilicen Path MTU Discovery para aprovechar las MTU superiores al mínimo. [1]
Desde julio de 2017, la Autoridad de Números Asignados de Internet (IANA) ha sido responsable de registrar todos los parámetros IPv6 que se utilizan en los encabezados de paquetes IPv6. [1]
El encabezado fijo inicia un paquete IPv6 y tiene un tamaño de 40 octetos (320 bits ). [1] Los bytes de los campos multibyte están en el orden de bytes de la red .
Para aumentar el rendimiento, y dado que se supone que la tecnología actual de la capa de enlace y los protocolos de la capa de transporte proporcionan una detección de errores suficiente, [9] el encabezado no tiene una suma de comprobación que lo proteja. [1]
Los encabezados de extensión contienen información opcional de la capa de Internet y se ubican entre el encabezado fijo y el encabezado de protocolo de la capa superior. [1] Los encabezados de extensión forman una cadena, utilizando los campos de Encabezado siguiente . El campo Encabezado siguiente en el encabezado fijo indica el tipo del primer encabezado de extensión; el campo Encabezado siguiente del último encabezado de extensión indica el tipo del encabezado de protocolo de la capa superior en la carga útil del paquete. Todos los encabezados de extensión tienen un tamaño múltiplo de 8 octetos; algunos encabezados de extensión requieren relleno interno para cumplir con este requisito.
Hay varios encabezados de extensión definidos y es posible que se definan nuevos en el futuro. La mayoría de los encabezados de extensión se examinan y procesan en el destino del paquete. Las opciones de salto a salto pueden procesarse y modificarse mediante nodos intermedios y, si están presentes, deben ser la primera extensión. Todos los encabezados de extensión son opcionales y deben aparecer como máximo una vez, excepto la extensión del encabezado Opciones de destino , que puede aparecer dos veces. [1]
Si un nodo no reconoce un encabezado de extensión específico, debe descartar el paquete y enviar un mensaje de problema de parámetro ( ICMPv6 tipo 4, código 1). [1]
Los encabezados de extensión definidos a continuación se enumeran en el orden preferido para el caso en que haya más de un encabezado de extensión después del encabezado fijo.
El valor 59 (Sin encabezado siguiente) en el campo Encabezado siguiente indica que no hay ningún encabezado siguiente a este, ni siquiera un encabezado de un protocolo de capa superior. Esto significa que, desde el punto de vista del encabezado, el paquete IPv6 termina justo después de él: la carga útil debería estar vacía. Sin embargo, aún podría haber datos en la carga útil si la longitud de la carga útil en el primer encabezado del paquete es mayor que la longitud de todos los encabezados de extensión en el paquete. Estos datos deberían ser ignorados por los hosts, pero transmitidos sin modificaciones por los enrutadores. [1] : 4.7
El encabezado de extensión Opciones de salto a salto puede ser examinado y modificado por todos los nodos en la ruta del paquete, incluidos los nodos de envío y recepción. (Para la autenticación, se ignoran los valores de las opciones que pueden cambiar a lo largo de la ruta). El encabezado de extensión Opciones de destino debe ser examinado únicamente por el nodo o los nodos de destino. Los encabezados de extensión tienen un tamaño de al menos 8 octetos; si hay más opciones de las que caben en ese espacio, se agregan al encabezado bloques de 8 octetos, que contienen opciones y relleno, repetidamente hasta que se representan todas las opciones.
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 de al menos 8 octetos; si se necesitan más datos específicos de tipo de los que caben en 4 octetos, se agregan bloques de 8 octetos al encabezado repetidamente, hasta que se coloquen todos los datos específicos de tipo . [1]
Para enviar un paquete que es más grande 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 volver a ensamblar el paquete original (no fragmentado). [1]
El encabezado de autenticación y la carga útil de seguridad encapsulante son parte de IPsec y se utilizan de manera idéntica en IPv6 y en IPv4. [19] [20]
Los encabezados IPv6 fijos y opcionales van seguidos de la carga útil de la capa superior , los datos proporcionados por la capa de transporte, por ejemplo, un segmento TCP o un datagrama UDP . El campo Next Header del último encabezado IPv6 indica qué tipo de carga útil contiene este paquete.
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 utilizable de la carga útil mediante Path MTU Discovery (que genera la MTU mínimaa lo largo de la ruta desde el remitente hasta el 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 gigante en un encabezado de extensión Hop-By-Hop Options , [8] permite el intercambio de paquetes con cargas útiles de hasta un octeto menor a 4 GB (2 32 − 1 = 4 294 967 295 octetos), utilizando un campo de longitud de 32 bits. Los paquetes con este tipo de cargas útiles se denominan jumbogramas .
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 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 Hop-by-Hop ). Solo unos pocos protocolos de capa de enlace pueden procesar paquetes más grandes que65 535 octetos. [ cita requerida ]
A diferencia de IPv4, los enrutadores IPv6 nunca fragmentan los paquetes IPv6. Los paquetes que exceden el tamaño de la unidad máxima de transmisión (MTU) del enlace de destino se descartan y esta condición se señala mediante un mensaje ICMPv6 de Paquete demasiado grande al nodo de origen, de manera similar al método IPv4 cuando se establece el bit No fragmentar . [1] Se espera que los nodos finales en IPv6 realicen Path MTU Discovery para determinar el tamaño máximo de los paquetes a enviar, y se espera que el protocolo de capa superior limite el tamaño de la carga útil. Si el protocolo de capa superior no puede hacerlo, el host de envío puede usar el encabezado de extensión Fragment en su lugar.
Cualquier capa de enlace de datos que transporte datos IPv6 debe ser capaz de transmitir un paquete IP que contenga hasta 1280 bytes, por lo que el punto final de envío puede limitar sus paquetes a 1280 bytes y evitar cualquier necesidad de fragmentación o descubrimiento de MTU de ruta.
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 por el 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 posterior consta de tres partes: los encabezados por fragmento, seguidos por el 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 en función de si el original contiene un encabezado de extensión de enrutamiento o de salto a salto . Si no existe ninguno, la parte por fragmento es solo 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 incluido . Si existe el encabezado de extensión de salto a salto , los encabezados por fragmento constan solo del encabezado fijo y del encabezado de extensión de salto a salto .
En cualquier caso, el último encabezado de la parte por fragmento tiene su valor de Next Header establecido en 44 para indicar que 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 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 "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 vuelve a ensamblar el paquete original reuniendo todos los fragmentos y colocando cada uno de ellos en el desplazamiento indicado y descartando los encabezados de extensión de fragmento de los paquetes que los contenían. Los paquetes que contienen fragmentos no necesitan llegar en secuencia; el nodo receptor los reorganizará.
Si no se reciben todos los fragmentos dentro de los 60 segundos posteriores a la recepción del primer paquete con un fragmento, se abandona el reensamblado del paquete original y se descartan todos los fragmentos. Si se recibió el primer fragmento (que contiene el encabezado fijo) y faltan uno o más fragmentos 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 reensamblado detecta un fragmento que se superpone con otro fragmento, se cancela el reensamblado del paquete original y se descartan todos los fragmentos. Un nodo puede ignorar opcionalmente los duplicados exactos de un fragmento en lugar de tratarlos como si se superpusieran entre sí. [1]
Los hosts receptores deben hacer todo lo posible por reensamblar los datagramas IP fragmentados que, después del reensamblado, contengan hasta 1500 bytes. Los hosts pueden intentar reensamblar datagramas fragmentados de más de 1500 bytes, pero también pueden descartar en silencio cualquier datagrama después de que se haga evidente que el paquete reensamblado tendrá más de 1500 bytes. Por lo tanto, los remitentes deben evitar enviar datagramas IP fragmentados con un tamaño reensamblado total de más de 1500 bytes, a menos que sepan que el receptor es capaz de reensamblar datagramas tan grandes.
Las investigaciones han demostrado que el uso de la fragmentación puede aprovecharse para evadir los controles de seguridad de la red. Como resultado, en 2014 se prohibió la posibilidad de desbordar la cadena de encabezados de IPv6 más allá del primer fragmento para evitar algunos casos de fragmentación muy patológicos. [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 el uso de la fragmentación con Secure Neighbor Discovery (SEND). [23]
Tipo 0: el mecanismo maligno...