El protocolo IP es un protocolo que solo se encarga de encaminar los datagramas hasta su destino, sin preocuparse si van ha llegar bien o mal, solo los encamina y que "se busquen la vida". Para eso tenemos el protocolo ICMP. El protocolo de Internet de mensajes de control como abreviatura ICMP (Internet Control Message Protocol) ofrece remedio a estos problemas. ICMP tambien desempeña un papel fundamental de asistente en la red, ayudando a los host con su encaminamiento de IP y permitiendo que los administradores de red comprueben el estado de los nodos de la red. Los mensajes de ICMP se transmiten como datagramas de IP con una cabecera normal de IP, con el campo de Protocolo con el valor 1.

MENSAJES DE ERROR DE ICMP
Ha veces cuando trabajamos en red, puede que la conexión que hemos realizado con algun host quede paralizada o se rompa por distintas cuestiones... Cuando se tiene que descartar un datagrama se tiene que informar de alguna forma al host de origen de que la trama que envio esta mal, ¿como se hace? pues muy simple, con el protocolo ICMP :P Cuando hay un error en la red, enseguida el protocolo ICMP notifica del fallo.

TIPOS DE MENSAJES DE ERROR

MENSAJE	DESCRIPCIÓN
Destino inalcanzable (Destination Unreachable)	Un datagrama no puede llegar a su host, utilidad o aplicación de destino
Plazo superado (Time Exceeded)	El tiempo de vida ha expirado en un encaminador o el plazo de reensamblado ha expirado en un host de destino
Problema de los parámetros (Parameter Problem)	Existe un parámetro erróneo en la cabecera de IP
Acallado de origen (Source Problem)	Un encaminador o un destino está congestionado. Se recomienda que los sistemas no envíen mensajes de acallado
Redirigir (Redirect)	Un host ha enviado un datagrama al encaminador local equivocado

OBLIGACIÓN DE ENVIAR MENSAJES DE ICMP

El protocolo ICMP especifica que los mensajes de ICMP deberían o podrían enviarse en todos los lugares. No requiere que todos los errores tengan que generar un mensaje de ICMP. Tiene sentido, la prioridad de un encaminador en una red es reenviar datagramas. Y un host receptor congestionado debería prestar más atención a la entrega de datagramas a sus aplicaciones que a la notificación remota de errores. No es un gran problema si algunos datagramas se descartan y no se indica.

MENSAJES ENTRANTES DE ICMP
¿Qué ocurre cuando un HOST recibe un mensaje de ICMP?... Lo haremos practico, intentemos conectar a una dirección que no existe:

	c:\> telnet 10.10.10.1
	Trying 10.10.10.1 ...
	telnet: connect: Host is unreachable

Y si lo que hemos hecho no te vale... pues lo haremos con el ping de WINDOWS que nos dice exactamente lo que nos manda el protocolo ICMP.

	C:\WINDOWS>ping 10.10.10.1

	Haciendo ping a 10.10.10.1 con 32 bytes de datos:

	Host de destino inaccesible.
	Host de destino inaccesible.
	Host de destino inaccesible.
	Host de destino inaccesible.

Fijate que nos a indicado exactamente lo que ocurre. Ahora para descubrir que encaminador fue el que nos mando ese mensaje a nuestra maquina podemos utilizar una herramienta muy util, como es el traceroute(en linux) o tracert(en windows). En este caso lo hemos hecho en una maquina sin trabajar en inet, tonces el que nos manda el mensaje de control es la propia maquina (127.0.0.1 o localhost). Si estuvieramos en inet pasaria algo parecido a esto:

	c:\> traceroute 10.10.10.1
	traceroute to 10.10.10.1 (10.10.10.1), 30 hops max. 40 byte packets
	1 nomad-gateway (128.121.50.50) 2 ms 2 ms 2 ms
	2 liberty-gateway (130.94.40.250) 91 ms 11 ms 78 ms
	3 border2-hssi2-O.NewYork.mci.net (204.70.45.9) !H !H !H

