Un paquete IPv6 es la entidad 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 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 la capa de transporte de nivel superior, pero pueden ser datos para una capa de Internet (por ejemplo, ICMPv6 ) o una capa de enlace (por ejemplo, OSPF ) en su lugar.
Los paquetes IPv6 generalmente se transmiten 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 se pueden transportar 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 más grandes que la unidad máxima de transmisión (MTU), es responsabilidad exclusiva del nodo de origen. IPv6 exige una MTU mínima de 1.280 octetos , pero se "recomienda encarecidamente" a los hosts que utilicen Path MTU Discovery para aprovechar MTU mayores que el mínimo. [1]
Desde julio de 2017, la Autoridad de Números Asignados de Internet (IANA) es responsable de registrar todos los parámetros de IPv6 que se utilizan en los encabezados de paquetes de IPv6. [1]
Encabezado fijo
El encabezado fijo inicia un paquete IPv6 y tiene un tamaño de 40 octetos (320 bits ). [1]
Formato de encabezado fijo Compensaciones Octeto 0 1 2 3 Octeto Un poco 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 dieciséis 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Versión Clase de trafico Etiqueta de flujo 4 32 Longitud de la carga útil Siguiente encabezado Límite de salto 8 64 Dirección de la fuente 12 96 dieciséis 128 20 160 24 192 Dirección de destino 28 224 32 256 36 288
- Versión (4 bits)
- La constante 6 (secuencia de bits 0110 ).
- Clase de tráfico (6 + 2 bits)
- Los bits de este campo tienen 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á diseñado para 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 de control de no 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 un flujo de medios. La etiqueta de flujo especial 0 significa que el paquete no pertenece a ningún flujo (usando este esquema). Un esquema más antiguo identifica el flujo por la dirección y el puerto de origen, la dirección y el puerto de destino, el protocolo (valor del último campo del encabezado siguiente ). [6] Además, se ha sugerido que la etiqueta de flujo se utilice para ayudar a detectar paquetes falsificados. [7]
- Longitud de carga útil (16 bits)
- El tamaño de la carga útil en octetos, incluidos los encabezados de extensión. La longitud se establece en cero cuando un encabezado de extensión Hop-by-Hop lleva una opción de carga útil Jumbo . [8]
- Siguiente encabezado (8 bits)
- Especifica el tipo de encabezado siguiente. Este campo generalmente especifica el protocolo de la capa de transporte utilizado por la carga útil de un paquete. Cuando los encabezados de extensión están presentes en el paquete, este campo indica qué encabezado de extensión sigue. Los valores se comparten con los utilizados para el campo de protocolo IPv4, ya que ambos campos tienen la misma función (ver Lista de números de protocolo IP ).
- Límite de saltos (8 bits)
- Reemplaza el campo de tiempo de vida en IPv4. Este valor se reduce en uno en cada nodo de reenvío y el paquete se descarta si se convierte en 0. Sin embargo, el nodo de destino debe procesar el paquete normalmente incluso si se recibe con un límite de salto de 0.
- Dirección de origen (128 bits)
- La dirección IPv6 de unidifusión del nodo remitente.
- Dirección de destino (128 bits)
- La dirección IPv6 de unidifusión o multidifusión de los nodos 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 suficiente detección de errores, [9] el encabezado no tiene suma de comprobación para protegerlo. [1]
Encabezados de extensión
Los encabezados de extensión llevan información de la capa de Internet opcional y se colocan entre el encabezado fijo y el encabezado del protocolo de la capa superior. [1] Los encabezados de extensión forman una cadena, utilizando los campos de Encabezado siguiente . El campo Siguiente encabezado en el encabezado fijo indica el tipo del primer encabezado de extensión; el campo Next Header del último encabezado de extensión indica el tipo de encabezado de protocolo de 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 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 Hop-by-Hop 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 solo deberían aparecer como máximo una vez, excepto la extensión de encabezado de 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 el que hay más de un encabezado de extensión después del encabezado fijo.
Encabezado de extensión Valor del campo de encabezado siguiente Descripción Opciones hop-by-hop 0 Opciones que deben examinar todos los dispositivos en la ruta Enrutamiento 43 Métodos para especificar la ruta para un datagrama (usado con Mobile IPv6 ) Fragmento 44 Contiene parámetros para la fragmentación de datagramas. Encabezado de autenticación (AH) 51 Contiene información utilizada para verificar la autenticidad de la mayoría de las partes del paquete. Carga útil de seguridad encapsulada (ESP) 50 Transporta datos encriptados para una comunicación segura Opciones de destino (antes del encabezado de la capa superior) 60 Opciones que deben examinarse solo por el destino del paquete Movilidad (actualmente sin encabezado de capa superior) 135 Parámetros utilizados con IPv6 móvil Protocolo de identidad de host 139 Se utiliza para el Protocolo de identidad de host versión 2 (HIPv2) [10] Protocolo Shim6 140 Usado para Shim6 [11] Reservado 253 Utilizado para experimentación y pruebas [12] [4] Reservado 254 Utilizado para experimentación y pruebas [12] [4]
Valor 59 (No Cabecera Siguiente) en el campo Siguiente Cabecera indica que no hay siguiente cabecera en absoluto siguiente éste, ni siquiera un encabezado de un protocolo de capa superior. Significa que, desde el punto de vista del encabezado, el paquete IPv6 termina justo después de él: la carga útil debe 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. Los hosts deben ignorar estos datos, pero los enrutadores deben pasarlos sin alterarlos. [1] : 4,7
Opciones de salto a salto y opciones de destino
El encabezado de la extensión Hop-by-Hop Options puede ser examinado y alterado 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 la extensión de Opciones de destino solo debe ser examinado por los nodos de destino. Los encabezados de extensión tienen un tamaño de al menos 8 octetos; si hay más opciones presentes de las que caben en ese espacio, se agregan bloques de 8 octetos al encabezado repetidamente, que contienen opciones y relleno, hasta que se representan todas las opciones.
Formato de encabezado de extensión de opciones de salto a salto y opciones de destino Compensaciones Octeto 0 1 2 3 Octeto Un poco 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 dieciséis 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Siguiente encabezado Longitud de la extensión del encabezado Opciones y acolchado 4 32 Opciones y acolchado 8 64 Opcional: más opciones y relleno 12 96
- Siguiente encabezado (8 bits)
- Especifica el tipo de encabezado siguiente.
- Longitud de la extensión del encabezado (8 bits)
- Longitud de este encabezado en unidades de 8 octetos, sin incluir los primeros 8 octetos.
- Opciones (variable)
- Contiene una o más opciones y campos de relleno opcionales para alinear las opciones y hacer que la longitud total del encabezado sea un múltiplo de 8 octetos. Las opciones están codificadas con 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 de al menos 8 octetos; si se necesitan más datos específicos del tipo de los que caben en 4 octetos, se agregan bloques de 8 octetos al encabezado repetidamente, hasta que se colocan todos los datos específicos del tipo . [1]
Formato de encabezado de extensión de enrutamiento Compensaciones Octeto 0 1 2 3 Octeto Un poco 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 dieciséis 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Siguiente encabezado Longitud de la extensión del encabezado Tipo de enrutamiento Segmentos a la izquierda 4 32 Datos específicos de tipo 8 64 Opcional: más datos específicos del tipo ... 12 96
- Siguiente encabezado (8 bits)
- Indica el tipo de encabezado siguiente.
- Longitud de la extensión del encabezado (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]
Tipo Estado Comentario 0 Obsoleto Debido al hecho de que con el Encabezado de enrutamiento tipo 0 se podría lanzar un ataque de denegación de servicio simple pero efectivo [14] , este encabezado está en desuso desde 2007 [15] y el host y los enrutadores deben ignorar estos encabezados.
1 Obsoleto Utilizado para el proyecto Nimrod [16] financiado por DARPA . Está en desuso desde 2009. 2 Permitido Una versión limitada del tipo 0 y se utiliza para IPv6 móvil , donde puede contener la dirección de inicio del nodo móvil. 3 Permitido Encabezado de ruta de origen RPL [17] para redes de baja potencia y con pérdidas. 253 Uso privado Puede usarse para pruebas, no para implementaciones reales. Experimento 1 al estilo RFC3692 . [12] 254 PrivateuUse Puede usarse para pruebas, no para implementaciones reales. Experimento 2 al estilo RFC3692 . [12]
- Segmentos a la izquierda (8 bits)
- Número de nodos que este paquete aún debe visitar antes de llegar a su destino final.
- Datos específicos de tipo (variable)
- Datos que pertenecen a este tipo de encabezado de enrutamiento.
Fragmento
Para enviar un paquete que es más grande que la ruta MTU , el nodo emisor divide el paquete en fragmentos. El encabezado de la extensión Fragmento contiene la información necesaria para volver a ensamblar el paquete original (sin fragmentar). [1]
Formato de encabezado de extensión de fragmento Compensaciones Octeto 0 1 2 3 Octeto Un poco 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 dieciséis 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Siguiente encabezado Reservado Desplazamiento de fragmento Res METRO 4 32 Identificación
- Siguiente encabezado (8 bits)
- Identifica el tipo de encabezado siguiente.
- Reservado (8 bits)
- Inicializado a todos los ceros.
- Desplazamiento de fragmento (13 bits)
- Desplazamiento, en unidades de 8 octetos, con respecto al inicio de la parte fragmentable del paquete original.
- Res (2 bits)
- Reservado; inicializado a ceros.
- Bandera M (1 bit)
- 1 significa que siguen más fragmentos; 0 significa último fragmento.
- Identificación (32 bits)
- Valor de identificación del paquete, generado por el nodo de origen. Necesario para volver a montar el 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 son parte de IPsec y se utilizan de forma idéntica en IPv6 y en IPv4. [18] [19]
Carga útil
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 Siguiente encabezado del último encabezado IPv6 indica qué tipo de carga útil está contenida en 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 utilizando Path MTU Discovery (que produce la MTU mínima a lolargo de la ruta del remitente al receptor), para evitar tener que fragmentar los paquetes. La mayoría de losprotocolos de capa de enlace tienen MTU considerablemente más pequeñas que65 535 octetos.
Jumbograma
Una característica opcional de IPv6, la opción de carga útil jumbo en un encabezado de extensión de Opciones Hop-By-Hop , [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), utilizando un campo de 32 bits de longitud. Los paquetes con tales 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 los 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 Hop-by-Hop ). Solo unos pocos protocolos de capa de enlace pueden procesar paquetes más grandes que65 535 octetos. [ cita requerida ]
Fragmentación
A diferencia de IPv4, los enrutadores IPv6 (nodos intermedios) 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 indica mediante un mensaje de paquete demasiado grande ICMPv6 tipo 2 al nodo de origen, de manera similar al método IPv4 cuando el bit No fragmentar es colocar. [1] Se espera que los nodos finales en IPv6 realicen Path MTU Discovery para determinar el tamaño máximo de paquetes a enviar, y se espera que el protocolo de capa superior limite el tamaño de la carga útil.
Sin embargo, si el protocolo de capa superior no puede hacerlo, el host de envío puede usar el encabezado de extensión Fragmento en su lugar. Cualquier capa de enlace de datos que transmita datos IPv6 debe ser capaz de transmitir un paquete IP que contenga hasta 1.280 bytes, por lo que el punto final de envío puede limitar sus paquetes a 1.280 bytes y evitar cualquier necesidad de fragmentación o descubrimiento de MTU de ruta.
Fragmentando
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 utilizan repetidamente en cada fragmento), seguidos del encabezado de extensión del 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 por el encabezado de extensión del 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 encabezado de extensión Routing o Hop-by-Hop :
- ninguno existe: la parte por fragmento es solo el encabezado fijo
- Enrutamiento cabecera de extensión existe: los encabezados por fragmento incluyen la cabecera fija y todas las cabeceras de extensión de hasta e incluyendo el enrutamiento uno
- Existe un encabezado de extensión Hop-by-Hop : los encabezados por fragmento constan solo del encabezado fijo y el encabezado de la extensión Hop-by-Hop .
En cualquier caso, el último encabezado de la parte por fragmento tiene su valor de Siguiente encabezado establecido en 44 para indicar que sigue un encabezado de extensión de fragmento .
Cada encabezado de extensión de Fragmento tiene su bandera M establecida en 1 (lo que indica que siguen más fragmentos), excepto el último, cuya bandera está establecida en 0 .
La longitud de cada fragmento es un múltiplo de 8 octetos, excepto el último fragmento.
Históricamente, los encabezados por fragmento se denominaron "parte no fragmentable", en referencia a la posibilidad anterior a 2014 de fragmentar el resto de encabezados. Ahora, ningún encabezado es realmente fragmentable. [20]
Reensamblaje
El paquete original es reensamblado por el nodo receptor recolectando todos los fragmentos y colocando cada fragmento en el desplazamiento correcto y descartando los encabezados de extensión de Fragmento de los paquetes que los transportaron. Los paquetes que contienen fragmentos no necesitan llegar en secuencia; serán reorganizados por el nodo receptor.
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 reensamblaje del paquete original y se descartan todos los fragmentos. Si se recibió el primer fragmento (que contiene el encabezado fijo), se devuelve un mensaje de tiempo excedido ( ICMPv6 tipo 3, código 1) al nodo que origina el paquete fragmentado, si el paquete se descartó por este motivo.
Cuando el nodo de reensamblaje detecta un fragmento que se superpone con otro fragmento, el reensamblaje del paquete original se cancela y todos los fragmentos deben descartarse silenciosamente. [1] La única excepción posible es que un nodo puede ignorar opcionalmente los duplicados exactos de un fragmento en lugar de tratar los duplicados exactos como superpuestos entre sí. [1]
Los hosts receptores deben hacer el mejor esfuerzo posible para reensamblar datagramas IP fragmentados que, después del reensamblaje, contienen hasta 1500 bytes. A los hosts se les permite intentar reensamblar datagramas fragmentados mayores de 1,500 bytes, pero también se les permite descartar silenciosamente cualquier datagrama después de que sea evidente que el paquete reensamblado sería mayor de 1,500 bytes. Por lo tanto, los remitentes deben evitar enviar datagramas IP fragmentados con un tamaño total reensamblado mayor de 1.500 bytes, a menos que tengan una garantía previa de que el receptor es capaz de reensamblar datagramas tan grandes.
Seguridad
La investigación ha demostrado que el uso de la fragmentación se puede aprovechar para evadir los controles de seguridad de la red. Como resultado, en 2014 se prohibió el permiso anterior para desbordar la cadena de encabezado IPv6 más allá del primer fragmento para evitar algunos casos de fragmentación muy patológica. [20] Además, como resultado de la investigación sobre la evasión de Router Advertisement Guard, [21] se desaprueba el uso de fragmentación con descubrimiento de vecinos y se desaconseja el uso de fragmentación con Secure Neighbor Discovery (SEND). [22]
Referencias
- ^ a b c d e f g h i j k l m n S. Deering ; R. Hinden (julio de 2017). Protocolo de Internet, especificación de la versión 6 (IPv6) . Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487 / RFC8200 . RFC 8200 . Desactiva RFC 2460.
- ^ K. Nickols; S. Blake; F. Baker ; D. Black (diciembre de 1998). Definición del campo de servicio diferenciado (campo DS) en los encabezados IPv4 e IPv6 . doi : 10.17487 / RFC2474 . RFC 2474 .
- ^ D. Grossman (abril de 2002). Nueva terminología y aclaraciones para DiffServ . doi : 10.17487 / RFC3260 . RFC 3260 .
- ^ a b c B. Fenner (noviembre de 2006). Valores experimentales en encabezados IPv4, IPv6, ICMPv4, ICMPv6, UDP y TCP . Grupo de trabajo en red. doi : 10.17487 / RFC4727 . RFC 4727 .
- ^ K. Ramakrishnan; S. Floyd; D. Black (septiembre de 2001). La adición de notificación explícita de congestión (ECN) a IP . doi : 10.17487 / RFC3168 . RFC 3168 .
- ^ S. Amante; B. Carpintero; S. Jiang; J. Rajahalme (noviembre de 2011). Especificación de etiqueta de flujo IPv6 . doi : 10.17487 / RFC6437 . RFC 6437 .
- ^ Uso de la etiqueta de flujo IPv6 como Nonce de capa de transporte para defenderse contra ataques de suplantación de identidad fuera de la ruta
- ^ a b c D. Borman; S. Deering ; R. Hinden (agosto de 1999). Jumbogramas IPv6 . doi : 10.17487 / RFC2675 . RFC 2675 .
- ^ C. Perdiz; F. Kastenholz (diciembre de 1994). Criterios técnicos para elegir IP de próxima generación (IPng) . segundo. 6.2. doi : 10.17487 / RFC1726 . RFC 1726 .
- ^ 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 .
- ^ E. Nordmark; M. Bagnulo (junio de 2009). Shim6: Protocolo de Shim Multihoming de nivel 3 para IPv6 . Grupo de Trabajo de Redes. doi : 10.17487 / RFC5533 . RFC 5533 .
- ^ a b c d T. Narten (enero de 2004). Asignar números experimentales y de prueba que se consideren útiles . Grupo de trabajo en red. doi : 10.17487 / RFC3692 . RFC 3692 . BCP 82. Actualiza RFC 2434.
- ^ "Parámetros del Protocolo de Internet versión 6 (IPv6): Tipos de enrutamiento" . IANA . Consultado el 17 de noviembre de 2017 .
- ^ Philippe Biondi, Arnoud Ebalard (abril de 2007). "Seguridad del encabezado de enrutamiento IPv6" (PDF) . EADS . Consultado el 3 de diciembre de 2010 .
Tipo 0: el mecanismo del mal ...
- ^ J. Abley; P. Savola; G. Neville-Neil (diciembre de 2007). Desactivación de los encabezados de enrutamiento de tipo 0 en IPv6 . doi : 10.17487 / RFC5095 . RFC 5095 .
- ^ I. Castineyra; N. Chiappa; M. Steenstrup (agosto de 1996). La arquitectura de enrutamiento de Nimrod . doi : 10.17487 / RFC1992 . RFC 1992 .
- ^ 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 bajo consumo y con pérdidas (RPL) . Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487 / RFC6554 . RFC 6554 .
- ^ S. Kent (diciembre de 2005). Encabezado de autenticación de IP . doi : 10.17487 / RFC4302 . RFC 4302 .
- ^ S. Kent (diciembre de 2005). Carga útil de seguridad de encapsulación IP . doi : 10.17487 / RFC4302 . RFC 4302 .
- ^ a b F. Gont; V. Manral; R. Bonica (enero de 2014). Implicaciones de cadenas de encabezado IPv6 de gran tamaño . doi : 10.17487 / RFC7112 . RFC 7112 .
- ^ F. Gont (febrero de 2014). Consejos de implementación para la protección de anuncios de enrutador IPv6 (RA-Guard) . doi : 10.17487 / RFC7113 . RFC 7113 .
- ^ F. Gont (agosto de 2013). Implicaciones de seguridad de la fragmentación de IPv6 con el descubrimiento de vecinos de IPv6 . doi : 10.17487 / RFC6980 . RFC 6980 .