Articulo de referencia

Paquete IPv6

Un paquete IPv6 es la unidad de mensaje más pequeña que se intercambia mediante el Protocolo de Internet versión 6 (IPv6). Los paquetes constan de información de control para el...

Un paquete IPv6 es la unidad de mensaje más pequeña que se intercambia mediante el Protocolo de Internet versión 6 (IPv6). Los paquetes constan de información de control para el direccionamiento y el enrutamiento, y una carga útil con datos de usuario. La información de control en los paquetes IPv6 se subdivide en una cabecera fija obligatoria y cabeceras de extensión opcionales. La carga útil de un paquete IPv6 suele ser un datagrama o un segmento del protocolo de la capa de transporte de nivel superior , pero también puede consistir en datos para la capa de Internet (por ejemplo, ICMPv6 ) o la 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 las tecnologías de transición 6to4 o Teredo .

A diferencia de IPv4, los enrutadores no fragmentan los paquetes IPv6 que superan la unidad de transmisión máxima (MTU); esta 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 el descubrimiento de MTU de ruta para aprovechar las MTU superiores a la mínima. [ 1 ]

Desde julio de 2017, la Autoridad de Números Asignados de Internet (IANA) es responsable de registrar todos los parámetros IPv6 que se utilizan en las cabeceras de los paquetes IPv6. [ 1 ]

Encabezado fijo

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 .

Versión : 4 bits
La constante 6 (secuencia de bits 0110 ).
Clase de tráfico : 6+2 bits
Los bits de este campo contienen dos valores. Los seis bits más significativos contienen el campo de servicios diferenciados (campo DS), que se utiliza para clasificar paquetes. [ 2 ] [ 3 ] Actualmente, todos los campos DS estándar terminan con un  bit '0'. Cualquier campo DS que termine con dos  bits '1' está destinado a uso local o experimental. [ 4 ] Los dos bits restantes se utilizan para la Notificación Explícita de Congestión (ECN); [ 5 ] los valores de prioridad se subdividen en rangos: tráfico donde la fuente proporciona control de congestión y tráfico sin control de congestión.
Etiqueta de flujo : 20 bits
Un identificador de alta entropía de un flujo de paquetes entre un origen y un destino. Un flujo es un grupo de paquetes, por ejemplo, una sesión TCP o una transmisión multimedia. La etiqueta de flujo especial 0 significa que el paquete no pertenece a ningún flujo (según este esquema). Un esquema anterior identifica el flujo mediante la dirección y el puerto de origen, la dirección y el puerto de destino y el protocolo (valor del último campo Next Header ). [ 6 ] Además, se ha sugerido que la etiqueta de flujo se utilice para ayudar a detectar paquetes falsificados. [ 7 ]
Longitud de la carga útil : 16 bits
El tamaño de la carga útil en octetos, incluyendo cualquier encabezado de extensión. La longitud se establece en cero cuando un encabezado de extensión Hop-by-Hop contiene una opción de carga útil Jumbo . [ 8 ]
Siguiente encabezado : 8 bits
Especifica el tipo de la siguiente cabecera. Este campo suele indicar el protocolo de la capa de transporte utilizado por la carga útil del paquete. Cuando el paquete contiene cabeceras de extensión, este campo indica cuál le sigue. Los valores son los mismos que los del campo de protocolo IPv4, ya que ambos campos tienen la misma función (véase la lista de números de protocolo IP ).
Límite de salto : 8 bits
Sustituye el campo de tiempo de vida en IPv4. Este valor se decrementa en uno en cada nodo de reenvío y el paquete se descarta si llega a cero. Sin embargo, el nodo de destino debería procesar el paquete normalmente incluso si se recibe con un límite de saltos de cero.
Dirección de origen : 128 bits
La dirección IPv6 unicast del nodo emisor.
Dirección de destino : 128 bits
La dirección IPv6 unicast o multicast del/de los nodo(s) de destino.

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 verificación para protegerlo. [ 1 ]

Encabezados de extensión

Las cabeceras de extensión contienen información opcional de la capa de Internet y se ubican entre la cabecera fija y la cabecera del protocolo de capa superior. [ 1 ] Las cabeceras de extensión forman una cadena, utilizando los campos de la cabecera siguiente . El campo de la cabecera siguiente en la cabecera fija indica el tipo de la primera cabecera de extensión; el campo de la última cabecera de extensión indica el tipo de la cabecera del protocolo de capa superior en la carga útil del paquete. Todas las cabeceras de extensión tienen un tamaño múltiplo de 8 octetos; algunas requieren relleno interno para cumplir con este requisito.