El encaminador de New York ha enviado mensajes de Destino inalcanzable, que se muestran en la pantalla con las respuestas "!H". La propia función traceroute utiliza los mensajes de Plazo superado de ICMP. El procedimiento es:

* Se construye un mensaje de UDP. Se le da una cabecera de IP cuyo tiempo de vida sea 1.
* Se transmite el datagrama tres veces.
* El primer encaminador, nomad-gateway en el ejemplo anterior, decrementa el tiempo de vida al valor 0, descarta el datagrama y envía de vuelta un mensaje de Plazo superado de ICMP al origen.
* La función traceroute identifica al encaminador que envió el mensaje e imprime los tres tiempos de ida y vuelta.
* Se pone el tiempo de vida a 2 y se envían de nuevo los mensajes.
* El proceso se repite, aumentando el tiempo de vida en cada paso.

Si se pudiera llegar al destino, se mostrara toda la ruta perfectamente :) Ahora ya podeis jugar con este comando para ver por donde pasa un datagrama cuando lo envies a un destino.

CUÁNDO NO ENVIAR MENSAJES DE ICMP
Se puede esperar que los mensajes de ICMP se envíen cuando una red tiene problemas. Es importante asegurar que el tráfico de ICMP no inunda la red, empeorando la situación. Hay que imponer algunos límites obvios al protocolo. ICMP debe informar de los problemas causados por:

* El encaminamiento o el envío de mensajes de ICMP.
* La difusión o multienvío de datagramas.
* Fragmentos de datagrama distintos del primero.
* Mensajes cuya dirección de origen no identifique a un host único, como por ejemplo las direcciones de IP como 127.0.0.1 o 0.0.0.0.

FORMATO DE MENSAJES DE ICMP
Recuerde que los mensajes de ICMP se transmiten en la parte de datos de un datagrama de IP. Cada mensaje de ICMP empieza con los mismos tres campos: un campo de Tipo, un campo de Código que a veces ofrece descripción concreta del error y un campo Suma de control. El formato del resto del mensaje viene determinado por el tipo. Los mensajes de error de ICMP incluyen la cabecera de ip y los 8 primeros octetos del datagrama que ocasionó el error. Esta información se puede utilizar para resolver el problema, ya que incluye datos como el destino previsto y protocolo destino de la capa 4. Al mensaje de ICMP se le aplica la suma de control de ICMP, empezando desde el campo Tipo.

MENSAJE DESTINO INALCANZABLE
La entrega de un datagrama puede fallar en muchos momentos. Debido a un enlace roto, a un encaminador físicamente incapaz de llegar a una subred de destino o para ejecutar el siguiente salto de encaminamiento. El destino puede estar fuera de servicio por labores de mantenimiento. Todos sabemos que en esta tiempo podemos encontrar dispositivos inteligentes que corten el paso a host de la red por administración segura de sus redes, pues entonces tambien estariamos con un mensaje de control de este tipo. El tipo de ICMP es el 3 y en el campo codigo pueden haber distintos valores que expondremos ahora mismo:

Tipo = 3	"Código"	Suma de control

Un datagrama puede expirar porque su tiempo de vida ha llegado a cero mientras se encontraba en tránsito. Otra razón es cuando el plazo de reensamblado del host expira antes de que lleguen todos los fragmentos. En cualquier caso, se envía un mensaje de ICMP de Plazo expirado al origen del datagrama. El formato del mensaje es el siguiente:

Tipo = 11	"Código"	Suma de control

Los valores de los códigos indican la naturaleza del plazo, y se pueden ver en la siguiente tabla:

El mensaje de ICMP Problemas de parámetros se usa para informar de otros problemas que no se cubre con ningún otro mensaje de error. Por ejemplo, puede existir información inconsistente en un campo de opciones que que sea imposible procesar el datagrama correctamente, por lo que hay que descartarlo. Lo más habitual en cuanto a problemas de parámetros se debe a errores de implementación en el sistema que escribió los parámetros en la cabecera de IP. En el formato del mensaje que estamos explicando, aparece un nuevo campo, "Apuntador", te dice en que octeto a detectado el fallo. El formato del mensaje es:

