Protocolo de mensajes de control de Internet

La cabecera ICMP comienza después de la cabecera IPv4 y se identifica por su número de protocolo , 1. ^[ 6 ^{] Todos los} paquetes ICMP tienen una cabecera de ocho bytes y una sección de datos de tamaño variable. Los primeros cuatro bytes de la cabecera tienen un formato fijo, mientras que los últimos cuatro bytes dependen del tipo y código del paquete ICMP. ^{[ 3 ]}

Tipo : 8 bits

Tipo ICMP, véase §  Mensajes de control .

Código : 8 bits

Subtipo ICMP, véase §  Mensajes de control .

Suma de verificación : 16 bits

Suma de verificación de Internet ^{[ 7 ]} para la verificación de errores, calculada a partir del encabezado ICMP y los datos con el valor 0 sustituido para este campo.

Resto del encabezado : 32 bits

Campo de cuatro bytes, cuyo contenido varía según el tipo y el código ICMP.

Los mensajes de error ICMP contienen una sección de datos que incluye una copia de la cabecera IPv4 completa, además de al menos los primeros ocho bytes de datos del paquete IPv4 que generó el mensaje de error. La longitud de los mensajes de error ICMP no debe exceder los 576 bytes. ^{[ 1 ]} El host utiliza estos datos para asociar el mensaje con el proceso correspondiente. Si un protocolo de nivel superior utiliza números de puerto, se asume que estos se encuentran en los primeros ocho bytes de los datos del datagrama original. ^{[ 2 ]}

Se ha explotado el tamaño variable de la sección de datos del paquete ICMP . En el ataque " Ping of death ", se utilizan paquetes ICMP grandes o fragmentados para ataques de denegación de servicio . Los datos ICMP también pueden utilizarse para crear canales de comunicación encubiertos , conocidos como túneles ICMP .

Source Quench solicita al remitente que reduzca la frecuencia de los mensajes enviados a un enrutador o host. Este mensaje puede generarse si un enrutador o host no dispone de suficiente espacio de búfer para procesar la solicitud, o si el búfer del enrutador o host se está acercando a su límite.

Los datos se envían a gran velocidad desde uno o varios hosts simultáneamente a un enrutador específico en la red. Si bien el enrutador cuenta con capacidad de almacenamiento en búfer, esta se limita a un rango determinado. El enrutador no puede almacenar en cola más datos de los que caben en su capacidad. Por lo tanto, si la cola se llena, los datos entrantes se descartan hasta que la cola vuelva a llenarse. Sin embargo, dado que no existe un mecanismo de confirmación en la capa de red, el cliente desconoce si los datos han llegado correctamente a su destino. Por consiguiente, la capa de red debe implementar medidas correctivas para evitar este tipo de situaciones. Estas medidas se conocen como saturación de la fuente.

En un mecanismo de control de flujo de origen, el enrutador detecta que la velocidad de datos entrantes es mucho mayor que la de salida y envía un mensaje ICMP a los clientes, indicándoles que deben reducir la velocidad de transferencia de datos o esperar un tiempo determinado antes de intentar enviar más datos. Cuando un cliente recibe este mensaje, reduce automáticamente la velocidad de salida o espera el tiempo suficiente, lo que permite al enrutador vaciar la cola. De esta forma, el mensaje ICMP de control de flujo de origen actúa como un mecanismo de control de flujo en la capa de red.

Dado que las investigaciones sugerían que "ICMP Source Quench [era] un antídoto ineficaz (e injusto) para la congestión", ^{[ 10 ]} la creación de mensajes source quench por parte de los enrutadores quedó obsoleta en 1995 mediante el RFC 1812. Además, el reenvío y cualquier tipo de reacción a (acciones de control de flujo) mensajes source quench quedaron obsoletos a partir de 2012 mediante el RFC 6633.

Dónde:

• El tipo debe establecerse en 4
• El código debe establecerse en 0.
• El remitente utiliza el encabezado IP y datos adicionales para hacer coincidir la respuesta con la solicitud asociada.

Las solicitudes de redirección hacen que los paquetes de datos se envíen por una ruta alternativa. La redirección ICMP es un mecanismo que utilizan los enrutadores para transmitir información de enrutamiento a los hosts. El mensaje informa a un host que actualice su información de enrutamiento (para enviar paquetes por una ruta alternativa). Si un host intenta enviar datos a través de un enrutador (R1) y R1 envía los datos a través de otro enrutador (R2) y existe una ruta directa desde el host a R2 (es decir, el host y R2 están en la misma subred ), entonces R1 enviará un mensaje de redirección para informar al host que la mejor ruta para el destino es a través de R2. El host deberá entonces cambiar su información de ruta y enviar los paquetes para ese destino directamente a R2. El enrutador seguirá enviando el datagrama original al destino previsto. ^{[ 15 ]} Sin embargo, si el datagrama contiene información de enrutamiento, este mensaje no se enviará incluso si existe una mejor ruta. El RFC 1122 establece que las redirecciones solo deben ser enviadas por las pasarelas y no por los hosts de Internet.

Dónde:

• El tipo debe estar configurado en 5.
• El código especifica el motivo de la redirección y puede ser uno de los siguientes:
• La dirección IP es la dirección de 32 bits de la puerta de enlace a la que se debe enviar la redirección.
• Se incluye un encabezado IP y datos adicionales para permitir que el host haga coincidir la respuesta con la solicitud que provocó la redirección.

El mensaje "Tiempo excedido" es generado por una puerta de enlace para informar al origen que un datagrama ha sido descartado debido a que el campo de tiempo de vida ha llegado a cero. Un host también puede enviar un mensaje de tiempo excedido si no logra reconstruir un datagrama fragmentado dentro del límite de tiempo establecido.

