Protocolo de mensajes de control de Internet (ICMP)
El Protocolo de mensajes de control de Internet o ICMP (Internet Control Message Protocol) es un protocolo de soporte en el conjunto de protocolos de Internet. Los dispositivos de red, incluidos los enrutadores, lo utilizan para enviar mensajes de error e información operativa que indica 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 un host o enrutador no pudo ser alcanzado. ICMP se diferencia de los protocolos de transporte como TCP y UDP en que normalmente no se usa para intercambiar datos entre sistemas, ni las aplicaciones de red del usuario final lo emplean regularmente (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 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.
Por ejemplo, cada dispositivo (como un enrutador intermedio) que reenvía un datagrama IP primero disminuye el campo de tiempo de vida (TTL) en el encabezado IP en uno. Si el TTL resultante es 0, el paquete se descarta y se envía un mensaje ICMP de tiempo excedido en tránsito 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 mediante la transmisión de 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 utilizando 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 enviar el mensaje de error correspondiente 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 un 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.
Estructura del datagrama
El paquete ICMP está encapsulado en un paquete IPv4. El paquete consta de secciones de encabezado y datos.
Encabezamiento
El encabezado ICMP comienza después del encabezado IPv4 y se identifica con el número de protocolo IP '1'. 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.
| Compensaciones | Octeto | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octeto | Un 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 verificación | |||||||||||||||||||||||||||||
| 4 | 32 | Resto de encabezado |
EscribeTipo ICMP, ver § Mensajes de control.CódigoSubtipo ICMP, ver § Mensajes de control.Suma de verificaciónSuma de comprobación de Internet (RFC 1071) para la comprobación de errores, calculada a partir del encabezado ICMP y los datos con valor 0 sustituidos por este campo.Resto de cabeceraCampo 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 completo de IPv4, 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. 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.
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 para la 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 de tipo. El campo de código brinda información de contexto adicional para el mensaje. Algunos mensajes de control han quedado obsoletos desde que se introdujo el protocolo por primera vez.
| Escribe | Código | Estado | Descripción |
|---|---|---|---|
| 0 – Respuesta de eco | 0 | Respuesta de eco (usada para hacer ping) | |
| 1 y 2 | no asignado | Reservado | |
| 3 – Destino inalcanzable | 0 | Red de destino inaccesible | |
| 1 | Host de destino inalcanzable | ||
| 2 | Protocolo de destino inalcanzable | ||
| 3 | Puerto de destino inalcanzable | ||
| 4 | Fragmentación requerida y bandera DF establecida | ||
| 5 | La ruta de origen falló | ||
| 6 | Red de destino desconocida | ||
| 7 | Host de destino desconocido | ||
| 8 | Host de origen aislado | ||
| 9 | Red administrativamente prohibida | ||
| 10 | Host administrativamente prohibido | ||
| 11 | Red inalcanzable para ToS | ||
| 12 | Host inalcanzable para ToS | ||
| 13 | Comunicación administrativamente prohibida | ||
| 14 | Violación de precedencia de host | ||
| 15 | Corte de precedencia en efecto | ||
| 4 – Apagado de la fuente | 0 | Apagar la fuente (control de congestión) | |
| 5 – Mensaje de redirección | 0 | Redirigir datagrama para la red | |
| 1 | Redirigir datagrama para el host | ||
| 2 | Datagrama de redirección para los ToS y la red | ||
| 3 | Redireccionar datagrama para ToS y host | ||
| 6 | Dirección de host alternativa | ||
| 7 | no asignado | Reservado | |
| 8 – Solicitud de eco | 0 | Solicitud de eco (usada para hacer ping) | |
| 9 – Anuncio de enrutador | 0 | Anuncio de enrutador | |
| 10 – Solicitud de enrutador | 0 | Descubrimiento/selección/solicitud de enrutadores | |
| 11 – Tiempo excedido | 0 | TTL vencido en tránsito | |
| 1 | Se excedió el tiempo de reensamblaje del fragmento | ||
| 12 – Problema de parámetros: encabezado de IP incorrecto | 0 | El puntero indica el error | |
| 1 | Falta una opción obligatoria | ||
| 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 – Información Respuesta | 0 | Información Responder | |
| 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 a 29 | reservado | Reservado para el experimento de robustez | |
| 30 – Trazado de ruta | 0 | Solicitud de información | |
| 31 | Error de conversión de datagrama | ||
| 32 | Redirección de host móvil | ||
| 33 | Where-Are-You (originalmente pensado para IPv6) | ||
| 34 | Here-I-Am (originalmente pensado para 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 | Protocolo de descubrimiento de algoritmo SKIP, administración de claves simple para el protocolo de Internet | ||
| 40 | Photuris, fallos de seguridad | ||
| 41 | Experimental | ICMP para protocolos de movilidad experimental como Seamoby [RFC4065] | |
| 42 – Solicitud de eco extendida | 0 | Solicitar eco extendido (XPing - ver Ping extendido (Xping)) | |
| 43 – Respuesta de eco extendida | 0 | No hay error | |
| 1 | Consulta con formato incorrecto | ||
| 2 | No hay tal interfaz | ||
| 3 | No hay tal entrada de tabla | ||
| 4 | Consulta de satisfacción de múltiples interfaces | ||
| 44 a 252 | no asignado | Reservado | |
| 253 | Experimental | Experimento 1 estilo RFC3692 (RFC 4727) | |
| 254 | Experimental | Experimento 2 al estilo RFC3692 (RFC 4727) | |
| 255 | reservado | Reservado |
Fuente para enfriar
Source Quench solicita que el remitente disminuya la tasa de mensajes enviados a un enrutador o host. Este mensaje se puede generar si un enrutador o host no tiene suficiente espacio de búfer para procesar la solicitud, o puede aparecer si el enrutador o el búfer de host se acercan 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 dentro de un rango específico. El enrutador no puede poner en cola más datos que la capacidad del espacio de almacenamiento intermedio 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 un mecanismo de reconocimiento en la capa de red, el cliente no sabe si los datos han llegado al destino con éxito. Por lo tanto, la capa de red debe tomar algunas medidas correctivas para evitar este tipo de situaciones. Estas medidas se denominan extinción de la fuente. En un mecanismo de apagado de fuente, el enrutador ve que la tasa de datos entrantes es mucho más rápida que la tasa 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, reducirá automáticamente la velocidad de los datos salientes o esperará una cantidad de tiempo suficiente, lo que permite que el enrutador vacíe la cola. Por lo 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", la creación de mensajes de extinción de fuente por parte de los enrutadores quedó obsoleta en 1995 por RFC 1812. Además, el reenvío y cualquier tipo de reacción a (control de flujo acciones) los mensajes de extinción de origen quedaron obsoletos a partir de 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 verificación | |||||||||||||||||||||||||||||
| no usado | |||||||||||||||||||||||||||||||
| Encabezado IP y primeros 8 bytes de datos del datagrama original |
Dónde:El tipo debe establecerse en 4El código debe establecerse en 0El encabezado de IP y los datos adicionales son utilizados por el remitente para hacer coincidir la respuesta con la solicitud asociada
Redirigir
El redireccionamiento 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 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 del host a R2 (es decir, el host y R2 están en la misma subred), luego, R1 enviará un mensaje de redirección 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 a R2. El enrutador seguirá enviando el datagrama original al destino previsto.Sin embargo, si el datagrama contiene información de enrutamiento, este mensaje no se enviará incluso si hay disponible una ruta mejor. 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 verificación | |||||||||||||||||||||||||||||
| dirección IP | |||||||||||||||||||||||||||||||
| Encabezado IP y primeros 8 bytes de datos del datagrama original |
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:
| Código | Descripción |
|---|---|
| 0 | Redirigir para la red |
| 1 | Redirigir para host |
| 2 | Redirección por tipo de servicio y red |
| 3 | Redirección por tipo de servicio y host |
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 incluyen 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 es generado por 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 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 las 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 verificación | |||||||||||||||||||||||||||||
| no usado | |||||||||||||||||||||||||||||||
| Encabezado IP y primeros 8 bytes de datos del datagrama original |
Dónde:El tipo debe establecerse en 11El código especifica el motivo del mensaje de tiempo excedido, incluye lo siguiente:
| Código | Descripción |
|---|---|
| 0 | Tiempo de vida excedido en tránsito. |
| 1 | Se excedió el tiempo de reensamblaje del fragmento. |
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 tiempo. 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 verificación | |||||||||||||||||||||||||||||
| identificador | Secuencia de números | ||||||||||||||||||||||||||||||
| Marca de tiempo de origen | |||||||||||||||||||||||||||||||
| Recibir marca de tiempo | |||||||||||||||||||||||||||||||
| Marca de tiempo de transmisión |
Dónde:El tipo debe establecerse en 13El código debe establecerse en 0El 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
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 la 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 verificación | |||||||||||||||||||||||||||||
| identificador | Secuencia de números | ||||||||||||||||||||||||||||||
| Marca de tiempo de origen | |||||||||||||||||||||||||||||||
| Recibir marca de tiempo | |||||||||||||||||||||||||||||||
| Marca de tiempo de transmisión |
Dónde:El tipo debe establecerse en 14El código debe establecerse en 0El 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 última vez que el remitente tocó el mensaje antes de enviarlo.La marca de tiempo de recepción es la hora en que el ecor lo tocó por primera vez al recibirlo.La marca de tiempo de transmisión es la hora en que el ecor tocó el mensaje por última vez 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, 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.
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 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 verificación | |||||||||||||||||||||||||||||
| identificador | Secuencia de números | ||||||||||||||||||||||||||||||
| Máscara de dirección |
Dónde:El tipo debe establecerse en 17El código debe establecerse en 0La 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 sobre la red de destino, por lo tanto, la respuesta de máscara de dirección ICMP está deshabilitada de manera predeterminada en Cisco IOS.
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.
| 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 verificación | |||||||||||||||||||||||||||||
| identificador | Secuencia de números | ||||||||||||||||||||||||||||||
| Máscara de dirección |
Dónde:El tipo debe establecerse en 18El código debe establecerse en 0La máscara de dirección debe establecerse en la máscara de subred
Destino inalcanzable
El destino inalcanzable es generado por el host o su puerta de enlace de entrada para informar al cliente que el destino es inalcanzable por algún motivo. Las razones de este mensaje pueden incluir: la conexión física al 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 de tipo 3, como cabría esperar. 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 verificación | |||||||||||||||||||||||||||||
| no usado | MTU de siguiente salto | ||||||||||||||||||||||||||||||
| Encabezado IP y primeros 8 bytes de datos del datagrama original |
Dónde:El campo de tipo (bits 0-7) debe establecerse en 3El campo de código (bits 8-15) se utiliza para especificar el tipo de error y puede ser cualquiera de los siguientes:
| Código | Descripción |
|---|---|
| 0 | Error de red inalcanzable. |
| 1 | Error de host inalcanzable. |
| 2 | Error de protocolo inalcanzable (no se admite el protocolo de transporte designado). |
| 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 fallida. |
| 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á administrativamente prohibida. |
| 10 | El host de destino está prohibido administrativamente. |
| 11 | La red es inalcanzable para el tipo de servicio. |
| 12 | El host es inalcanzable para el tipo de servicio. |
| 13 | Comunicación prohibida administrativamente (el filtrado administrativo impide el reenvío de paquetes). |
| 14 | Infracción de precedencia de host (indica que la precedencia solicitada no está permitida para la combinación de host o red y puerto). |
| 15 | Corte de precedencia vigente (la precedencia del datagrama está por debajo del nivel establecido por los administradores de red). |
El campo MTU del siguiente salto (bits 48-63) contiene la MTU de la red del siguiente salto si se produce un error de código 4.Se incluyen encabezado IP y datos adicionales para permitir que el cliente haga coincidir la respuesta con la solicitud que provocó la respuesta de destino inalcanzable.
Contenido relacionado
Protocolo de control de puerta de enlace de medios (MGCP)
Protocolo de reserva de recursos (RSVP)
Intercambio de archivos