Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización:
30 de Junio de 1.996 - Domingo
El módulo ICMP (Internet Control Message Protocol) es el responsable de proporcionar información de control sobre la capa IP. Se encarga, por ejemplo, de informar a la máquina origen de los posibles errores IP que puedan surgir a lo largo del tránsito de un datagrama. Facilita, asimismo, un sistema rudimentario de gestión de encaminamiento y control de flujo, así como unos cuantos servicios como "echo" o "TimeStamp".
El sistema ICMP, tradicionalmente, ha sido modelado al margen de la capa IP, aunque físicamente ambos módulos suelen programarse juntos debido a su estrecha colaboración. En este Proyecto hemos decidido abordar la implantación desde el punto de vista de módulos separados, fieles a un enfoque modular.
La primera versión del ICMP [RFC792] define una serie de mensajes de control que incluyen:
Al igual que con el protocolo IP, se ha definido recientemente una ampliación al ICMP para acomodarlo a las nuevas necesidades nacidas del crecimiento de Internet [RFC1885]. Se incorporan algunas mejoras, pero las funcionalidades básicas del ICMP original se mantienen. En este Proyecto Fin de Carrera hemos decidido implantar la versión ICMP 4 debido a que es la utilizada comúnmente en Internet, y la versión 6 es demasiado reciente como para poder utilizarla de forma efectiva, además de requerir la implementación de IPv6.
En [RFC1256] se define una extensión al protocolo ICMP original para posibilitar que un nodo conozca las direcciones IP de sus pasarelas vecinas. De esta forma se elimina la necesidad de utilizar tablas de configuración en cada máquina, mantenidas de forma manual.
Por último, en [RFC1788] se propone una extensión experimental al
ICMP para distribuir la traducción entre direcciones IP y nombres
de máquinas y reducir la carga de trabajo del dominio "IN-ADDR".
Interfaz
Este módulo ha sido diseñado especialmente para comunicarse con la capa IP. Aunque muchos de sus servicios también están disponibles a otros niveles, deben utilizarse con precaución. El hecho de que las capas superiores puedan utilizar el ICMP es una de las razones por las que IP envía hacia arriba la cabecera IP original de los datagramas que se reciben.
La comunicación con el resto de los procesos se realiza única y exclusivamente a través del intercambio de mensajes. Los procesos definidos en esta capa son:
PROC_ICMP_BC
Este proceso es el encargado de inicializar este módulo. Debe ser invocado con un mensaje "MSG_INIT" o "MSG_QUIT". La inicialización de este módulo debe ser posterior a la del módulo IP.
PROC_ICMP_SUP
Este es el proceso al que las otras capas (especialmente la capa IP) solicitan servicios. Los mensajes permitidos son:
Utilizado cuando una capa IP detecta que no puede entregar el datagrama. campo1 contiene el datagrama problemático completo, que puede estar compuesto por una cadena de MBUFs con la única limitación de que la cabecera IP en sí debe constar de un único MBUF. campo2 proporciona más información:
No se puede alcanzar la red destino.
No se puede alcanzar la máquina destino.
La máquina destino desconoce el protocolo especificado en la cabecera IP.
El protocolo de la máquina destino desconoce el puerto al cual se hace referencia en el datagrama.
Para llegar a la máquina destino es necesario atravesar una red con MTU (Maximum Transfer Unit) menor que el tamaño del datagrama, y la bandera "Don't fragment" del mismo está activada.
Este mensaje genera un datagrama de error para informar a la máquina fuente de que uno de sus datagramas ha excedido su tiempo de vida. En campo1 se indica el datagrama en cuestión, sujeto a las mismas restricciones anteriores. campo2 proporciona información adicional:
El datagrama agotó su tiempo de vida mientras estaba siendo encaminado hacia su destino. Si el datagrama ha sido fragmentado, este mensaje sólo se genera para el primer fragmento.
El datagrama agotó su tiempo de vida mientras estaba esperando la llegada de alguno de sus fragmentos. Sólo se genera cuando disponemos del primer fragmento. La cabecera IP suministrada es la de cualquiera de los fragmentos recibidos, y el datagrama en sí contiene todos los fragmentos que han llegado hasta el momento.
Este mensaje se genera cuando se detecta algún error en la cabecera IP de un datagrama recibido. campo1 contiene el datagrama en cuestión, mientras que campo2 almacena el offset, en bytes, del valor problemático (formato HOST).
Este mensaje se genera cuando la capa IP se ve sobrecargada, siendo éste el mecanismo básico de control de flujo a nivel IP. campo1 contiene el datagrama que provocó el problema.
Este es un mensaje utilizable por todas las capas (los vistos hasta ahora están diseñados para ser utilizados, fundamentalmente, por el módulo IP). Envía un datagrama de prueba a una máquina remota y espera su respuesta. Se utiliza, por ejemplo, para implementar esquemas "ping" y comprobar la existencia de una máquina dada, su funcionaminento en un instante determinado y el retardo ida y vuelta del enlace. campo1 contiene el datagrama a enviar al otro extremo (la cabecera IP sólo necesita tener correcto el campo de dirección IP fuente, que será igual al DESTINO que se desea alcanzar). campo2 es el proc_id del proceso al cual hay que avisar cuando se reciba la respuesta. campo3, por último, contiene un número de secuencia utilizado para emparejar las respuestas con sus peticiones originarias correspondientes. Sólo son significativos los 16 bits de menor peso.
PROC_ICMP_INF
Este es el proceso que recibe los datagramas ICMP que llegan y procesarlos adecuadamente. Espera recibir un mensaje MSG_MBUF con campo1 conteniendo la estructura de MBUFs definida por el interfaz IP. Los mensajes que genera este proceso son:
Informa a la capa correspondiente de que un datagrama enviado por ella no puede alcanzar su destino. campo1 contiene los ocho primeros bytes de datos del datagrama original, que se supone almacenan la suficiente información como para que el proceso correspondiente pueda desentrañar a qué puerto corresponde. campo2 proporciona datos adicionales sobre la causa del error, tal y como se ha visto descrito ya con anterioridad: ICMP_NO_RED, ICMP_NO_MAQUINA, ICMP_NO_PROTOCOLO, ICMP_NO_PUERTO e ICMP_ERR_FRAGMENT. En cuanto a campo3, contiene la dirección IP (formato RED) de la máquina donde ocurrió el problema. El mensaje se envía al proceso responsable del protocolo a cuyo datagrama pertenecía el original.
Este mensaje se genera cuando la capa IP recibe un datagrama SOURCE_QUENCH. Se envía al proceso responsable del protocolo del datagrama que causa la acción. campo1 contiene los 8 primeros bytes de datos del datagrama que disparó el mecanismo de control de flujo. campo2 posee un valor indefinido. campo3 almacena la dirección IP (formato RED) de la máquina que solicita el control de flujo.
Este mensaje se genera cuando se recibe una respuesta a una petición de eco anterioremente generada. El proceso destinatario es el indicado en la petición de eco. campo1 contiene los datos originales enviados, campo2 contiene el proc_id del proceso en ejecución y campo3 es el número de secuencia indicado en el mensaje inicial.
Este módulo implementa una capa ICMP acorde a los requisitos declarados en [RFC792]. Se han omitido, no obstante, algunas funcionalidades consideradas de reducido interés en el contexto de este Proyecto (acceso a un proveedor de servicios Internet):
Cuando sea apropiado se intenta hacer llegar los mensajes ICMP al proceso adecuado. Ello se realiza en cooperación con la capa IP, que es la que conoce a qué proceso hay que informar sobre los eventos ocurridos a los datagramas de un protocolo determinado. En el caso de que el protocolo sea desconocido, los mensajes ICMP simplemente se ignoran.
Como ya se ha comentado con anterioridad, los servicios de la
capa ICMP están orientados, fundamentalmente, a la capa IP.
Ningún otro nivel debería hacer uso de ellos sin un conocimiento
profundo de su funcionamiento y de las estructuras de datos
implicadas (en especial, la cabecera IP). La excepción es
MSG_ICMP_ECHO, de libre uso por parte de cualquier proceso.
Bibliografía
[RFC778] RFC 778: "DCNET Internet Clock Service"
D.L. Mills
Abril 1.981
[RFC792] RFC 792: "Internet Control Message Protocol"
Jon Postel
Septiembre 1.981
[RFC1122] RFC1122: "Requirements for Internet Hosts --
Communication Layers"
Robert Braden
Octubre 1.989
[RFC1256] RFC 1256: "ICMP Router Discovery Messages"
S. Deering
Septiembre 1.991
[RFC1788] RFC1788: "ICMP Domain Name Messages"
William Allen Simpson
Abril 1.995
[RFC1885] RFC1885: "Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6)
Specification"
S. Deering
A. Conta
Diciembre 1.995
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