Los mensajes de tiempo excedido son utilizados por la utilidad traceroute para identificar las puertas de enlace en la ruta entre dos hosts.

Dónde:

• El tipo debe estar configurado en 11.
• El código especifica el motivo del mensaje de tiempo excedido e incluye lo siguiente:
• El host de origen utiliza la cabecera IP y los primeros 64 bits de la carga útil original para asociar el mensaje de tiempo excedido con el datagrama descartado. Para protocolos de nivel superior como UDP y TCP, la carga útil de 64 bits incluirá los puertos de origen y destino del paquete descartado.

La marca de tiempo se utiliza para la sincronización horaria. La marca de tiempo de origen se establece en el momento (en milisegundos desde la medianoche) en que el remitente accedió por última vez al paquete. Las marcas de tiempo de recepción y transmisión no se utilizan.

Dónde:

• El tipo debe establecerse en 13.
• El código debe establecerse en 0.
• El cliente puede utilizar el identificador y el número de secuencia para hacer coincidir la respuesta con la marca de tiempo solicitada.
• La marca de tiempo de origen es el número de milisegundos transcurridos desde la medianoche, hora universal (UT). Si no se dispone de una referencia UT, se puede configurar el bit más significativo para indicar un valor de tiempo no estándar.

La respuesta con marca de tiempo responde a un mensaje con marca de tiempo . Consta de la marca de tiempo original enviada por el remitente, una marca de tiempo de recepción que indica cuándo se recibió el mensaje y una marca de tiempo de transmisión que indica cuándo se envió la respuesta .

Dónde:

• El tipo debe establecerse en 14.
• El código debe establecerse en 0.
• El cliente puede utilizar el identificador y el número de secuencia para relacionar la respuesta con la solicitud que la originó.
• La marca de tiempo de origen es la hora en que el remitente modificó el mensaje por última vez antes de enviarlo.
• La marca de tiempo de recepción es el momento en que el emisor la tocó por primera vez al recibirla.
• La marca de tiempo de transmisión es la hora en que el emisor modificó por última vez el mensaje al enviarlo.

Todas las marcas de tiempo se expresan en milisegundos desde la medianoche (UT). Si la hora no está disponible en milisegundos o no se puede proporcionar con respecto a la medianoche (UT), se puede insertar cualquier hora en la marca de tiempo, siempre que el bit de orden superior de la marca de tiempo también indique este valor no estándar.

El uso de mensajes de marca de tiempo y respuesta de marca de tiempo para sincronizar los relojes de los nodos de Internet ha sido reemplazado en gran medida por el Protocolo de tiempo de red basado en UDP y el Protocolo de tiempo de precisión . ^{[ 16 ]}

Normalmente, un host envía una solicitud de máscara de dirección a un enrutador para obtener una máscara de subred adecuada .

Los destinatarios deberán responder a este mensaje con un mensaje de respuesta con máscara de dirección .

Dónde:

• El tipo debe establecerse en 17.
• El código debe establecerse en 0.
• La máscara de dirección se puede establecer en 0.

La solicitud de máscara de dirección ICMP puede utilizarse como parte de un ataque de reconocimiento para recopilar información sobre la red objetivo; por lo tanto, la respuesta de máscara de dirección ICMP está deshabilitada de forma predeterminada en Cisco IOS . ^{[ 17 ]}

La respuesta de máscara de dirección se utiliza para responder a un mensaje de solicitud de máscara de dirección con una máscara de subred adecuada.

Dónde:

• El tipo debe establecerse en 18.
• El código debe establecerse en 0.
• La máscara de direcciones debe configurarse con la máscara de subred.

El mensaje "Destino inalcanzable" es generado por el host o su puerta de enlace de entrada ^{[ 2 ]} para informar al cliente que el destino es inalcanzable por alguna razón. Las razones para este mensaje pueden incluir: la conexión física con el host no existe (la distancia es infinita); el protocolo o puerto indicado no está activo; los datos deben fragmentarse pero la bandera "no fragmentar" está activada. ^{[ 18 ]} Los puertos TCP inalcanzables responden notablemente con TCP RST en lugar de un tipo de destino inalcanzable 3, como cabría esperar. El mensaje "Destino inalcanzable" nunca se informa para las transmisiones multicast IP .

Con el siguiente contenido de campo:

Tipo : 8 bits ; Tipo == 3

Un valor de 3 indica que el destino es inaccesible.

Código : 8 bits

Esto especifica el tipo de error y puede ser cualquiera de los siguientes: ^{[ 8 ]}

Sin usar : 8 - 32 bits ; Sin usar == 0

Si no se utiliza, debe establecerse en cero. Si no se utilizan la longitud o la MTU del siguiente salto , se consideran parte de este campo.

Longitud : 8 bits

Opcional. El campo Longitud indica la longitud de los datos del datagrama original, en palabras de 32 bits. Esto permite extender este mensaje ICMP con información adicional. Si se utiliza, los datos del datagrama original deben rellenarse con ceros hasta el límite de 32 bits más cercano.

MTU del siguiente salto : 16 bits

Opcional. Contiene la MTU de la red del siguiente salto si se produce un error de código 4.

Encabezado y datos IP : 20 - 568 bytes

El encabezado IP (20 bytes) y, como máximo, 548 bytes del inicio del datagrama original (para no exceder el tamaño mínimo del búfer de reensamblaje IPv4). Si este mensaje se extiende, este campo debe contener al menos 128 bytes de datos del datagrama original (rellenados con ceros si es necesario). Estos datos se incluyen para que el cliente pueda relacionar la respuesta con la solicitud que provocó la respuesta de destino inalcanzable .