stringtranslate.com

Protocolo de mensajes de control de Internet

El Protocolo de mensajes de control de Internet ( ICMP ) es un protocolo de soporte en el conjunto de protocolos de Internet . Lo utilizan dispositivos de red , incluidos 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 cuando no se pudo acceder a un host o enrutador. [2] ICMP se diferencia de los protocolos de transporte como TCP y UDP en que normalmente no se utiliza para intercambiar datos entre sistemas, ni tampoco lo emplean regularmente las aplicaciones de red del usuario final (con la excepción de algunas herramientas de diagnóstico como ping y traceroute ). .

ICMP para IPv4 se define en RFC  792. Con IPv6 se utiliza un ICMPv6 separado , definido por RFC 4443 .

Detalles técnicos

ICMP es parte del conjunto de protocolos de Internet tal como se define en RFC 792. Los mensajes ICMP generalmente se usan 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 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 disminuye 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 excedido ICMP a la dirección de origen del datagrama.

Muchas utilidades de red utilizadas habitualmente 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 inalcanzables 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, a diferencia 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 ; esto 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 el modelo moderno de cinco capas. Definiciones del protocolo TCP/IP (por Kozierok, Comer, Tanenbaum, Forouzan, Kurose, Stallings). [ cita necesaria ]

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. [3]

Estructura del datagrama

El paquete ICMP está encapsulado en un paquete IPv4. [2] 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 . [4] 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 código del paquete ICMP. [2]

Tipo
Tipo ICMP, consulte § Mensajes de control.
Código
Subtipo ICMP, consulte § Mensajes de control.
Suma de comprobación
Suma de verificación de Internet (RFC 1071) para verificación de errores, calculada a partir del encabezado ICMP y datos con valor 0 sustituidos por este campo.
Resto del encabezado
Campo de cuatro bytes, el contenido varía según el tipo y 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 provocó el mensaje de error. La longitud de los mensajes de error ICMP no debe exceder los 576 bytes. [5] El host utiliza estos datos para hacer coincidir el mensaje con el proceso apropiado. Si un protocolo de nivel superior utiliza números de puerto, se supone que están en los primeros ocho bytes de los datos del datagrama original. [6]

Se ha explotado el tamaño variable de la sección de datos del paquete ICMP . En el " Ping de la muerte ", 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 de comunicación. Estos canales se conocen como túneles ICMP .

Mensajes de control

Los mensajes de control se identifican por el valor en el campo 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.

Fuente para enfriar

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 en el búfer para procesar la solicitud, o puede ocurrir si el búfer del enrutador o del host se acerca a su límite.

Los datos se envían a muy alta velocidad 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 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 correctamente al destino. 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 origen, 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 datos. tiempo antes de intentar enviar más datos. Cuando un cliente recibe este mensaje, automáticamente reduce la velocidad de datos salientes o espera una cantidad de tiempo suficiente, lo que permite que el enrutador vacíe 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", [11] la creación de mensajes de extinción de origen por parte de los enrutadores quedó obsoleta 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 quedaron obsoletos desde 2012 por 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

Un ejemplo de cómo funciona un mensaje de redireccionamiento ICMPv4

La redirección 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 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 ), 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 su información de ruta y enviar paquetes para ese destino directamente al R2. El enrutador seguirá enviando el datagrama original al destino previsto. [12] Sin embargo, si el datagrama contiene información de ruta, este mensaje no se enviará incluso si hay una ruta mejor disponible. RFC 1122 establece que las redirecciones solo deben enviarse mediante puertas de enlace y no deben enviarse desde servidores 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 un 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

El tiempo excedido lo genera una puerta de enlace para informar a la fuente de un datagrama descartado debido a que el campo de tiempo de vida llega a cero. Un host también puede enviar un mensaje de tiempo excedido si no logra 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.

Dónde:

El tipo debe establecerse en 11
El código especifica el motivo del mensaje de tiempo excedido ; 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. 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.

Marca de tiempo

