stringtranslate.com

ICMPv6

El Protocolo de mensajes de control de Internet versión 6 ( ICMPv6 ) es la implementación del Protocolo de mensajes de control de Internet (ICMP) para el Protocolo de Internet versión 6 (IPv6). [1] ICMPv6 es una parte integral de IPv6 y realiza funciones de diagnóstico e informes de errores.

ICMPv6 tiene un marco para extensiones para implementar nuevas características. Se han publicado varias extensiones, que definen nuevos tipos de mensajes ICMPv6, así como nuevas opciones para los tipos de mensajes ICMPv6 existentes. Por ejemplo, Neighbor Discovery Protocol (NDP) es un protocolo de descubrimiento de nodos basado en ICMPv6 que reemplaza y mejora las funciones de ARP . [2] Secure Neighbor Discovery (SEND) es una extensión de NDP con seguridad adicional. Multicast Listener Discovery (MLD) es utilizado por enrutadores IPv6 para descubrir oyentes de multidifusión en un enlace conectado directamente, de manera similar a como se utiliza el Protocolo de administración de grupos de Internet (IGMP) en IPv4 . Multicast Router Discovery (MRD) permite el descubrimiento de enrutadores de multidifusión.

Tipos y formatos de mensajes

Los mensajes ICMPv6 pueden clasificarse como mensajes de error y mensajes de información . Los mensajes ICMPv6 se transportan mediante paquetes IPv6 en los que el valor del encabezado siguiente IPv6 para ICMPv6 se establece en el valor 58 .

El mensaje ICMPv6 consta de un encabezado y la carga útil del protocolo. El encabezado contiene solo tres campos: Tipo (8 bits), Código (8 bits) y Suma de comprobación (16 bits).

Tipo: 8 bits
Especifica el tipo de mensaje. Los valores comprendidos entre 0 y 127 (el bit de orden superior es 0) indican un mensaje de error, mientras que los valores comprendidos entre 128 y 255 (el bit de orden superior es 1) indican un mensaje de información.
Código: 8 bits
El valor del campo Código depende del tipo de mensaje y proporciona un nivel adicional de granularidad del mensaje.
Suma de comprobación: 16 bits
Proporciona un nivel mínimo de verificación de integridad para el mensaje ICMP. La suma de comprobación se calcula a partir del mensaje ICMP (comenzando con el campo Tipo ), precedido por un pseudoencabezado IPv6 . [1] Véase a continuación.
Cuerpo del mensaje: Variable
El contenido depende del mensaje.

Tipos

Los mensajes de control se identifican por el valor del campo de tipo . El campo de código proporciona información de contexto adicional para el mensaje. Algunos mensajes cumplen la misma función que los tipos de mensajes ICMP con el nombre correspondiente.

Tenga en cuenta que la tabla anterior no es exhaustiva. La lista completa actual de tipos ICMPv6 asignados se puede encontrar en este enlace: IANA: Parámetros ICMPv6.

Suma de comprobación

ICMPv6 proporciona un nivel mínimo de verificación de integridad de mensajes mediante la inclusión de una suma de comprobación de 16 bits en su encabezado. La suma de comprobación se calcula comenzando con un pseudoencabezado de campos de encabezado IPv6 de acuerdo con el estándar IPv6, [6] que consta de las direcciones de origen y destino, la longitud del paquete y el siguiente campo de encabezado, el último de los cuales se establece en el valor 58. Después de este pseudoencabezado, la suma de comprobación continúa con el mensaje ICMPv6. El cálculo de la suma de comprobación se realiza de acuerdo con los estándares del protocolo de Internet utilizando la suma de complemento a uno de 16 bits , seguida de un complemento a uno final de la suma de comprobación misma e insertándola en el campo de suma de comprobación. [7] Tenga en cuenta que esto difiere de la forma en que se calcula para IPv4 en ICMP , pero es similar al cálculo realizado en TCP .

Formato

La carga útil de un mensaje ICMPv6 varía según el tipo de mensaje que se envía. Comienza en el bit 32, inmediatamente después del encabezado descrito anteriormente. Para algunos mensajes, como destino inalcanzable o tiempo excedido, no hay un cuerpo de mensaje definido.

Otros definen un uso solo para los primeros cuatro bytes del cuerpo sin ningún otro contenido definido:

En el caso de los mensajes NDP , los primeros cuatro bytes están reservados o se utilizan para indicadores o límites de saltos. Mientras que el restablecimiento del cuerpo tiene datos estructurados no especificados:

Para una redirección, los primeros bytes del cuerpo del mensaje se reservan pero no se utilizan. A continuación, se incluye una dirección de destino. Se pueden adjuntar opciones no especificadas al final:

Procesamiento de mensajes

Cuando un nodo ICMPv6 recibe un paquete, debe llevar a cabo acciones que dependen del tipo de mensaje. El protocolo ICMPv6 debe limitar la cantidad de mensajes de error enviados al mismo destino para evitar la sobrecarga de la red. Por ejemplo, si un nodo continúa reenviando paquetes erróneos, ICMP señalará el error al primer paquete y luego lo hará periódicamente, con un período mínimo fijo o con una carga máxima fija de la red. Nunca se debe enviar un mensaje de error ICMP en respuesta a otro mensaje de error ICMP.

Referencias

  1. ^ ab A. Conta; S. Deering (marzo de 2006). M. Gupta (ed.). Protocolo de mensajes de control de Internet (ICMPv6) para la especificación del protocolo de Internet versión 6 (IPv6). Grupo de trabajo de redes. doi : 10.17487/RFC4443 . STD 89. RFC 4443. Estándar de Internet 89. Obsoleto RFC 2463. Actualiza RFC 2780. Actualizado por RFC 4884.
  2. ^ T. Mrugalski; M. Siodelski; B. Volz; A. Yourtchenko; M. Richardson; S. Jiang; T. Lemon; T. Winters (noviembre de 2018). Protocolo de configuración dinámica de host para IPv6 (DHCPv6). IETF . doi : 10.17487/RFC8415 . ISSN  2070-1721. RFC 8415. Norma propuesta. Sec. 3. Deja obsoletas las RFC 3315, 3633, 3736, 4242, 7083, 7283 y 7550.
  3. ^ M. Crawford (agosto de 2000). Renumeración de enrutadores para IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC2894 . RFC 2894. Norma propuesta.
  4. ^ R. Vida; L. Costa, eds. (junio de 2004). Multicast Listener Discovery Version 2 (MLDv2) para IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC3810 . RFC 3810. Norma propuesta. Actualizaciones RFC 2710. Actualizado por RFC 4604.
  5. ^ ab R. Bonica; R. Thomas; J. Linkova; C. Lenart; M. Boucadair (febrero de 2018). PROBE: una utilidad para sondear interfaces. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC8335 . ISSN  2070-1721. RFC 8335. Norma propuesta. Actualizaciones RFC 4884.
  6. ^ S. Deering ; R. Hinden (julio de 2017). Especificación del Protocolo de Internet, versión 6 (IPv6). IETF . doi : 10.17487/RFC8200 . STD 86. RFC 8200. Estándar de Internet 86. seg. 8.1. Obsoleto RFC 2460.
  7. ^ R. Braden ; D. Borman; C. Partridge (septiembre de 1988). Cálculo de la suma de comprobación de Internet. Grupo de trabajo de redes. doi : 10.17487/RFC1071 . RFC 1071. Informativo. Actualizado por RFC 1141.

Enlaces externos