Tipos de mensaje ICMP (Internet Control Message Protocol)

     En esta entrada, continuación de la anterior sobre ICMP, describimos uno por uno los tipos de
mensaje ICMP:

     Mensajes ICMP Echo (8) y Echo Reply (0)

     Los mensajes de echo son utilizados para detectar si otro equipo está activo en la red. Es
utilizado por el comando Ping. El host que envía el mensaje de petición (request) inicializa los
campos identifier, sequence number a valores escogidos por él, así como el contenido de los datos
(data). El host receptor de la petición

 cambia el tipo de mensaje a Echo Reply y devuelve el datagrama al emisor con los mismos valores
en los campos identifier, sequence number y contenido que recibió, es decir realiza un ‘eco’ del
mensaje recibido. 

     Mensaje ICMP Destination Unreachable (3)

     Si este mensaje es recibido desde un router intermedio nos indicará que el router considera la
dirección IP destino como inalcanzable.

     Si el mensaje es recibido desde el equipo destino nos indicará que el protocolo especificado en
campo protocol number del datagrama original no está activo o que el puerto especificado no está
activo.
   
     El campo código de la cabecera ICMP puede contener uno de los siguientes valores:

Códig Valor
o
0 Net unreachable
1 Host unreachable
2 Protocol unreachable
3 Port unreachable
4 Fragmentation needed and don’t fragment bit was set
5 Source route failed
6 Destination network unknown
7 Destination host unknown
8 Source host isolated
9 Destination network is administratively prohibited
10 Destination host is administratively prohibited
11 Destination network unreacheable for type of service
12 Destination host unreacheable for type of service
13 Communication Administratively prohibited
14 Host precedence violation
15 Precedence cutoff in effect

   
     Si el router implementa el protocolo Path MTU Discovery, el formato del mensaje de destino
inalcanzable es sustituido por el código 4. Incluirá la MTU de el link que no acepta el datagrama.
     Mensaje ICMP Source Quench (4)
     Si el mensaje es recibido desde un router intermedio nos indicará que el router no tiene
capacidad en los buffer para encolar el datagrama. 

     Si el mensaje es recibido desde el equipo destino nos indicará que los datagramas entrantes
llegan demasiado deprisa para ser procesados. El campo código de la cabecera ICMP siempre será
0.

     Mensaje ICMP Redirect (5)

     El ICMP redirect es un mecanismo que permite a los router transmitir información de routing a
los host. Este mensaje informa a un host para que actualice su información de routing.

     Si el mensaje es recibido desde un router intermedio nos indicará que el host debe enviar futuros
mensajes a un  router alternativo cuya dirección IP es especificada en el mensaje ICMP. Este router
alternativo deberá estar en la misma subred que el host que envía el datagrama y el router que lo
devuelve.
Este mensaje no será enviado si el datagrama IP contiene información de routing.
   
     El campo código de la cabecera ICMP puede contener, especificando la razón para la
redirección, los valores siguientes:
 0. Error de red
 1. Error de host
 2. Error de tipo de servicio (TOS) y red
 3. Error de tipo de servicio (TOS) y host 

     Mensaje ICMP Router Advertisement (9) and Router Solicitation (10)

     Los mensajes de ICMP 9 y 10, de tipo Router discovery son opcionales y se encuentran descritos
en la RFC 1256.
     Periódicamente cada router envía mediante multicast mensajes router advertisement (RA) por
cada una de sus interfaces anunciando la dirección IP de la misma. Los host descubren la dirección
IP de sus routers adyacentes simplemente escuchando estos mensajes. Un host, cuando se conecta a
una subred, también puede enviar un mensaje multicast de router solicitation (RS) para recibir un
anuncio inmediato, en vez de tener que esperar al próximo anuncio periódico. Si no recibe
respuesta, retransmitirá el mensaje un número limitado de veces, tras la cuales desistirá de su
solicitud.

     Estos mensajes para descubrir routers no constituyen un protocolo de routing. Únicamente

