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).
Especifica el tipo de mensaje. Los valores en el rango de 0 a 127 (el bit de orden superior es 0) indican un mensaje de error, mientras que los valores en el rango de 128 a 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.
Hay dos subtipos de mensajes de consulta de escucha de multidifusión:
Consulta general, utilizada para saber qué direcciones de multidifusión tienen oyentes en un enlace adjunto.
Consulta específica de dirección de multidifusión, utilizada para saber si una dirección de multidifusión particular tiene algún oyente en un enlace adjunto.
Estos dos subtipos se diferencian por el contenido del campo Dirección de multidifusión, como se describe en la sección 3.6 del RFC 2710.
Reservado para la expansión de mensajes informativos ICMPv6
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 .
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.
Destino inalcanzable
Desplazamiento de bits
0–7
8–15
16–31
0
1
Código
Suma de comprobación
32
No usado
64
Cuerpo del mensaje (tamaño variable)
Tiempo excedido
Desplazamiento de bits
0–7
8–15
16–31
0
3
Código
Suma de comprobación
32
No usado
64
Cuerpo del mensaje (tamaño variable)
Otros definen un uso solo para los primeros cuatro bytes del cuerpo sin ningún otro contenido definido:
Paquete demasiado grande
Desplazamiento de bits
0–7
8–15
16–31
0
2
0
Suma de comprobación
32
Unidad de medida máxima
64
Cuerpo del mensaje (tamaño variable)
Problema de parámetros
Desplazamiento de bits
0–7
8–15
16–31
0
4
Código
Suma de comprobación
32
Puntero
64
Cuerpo del mensaje (tamaño variable)
Solicitud de eco
Desplazamiento de bits
0–7
8–15
16–31
0
128
0
Suma de comprobación
32
Identificador
Número de secuencia
64
Datos (Tamaño variable)
Respuesta de eco
Desplazamiento de bits
0–7
8–15
16–31
0
129
0
Suma de comprobación
32
Identificador
Número de secuencia
64
Datos (Tamaño variable)
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:
Solicitud de enrutador
Desplazamiento de bits
0–7
8–15
16–31
0
133
0
Suma de comprobación
32
Reservado
64
Opciones (Tamaño variable)
Anuncio de enrutador
Desplazamiento de bits
0–7
8–15
16–31
0
134
0
Suma de comprobación
32
Límite de saltos de Cur
Bandera de dirección administrada
Otra bandera de configuración
Reservado
Duración de vida del enrutador
64
Tiempo alcanzable
96
Tiempo de retransmisión
128
Opciones (Tamaño variable)
Solicitud de vecinos
Desplazamiento de bits
0–7
8–15
16–31
0
135
0
Suma de comprobación
32
Reservado
64
Dirección de destino (16 bytes)
192
Opciones (Tamaño variable)
Anuncio de vecino
Desplazamiento de bits
0–7
8–15
16–31
0
136
0
Suma de comprobación
32
Desde el enrutador (R)
Bandera(s) solicitada(s)
Anular(O)
Reservado
64
Dirección de destino (16 bytes)
192
Opciones (Tamaño variable)
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:
Redirección ICMPv6
Desplazamiento de bits
0–7
8–15
16–31
0
137
0
Suma de comprobación
32
Reservado
64
Dirección de destino (16 bytes)
192
Dirección de destino (16 bytes)
320
Opciones (Tamaño variable)
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
^ 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.
^ 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.
^ M. Crawford (agosto de 2000). Renumeración de enrutadores para IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC2894 . RFC 2894.Norma propuesta.
^ 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.
^ 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.
^ 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.
^ 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
Wikiversidad tiene recursos de aprendizaje sobre ICMPv6
