Hispanopedia Wiki
Articulo de referencia

ICMPv6

Internet Control Message Protocol version 6 ( ICMPv6 ) is the implementation of the Internet Control Message Protocol (ICMP) for Internet Protocol version 6 (IPv6). [ 1 ] ICMPv6...

Hispanopedia WikiContenido en espanolLectura gratuita

Internet Control Message Protocol version 6 (ICMPv6) is the implementation of the Internet Control Message Protocol (ICMP) for Internet Protocol version 6 (IPv6).[1] ICMPv6 is an integral part of IPv6 and performs error reporting and diagnostic functions.

ICMPv6 has a framework for extensions to implement new features. Several extensions have been published, defining new ICMPv6 message types as well as new options for existing ICMPv6 message types. For example, Neighbor Discovery Protocol (NDP) is a node discovery protocol based on ICMPv6 which replaces and enhances functions of ARP.[2]Secure Neighbor Discovery (SEND) is an extension of NDP with extra security. Multicast Listener Discovery (MLD) is used by IPv6 routers for discovering multicast listeners on a directly attached link, much like Internet Group Management Protocol (IGMP) is used in IPv4. Multicast Router Discovery (MRD) allows the discovery of multicast routers.

Message types and formats

ICMPv6 messages may be classified as error messages and information messages. ICMPv6 messages are transported by IPv6 packets in which the IPv6 Next Header value for ICMPv6 is set to the value 58.

The ICMPv6 message consists of a header and the protocol payload. The header contains only three fields: Type (8 bits), Code (8 bits), and Checksum (16 bits).

Type: 8 bits
Specifies the type of the message. Values in the range from 0 to 127 (high-order bit is 0) indicate an error message, while values in the range from 128 to 255 (high-order bit is 1) indicate an information message.
Code: 8 bits
The Code field value depends on the message type and provides an additional level of message granularity.
Checksum: 16 bits
Provides a minimal level of integrity verification for the ICMP message. The checksum is calculated from the ICMP message (starting with the Type field), prepended with an IPv6 pseudo-header.[1] See below.
Message body: Variable
Contents depends on the message.

Types

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

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 verificación

ICMPv6 proporciona un nivel mínimo de verificación de integridad del mensaje mediante la inclusión de una suma de comprobación de 16 bits en su encabezado. La suma de comprobación se calcula a partir de un pseudoencabezado de campos de encabezado IPv6 según el estándar IPv6, [ 6 ] que consta de las direcciones de origen y destino, la longitud del paquete y el siguiente campo de encabezado, este último establecido 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 según 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 propia suma de comprobación y su inserción en el campo de suma de comprobación. [ 7 ] Nótese 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 existe un cuerpo de mensaje definido.

Otros definen un uso únicamente 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/límite de saltos. Mientras que el resto del cuerpo contiene 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 la dirección de destino. Se pueden añadir opciones no especificadas al final.

Procesamiento de mensajes

Cuando un nodo ICMPv6 recibe un paquete, debe realizar 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 notificará el error al primer paquete y, posteriormente, lo hará periódicamente, con un intervalo mínimo fijo o con una carga máxima de red fija. Nunca se debe enviar un mensaje de error ICMP en respuesta a otro mensaje de error ICMP.

Referencias

  1. 1 2 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. Deja obsoleto el RFC 2463. Actualiza el RFC 2780. Actualizado por el 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) . Grupo de trabajo de ingeniería de Internet . 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) for IPv6 . Network Working Group. doi : 10.17487/RFC3810 . RFC 3810 .Estándar propuesto. Actualiza RFC 2710. Actualizado por RFC 4604 .  
  5. 1 2 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 . doi : 10.17487/RFC8335 . ISSN 2070-1721 . RFC 8335 . Estándar propuesto. Actualiza el RFC 4884 . 
  6. ↑ 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. seg. 8.1. Obsoleto RFC 2460 . 
  7. ↑ R. Braden ; D. Borman; C. Partridge (septiembre de 1988). Cálculo de la suma de verificación de Internet . Grupo de trabajo de redes. doi : 10.17487/RFC1071 . RFC 1071 .Informativo. Actualizado por RFC 1141 . 
  • IANA: Parámetros de ICMPv6