permiten al host descubrir los routers existentes en su subred, pero no cuál de ellos es el mejor para
alcanzar un destino concreto. Si un host elige uno de los routers que no es el mejor para alcanzar el
destino, deberá recibir un mensaje ICMP de redirección indicándole el mejor.

     La estructura del mensaje router advertisement es la siguiente:

     Donde:
 Contador. Es el número de routers anunciados en este mensaje.
 Longitud. Indica la longitud de cada una de las entradas  (palabras de 32
bit) para cada una de las direcciones de router. Este valor generalmente es 2
(32 bit para la dirección IP del router + 32 bit para el valor de nivel de
preferencia).
 TTL. Indica el número máximo de segundos durante los cuales la dirección
IP del router puede ser considerada válida. El router puede anunciarse
como no disponible enviando este campo con el valor 0.
 Dirección IP del router. Dirección IPv4 del router anunciado
 Preferencia. La preferencia asignada a la dirección IP del router relativa a
las direcciones de otros routers en la misma subred. A mayor valor mayor
preferencia. El valor por  defecto es 0, que se encuentra en la mitad del
posible rango.
     Mensaje ICMP Time exceeded (11)
     Si este mensaje es recibido desde un router intermedio, nos indicará que el campo TTL de un
datagrama IP ha expirado.

     Si el mensaje lo recibimos desde el host destino, nos indicará que el timer TTL ha expirado
durante el re-ensamblaje de un datagrama IP fragmentado (esperando a un fragmento del
datagrama).

     Estos mensajes son utilizados por el comando traceroute para identificar routers en el camino
entre dos hosts.

     La estructura de este mensaje es la siguiente:

     Donde el campo código puede tener uno de los valores siguientes:
 0. TTL excedido en tránsito
 1. TTL excedido durante el re-ensamblaje

     Mensaje ICMP Parameter Problem (12)

     Este tipo de mensaje indica que se ha encontrado un problema durante el procesamiento de los
parámetros de la cabecera IP. Este mensaje es generado en respuesta a cualquier error no cubierto
específicamente por otro mensaje ICMP. No es generado en respuesta a un datagrama destinado a
una dirección multicast.

     La estructura de este mensaje es la siguiente:

     Donde:
 Código. Puede tener uno de los valores siguientes:
 0. Cabecera IP inválida
 1. Una opción requerida no ha sido encontrada
 Puntero. En caso de una cabecera IP inválida (code=0) este campo indica el ‘byte
offset’ del error en la cabecera. 
     Mensajes ICMP Timestamp Request (13) and Timestamp Reply (14)
     Estos dos mensajes  son para debugging y medidas de rendimiento.

     El emisor del mensaje inicializa el identificador (identifier) y el número de secuencia (sequence
number; utilizado si se envían varias solicitudes), marca el  timestamp y envía el datagrama al
receptor. El host receptor rellena los timestamp de recepción (momento en que lo recibe) y
transmisión (momento en que lo envía), cambia el tipo de mensaje a timestamp reply y se lo
devuelve al emisor. Los campos  identificador y número de secuencia deben volver al emisor sin
alterar.

     El datagrama tiene dos timestamps si hay una diferencia de tiempo perceptible entre los tiempos
de recepción y transmisión. En la práctica, la mayoría de las implementaciones realizan ambos
(recepción y transmisión) en una operación. Esto marca los dos tiempos con el mismo valor. Los
timestamps son el número en milisegundos transcurrido desde la medianoche (UT).

     Mensajes ICMP Address Mask Request (17) and Address Mask Reply (18)
     El mensaje de solicitud de máscara es utilizado por un equipo para determinar la máscara de
subred utilizada en la red donde está conectado. La mayoría de los equipos están configurados  con
su máscara, sin embargo, algunos equipos sin disco pueden obtener está información de un servidor.
El equipo utiliza RARP (Reverse Address Resolution Protocol) para obtener su dirección IP. Para
obtener la máscara de subred lanza una petición de máscara con el campo máscara a 0. Cualquier
equipo que haya sido configurado para enviar respuestas de máscara de dirección rellena el campo
de máscara de subred y devuelve el paquete al solicitante.

ARP

