Member of The Internet Defense League Últimos cambios
Últimos Cambios
Blog personal: El hilo del laberinto Geocaching

Desarrollo de una Herramienta Software para el Acceso a Redes TCP/IP a través de la Red Telefónica Conmutada

Última Actualización: 30 de Junio de 1.996 - Domingo

Capítulo 6:
El Módulo ICMP

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:

  • Informes de errores en la entrega de un datagrama, por diversas causas: red o máquina no alcanzables, puerto o protocolo desconocido en la máquina destino, MTU excedida y prohibición de fragmentación o "Source Routing" inválido.

  • Tiempo de vida del datagrama excedido, ya sea en ruta o bien durante el reensamblaje.

  • Problema en alguno de los parámetros IP de la cabecera del datagrama.

  • Control de flujo.

  • Datagramas de redirección a otras pasarelas.

  • Datagramas eco para comprobar la conexión ("ping").

  • Datagramas con firma temporal ("TimeStamp").

  • Datagramas de información general.

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:

  • MSG_ICMP_DEST_UNREACHABLE

    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:

    • ICMP_NO_RED

      No se puede alcanzar la red destino.

    • ICMP_NO_MAQUINA

      No se puede alcanzar la máquina destino.

    • ICMP_NO_PROTOCOLO

      La máquina destino desconoce el protocolo especificado en la cabecera IP.

    • ICMP_NO_PUERTO

      El protocolo de la máquina destino desconoce el puerto al cual se hace referencia en el datagrama.

    • ICMP_ERR_FRAGMENT

      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.

  • MSG_ICMP_TIME_EXCEDED

    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:

    • ICMP_EN_TRANSITO

      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.

    • ICMP_ENSAMBLAJE

      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.

  • MSG_ICMP_PARAM_PROBLEM

    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).

  • MSG_ICMP_SOURCE_QUENCH

    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.

  • MSG_ICMP_ECHO

    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:

  • MSG_ICMP_DEST_UNREACHABLE

    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.

  • MSG_ICMP_SOURCE_QUENCH

    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.

  • MSG_ICMP_REPLY

    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.


Implementación

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):

  • Firmas temporales ("TimeStamps") [RFC778]

  • Datagramas de redirección

  • Datagramas de información general

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



Python Zope ©1996 jcea@jcea.es

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS