Hispanopedia WikiEl Protocolo de mensajes de control de Internet ( ICMP ) es un protocolo de apoyo [2] 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 el éxito o el fracaso al comunicarse con otra dirección IP . Por ejemplo, se indica un error cuando un servicio solicitado no está disponible o que no se pudo acceder a un host o enrutador. [3] ICMP se diferencia de los protocolos de transporte como TCP y UDP en que no se utiliza normalmente para intercambiar datos entre sistemas, ni lo emplean regularmente las aplicaciones de red de usuario final (con la excepción de algunas herramientas de diagnóstico como ping y traceroute ).
Con IPv6 se utiliza un protocolo de mensajes de control de Internet independiente (llamado ICMPv6 ) . [4]
Detalles técnicos
El protocolo ICMP forma parte del conjunto de protocolos de Internet, tal como se define en el 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 IP (tal como se especifica en el RFC 1122). Los errores ICMP se dirigen a la dirección IP de origen del paquete de origen. [3]
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 ICMP de tiempo excedido a la dirección de origen del datagrama.
Muchas utilidades de red de uso común se basan en mensajes ICMP. El comando traceroute se puede implementar transmitiendo datagramas IP con campos de encabezado TTL IP especialmente configurados y buscando mensajes ICMP de tiempo excedido en tránsito y destino inalcanzable generados en respuesta. La utilidad ping relacionada se implementa utilizando los mensajes de solicitud de eco ICMP y 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 dentro de paquetes IP estándar, los mensajes ICMP generalmente se procesan como un caso especial, distinto 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 provocó el envío del mensaje ICMP.
ICMP es un protocolo de capa de red , lo que lo convierte en un protocolo de capa 3 en el modelo OSI de siete capas . Basado en el modelo TCP/IP de cuatro capas, ICMP es un protocolo de capa de Internet , lo que lo convierte en un protocolo de capa 2 en el modelo de cuatro capas TCP/IP del estándar de Internet RFC 1122 o un protocolo de capa 3 en las definiciones de protocolo TCP/IP de cinco capas modernas (por Kozierok, Comer, Tanenbaum, Forouzan, Kurose, Stallings). [ cita requerida ]
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 superior. [5]
Estructura del datagrama
El paquete ICMP está encapsulado en un paquete IPv4. [3] El paquete consta de secciones de encabezado y datos.
Encabezamiento
El encabezado ICMP comienza después del encabezado IPv4 y se identifica por su número de protocolo , 1. [6] Todos los paquetes ICMP tienen un encabezado de ocho bytes y una sección de datos de tamaño variable . Los primeros cuatro bytes del encabezado tienen un formato fijo, mientras que los últimos cuatro bytes dependen del tipo y el código del paquete ICMP. [3]
- Tipo: 8 bits
- Tipo ICMP, ver § Mensajes de control.
- Código: 8 bits
- Subtipo ICMP, consulte § Mensajes de control.
- Suma de comprobación: 16 bits
- Suma de comprobación de Internet [7] para la comprobación de errores, calculada a partir del encabezado ICMP y los datos con el valor 0 sustituido por este campo.
- Resto del encabezado: 32 bits
- Campo de cuatro bytes, el contenido varía según el tipo y el código ICMP.
Datos
Los mensajes de error ICMP contienen una sección de datos que incluye una copia del encabezado IPv4 completo, además de al menos los primeros ocho bytes de datos del paquete IPv4 que causó el mensaje de error. La longitud de los mensajes de error ICMP no debe superar los 576 bytes. [1] El host utiliza estos datos para hacer coincidir el mensaje con el proceso adecuado. Si un protocolo de nivel superior utiliza números de puerto, se supone que 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 de los paquetes ICMP . En el " ping de la muerte ", se utilizan paquetes ICMP grandes o fragmentados para realizar 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 .
Mensajes de control
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 de control han quedado obsoletos desde que se introdujo el protocolo por primera vez.
Enfriamiento de la fuente
Source Quench solicita que el remitente reduzca la velocidad de los mensajes enviados a un enrutador o host. Este mensaje puede generarse si un enrutador o host no tiene suficiente espacio en el búfer para procesar la solicitud, o puede ocurrir si el búfer del enrutador o host se está 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 en 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 hay ningún mecanismo de reconocimiento presente 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 origen.
En un mecanismo de extinción de origen, el enrutador detecta que la velocidad de los datos entrantes es mucho más rápida que la velocidad de los datos salientes y envía un mensaje ICMP a los clientes, informándoles de 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 reduce la velocidad de los datos salientes o espera una cantidad de tiempo suficiente, lo que permite al enrutador vaciar la cola. De este modo, el mensaje ICMP de extinción de origen actúa como 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", [11] la creación de mensajes de source quench por parte de los enrutadores quedó obsoleta en 1995 por la RFC 1812. Además, el reenvío y cualquier tipo de reacción a los mensajes de source quench (acciones de control de flujo) quedó obsoleto a partir de 2012 por la 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.
Redirigir
Las solicitudes de redireccionamiento solicitan que los paquetes de datos se envíen por una ruta alternativa. El redireccionamiento ICMP es un mecanismo para que los enrutadores transmitan 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 otro enrutador (R2) y hay disponible 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 redireccionamiento para informar al host que la mejor ruta para el destino es a través de R2. El host debe cambiar su información de ruta y enviar paquetes para ese destino directamente a R2. El enrutador seguirá enviando el datagrama original al destino previsto. [16] Sin embargo, si el datagrama contiene información de enrutamiento, este mensaje no se enviará incluso si hay una ruta mejor disponible. RFC 1122 establece que las redirecciones solo deben enviarse por puertas de enlace y no deben enviarse por hosts de Internet.
Dónde:
- El tipo debe establecerse 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 encabezado IP y datos adicionales para permitir que el host haga coincidir la respuesta con la solicitud que provocó la respuesta de redirección.
Tiempo excedido
Un gateway genera un mensaje de tiempo excedido para informar a la fuente de un datagrama descartado debido a que el campo de tiempo de vida llegó a cero. Un host también puede enviar un mensaje de tiempo excedido si no logra reensamblar un datagrama fragmentado dentro de su límite de tiempo.
La utilidad traceroute utiliza mensajes de tiempo excedido para identificar puertas de enlace en la ruta entre dos hosts.
Dónde:
- El tipo debe establecerse en 11
- El código especifica el motivo del mensaje de tiempo excedido e incluye lo siguiente:
- El host de origen utiliza el encabezado IP y los primeros 64 bits de la carga útil original para hacer coincidir el mensaje de tiempo excedido con el datagrama descartado. En el caso de protocolos de nivel superior, como UDP y TCP, la carga útil de 64 bits incluirá los puertos de origen y destino del paquete descartado.
Marca de tiempo
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.
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 de marca de tiempo con la solicitud de marca de tiempo.
- La marca de tiempo de origen es la cantidad de milisegundos transcurridos desde la medianoche en la hora universal (UT). Si no hay una referencia UT disponible, se puede configurar el bit más significativo para indicar un valor de hora no estándar.
Respuesta con marca de tiempo
La respuesta de marca de tiempo responde a un mensaje de marca de tiempo . Consta de 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 .
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 hacer coincidir la respuesta con la solicitud que provocó la respuesta.
- La marca de tiempo de origen es el momento en que el remitente tocó el mensaje por última vez antes de enviarlo.
- La marca de tiempo de recepción es el momento en que el ecodor lo tocó por primera vez al recibirlo.
- La marca de tiempo de transmisión es el momento en que el ecodor tocó el mensaje por última vez al enviarlo.
- Todas las marcas de tiempo se expresan en unidades de 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 una marca de tiempo siempre que el bit de orden superior de la marca de tiempo también esté configurado para indicar este valor no estándar.
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 . [17]
Solicitud de máscara de dirección
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 .
Dónde:
- El tipo debe establecerse en 17
- El código debe establecerse en 0
- La máscara de dirección se puede configurar en 0
La solicitud de máscara de dirección ICMP se puede utilizar 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. [18]
Máscara de dirección de respuesta
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 dirección debe configurarse en la máscara de subred.
Destino inalcanzable
El host o su puerta de enlace de entrada [2] genera un mensaje de destino inalcanzable para informar al cliente de que el destino es inalcanzable por algún motivo. 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 bandera "no fragmentar" está activada. [19] Los puertos TCP inalcanzables responden notablemente con TCP RST en lugar de un destino inalcanzable de tipo 3 como podría esperarse. El destino inalcanzable nunca se informa para transmisiones de multidifusión IP .
Con el siguiente contenido de campo:
- Tipo: 8 bits; Tipo == 3
- Un valor de 3 indica 'Destino inalcanzable'.
- 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
- No se utiliza, debe establecerse en cero. Si no se utilizan la longitud ni 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 que este mensaje ICMP se amplíe 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 IP y datos: 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 reensamblado de IPv4). Si se extiende este mensaje, este campo debe contener al menos 128 bytes de datos del datagrama original (rellenados con ceros si es necesario).
Estos datos se incluyen para permitir que el cliente haga coincidir la respuesta con la solicitud que provocó la respuesta de Destino inalcanzable .
Extensiones
Los mensajes ICMP pueden ampliarse con información adicional. Esta información se transporta en uno o más objetos de extensión, que están precedidos por un encabezado de extensión ICMP. [20]
- Versión: 4 bits; Versión == 2
- Versión del encabezado de extensión.
- Reservado: 12 bits; Reservado == 0
- Reservado.
- Suma de comprobación: 16 bits
- Suma de comprobación de este encabezado y de todos los objetos de extensión. Este campo está incluido, por lo que se establece en cero al realizar el cálculo.
Los objetos de extensión tienen la siguiente estructura general:
- Longitud: 16 bits
- La longitud del objeto en octetos, incluido el encabezado.
- Clase-Num: 8 bits
- Identifica la clase del objeto.
- Tipo C: 8 bits
- Identifica el subtipo del objeto.
- Carga útil del objeto: variable
- Carga útil opcional. Si no está vacía, contiene una estructura de datos cuyo tamaño es múltiplo de 32 bits.
Véase también
Referencias
- ^ ab F. Baker , ed. (junio de 1995). Requisitos para enrutadores IP versión 4. Grupo de trabajo de redes. doi : 10.17487/RFC1812 . RFC 1812. Norma propuesta. Deja obsoletas las RFC 1716 y 1009. Actualizada por las RFC 2644 y 6633.
- ^ abcdefghijkl J. Postel (septiembre de 1981). PROTOCOLO DE MENSAJE DE CONTROL DE INTERNET - ESPECIFICACIÓN DEL PROTOCOLO DE PROGRAMA DE INTERNET DE DARPA. Grupo de trabajo de redes. doi : 10.17487/RFC0792 . STD 5. RFC 792. Estándar de Internet 5. Actualizaciones RFC 760, 777, IENs 109, 128. Actualizado por RFC 950, 4884, 6633 y 6918.
- ^ abcd Forouzan, Behrouz A. (2007). Comunicaciones de datos y redes (cuarta edición). Boston: McGraw-Hill. págs. 621–630. ISBN 978-0-07-296775-3.
- ^ 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.
- ^ "Las siete capas del modelo OSI definidas y sus funciones explicadas". Soporte técnico de Microsoft . Consultado el 28 de diciembre de 2014 .
- ^ "Números de protocolo". Autoridad de Números Asignados de Internet . Consultado el 23 de junio de 2011 .
- ^ 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.
- ^ ab "IANA ICMP Parameters". Iana.org. 2012-09-21 . Consultado el 2013-01-07 .
- ^ Kurose, JF; Ross, KW (2006). Redes informáticas: un enfoque descendente. Serie de estudiantes del mundo. Addison-Wesley. ISBN 9780321418494.
- ^ "Parámetros del Protocolo de mensajes de control de Internet (ICMP)". www.iana.org . Consultado el 13 de septiembre de 2023 .
- ^ ab F. Gont (mayo de 2012). Desuso de los mensajes ICMP Source Quench. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6633 . ISSN 2070-1721. RFC 6633. Norma propuesta. Actualizaciones RFC 792, 1122 y 1812.
- ^ abcdefghijklmno F. Gont; C. Pignataro (abril de 2013). Desaprobación formal de algunos tipos de mensajes ICMPv4. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6918 . ISSN 2070-1721. RFC 6918. Norma propuesta. Deja obsoleta la RFC 1788. Actualiza las RFC 792 y 950.
- ^ J. Kempf (julio de 2005). Instrucciones para las asignaciones de la IANA del Protocolo de movilidad experimental y Seamoby. doi : 10.17487/RFC4065 . RFC 4065. Experimental.
- ^ 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.
- ^ ab B. Fenner (noviembre de 2006). Valores experimentales en encabezados IPv4, IPv6, ICMPv4, ICMPv6, UDP y TCP. Grupo de trabajo de redes. doi : 10.17487/RFC4727 . RFC 4727. Norma propuesta.
- ^ "¿Cuándo se envían las redirecciones ICMP?". Cisco Systems . 28 de junio de 2008. Consultado el 15 de agosto de 2013 .
- ^ DL Mills (septiembre de 1985). Protocolo de tiempo de red (NTP). doi : 10.17487/RFC0958 . RFC 958.
Es una evolución del Protocolo de tiempo y del mensaje de marca de tiempo ICMP y es un reemplazo adecuado para ambos.
- ^ "Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and Services, Release 12.3 - IP Addressing and Services Commands: ip mask-reply through ip web-cache". Cisco Systems . Archivado desde el original el 2013-01-02 . Consultado el 2013-01-07 .
- ^ J. Mogul; S. Deering (noviembre de 1990). Path MTU Discovery. Grupo de trabajo de redes. doi : 10.17487/RFC1191 . RFC 1191. Proyecto de Norma. Obsoleto RFC 1063.
- ^ ab R. Bonica; D. Gan; D. Tappan; C. Pignataro (abril de 2007). ICMP extendido para soportar mensajes de varias partes. Grupo de trabajo de redes. doi : 10.17487/RFC4884 . RFC 4884. Norma propuesta. Actualizaciones RFC 792 y 4443. Actualizada por RFC 8335.
Enlaces externos
- Parámetros ICMP de la IANA
- Números de protocolo de la IANA
- Explicación del comportamiento de redireccionamiento ICMP en Wayback Machine (archivado el 10 de enero de 2015)