En red de computadoras, el protocolo de resolución de direcciones (ARP, del inglés Address

Resolution Protocol) es un protocolo de comunicaciones de la capa de enlace de datos, responsable
de encontrar la dirección de hardware (Ethernet MAC) que corresponde a una
determinada dirección IP. Para ello se envía un paquete (ARP request) a la dirección de difusión de
la red (broadcast, MAC = FF FF FF FF FF FF) que contiene la dirección IP por la que se pregunta,
y se espera a que esa máquina (u otra) responda (ARP reply) con la dirección Ethernet que le
corresponde. Cada máquina mantiene una caché con las direcciones traducidas para reducir el
retardo y la carga. ARP permite a la dirección de Internet ser independiente de la
dirección Ethernet, pero esto solo funciona si todas las máquinas lo soportan.

ARP está documentado en el RFC 826. El protocolo RARP realiza la operación inversa y se

encuentra descrito en el RFC 903.

En Ethernet, la capa de enlace trabaja con direcciones físicas. El protocolo ARP se encarga de
traducir las direcciones IP a direcciones MAC (direcciones físicas). Para realizar esta conversión, el
nivel de enlace utiliza las tablas ARP, cada interfaz tiene tanto una dirección IP como una dirección
física MAC.

ARP se utiliza en cuatro casos referentes a la comunicación entre dos hosts:

1. Cuando dos hosts están en la misma red y uno quiere enviar un paquete a otro.

2. Cuando dos hosts están sobre redes diferentes y deben usar un gateway o router para
alcanzar otro host.
3. Cuando un router necesita enviar un paquete a un host a través de otro router.
4. Cuando un router necesita enviar un paquete a un host de la misma red.
Alcance de funcionamiento

El protocolo de resolución de direcciones es una solicitud y un protocolo de respuesta que ejecuta

encapsulado por el protocolo de línea. Se comunica dentro de los límites de una sola red, nunca
encaminado a través de los nodos de interconexión de redes. Este establecimiento pone ARP en
la capa de enlace del conjunto de protocolos de Internet; mientras que en la interconexión de
sistemas abiertos (OSI), normalmente se describe como residentes entre las capas 2 y 3, el ARP está
rodeado por protocolos de capa 2, sin embargo, ARP no se desarrolló en el marco de OSI.
Funcionamiento I
Si  A  quiere enviar una trama a la dirección IP de  B  (misma red), mirará su tabla ARP para poner
en la trama la dirección destino física correspondiente a la IP de  B . De esta forma, cuando les
llegue a todos la trama, no tendrán que deshacerla para comprobar si el mensaje es para ellos, sino
que se hace con la dirección física.
Funcionamiento II
Si  A  quiere enviar un mensaje a  C  (un nodo que no esté en la misma red), el mensaje deberá salir
de la red. Así,  A  envía la trama a la dirección física de salida del router. Esta dirección física la
obtendrá a partir de la IP del router, utilizando la tabla ARP. Si esta entrada no está en la tabla,
mandará un mensaje ARP a esa IP (llegará a todos), para que le conteste indicándole su dirección
física.

Ejemplo Address Resolution Protocol (ARP).

Una vez en el router, este consultará su tabla de encaminamiento, obteniendo el próximo nodo
(salto) para llegar al destino, y saca el mensaje por la interfaz correspondiente. Esto se repite por
todos los nodos, hasta llegar al último router, que es el que comparte el medio con el host destino.
Aquí el proceso cambia: la interfaz del router tendrá que averiguar la dirección física de
la IPdestino que le ha llegado. Lo hace mirando su tabla ARP, y en caso de no existir la entrada
correspondiente a la IP, mandará un mensaje ARP a esa IP (llegará a todos), para que le conteste
indicándole su dirección física.

Estructura del paquete

El ARP utiliza un formato de mensaje simple que contiene una solicitud de resolución de dirección
o respuesta.

El tamaño del mensaje ARP depende de la capa superior y menor tamaño de dirección de capa, que
se da por el tipo de protocolo de red (por lo general IPv4) en uso y el tipo de capa de enlace virtual
que el protocolo de capa superior se ejecuta en el hardware.

El encabezado del mensaje especifica estos tipos, así como el tamaño de las direcciones de cada
uno. El encabezado del mensaje se completa con el código de operación para la solicitud (1) y la
respuesta (2).