La marca de tiempo se utiliza para la sincronización de la hora. La marca de tiempo de origen se establece en la hora (en milisegundos desde la medianoche) en la que el remitente tocó el paquete por última vez. No se utilizan las marcas de tiempo de recepción y transmisión.

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 la marca de tiempo con la solicitud de marca de tiempo.
La marca de tiempo de origen es el número de milisegundos desde la medianoche, hora universal (UT). Si una referencia UT no está disponible, el bit más significativo se puede configurar para indicar un valor de tiempo no estándar.

Respuesta de marca de tiempo

Timestamp Reply 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 la 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 la hora en que el remitente tocó el mensaje por última vez antes de enviarlo.
La marca de tiempo de recepción es la hora en que el emisor de eco la tocó por primera vez al recibirla.
La marca de tiempo de transmisión es la hora en que el emisor tocó por última vez el mensaje al enviarlo.
Todas las marcas de tiempo están 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, entonces 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 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 . [13]

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 establecer 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 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. [14]

Respuesta de máscara de dirección

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 como la máscara de subred

Destino inalcanzable

El destino inalcanzable lo genera el host o su puerta de enlace de entrada [6] para informar al cliente que el destino es inalcanzable por algún motivo. Los motivos 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 el indicador "no fragmentar" está activado. 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 .

Dónde:

El campo de tipo (bits 0 a 7) debe establecerse en 3
El campo de código (bits 8 a 15) se utiliza para especificar el tipo de error y puede ser cualquiera de los siguientes:
El campo MTU del siguiente salto (bits 48 a 63) contiene la MTU de la red del siguiente salto si se produce un error de código 4. [15]
Se incluye un encabezado IP y datos adicionales para permitir que el cliente haga coincidir la respuesta con la solicitud que provocó que el destino fuera inalcanzable.

Ver también

Referencias

  1. ^ F. Baker (junio de 1995). Panadero, F (ed.). Requisitos para enrutadores IP versión 4 . pag. 52. RFC 1812 . 
  2. ^ abcd Forouzan, Behrouz A. (2007). Comunicaciones de datos y redes (Cuarta ed.). Boston: McGraw-Hill. págs. 621–630. ISBN 978-0-07-296775-3.
  3. ^ "Las siete capas del modelo OSI definidas y explicadas las funciones". Soporte de Microsoft . Consultado el 28 de diciembre de 2014 .
  4. ^ "Números de protocolo". Autoridad de asignación de números de Internet . Consultado el 23 de junio de 2011 .
  5. ^ Requisitos para enrutadores IP versión 4. doi : 10.17487/RFC1812 . RFC 1812.
  6. ^ abcdefghijk Postel, J. (septiembre de 1981). Protocolo de mensajes de control de Internet. IETF . doi : 10.17487/RFC0792 . RFC 792.
  7. ^ "Parámetros ICMP de IANA". Iana.org. 2012-09-21 . Consultado el 7 de enero de 2013 .
  8. ^ Kurose, JF; Ross, KW (2006). Redes de computadoras: un enfoque de arriba hacia abajo. Serie mundial de estudiantes. Addison-Wesley. ISBN 9780321418494.
  9. ^ "Parámetros del Protocolo de mensajes de control de Internet (ICMP)". www.iana.org . Consultado el 13 de septiembre de 2023 .
  10. ^ ab PROBE: una utilidad para sondear interfaces. doi : 10.17487/RFC8335 . RFC 8335.
  11. ^ RFC  6633
  12. ^ "¿Cuándo se envían las redirecciones ICMP?". Sistemas Cisco . 2008-06-28 . Consultado el 15 de agosto de 2013 .
  13. ^ 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.
  14. ^ "Referencia de comandos IP de Cisco IOS, volumen 1 de 4: direccionamiento y servicios, versión 12.3 - Comandos de servicios y direccionamiento IP: ip mask-reply a través de ip web-cache". Sistemas Cisco . Archivado desde el original el 2 de enero de 2013 . Consultado el 7 de enero de 2013 .
  15. ^ ICMP ampliado para admitir mensajes de varias partes. doi : 10.17487/RFC4884 . RFC 4884.

Fuentes

RFC

enlaces externos