Tipo = 12	"Código"	Suma de control

Apuntador		No usado

Este mensaje no es muy efectivo, ya que ¿Cuándo, y quién, debería enviar un mensaje de acallamiento de origen?. Cuando un encaminador se ve colapsado puede que el datagrama que descarte no sea del origen que lo esta colapsando, por eso se esta intentando encontrar algo más efectivo que un Acallamiento de origen. El formato del mensaje es el siguiente:

Tipo = 4	"Código"	Suma de control

Puede que haya mas de un encaminador conectado a la LAN. Si el host local envía un datagrama al encaminador equivocado, el encaminador reenviará el datagrama y un mensaje Redirección (Redirect) al host origen, como se muestra en la Figura 7.8. El jost debería enviar el tráfico siguiente al encaminador con la ruta más corta. Los mensajes Redirección se pueden usar para reducir el trabajo manual de administración. Se puede configurar un encaminador con un único encaminador por defecto y que aprenda dinámicamente sobre las rutas que van por otros encaminadores. Algunos protocolos de encaminamiento pueden elegir el camino de entrea según el campo Tipo de servicio (TOS). Los codigos 2 y son consejos que reflejan estas consideraciones. El formato de los mensajes Redirección es:

Tipo = 5	"Código"	Suma de control

¿Qué se hace cuando llega un mensaje de error de ICMP a un host de origen? Cada fabricante implementa su software de red de forma variada a los demas, pero como el protocolo TCP/IP es muy libre, puede existir muchos modos de actuar con un mensaje de ICMP. Las guías que se dan para los distintos tipos de mensajes son:

Destino inalcanzable	Entregar el mensaje de ICMP a la capa de transporte. La acción depende de si la razón es permanente o transitoria
Redirect	El host debe actualizar la tabla de encaminamiento
Acallamiento de origen	Entregar el mensaje a la capa de transporte o a un módulo de procesamiento de ICMP
Plazo superado	Entregar el mensaje a la capa de transporte
Problema de parámetros	Entregar el mensaje a la capa de transporte; opcionalmente notificar al usuario

A veces, se pueden tratar las condiciones de error mediante la cooperación entre el sistema operativo, el software de comunicaciones y la aplicación que realiza la comunicación.

OBTENCIÓN DE LA MTU DE UNA RUTA
Cuando se realiza una operación que transmite gran cantidad de información entre dos host, como una transferencia de archivos, el tamaño de datagrama puede tener un gran impacto en el rendimiento del sistema. Las cabeceras IP y de TCP aportan una sobrecarga de al menos 40 bytes.

* Si se envían los datos en datagramas de 80 bytes, la sobrecarga es del 50 por ciento

* Si se envían los datos en datagramas de 400 bytes, la sobrecarga es del 10 por ciento

* Si se envían los datos en datagramas de 4000 bytes, la sobrecarga es de un 1 por ciento

Para minimizar la sobrecarga, se desearía enviar los mayores datagramas posibles. Pero hay que recordar que existe cierto límite en el tamaño del datagrama en un medio dado, la Unidad máxima de transmisión (MTU). Si los datagramas son demasiado grandes, se fragmentarán, y la fragmentación reduce el rendimiento del sistema.
Durante muchos años, los host evitaban la fragmentación fijando la "MTU efectiva de envío" en 576 bytes para el tráfico a cualquier lugar que no fuese local. A menudo, distorsionaba innecesariamente el rendimiento.
Sabiendo esto, sería muy util predecir el mayor datagrama que se puede enviar por una ruta especifica para que no baje el rendimiento en el sistema. Existe un mecanismo, el de Obtención de la MTU de una ruta (Path MTU discovery) que permite determinar este tamaño. Su modo de funcionamiento es el siguiente:

* Se fija 1 la bandera "No fragmentar" de las cabeceras de IP.

* Se empieza con un tamaño de MTU de la ruta como el de la MTU de la interfaz local.

* Si el datagrama es demasiado grande para que lo reenvíe algún encaminador, le devolverá un mensaje de ICMP de Destino inalcanzable con el código = 4.