La carga útil del paquete consta de cuatro direcciones, el hardware y la dirección de protocolo del
remitente y el receptor host.

 Tipo de hardware o Hardware Type (HTYPE): este campo especifica el tipo de protocolo

de red. Ejemplo: Ethernet es 1.
 Tipo de protocolo o Protocol Type (PTYPE): este campo especifica el protocolo de
interconexión de redes para las que se destina la petición ARP. Para IPv4, esto tiene el valor
0x0800. Los valores permitidos pType comparten un espacio de numeración con los de
EtherType.
 Longitud Hardware (HLEN): longitud (en octetos) de una dirección de hardware. En
Ethernet el tamaño de direcciones es de 6.
 Longitud del Protocolo (PLEN): longitud (en octetos) de direcciones utilizadas en el
protocolo de capa superior. El protocolo de capa superior especificado en PTYPE. IPv4 tamaño
de la dirección es de 4.
 Operación: especifica la operación que el emisor está realizando: 1 para la petición, 2 para
la respuesta.
 Dirección de hardware del remitente (SHA): dirección de medios de comunicación del
remitente.
 Remitente dirección de protocolo ('SPA): dirección de la interconexión del remitente.
 Dirección de hardware de destino (THA): dirección de los medios de comunicación del
receptor previsto. Este campo se ignora en las solicitudes.
 Dirección de protocolo target (TPA): dirección de la interconexión del receptor previsto.

Valores de los parámetros del protocolo ARP se han normalizado y se mantienen por la Autoridad
de Números Asignados de Internet (IANA).
Generación del paquete ARP

Si una aplicación desea enviar datos a una determinada dirección IP de destino, el mecanismo de
encaminamiento IP determina primero la dirección IP del siguiente salto del paquete (que puede ser
el propio host de destino o un “router”) y el dispositivo hardware al que se debería enviar.
Si se trata de una red 802.3./4/5, deberá consultarse al módulo ARP para mapear el par  <tipo de
protocolo, dirección de destino>  a una dirección física.

El módulo ARP intenta hallar la dirección en su caché. Si encuentra el par buscado, devuelve la
correspondiente dirección física de 48 bits al llamador (el manejador de dispositivo). Si no lo
encuentra, descarta el paquete (se asume que al ser un protocolo de alto nivel volverá a transmitirlo)
y genera un broadcast de red para una solicitud ARP.
Recepción del paquete ARP

Cuando un host recibe un paquete ARP (bien un broadcast o una respuesta punto a punto), el
dispositivo receptor le pasa el paquete al módulo ARP.
Ejemplo

Las computadoras Matterhorn y Washington están en una oficina, conectados entre sí en una red de
área local de la oficina mediante cables Ethernet y conmutadores de red,
sin gateways o routers intermedios.

Matterhorn quiere enviar un paquete a Washington. A través de otros medios, se determina que la
dirección IP de Washington es  192.168.0.55 , pero para enviar el mensaje también tiene que saber
la dirección MAC de Washington.

En primer lugar, Matterhorn utiliza una tabla caché ARP para buscar 192.168.0.55 en todos los
registros existentes la dirección MAC de Washington ( 00: eb: 24: B2: 05: ac ).

Si el caché no ha dado ningún resultado para 192.168.0.55, Matterhorn envía un mensaje ARP

broadcast (destino  FF: FF: FF: FF: FF: FF  de dirección MAC, que es aceptada por todos los
equipos), solicitando una respuesta para  192.168.0.55 .

Washington responde con su dirección MAC (y su IP). Washington puede insertar una entrada para
Matterhorn en su propia tabla ARP para su uso futuro.

La información de la respuesta se almacena en caché en la tabla ARP del Matterhorn y el mensaje

que se puede enviar.
 Capa de enrutamiento del protocolo TCP-IP

Protocolos ARP e ICMP

Protocolo ARP
El protocolo IP debe conocer la dirección fisica del computador destino para que la capa de enlace
pueda proceder con la transmisión de paquetes IP. Para ello el protocolo IP hace uso del protocolo
de resolución de direcciones "ARP Address Resolution Protocol". La función de este protocolo es
dar a conocer al protocolo IP la dirección física asociada a la dirección IP destino. Una vez que el
protocolo IP conoce la dirección física asociada a una dirección IP la capa de enlace puede
proceder con el envío del frame. En la siguiente figura 1.7 podemos apreciar la cabecera del
protocolo ARP:

16 bits Hardware type

16 bits Protocol type

8 bits Octet length of hardware address (n)

8 bits Octet length of protocol address (m)

16 bits Operation code (solicitus o respuesta)

noctets fuente hardware address

moctets fuente protocol address

noctets destino hardware address

moctets destino protocol address

Figura 1.7 Cabecera del protocolo ARP

La función de cada uno de los campos es la siguiente:

-. Hardware address space. Especifica el tipo de hardware. Ejemplo: Ethernet.
-. Protocol address space. Especifica el tipo de protocolo.
-. Hardware address length. Especifica la longitud(en bytes) de la dirección de hardware del
paquete. Para los standares IEEE 802.3 e IEEE 802.5 son 6 Bytes.
-. Protocol address length. Especifica la longitud en bytes de las direcciones del protocolo.
Para IP será de 4 bytes.
-. Operation code. Especifica si se trata de una solicitud (1) o una respuesta de una solicitud(2)
ARP.
-. Fuente/Destino hardware address. Contiene las direcciones físicas del computador destino y
fuente. En IEEE 802.3 son direcciones de 48 bits.
 -. Fuente/Destino protocol address. Contiene las direcciones del protocolo IP del computador
destino y fuente. En TCP/IP son direcciones IP de 32 bits.
Para el paquete de solicitud, la dirección de hardware del computador destino es el único campo
indefinido del paquete.
Es importante resaltar que el formato de una dirección física utilizada por los protocolos 802 es el
siguiente:
1Byte - 2Byte - 3Byte - 4Byte - 5Byte - 6Byte
Los bytes 1, 2 y 3 pertenecen al identificador OUI "Identificador único de la organizacion". Este
identificador es asignado por la IEEE a los fabricantes de hardware o software que soliciten un
OUI. Los bytes 4, 5 y 6 son asignados por el fabricante de hardware. La IEEE tiene la
responsabilidad de asignar un único OUI. Esto implica que por cada OUI asignado el fabricante
puede fabricar hasta 2^24 interfaces de red.
El formato de una dirección física 802 "MAC" fuente es distinta al formato de una dirección
destino. El formato del primer byte de una direccion MAC fuente es el siguiente:
+-+-+-+-+-+-+-+-+
|0 1 2 3 4 5 6 7|
+-+-+-+-+-+-+-+-+
-. Si Bit 1 es igual a 0 implica que la direccion MAC tiene sentido global.
-. Si Bit 1 es igual a 1 implica que la direccion MAC tiene sentido local.
En el diseño inicial de protocolo Ethernet no existía el concepto de sentido local. Todas las
direcciones en ese momento tenían sentido global únicamente. Cuando el protocolo Ethernet fue
standarizado por la IEEE y absorbido por el grupo 802 se tomó la decisión de incorporar el sentido
local en una dirección MAC. El sentido local de una dirección MAC permite al administrador de la
red asignar los bytes 4, 5 y 6. El sentido global de una dirección MAC es la dirección MAC
asignada por el fabricante y no puede ser manipulada por el administrador de la red.
El bit 0 es utilizado por los protocolos Token Ring y FDDI únicamente y su función es inidicar la
presencia del parámetro de enrutamiento RII en una trama Token Ring o FDDI. El valor de este bit
es igual a cero para las tramas Ethernet.
El formato del primer byte de una dirección MAC destino es la siguiente:
+-+-+-+-+-+-+-+-+
|0 1 2 3 4 5 6 7|
+-+-+-+-+-+-+-+-+
-. Si Bit 0 es igual a 0 implica que la dirección MAC destino es UNICAST.
-. Si Bit 0 es igual a 1 implica que la dirección MAC Destino es MULTICAST.
-. Si Bit 1 es igual a 0 implica que la dirección MAC tiene sentido global.
-. Si Bit 1 es igual a 1 implica que la dirección MAC tiene sentido local.
Es importante resaltar que la dirección MAC destino con valor FF-FF-FF-FF-FF-FF es una
dirección física del tipo MULTICAST donde muchos protocolos interpretan está dirección como
una dirección broadcast.

ARP Gratuito
Cada vez que un computador inicia la configuración de una interface de red que hace uso del
protocolo ARP, el protocolo ARP envía un paquete ARP con el fin de determinar si su dirección IP
o dirección física está siendo utilizada por otro computador y así ofrecer la oportunidad a los
demás computadores de actualizar su ARP Cache.
En un paquete ARP gratuito la dirección fisica destino es igual a la dirección física Fuente, y la
dirección IP destino es igual a la dirección IP fuente. Si algún computador de la red local detecta
un paquete ARP gratuito cuya dirección IP es la misma que la configurada en su interface de red el
mismo envía un paquete ARP indicando su dirección IP y dirección física al computador que
transmitió el ARP gratuito. De esta manera el computador que envió el ARP gratuito genera un
mensaje de advertencia indicando que dicha dirección IP está siendo utilizada por otro computador.

Protocolo de mensajes de control Internet "ICMP"

El Protocolo IP utiliza el protocolo de mensajes de control Internet "ICMP Internet Control
Message Protocol" para informar de los errores que pueden ocurrir durante el enrutamiento de
paquetes IP. El protoclo ICMP utiliza el soporte básico de IP como si se tratara de un protocolo de
nivel superior. Sin embargo, ICMP es realmente una parte integral del protocol IP, y debe ser
implementado por todo módulo IP.
Los mensajes ICMP son enviados en varias situaciones: por ejemplo, cuando un datagrama no
puede alcanzar su destino, cuando un enrutador no dispone de capacidad de almacenamiento
temporal para reenviar un paquete IP, y cuando el enrutador puede dirigir al computador para
enviar el tráfico por una ruta más corta. El propósito de estos mensajes de control no es hacer a IP
fiable, sino suministrar información sobre los problemas en el entorno de comunicación.
Los mensajes ICMP se envían usando la cabecera IP básica. El primer octeto de la parte de datos
del datagrama es el campo de tipo ICMP; el valor de este campo determina el formato del resto de
los datos. Los campos etiquetados como "no usado" están reservados para posteriores extensiones
y deben ser cero al ser enviados, y los receptores no deberán usar estos campos (excepto para
incluirlos en la suma de control).

0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tipo | Código | Suma de Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sin usar |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cabecera Internet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 1.8 Cabecera ICMP

A continuación se presenta un resumen de los tipos de mensajes.

0 Eco Respuesta ("Echo Reply")
 3 Destino Inaccesible ("Destination Unreachable")
4 Disminución del tráfico desde el origen ("Source Quench")
5 Redirección ("Redirect")
8 Eco ("Echo")
11 Tiempo Superado ("Time Exceeded")
12 Problema de Parámetros ("Parameter Problem")
13 Marca de Tiempo ("Timestamp")
14 Respuesta de Marca de Tiempo ("Timestamp Reply")
15 Solicitud de Información ("Information Request")
16 Respuesta de Información ("Information Reply")

IGMP es un protocolo estándar con número de STD 5 que también incluye IP e ICMP. Su status

es recomendado y se describe en el RFC 1112.

Nota: Se requieren IP e ICMP.

IGMP es vagamente análogo a ICMP y ocupa el mismo lugar en la pila de protocolos IP.

Mensajes IGMP

Los mensajes ICMP se envían en datagramas IP. La cabecera IP tendrá siempre un número de
protocolo de 2, indicando IGMP y un tipo de servicio de cero (rutina). El campo de datos IP
contendrá mensaje IGMP de 8 bytes con el formato mostrado en la figura que se muestra a
continuación.

donde:

Vers
Versión IP de 4 bits. Siempre 1.
Tipo
Especifica una recuperación o un informe.
1
Especifica una recuperación que envía un router multicast.
2
Especifica un informe que envía un host.
Checksum
 Una suma de comprobación de 16 bits calculada como para ICMP.
Dirección de clase D
Esta es cero para una petición y es una dirección de grupo multicast válida para un informe.

Operación IGMP

Los sistemas que participan en IGMP son de dos tipos: hosts y routers multicast.

Como se describió en Multicasting, con objeto de recibir datagramas multicast, un host debe unirse
a un grupo de host. Cuando un host es multi-homed, puede unirse a cualquier grupo en uno o más
de sus interfaces (subredes conectadas). Los mensajes multicast que el host recibe del mismo grupo
de dos subredes diferentes pueden ser diferentes. Por ejemplo 244.0.0.1 es el grupo para "todos los
hosts de esta subred", así que los mensajes recibidos en una subred siempre serán distintos para este
grupo de esos en otros. Pueden escucharse múltiples procesos en un único host para mensajes por
un grupo multicast de una subred. Si se da el caso, el host une el grupo sólo una vez y mantiene una
pista internamente de qué procesos están interesados en ese grupo.

Para unir un grupo, el host envía un informe por una interfaz. El informe se direcciona al grupo
multicast de interés. Los routers multicast de la misma subred reciben el informe y ponen una
bandera indicando que al menos un host de esa subred es un miembro de ese grupo. Ningún host
tiene que unir a todo el grupo de hosts (224.0.0.1); la agrupación es automática. Los routers
multicast tienen que escuchar todas las direcciones multicast (esto es, todos los grupos) para
detectar tales informes. Las alternativas podrían ser que routers multicast usaran broadcast para los
informes o para configurar hosts con direcciones unicast.

Los routers multicast regularmente, pero infrecuentemente (el RFC 1112 menciona intervalos de un
minuto), mandan una pregunta a las direcciones multicast de todos los hosts. Todos los host que
todavía deseen ser miembro de uno o más grupos responderán una vez para cada grupo de interés
(pero nunca a todo el grupo de hosts, dado que la agrupación es automática). Cada respuesta se
envía después de un retardo aleatorio para asegurar que IGMP no causa despliegue violento de
tráfico en la subred. Puesto que los routers no se preocupan de cómo muchos hosts son miembros de
un grupo y dado que todos los hosts que son miembros de ese grupo pueden oir la respuesta de los
otros, cualquier host que oiga otra demanda agrupación de un grupo cancelará cualquier respuesta
que se debe enviar para evitar malgastar recursos. Si ningún host demanda agrupación de un grupo
con un intervalo especifico, el router multicast decide que ningún host es un miembro del grupo.
Cuando un host o un router multicast recibe un datagrama multicast, su acción depende del valor
TTL y de la dirección IP de destino.

0
Un datagrama enviado con un TTL a cero es privado para el host origen.
1
Un datagrama con un TTL de uno alcanza a todos los hosts de la subred quesean miembros
del grupo. pero distintos datagramas unicast, no informan esto con un mensaje ICMP de
tiempo excedido. Expiration de un datagrama multicast es una ocurrencia normal.
2+
Todos los hosts que sean miembros del grupo y todos los routers multicast reciben el
datagrama. La acción de los routers depende de la dirección de grupo multicast.
224.0.0.0 - 224.0.0.255
Este rango se propone sólo para aplicaciones multicasting de un salto. Los routers multicast
no enviarán datagramas con dirección IP de destino en este rango.

Puede parecer en un principio como si un host no necesitara molestar informando a su

agrupación de un grupo en este rango ya que los routers multicast no mandarán datagramas
de otras subredes. Sin embargo, el informe también comunica a otros hosts de la subred que
el reporting host es un miembro del grupo. Al único grupo que nunca se le informa es el
224.0.0.1 porque todos los hosts saben que el grupo consiste en todos los hosts de esa
subred.

otro
Los datagramas con otros valores para la dirección de destino los envía el router multicast
como normales: decrementa el valor de TTL al menos un segundo como siempre.

Esto permite que un host localice el servidor más cercano que se escucha en una dirección
multicast usando lo que se llama un buscador en anillo expandido. El host manda un
datagrama con valor de TTL 1 (misma subred) y espera por respuesta. Si no se recibe nada,
intenta un valor de TTL de 2, luego de 3, y así sucesivamente. A la larga encontrará el
servidor más cercano,