6.1 Introducción
ICMP a menudo se considera una parte de la capa IP. Se comunica mensajes de error y otra información que necesita atención. los paquetes ICMP se envían generalmente la capa IP o protocolo de capa superior (TCP o UDP). Algunos paquetes ICMP el mensaje de error se devuelve al proceso de usuario.
los paquetes ICMP se transmiten dentro de datagramas IP como 6--1 en la figura.
Ver ICMP especificación formal de RFC 792 [Posterl1 9 8 1 b].
formato de paquete ICMP de la figura 6 - la Fig. 2. Los primeros 4 bytes de todos los paquetes son los mismos, pero el resto de los otros bytes son diferentes entre sí. Aquí vamos a introducir uno por uno los diversos formatos de mensaje.
campo Tipo puede tener 15 valores diferentes, para describir un tipo particular de paquete ICMP. Algunos también utilizar el campo de paquete ICMP valores son sustituidos a describir con más detalle diversas condiciones.
El campo de suma de comprobación cubre la totalidad de los paquetes ICMP. El algoritmo utiliza definiciones de la sección 3.2 en el mismo algoritmo de suma de comprobación de cabecera IP. Se requiere ICMP checksum.
En este capítulo, vamos a discutir los mensajes ICMP en general, y como parte de la descarga: solicitud de máscara de dirección y de la respuesta, la solicitud de marca de tiempo y la respuesta y el puerto inalcanzable. Detallaremos Capítulo 27 en respuesta a una solicitud ing procedimientos utilizados P y el mensaje de respuesta y el paquete ICMP Capítulo 9 procesamiento de enrutamiento IP.
6,2 ICMP tipo de paquete
Varios tipos de ICMP paquetes figura 6--3 mostrado, diferentes tipos determinados por el campo de tipo de mensaje y un campo de código.
La figura de las dos últimas columnas indican el mensaje ICMP es un mensaje de consulta o un mensaje de error. Debido a los mensajes de error ICMP a veces se requiere un tratamiento especial, por lo que es necesario distinguir entre ellos. Por ejemplo, cuando el mensaje de error ICMP en respuesta, nunca se va a generar otro mensaje de error ICMP (si no hay una regla de restricción, es posible que se produzca un error producido otro caso de errores, y luego generar un error y el error, por lo el ciclo continúa sin fin).
Al enviar un paquetes de error ICMP, paquete contiene siempre la cabecera IP y los primeros 8 bytes para generar el error ICMP del datagrama IP. Por lo tanto, el módulo recibe el mensaje que va a error ICMP (determinado de acuerdo con los datagramas IP encapsulado ICMP campo de cabecera de protocolo de 6-1 de la figura dentro de datagrama IP) con una particular procedimientos de protocolo y el usuario (que figura en el datagramas IP en los primeros ocho bytes de la cabecera del paquete TCP o UDP en el número de puerto TCP o UDP se determina) enlace. Sección 6.5 describe punto se ejemplificará.
Las siguientes situaciones no dará lugar a un mensaje de error ICMP:
- 1) mensaje de error ICMP (sin embargo, los mensajes de consulta ICMP pueden generar mensajes de error ICMP).
- 2) la dirección de destino es una dirección de difusión (véase la figura 3-9) o la dirección de multidifusión (dirección de clase D, véase la Figura 1--5) datagrama IP.
- 3) como un enlace de datos mensajes de capa de difusión.
- 4) la primera hoja no es fragmento IP (el fragmento descrito en la Sección 11.5).
- 5) una dirección de origen del paquete de datos no es un único host. Es decir, la dirección de origen no puede ser la dirección cero, una dirección de bucle de retorno, una dirección de difusión o una dirección de multidifusión.
Estas reglas permiten el pasado para evitar que los mensajes de error ICMP en respuesta a los paquetes de difusión causados por las tormentas de broadcast.
6.3 dirección de ICMP solicitud máscara y respuesta
ICMP solicitud de máscara de dirección para adquirir su propio sistema sin disco máscara de subred durante el proceso de arranque (Sección 3.5). El sistema transmite su paquete de solicitud de ICMP (RARP sistema de proceso sin disco obtiene una dirección IP que se utiliza en el proceso de arranque son similares). Otro sistema sin disco manera de obtener la máscara de subred es el protocolo BOOTP, vamos a introducir en el primer capítulo 6. solicitud de máscara de dirección y el formato de paquete de respuesta ICMP se muestra en la Figura 6--4.
identificador de mensaje ICMP y un campo de número de secuencia conjunto seleccionado arbitrariamente por el remitente, los valores son devueltos en la respuesta. Por lo tanto, el emisor puede solicitar una respuesta a ser igualada.
Podemos escribir un programa simple (llamado icmpaddrmask), envía un mensaje de petición de máscara de dirección ICMP, luego imprimir todas las respuestas. A medida que el mensaje de solicitud general se envía a la dirección de difusión, por lo que vamos a hacer lo mismo. Dirección de destino (... 1402521363) es la dirección de difusión de subred 1402521332 (ver Figura 3--12) ....
sun % icmpaddrmask 140.252.13.63
received mask = ffffffe0, from 140.252.13.来3自3 本 机
received mask = ffffffe0, from 140.252.13.来3自5 b s d i
received mask = ffff0000, from 140.252.13.来3自4 s v r 4primero que notamos en la salida se devuelve desde la máscara de subred SVR 4 que está mal. Es evidente que, aunque SVR 4 interfaces han puesto la máscara de subred adecuada, pero SVR 4 es devolver la máscara de dirección de clase B en general, de subred como si no existiera.
svr4 % ifconfig emd0
emd0: flags=23<UP,BROADCAST,NOTRAILERS>
inet 140.252.13.34 netmask ffffffe0 broadcast 140.252.13.63existe proceso de SVR4 máscara de dirección ICMP de error procedimiento de solicitud.
Consideramos que la situación usando tcpdump en el bsdi anfitrión, salida de la figura 6--5 en la figura. Nosotros usamos la opción -e para ver la dirección de hardware.
Tenga en cuenta que, aunque la línea no puede ver nada, pero el host emisor puede recibir la respuesta ICMP sol (con lo anterior "de un local" línea de salida). Esta es una característica general de la radiodifusión: el envío de acogida también a través de algún mecanismo de bucle de retorno interno para recibir una copia del mensaje de difusión. Dado que el término "radiodifusión" se define para referirse a todos los hosts en la red local, debe ser incluido, incluyendo el envío de host (ver Figura 2 - 4, cuando el conductor Ethernet reconoce que la dirección de destino es una dirección de difusión, el paquete se envía red, mientras que una copia es a la interfaz de bucle de retorno).
A continuación, bsdi para emitir la respuesta,. SVR 4 pero sólo la respuesta al solicitante. Típicamente, la dirección debe ser una dirección de respuesta de unidifusión, a menos que el final de la dirección IP fuente de solicitud de 0.0. 0.0. La presente realización no es el caso, por lo tanto, la respuesta a la dirección de difusión es, un BSD interna error / 3 8 6 en.
normativa RFC, a menos que el sistema es una máscara de dirección de un agente autorizado, de lo contrario no pueden enviar una respuesta de máscara de dirección (con el fin de convertirse en un agente autorizado, que debe estar especialmente configurado para enviar la respuesta. Véase el Apéndice E). Pero, como podemos ver en este ejemplo que, la mayoría host envía una respuesta cuando se recibe una solicitud, incluso algunos de los principales
máquina también envía respuesta de error.
El último punto se puede ilustrar mediante los siguientes ejemplos. Enviamos una solicitud de máscara de dirección a la dirección IP local y direcciones de bucle son:
sun % icmpaddrmask sun
received mask= ff000000, from 140.252.13.33
sun % icmpaddrmask localhost
received mask= ff000000, from 127.0.0.1Devuelve la máscara de dirección en ambos casos es la dirección de bucle de retorno correspondiente a, es decir, clase A dirección 127. 0.0. 1 Asimismo, en la figura 2 -. 4 puede verse, los paquetes de datos enviados a las direcciones IP locales (1402521233) ... En realidad enviados a la interfaz de bucle de retorno. ICMP respuesta de máscara de dirección debe ser recibida una interfaz de máscara de subred solicitud (Esto es porque cada interfaz de host de interfaz múltiple tiene una máscara de subred diferente), la solicitud de máscara de dirección en ambos casos desde la interfaz de bucle invertido .
6.4 Marca de tiempo ICMP de petición y respuesta
solicitud ICMP marca de tiempo permite que el sistema para comprobar la hora actual a otro sistema. El valor de retorno es el número recomendado de milisegundos después de la medianoche, hora coordinada unificada (Tiempo Universal Coordinado, UTC) (manual de referencia temprana a UTC de Greenwich Mean Time). Esta ventaja paquete ICMP es que proporciona una resolución de milisegundos, mientras que el uso de otros métodos a partir del tiempo (tales como comando rdate algún sistema nix U proporcionado) para obtener otros anfitriones para proporcionar solamente de segunda clase resolución. Desde el tiempo de retorno se calcula a partir de la medianoche, por lo que la persona que llama debe conocer la fecha actual por otros medios, que es uno de sus inconvenientes.
solicitud de indicación de la hora y paquete de respuesta formato ICMP se muestra en la figura 6 - 6 mostrado en la figura.
El solicitante para rellenar la marca de tiempo se originan , y luego enviar el mensaje. El sistema de contestador recibe una solicitud para rellenar el paquete de marca de tiempo es recibida , la fecha y hora de transmisión al enviar la respuesta . Sin embargo, en la práctica, para lograr la mayor parte de los dos últimos campos se establecen en el mismo valor (debido a tres campos se proporciona que permite el tiempo calcula el remitente y el tiempo de transmisión de las respuestas de solicitud de transmisión).
6.4.1 Ejemplos
Podemos escribir un programa simple (llamado icmptime), solicitud de marca de tiempo ICMP se envía a un host, e imprimir una respuesta devuelta. Se ejecuta en nuestra pequeña de Internet de la siguiente manera:
programa ICMP paquetes imprime las tres marcas de tiempo: iniciar un sello de tiempo (orig), que reciben sello de tiempo (el recv) y un sello de tiempo de transmisión (XMIT). Como en este ejemplo y los siguientes ejemplos hemos visto, todos los hosts que reciben y las marcas de tiempo de transmisión se fijan al mismo valor.
Podemos calcular el tiempo de ida y vuelta (RTT), su valor es el valor de tiempo del valor de tiempo cuando se recibe menos enviar la solicitud de la respuesta. diferencia de valor es para recibir un valor de marca de tiempo, menos el valor de marca de tiempo se originan. La relación entre estos valores en la figura 6 - Fig. 7.
Si creemos en el valor de RT T, y la mitad creía RT T para la transmisión de paquete de solicitud, y la otra mitad para la transmisión de mensajes de respuesta, con el fin de hacerlo compatible con el reloj local y consultar el reloj de ordenador, las necesidades de reloj locales sean ajuste, el valor de ajuste es la diferencia menos un medio de RT T. En el ejemplo anterior, el reloj bsdi es más lento que el sol reloj de 7 ms y 8 ms.
Dado que los valores de marca de tiempo se calcula el número de milisegundos desde la medianoche, es decir UTC, deben siempre ser inferior a 86 400 000 (2 × 4 6 0 × 6 0 × 1 0 0 0). Estos ejemplos son a las 4: 00 Run antes, y una zona de tiempo lento de 7 horas, UTC, valoran de 82,8 millones (2.300 horas) es mayor justificada.
Repetir varias veces si el host BSDi ejecutar el programa, encontramos que para recibir y sello de tiempo de transmisión del último dígito es siempre 0. Esto es porque la versión del software (0.9. Versión 4) sólo puede proporcionar 1 0 ms resolución de tiempo (ver las instrucciones Apéndice B).
Si el anfitrión SVR 4 para ejecutar el programa dos veces, encontramos los tres últimos dígitos del SVR4 marca de tiempo son siempre 0:
Por alguna razón, SVR 4 resolución de milisegundos no se proporciona en la marca de tiempo ICMP. Así, el tiempo de ajuste segundos diferencia no tendrán ningún efecto.
. Si se corre el programa de subred 140 252 1 en otros hosts, en donde un huésped resultados muestran que la diferencia entre el reloj y el sol 37 segundos, mientras que otro maestro del reloj diferencia de casi 75 segundos .:
Otro ejemplo interesante es una puerta de enlace (a C isco router). Esto demuestra que, cuando el sistema devuelve un valor de marca de tiempo no estándar (no el número de milisegundos desde cálculo medianoche, UTC), es con la marca de tiempo de orden alto 32 bits representado. Nuestro programa detecta esto, e imprimir el valor de marca de tiempo recibida transmitida (después de apagar el alta) encerrado entre paréntesis angulares. Además el tiempo, el inicio no se puede calcular la diferencia entre las marcas de tiempo y recibir, ya que son unidades.
Si estamos ejecutando en ese host el programa varias veces, será obvio que los valores tienen una resolución de milisegundos, y es el número de milisegundos contados a partir de un punto de partida, pero el punto de partida no es la medianoche, la hora UTC (por ejemplo, es posible es el número de milisegundos desde que el enrutador empieza a contar la guía).
Como último ejemplo, comparemos el sol se sabe que es preciso reloj del sistema - un servidor NT Pstratum 1 (digamos más sobre NTP, Network Time Protocol).
Si calculamos la diferencia menos la mitad RT T, los resultados indican que el reloj de sol es más rápido 8. 3 5 ~ 51,5 ms.
6.4.2 Otro método
Otro método también puede usarse para obtener el tiempo y la fecha.
- 1) en la Sección 1. 12 describe los programas y servicios de servicios de fecha y hora. El primero es un formato legible por humanos devuelve la fecha y hora actuales, una línea de caracteres ASCII. Este servicio puede ser verificada usando el comando telnet: Por otro lado, el servicio de tiempo devuelve un valor binario con 3 2 bits, mostrando de la UTC, el número de segundos en enero de 1900 a la fecha de la medianoche. Este programa se basa en la fecha y hora previstas en segundos (que hemos mencionado anteriormente el comando rdate utiliza el servicio de tiempo TCP).
- 2) temporizador Estricto utilizando el protocolo de tiempo de red (NTP), se da una descripción del protocolo [M enfermo s1 9 9 2] en el RFC 1305. Este protocolo utiliza tecnologías avanzadas para asegurar el error del reloj milisegundos dentro de un grupo de sistemas de la LAN o WA N. Ordenador tiempo preciso al lector interesado debe leer este RFC.
- 3) Abrir Software Foundation (OSF) Distributed Computing Environment (DCE) define el servicio de hora distribuido (DTS), sino que también proporciona la sincronización de reloj entre los ordenadores. El documento [R osenbe rg, Kenney y Fisher 1992] proporcionan detalles adicionales de la descripción del servicio.
- 4) Sistema de nix U proporcionando Berkeley daemon timed (8), para sincronizar el reloj del sistema en la LAN. A diferencia de NTP y DTS, temporizada no funciona dentro del rango de la WAN.
6.5 puerto de error ICMP inalcanzable
Las dos últimas secciones vamos a discutir los mensajes ICMP de consulta - máscara de dirección y consultas de marca de hora y respuestas. Ahora Análisis de un mensaje de error ICMP, el mensaje inalcanzable puerto, es ICMP de destino paquetes OSPF inalcanzables con el fin de ver si el mensaje de error ICMP como información adicional. El uso de UDP (véase el Capítulo 11) para verlo.
UDP es una de las reglas, si recibe un datagrama UDP y el puerto de destino no corresponde a un proceso está utilizando, a continuación, devuelve un mensaje ICMP inalcanzable UDP. TFTP se puede utilizar para forzar un mensaje inalcanzable puerto (TFTP describe en el Capítulo 15).
Para los servidores TFTP, el número de puerto UDP común es 69. Pero la mayoría de los programas cliente TFTP permiten un comando de conexión para especificar un número de puerto diferente. Aquí, la usamos para especificar el puerto 8888:
En primer mandato de conexión para especificar el nombre de host y número de puerto para conectarse a, seguido de un comando get para obtener el archivo. Después de escribir el comando get un datagrama UDP enviado al puerto 8888 en el equipo host SVR 4. Tcpdump resultados de cambio de paquetes de salida se muestran 6--8 en la figura.
Antes de que los datos UDP enviadas a SVR4, envía primero una solicitud ARP para determinar la dirección de hardware (línea 1). A continuación, devuelve una respuesta ARP (línea 2), entonces se envía un datagrama UDP (línea 3) (solicitud Reservados ARP y la respuesta en tcpdump salida para recordarnos que estos mensajes pueden ser intercambiados en un primer datagrama IP desde antes de que un host envía a otro host que se requiere. en los capítulos posteriores de este libro, si estos mensajes no están relacionados con los temas tratados, a continuación, vamos a ahorrar
ellos se omite).
Un puerto de ICMP inalcanzable se devuelve inmediatamente (línea 4). Sin embargo, cliente TFTP parece ignorar el paquete ICMP, y después de 5 segundos más tarde, el envío de otro datagrama UDP (línea 5). Antes de abandonar el reenvío cliente tres veces.
Tenga en cuenta que, los mensajes ICMP se intercambian entre el anfitrión, en lugar de un número de puerto de destino, y cada uno de 20 bytes datagrama UDP se transmiten desde un puerto específico (2924) a otro puerto específico (8 888).
Seguido el número UDP 20 se refiere a cada una de la longitud de datos del datagrama UDP. En este ejemplo, 20 bytes incluidos 2 bytes del código de operación TFTP, null 9-byte terminados nombre temp. Foo, y 9-byte cadena netascii terminada en nulo (TFTP el formato detallado del paquete referencia a la figura 15 a -1).
Si - e opción para ejecutar el mismo ejemplo, podemos ver que cada regresaron paquetes de longitud completa inalcanzables puerto ICMP. Esta longitud es de 70 bytes, y se asigna en la figura 6 - 9 se muestra en la figura.
Una regla ICMP es, mensaje de error ICMP (ver Fig. 6 - el último 3.) Debe ser incluido que genera la cabecera IP paquetes de datos mensaje de error (que no contiene opciones), también debe incluir al menos precedido en el detrás de cabecera IP 8 bytes. En nuestro ejemplo, con la primera parte detrás de los primeros 8 bytes de cabecera UDP contiene el IP (véase la figura 11 a -2).
Un hecho importante es que el contenido en el encabezado del número de puerto UDP de origen y puerto de destino número. Este es el número de puerto de destino (8888) arrojó como resultado mensaje de error ICMP inalcanzable puerto. sistema de ICMP recibe un usuario en particular puede estar asociada con el proceso (en el presente ejemplo de cliente TFTP) de acuerdo con el número de puerto de origen (2924) del mensaje de error.
Provoca errores en la cabecera de los paquetes de datos IP para ser devuelto se incluye porque el campo de protocolo de cabecera IP, para que el ICMP sabe cómo interpretar los últimos 8 bytes (en la presente realización el UDP cabecera). Si consideramos la cabecera TCP (Figura 17 a -2), se pueden encontrar en los números de puerto de origen y destino están contenidos en los primeros ocho bytes de la cabecera TCP.
El formato general de paquetes ICMP inalcanzables figura 6--10 figura.
En la figura 6 - 3, observamos que hay 16 tipos diferentes de paquetes ICMP inalcanzables, códigos de 0 a 15, respectivamente. código de error ICMP inalcanzable puerto es 3. Además, aunque la figura 6--10 indica en el paquete ICMP en la segunda palabra de 32 bits debe ser 0, pero cuando el código es 4 ( "fragmentación necesarios pero no lo hacen los bits de fragmentos establecidos"), Path MTU Discovery mecanismo (sección 2.9), pero permite que la interfaz del router para llenar en el exterior MTU inferior 16 bit de la palabra de 32 bits. Le damos un ejemplo de este error en 11,6 pulg.
Aunque las reglas ICMP permiten que el sistema para volver más de 8 bytes de datos para generar un error en el datagrama IP, pero la mayoría de los sistemas derivados de Berkeley retorno sólo 8 bytes. Devuelve los primeros 64 bytes de (E. Sección 4) bajo opción predeterminada condiciones ipicmpreturndatabytes en Solaris 2.2.
series de tiempo tcpdump
A lo largo del texto, también damos una serie de tiempo del formato de salida de tcpdump, como se muestra en la Figura 6--11 figura.
Con el tiempo de inactividad se incrementa, la salida está a la izquierda de la figura de salida tcpdump marca de tiempo del mismo (ver Fig. 6 - 8). Situado en la parte superior de la marca figura es la comunicación tanto del nombre de host y número de puerto. Cabe señalar que, por la página y ejes de coordenadas y el valor verdadero no está en proporción con el tiempo. Cuando hay un período significativo de tiempo, es una retransmisión entre cada 5 segundos en el presente ejemplo, marcamos en ambos lados de la línea de tiempo. Cuando los datos UDP o TCP se están transmitiendo, usamos una línea más gruesa para representar.
Cuando se devuelve el paquete ICMP, ¿por qué cliente TFTP solicitud de retransmisión torreón que? Esto se debe a un factor en la programación de la red, el sistema BSD que no son los paquetes de datos ICMP UDP recibidos del zócalo (socket) para notificar al usuario del proceso, a menos que el proceso ha enviado un comando para conectarse a la toma de corriente. cliente estándar BSD TFTP no envía un comando de conexión, por lo que nunca se notificó a los paquetes ICMP de error.
Otro punto a tener en cuenta es utilizada por el cliente TFTP no es un algoritmo de buena retransmisión de tiempo de espera. Sólo se supone que 5 segundos es suficiente, y por lo tanto vuelve a transmitir cada 5 segundos para un total de 25 segundos requeridos. Más adelante veremos un algoritmo de tiempo de espera de retransmisión TCP buena.
algoritmo de retransmisión de tiempo de espera utilizado por el cliente TFTP está prohibido por el RFC. Sin embargo, todavía está en uso en los tres sistemas en los autores y Solaris 2.2. AIX 3.2.2 se aplica un retardo exponencial con el valor de tiempo de espera, respectivamente, al enviar paquetes 0,5,1 5 y 35 segundos, que es el método recomendado. Vamos a discutir la cuestión de horas extras con más detalle en el capítulo 21.
Por último, cabe señalar que, los mensajes ICMP se envían datagramas UDP devuelto alrededor de 3,5 ms después del tiempo de ida y vuelta que hemos visto en el capítulo 7 de la P ing respuestas similares.
6,6 ICMP 4.4BSD procesamiento de paquetes
Desde que cubre una amplia gama de ICMP, a partir de la información de error a un error fatal, incluso si en una implementación sistema dado, cada uno de procesamiento de paquetes ICMP son diferentes. Contenido y 12 en la figura 6 -. - 3 son los mismos, se muestra el método de procesamiento 4 4 sistemas BSD para cada posible paquetes ICMP 6 Fig.
Si el último marcado como "núcleo", el ICMP será manejado por el núcleo. Si el último indica "proceso de usuario", entonces el mensaje se transfiere a todos los procesos de usuarios registrados en el kernel para leer los paquetes ICMP recibidos. Si cualquier proceso de usuario no existe, entonces el mensaje será descartado en silencio (Estos procesos de usuario también recibirán una copia de todos los paquetes ICMP otros tipos, a pesar de que deben ser manejadas por el núcleo, por supuesto, sólo en el núcleo de procesamiento proceso de usuario después de recibir estos mensajes). Algunos mensajes de ignorados por completo. Por último, si está indicado en la última columna es una cadena de caracteres entre comillas, entonces es el error nix T correspondiente. Algunos de los errores, tales como el TCP del procesamiento de lado de transmisión cerrado, que serán discutidas en secciones posteriores.
6.7 Resumen
En este capítulo se discutió por I nternet Cada sistema debe incluir protocolo de mensaje de control. Figura 6--3 listas de todos los tipos de mensajes ICMP, la mayoría de los cuales serán discutidos en capítulos posteriores.
Hemos discutido en detalle la solicitud de máscara de dirección ICMP y la respuesta y la solicitud de marca de tiempo y respuesta. Estas son las peticiones típicas - mensaje de respuesta. Tanto el identificador de mensaje ICMP y número de secuencia en ambos. Envío de memoria de campo identificador de la aplicación final en un número único para distinguir la respuesta de otros procesos. El campo de número de secuencia para que el cliente puede enviar solicitudes y respuestas entre emparejado.
También discutimos el error ICMP inalcanzable puerto, un error ICMP común. mensaje de error ICMP se devuelve a la analizada: causa un error de la cabecera de datagrama IP y los posteriores 8 bytes. La información para el destinatario del error ICMP es necesario, se puede aprender más acerca de las causas de los errores. Esto se debe a que TCP y UDP número de puerto de origen y se almacenan en el número de puerto de destino en la cabecera de sus primeros 8 bytes.
Por último, por primera vez, se muestra la salida de tcpdump cronológicamente. Esta representación se utiliza con frecuencia en los últimos capítulos de este libro.