* El host reduce el tamaño del datagrama y lo intenta de nuevo.

Entonces, sabiendo esto, se deduce que si el software es lo bastante actualizado, el mensaje Destino Inalcanzable tendra un campo que contendra el MTU con el que se deberia transmitir. Como la ruta pueden cambiar dinámicamente, la bandera "No fragmentar" se puede mantener durante toda la comunicación. Los encaminadores enviarán correcciones si se necesita. Si en el caso de que el software del encaminador sea antiguo, el encaminador no indicara el tamaño de la MTU del siguiente salto. Un host puede hacer un supuesto razonable eligiendo el siguiente nivel inferior de la lista de tamaños estándar de MTU. El procedimiento de cambio de tamaño continúa hasta que se encuentra un valor con el que se alcanza el destino. Por supuesto, si ocurre un cambio en la ruta existe la posibilidad de cambiar a una MTU mayor. Un sistema que haya tenido que elegir una MTU pequeña puede intentar, periódicamente, enviar una de mayor tamaño para comprobar si se puede conseguir alguna mejora.

Tipo = 3	"Código"	Suma de control

No usado		MTU del siguiente salto

No todos los mensajes ICMP son señales de error. Algunos se usan para obtener información útil de la red. ¿está vivo el host?¿Está ejecutando el host Y? ... Concretamente, entre los mensajes de petición de ICMP están:

* Mensajes de petición y respuesta de ECO (ECHO) que pueden intercambiar con los host y con los encaminadores.

* Mensajes de petición y respuesta de la Máscara de dirección que permite a un sistema descubrir la máscara de dirección que debería asignar a una interfaz.

* Mensajes de petición y respuesta de Marca de tiempo que lee el reloj de un sistema dado.

El objetivo es que la respuesta dé una idea de cuanto tiempo le lleva al sistema procesar un datagrama.

PETICIÓN Y RESPUESTA DE ECO

La petición de ECO y la respuesta de ECO se usan para comprobar si un sistema está activo. Se usa Tipo = 8 para la petición y Tipo = 0 para la respuesta. El número de octetos del campo de datos es variable y se selecciona en el origen. El destino debe enviar de vuelta el mismo mensaje recibido. El campo "Indentificador" se usa para hacer coincidir la respuesta con la petición original. Se puede enviar una secuencia de ocho mensajes para comprobar si la red está tirando mensajes y estimar el tiempo medio de ida y vuelta. Para ello, se deja fijo el identificador y el número de secuencia se incrementa con cada mensaje, empezando en cero. Formato de ECO:

Tipo = 8 o 0	"Código"	Suma de control

Identificador		Número de secuencia

	C:\WINDOWS>ping -n 14 -l 64 127.0.0.1

	Pinging 127.0.0.1 with 64 bytes of data:

	Reply from 127.0.0.1: bytes=64 time=1ms TTL=32
	Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
	Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
	Reply from 127.0.0.1: bytes=64 time=1ms TTL=32
	Reply from 127.0.0.1: bytes=64 time=1ms TTL=32
	Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
	Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
	Reply from 127.0.0.1: bytes=64 time=1ms TTL=32
	Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
	Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
	Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
	Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
	Reply from 127.0.0.1: bytes=64 time=10ms TTL=32
	Reply from 127.0.0.1: bytes=64 time=10ms TTL=32

Donde pone time=?? aparece el tiempo de ida y vuelta que ha transcurrido a enviar el paquete, tambien puede aparecer time??.