Se han definido varios encabezados de extensión, y es posible que se definan nuevos encabezados de extensión en el futuro. La mayoría de los encabezados de extensión se examinan y procesan en el destino del paquete. Las opciones salto a salto pueden ser procesadas y modificadas por 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 una cabecera de extensión específica, 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 después de 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, 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 del paquete. Estos datos deberían ser ignorados por los hosts, pero transmitidos sin modificaciones por los enrutadores. [ 1 ] : 4.7

Opciones de viaje paso a paso y opciones de destino

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 .

Enrutamiento

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.

Fragmento

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 que es 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.

Encabezado de autenticación (AH) y carga útil de seguridad encapsulada (ESP)

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 ]

Carga útil

A continuación de las cabeceras IPv6 fijas y opcionales se encuentra la carga útil de la capa superior , es decir, los datos proporcionados por la capa de transporte, como un segmento TCP o un datagrama UDP . El campo "Siguiente cabecera" de la última cabecera IPv6 indica el tipo de carga útil que contiene este paquete.

Longitud de carga útil estándar

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.

Jumgram

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 32 − 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.

Fragmentación

A diferencia de IPv4, los enrutadores IPv6 nunca fragmentan los paquetes IPv6. Los paquetes que superan el tamaño de la unidad de transmisión máxima (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 forma similar al método de IPv4 cuando se establece el bit "No fragmentar" . [ 1 ] Se espera que los nodos finales en IPv6 realicen un descubrimiento de MTU de ruta 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 emisor puede utilizar el encabezado de extensión "Fragment" en su lugar.

Cualquier capa de enlace de datos que transmita datos IPv6 debe ser capaz de transmitir un paquete IP que contenga hasta 1280 bytes; por lo tanto, el punto final emisor puede limitar sus paquetes a 1280 bytes y evitar cualquier necesidad de fragmentación o descubrimiento de MTU de ruta.

Fragmentación

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 ]

Reensamblaje

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.

Seguridad

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 ]

