Protocolo de comunicación | |
Objetivo | Protocolo auxiliar para IPv4 [1] |
---|---|
Desarrollador (es) | DARPA |
Introducido | 1981 |
Capa OSI | Capa de red |
RFC (s) | RFC 792 |
El Protocolo de mensajes de control de Internet ( ICMP ) es un protocolo de apoyo en el conjunto de protocolos de Internet . Lo utilizan los dispositivos de red , incluidos los enrutadores , para enviar mensajes de error e información operativa que indican éxito o falla al comunicarse con otra dirección IP , por ejemplo, se indica un error cuando un servicio solicitado no está disponible o que un host o enrutador no pudo ser alcanzado. [2] ICMP se diferencia de los protocolos de transporte como TCP y UDP.en el sentido de que no se utiliza normalmente para intercambiar datos entre sistemas, ni las aplicaciones de red del usuario final lo emplean habitualmente (con la excepción de algunas herramientas de diagnóstico como ping y traceroute ).
ICMP para IPv4 se define en RFC 792. Se utiliza un ICMPv6 separado , definido por RFC 4443, con IPv6 .
Conjunto de protocolos de internet |
---|
Capa de aplicación |
Capa de transporte |
|
Capa de internet |
|
Capa de enlace |
|
ICMP es parte del conjunto de protocolos de Internet según se define en RFC 792. Los mensajes ICMP se utilizan normalmente con fines de diagnóstico o control o se generan en respuesta a errores en las operaciones de IP (como se especifica en RFC 1122). Los errores de ICMP se dirigen a la dirección IP de origen del paquete de origen. [2]
Por ejemplo, cada dispositivo (como un enrutador intermedio ) que reenvía un datagrama IP primero reduce en uno el campo de tiempo de vida (TTL) en el encabezado IP. Si el TTL resultante es 0, el paquete se descarta y se envía un mensaje de tiempo ICMP excedido en tránsito a la dirección de origen del datagrama.
Muchas de las utilidades de red más utilizadas se basan en mensajes ICMP. El comando traceroute se puede implementar transmitiendo datagramas IP con campos de encabezado IP TTL especialmente configurados y buscando el tiempo ICMP excedido en tránsito y los mensajes de destino inalcanzable generados en respuesta. La utilidad de ping relacionada se implementa mediante la solicitud de eco ICMP y los mensajes de respuesta de eco .
ICMP utiliza el soporte básico de IP como si fuera un protocolo de nivel superior, sin embargo, ICMP es en realidad una parte integral de IP. Aunque los mensajes ICMP están contenidos en paquetes IP estándar, los mensajes ICMP generalmente se procesan como un caso especial, que se distingue del procesamiento IP normal. En muchos casos, es necesario inspeccionar el contenido del mensaje ICMP y entregar el mensaje de error apropiado a la aplicación responsable de transmitir el paquete IP que solicitó el envío del mensaje ICMP.
ICMP es un protocolo de capa de red. No hay ningún número de puerto TCP o UDP asociado con los paquetes ICMP, ya que estos números están asociados con la capa de transporte anterior. [3]
El paquete ICMP está encapsulado en un paquete IPv4. [2] El paquete consta de secciones de datos y encabezado.
El encabezado ICMP comienza después del encabezado IPv4 y se identifica con el número de protocolo IP '1'. [4] Todos los paquetes ICMP tienen un encabezado de 8 bytes y una sección de datos de tamaño variable. Los primeros 4 bytes del encabezado tienen un formato fijo, mientras que los últimos 4 bytes dependen del tipo / código de ese paquete ICMP. [2]
Compensaciones | Octeto | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Octeto | 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 | Escribe | Código | Suma de comprobación | |||||||||||||||||||||||||||||
4 | 32 | Resto del encabezado |
Los mensajes de error ICMP contienen una sección de datos que incluye una copia del encabezado IPv4 completo, más al menos los primeros ocho bytes de datos del paquete IPv4 que causó el mensaje de error. La longitud máxima de los mensajes de error ICMP es 576 bytes. [5] El host utiliza estos datos para hacer coincidir el mensaje con el proceso correspondiente. Si un protocolo de nivel superior usa números de puerto, se supone que están en los primeros ocho bytes de los datos del datagrama original. [6]
Se ha aprovechado el tamaño variable de la sección de paquetes de datos ICMP . En el " Ping of death ", se utilizan paquetes ICMP grandes o fragmentados para ataques de denegación de servicio . Los datos ICMP también se pueden utilizar para crear canales encubiertos para la comunicación. Estos canales se conocen como túneles ICMP .
Los mensajes de control se identifican por el valor en el campo de tipo . El campo de código proporciona información de contexto adicional para el mensaje. Algunos mensajes de control han quedado obsoletos desde que se introdujo por primera vez el protocolo.
Escribe | Código | Estado | Descripción |
---|---|---|---|
0 - Respuesta de eco [6] : 14 | 0 | Respuesta de eco (usado para hacer ping ) | |
1 y 2 | no asignado | Reservado | |
3 - Destino inalcanzable [6] : 4 | 0 | Red de destino inalcanzable | |
1 | Host de destino inalcanzable | ||
2 | Protocolo de destino inalcanzable | ||
3 | Puerto de destino inalcanzable | ||
4 | Se requiere fragmentación y se ha establecido el indicador DF | ||
5 | Error en la ruta de origen | ||
6 | Red de destino desconocida | ||
7 | Host de destino desconocido | ||
8 | Host de origen aislado | ||
9 | Red prohibida administrativamente | ||
10 | Anfitrión administrativamente prohibido | ||
11 | Red inalcanzable para ToS | ||
12 | Host inalcanzable para ToS | ||
13 | Comunicación prohibida administrativamente | ||
14 | Violación de la precedencia del host | ||
15 | Corte de precedencia en efecto | ||
4 - Enfriamiento de la fuente | 0 | Apagado de la fuente (control de la congestión) | |
5 - Mensaje de redireccionamiento | 0 | Redirigir datagrama para la red | |
1 | Redirigir datagrama para el host | ||
2 | Redirigir datagrama para ToS y red | ||
3 | Redirigir datagrama para ToS y host | ||
6 | Dirección de host alternativa | ||
7 | no asignado | Reservado | |
8 - Solicitud de eco | 0 | Solicitud de eco (usado para hacer ping) | |
9 - Anuncio de enrutador | 0 | Anuncio de enrutador | |
10 - Solicitud de enrutador | 0 | Descubrimiento / selección / solicitud de enrutador | |
11 - Tiempo excedido [6] : 6 | 0 | TTL caducó en tránsito | |
1 | Se superó el tiempo de reensamblaje del fragmento | ||
12 - Problema de parámetro: encabezado IP incorrecto | 0 | El puntero indica el error | |
1 | Falta una opción requerida | ||
2 | Mala longitud | ||
13 - Marca de tiempo | 0 | Marca de tiempo | |
14 - Respuesta de marca de tiempo | 0 | Respuesta de marca de tiempo | |
15 - Solicitud de información | 0 | Solicitud de información | |
16 - Respuesta de información | 0 | Respuesta de información | |
17 - Solicitud de máscara de dirección | 0 | Solicitud de máscara de dirección | |
18 - Respuesta de máscara de dirección | 0 | Respuesta de máscara de dirección | |
19 | reservado | Reservado por seguridad | |
20 al 29 | reservado | Reservado para el experimento de robustez | |
30 - Traceroute | 0 | Solicitud de información | |
31 | Error de conversión del datagrama | ||
32 | Redirección de host móvil | ||
33 | Dónde estás (originalmente destinado a IPv6 ) | ||
34 | Here-I-Am (originalmente destinado a IPv6) | ||
35 | Solicitud de registro móvil | ||
36 | Respuesta de registro móvil | ||
37 | Solicitud de nombre de dominio | ||
38 | Respuesta de nombre de dominio | ||
39 | SKIP Algorithm Discovery Protocol, administración de claves simple para el protocolo de Internet | ||
40 | Photuris , fallos de seguridad | ||
41 | Experimental | ICMP para protocolos de movilidad experimentales como Seamoby [RFC4065] | |
42 - Solicitud de eco extendida [9] | 0 | Solicitar eco extendido (XPing; consulte Ping extendido (Xping) ) | |
43 - Respuesta de eco extendida [9] | 0 | No hay error | |
1 | Consulta con formato incorrecto | ||
2 | No hay tal interfaz | ||
3 | No hay tal entrada de tabla | ||
4 | Múltiples interfaces satisfacen la consulta | ||
44 hasta 252 | no asignado | Reservado | |
253 | Experimental | Experimento 1 al estilo RFC3692 (RFC 4727) | |
254 | Experimental | Experimento 2 al estilo RFC3692 (RFC 4727) | |
255 | reservado | Reservado |
Source Quench solicita que el remitente reduzca la tasa de mensajes enviados a un enrutador o host. Este mensaje puede generarse si un enrutador o host no tiene suficiente espacio de búfer para procesar la solicitud, o puede ocurrir si el enrutador o el búfer del host se están acercando a su límite.
Los datos se envían a una velocidad muy alta desde un host o desde varios hosts al mismo tiempo a un enrutador particular en una red. Aunque un enrutador tiene capacidades de almacenamiento en búfer, el almacenamiento en búfer está limitado a un rango específico. El enrutador no puede poner en cola más datos que la capacidad del espacio de almacenamiento en búfer limitado. Por lo tanto, si la cola se llena, los datos entrantes se descartan hasta que la cola ya no esté llena. Pero como no existe ningún mecanismo de reconocimiento en la capa de red, el cliente no sabe si los datos han llegado al destino correctamente. Por lo tanto, la capa de red debe tomar algunas medidas correctivas para evitar este tipo de situaciones. Estas medidas se conocen como extinción de la fuente. En un mecanismo de extinción de la fuente, el enrutador ve que la velocidad de datos entrantes es mucho más rápida que la velocidad de datos salientes,y envía un mensaje ICMP a los clientes, informándoles que deben reducir la velocidad de transferencia de datos o esperar una cierta cantidad de tiempo antes de intentar enviar más datos. Cuando un cliente recibe este mensaje, automáticamente ralentizará la velocidad de datos salientes o esperará una cantidad de tiempo suficiente, lo que permite al enrutador vaciar la cola. Por tanto, el mensaje ICMP de extinción de origen actúa como control de flujo en la capa de red.
Dado que la investigación sugirió que "ICMP Source Quench [era] un antídoto ineficaz (e injusto) para la congestión", [10] la creación de mensajes de desactivación de fuente de los enrutadores fue desaprobada en 1995 por RFC 1812. Además, el reenvío y cualquier tipo de reacción a (acciones de control de flujo) los mensajes de extinción de origen fueron obsoletos desde 2012 por RFC 6633.
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo = 4 | Código = 0 | Suma de comprobación | |||||||||||||||||||||||||||||
no usado | |||||||||||||||||||||||||||||||
Encabezado de IP y primeros 8 bytes de los datos del datagrama original |
Dónde:
Redirigir solicita que los paquetes de datos se envíen por una ruta alternativa. ICMP Redirect es un mecanismo para que los enrutadores transmitan información de enrutamiento a los hosts. El mensaje le informa a un anfitrión que actualice su información de enrutamiento (para enviar paquetes en una ruta alternativa). Si un host intenta enviar datos a través de un enrutador (R1) y R1 envía los datos a otro enrutador (R2) y hay disponible una ruta directa desde el host a R2 (es decir, el host y R2 están en el mismo segmento de Ethernet) , luego R1 enviará un mensaje de redireccionamiento para informar al host que la mejor ruta para el destino es a través de R2. Luego, el host debe cambiar la información de su ruta y enviar paquetes para el destino directamente a R2. El enrutador seguirá enviando el datagrama original al destino previsto. [11]Sin embargo, si el datagrama contiene información de enrutamiento, este mensaje no se enviará incluso si hay una mejor ruta disponible. RFC 1122 establece que los redireccionamientos solo deben ser enviados por puertas de enlace y no deben ser enviados por hosts de Internet.
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo = 5 | Código | Suma de comprobación | |||||||||||||||||||||||||||||
dirección IP | |||||||||||||||||||||||||||||||
Encabezado de IP y primeros 8 bytes de los datos del datagrama original |
Dónde:
Código | Descripción |
---|---|
0 | Redirigir a la red |
1 | Redirigir para host |
2 | Redirigir por tipo de servicio y red |
3 | Redirigir por tipo de servicio y host |
El tiempo excedido es generado por una puerta de enlace para informar a la fuente de un datagrama descartado debido a que el tiempo de vida del campo llegó a cero. Un host también puede enviar un mensaje de tiempo excedido si no puede volver a ensamblar un datagrama fragmentado dentro de su límite de tiempo.
La utilidad traceroute utiliza los mensajes de tiempo excedido para identificar puertas de enlace en la ruta entre dos hosts.
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo = 11 | Código | Suma de comprobación | |||||||||||||||||||||||||||||
no usado | |||||||||||||||||||||||||||||||
Encabezado de IP y primeros 8 bytes de los datos del datagrama original |
Dónde:
Código | Descripción |
---|---|
0 | Se superó el tiempo de vida en tránsito. |
1 | Se excedió el tiempo de reensamblaje del fragmento. |
La marca de tiempo se utiliza para la sincronización horaria. La marca de tiempo de origen se establece en la hora (en milisegundos desde la medianoche) en que el remitente tocó el paquete por última vez. Las marcas de tiempo de recepción y transmisión no se utilizan.
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo = 13 | Código = 0 | Suma de comprobación | |||||||||||||||||||||||||||||
Identificador | Secuencia de números | ||||||||||||||||||||||||||||||
Originar marca de tiempo | |||||||||||||||||||||||||||||||
Recibir marca de tiempo | |||||||||||||||||||||||||||||||
Transmitir marca de tiempo |
Dónde:
La respuesta de marca de tiempo responde a un mensaje de marca de tiempo . Consiste en la marca de tiempo de origen enviada por el remitente de la marca de tiempo , así como una marca de tiempo de recepción que indica cuándo se recibió la marca de tiempo y una marca de tiempo de transmisión que indica cuándo se envió la respuesta de marca de tiempo .
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo = 14 | Código = 0 | Suma de comprobación | |||||||||||||||||||||||||||||
Identificador | Secuencia de números | ||||||||||||||||||||||||||||||
Originar marca de tiempo | |||||||||||||||||||||||||||||||
Recibir marca de tiempo | |||||||||||||||||||||||||||||||
Transmitir marca de tiempo |
Dónde:
El uso de mensajes de marca de tiempo y de 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 . [12]
La solicitud de máscara de dirección normalmente la envía un host a un enrutador para obtener una máscara de subred adecuada .
Los destinatarios deben responder a este mensaje con un mensaje de respuesta de máscara de dirección .
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo = 17 | Código = 0 | Suma de comprobación | |||||||||||||||||||||||||||||
Identificador | Secuencia de números | ||||||||||||||||||||||||||||||
Máscara de dirección |
Dónde:
La solicitud de máscara de dirección ICMP se puede utilizar como parte de un ataque de reconocimiento para recopilar información en la red de destino; por lo tanto, la respuesta de máscara de dirección ICMP está deshabilitada de forma predeterminada en Cisco IOS. [13]
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.
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo = 18 | Código = 0 | Suma de comprobación | |||||||||||||||||||||||||||||
Identificador | Secuencia de números | ||||||||||||||||||||||||||||||
Máscara de dirección |
Dónde:
Destino inalcanzable es generado por el host o su puerta de enlace de entrada [6] para informar al cliente que el destino es inalcanzable por alguna razón. Las razones de 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 estar fragmentados pero la marca de 'no fragmentar' está activada. Los puertos TCP inalcanzables responden notablemente con TCP RST en lugar de un destino inalcanzable tipo 3 como podría esperarse. El destino inalcanzable nunca se informa para las transmisiones de multidifusión IP .
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | dieciséis | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo = 3 | Código | Suma de comprobación | |||||||||||||||||||||||||||||
no usado | MTU de siguiente salto | ||||||||||||||||||||||||||||||
Encabezado de IP y primeros 8 bytes de los datos del datagrama original |
Dónde:
Código | Descripción |
---|---|
0 | Error de red inalcanzable. |
1 | Error de host inalcanzable. |
2 | Error de protocolo inalcanzable (el protocolo de transporte designado no es compatible). |
3 | Error de puerto inalcanzable (el protocolo designado no puede informar al host del mensaje entrante). |
4 | El datagrama es demasiado grande. Se requiere la fragmentación de paquetes, pero el indicador "no fragmentar" (DF) está activado. |
5 | Error de ruta de origen. |
6 | Error desconocido de la red de destino. |
7 | Error de host de destino desconocido. |
8 | Error aislado del host de origen. |
9 | La red de destino está prohibida administrativamente. |
10 | El host de destino está prohibido administrativamente. |
11 | No se puede acceder a la red para el tipo de servicio. |
12 | El host no está disponible para el tipo de servicio. |
13 | Comunicación prohibida administrativamente (el filtrado administrativo evita que el paquete se reenvíe). |
14 | Violación de la precedencia del host (indica que la precedencia solicitada no está permitida para la combinación de host o red y puerto). |
15 | Corte de precedencia en efecto (la precedencia del datagrama está por debajo del nivel establecido por los administradores de red). |
Es una evolución del Protocolo de tiempo y el mensaje de marca de tiempo ICMP y es un reemplazo adecuado para ambos.
Wikiversity tiene recursos de aprendizaje sobre el Protocolo de mensajes de control de Internet |