MASCARA DE DIRECCIÓN
Recuerde que una organización puede decidir dividir sus campos de direcciones locales en parte de subred y parte de host. Cuando se arranca un sistema puede que no esté configurado para conocer cuantos bits se le han asignado al campo de dirección de subred. Para obtenerlo, el sistema puede difundir una petición de Máscara de Dirección. La respuesta debería enviarla un servidor autorizado de Máscaras de Dirección. Normalmente, se supone que el servidor sea un encaminador, pero a veces puede usarse un host. La respuesta pondrá a uno los campos de red y subred del camo de Máscara de dirección en cuanto esté activo de nuevo. Se hace así en beneficio de los sitemas que hayan arrancado mientras no estaba disponible el servidor.
El tipo 17 es para la petición y el Tipo 18 para la respuesta. Generalmente se pueden ignorar los campos de número de secuencia. En la actualidad el metodo preferido para determinar la Máscara de Dirección es utilizando un protocolo de arranque como el Protocolo Dinámico de Configuración de host, o BOOTP. Estos procesos son más eficientes ya que disponen de un amplio conjunto de parámetros de configuración. También son, a menudo, más precisos. Por ejemplo, una estación Unix puede estar desconfigurada y responder erróneamente a los mensajes de petición de Mascara de Dirección. El resultado es que su sistema recibirá varias respuestas y algunas de ellas serán erróneas.

Tipo = 17 o 18		"Código"	Suma de control

Identificador		Número de secuencia

Tipo = 13 o 14		"Código"	Suma de control

Identificador		Número de secuencia

ICMP Statistics

                            Received    Sent
  Messages                  19          31
  Errors                    0           0
  Destination Unreachable   3           3
  Time Exceeded             0           0
  Parameter Problems        0           0
  Source Quenchs            0           0
  Redirects                 0           0
  Echos                     8           20
  Echo Replies              8           8
  Timestamps                0           0
  Timestamp Replies         0           0
  Address Masks             0           0
  Address Mask Replies      0           0

icmp:
  1075 calls to icmp_error

  Output histogram:
    echo reply: 231
    destination unreachable: 1075

  2 messages with bad code fields
  0 messages (menor) minimum length
  21 bad checksums
  0 messages with bad length

  Input histogram:
    echo reply: 26
    destination unreachable: 1269
    source quench: 2
    echo: 231
  231 message responses generated

$ netstat -rs

routing:
  0 bad routing redirects
  0 dynamically created routes
  2 new routers due to redirects
  12 destinations found unreachable
  349 uses of a wildcard route

* Se configura la interfaz de los encaminadores con la dirección de aviso, o 225.0.0.1 o 255.255.255.255, para la LAN a la que está conectada.

* Cuando el encaminador se inicializa, si se puede usar multienvío el encaminador empieza a escuchar en la dirección de multienvío todos-los-encaminadores, que es la 224.0.0.2. Tambien escucha posibles difusiones.

* El encaminador anuncia su presencia a los host conectados a la LAN transmitiendo un Aviso de encaminador a la dirección de aviso de esa LAN. El aviso lista todas las direcciones de IP de ese encaminador para esa interfaz.

* El encaminador demuestra que aun está vivo, enviando periódicamente por multienvío otro Aviso de encaminador. Se sugiere un período de entre 7 y 10 min.

* El encaminador envía un aviso cuando un host lo solicita.

* Se configuran las interfaces del host con la Dirección de solicitud, bien 224.0.0.2 o 255.255.255.255.

* Cuando se inicializa el host, empieza escuchando Avisos de encaminador.

* Al arrancar, el host puede, opcionalmente, enviar un mensaje de Solicitud de Encaminador a la dirección de solicitud. Los encaminadores responden a la dirección de IP del host o a la dirección de aviso.

* Cuando un host escucha a un nuevo encaminador, el host añade una ruta default a su tabla de encaminamiento. Se asigna a la entrada un tiempo de vida del valor del plao, normalmente 30 minutos, que se anunciaba en el Aviso del encaminador.

* El tiempo de vida del plazo se reinicia siempre que se recibe un nuevo aviso del encaminador. Si el plazo expira, se elimina la entrada del encaminador de la tabla de encaminamiento del host.

* Para indicar al resto del mundo que se va a apagar, un encaminador puede enviar un aviso con un tiempo de vida de valor 0.

* La existencia de sesiones de TCP activas en el encaminador

* La recepción de un mensaje de redirección del encaminador

* Falla la respuesta a peticiones de ARP o ECHO REPLY

* Hay muchos plazos de retransmisión de TCP consecutivos