Referencias

  1. 1 2 3 4 5 6 7 8 9 10 11 12 13 S. Deering ; R. Hinden (julio de 2017). Especificación del Protocolo de Internet, versión 6 (IPv6) . Grupo de Trabajo de Ingeniería de Internet . doi : 10.17487/RFC8200 . STD 86. RFC 8200 .Estándar de Internet 86. Obsoleto RFC 2460 . 
  2. K. Nichols; S. Blake; F. Baker ; D. Black (diciembre de 1998). Definición del campo de servicios diferenciados (campo DS) en los encabezados IPv4 e IPv6 . Grupo de trabajo de redes. doi : 10.17487/RFC2474 . RFC 2474 .Norma propuesta. Sustituye a las RFC 1455 y 1349. Actualizada por las RFC 3168 , 3260 y 8436 .  
  3. D. Grossman (abril de 2002). Nueva terminología y aclaraciones para DiffServ . IETF . doi : 10.17487/RFC3260 . RFC 3260 .Informativo. Actualiza los RFC 2474 , 2475 y 2597 . 
  4. 1 2 3 B. Fenner (noviembre de 2006). Valores experimentales en encabezados IPv4, IPv6, ICMPv4, ICMPv6, UDP y TCP . Grupo de trabajo de redes de la IETF . doi : 10.17487/RFC4727 . RFC 4727 .Norma propuesta.
  5. K. Ramakrishnan; S. Floyd; D. Black (septiembre de 2001). La adición de notificación explícita de congestión (ECN) a IP . Grupo de trabajo de redes. doi : 10.17487/RFC3168 . RFC 3168 .Estándar propuesto. Deja obsoleto el RFC 2481. Actualiza los RFC 2474 , 2401 y 793. Actualizado por los RFC 4301 , 6040 y 8311 .   
  6. S. Amante; B. Carpenter ; S. Jiang; J. Rajahalme (noviembre de 2011). Especificación de etiquetas de flujo IPv6 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6437 . ISSN 2070-1721 . RFC 6437 . Norma propuesta. Sustituye a RFC 3697. Actualiza RFC 2205 y 2460 .  
  7. Uso de la etiqueta de flujo IPv6 como un nonce de capa de transporte para defenderse contra ataques de suplantación de identidad fuera de ruta.
  8. 1 2 3 D. Borman; S. Deering ; R. Hinden (agosto de 1999). Jumbogramas IPv6 . Grupo de trabajo de redes. doi : 10.17487/RFC2675 . RFC 2675 .Norma propuesta. Sustituye a RFC 2147 . 
  9. C. Partridge; F. Kastenholz (diciembre de 1994). Criterios técnicos para elegir IP de próxima generación (IPng) . Grupo de trabajo de redes. doi : 10.17487/RFC1726 . RFC 1726 .Informativo. sec. 2.6.
  10. T. Heer; P. Jokela; T. Henderson (abril de 2015). R. Moskowitz (ed.). Protocolo de identidad de host versión 2 (HIPv2) . Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC7401 . ISSN 2070-1721 . RFC 7401 . Norma propuesta. Sustituye a RFC 5201. Actualizada por RFC 8002 y 9374 .  
  11. E. Nordmark; M. Bagnulo (junio de 2009). Shim6: Protocolo Shim de multihoming de nivel 3 para IPv6 . Grupo de trabajo de redes del Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC5533 . RFC 5533 .Norma propuesta.
  12. 1 2 3 4 T. Narten (enero de 2004). Asignación de números experimentales y de prueba considerados útiles . Grupo de trabajo de redes. doi : 10.17487/RFC3692 . BCP 82. RFC 3692 .Mejores prácticas actuales 82. Actualizaciones RFC 2434 . 
  13. "Parámetros del protocolo de Internet versión 6 (IPv6): Tipos de enrutamiento" . IANA . Consultado el 15 de octubre de 2021 .
  14. Philippe Biondi, Arnoud Ebalard (abril de 2007). "Seguridad de las cabeceras de enrutamiento IPv6" (PDF) . EADS . Consultado el 3 de diciembre de 2010. Tipo 0: el mecanismo maligno...
  15. J. Abley; P. Savola; G. Neville-Neil (diciembre de 2007). Desuso de los encabezados de enrutamiento de tipo 0 en IPv6 . Grupo de trabajo de redes. doi : 10.17487/RFC5095 . RFC 5095 .Norma propuesta. Actualiza los RFC 2460 y 4294 . 
  16. I. Castineyra; N. Chiappa; M. Steenstrup (agosto de 1996). La arquitectura de enrutamiento Nimrod . IETF . doi : 10.17487/RFC1992 . RFC 1992 .Informativo.
  17. J. Hui; JP. Vasseur; D. Culler; V. Manral (marzo de 2012). Un encabezado de enrutamiento IPv6 para rutas de origen con el protocolo de enrutamiento para redes de baja potencia y con pérdidas (RPL) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6554 . RFC 6554 .Norma propuesta.
  18. S. Previdi; J. Leddy; S. Matsushima; D. Voyer (marzo de 2020). C. Filsfils; D. Dukes (eds.). IPv6 Segment Routing Header (SRH) . Internet Engineering Task Force . doi : 10.17487/RFC8754 . ISSN 2070-1721 . RFC 8754 . Norma propuesta.
  19. S. Kent (diciembre de 2005). Encabezado de autenticación IP . Grupo de trabajo de redes. doi : 10.17487/RFC4302 . RFC 4302 .Norma propuesta. Sustituye a RFC 2402 . 
  20. S. Kent (diciembre de 2005). Carga útil de seguridad encapsulada IP . Grupo de trabajo de redes. doi : 10.17487/RFC4303 . RFC 4303 .Norma propuesta. Sustituye a RFC 2406 . 
  21. 1 2 F. Gont; V. Manral; R. Bonica (enero de 2014). Implicaciones de las cadenas de encabezados IPv6 de gran tamaño . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7112 . ISSN 2070-1721 . RFC 7112 . Norma propuesta. Actualiza RFC 2460 . 
  22. F. Gont (febrero de 2014). Consejos de implementación para IPv6 Router Advertisement Guard (RA-Guard) . Internet Engineering Task Force . doi : 10.17487/RFC7113 . ISSN 2070-1721 . RFC 7113 . Informativo. Actualizaciones RFC 6105 . 
  23. F. Gont (agosto de 2013). Implicaciones de seguridad de la fragmentación de IPv6 con descubrimiento de vecinos IPv6 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6980 . ISSN 2070-1721 . RFC 6980 . Norma propuesta. Actualiza los RFC 3971 y 4861 .