Resumen

  • IGMPv1 y v2 distribuían las respuestas con temporizadores aleatorios. Cuando un host oía un informe válido para su grupo, cancelaba el suyo: normalmente una sola voz demostraba que había al menos un miembro en el enlace.
  • El Leave de v2 solo aceleraba una comprobación con consultas específicas. V3 eliminó la supresión entre hosts porque el filtrado por origen, los cambios de estado y el aprendizaje por puerto hicieron que los informes ya no fueran equivalentes.

Contar a todos habría sido responder a la pregunta equivocada

Un router multicast conectado a una LAN no necesitaba un censo para decidir si debía enviar un grupo hacia ella. Le bastaba una condición: que quedara al menos un interesado. Pedir una respuesta simultánea a cada máquina habría consumido el enlace para producir muchas copias del mismo sí.

RFC 1112, de agosto de 1989, definió la primera versión de IGMP que llegó a desplegarse ampliamente. La pertenencia era dinámica y pertenecía a una interfaz. El emisor ni siquiera tenía que formar parte del grupo. Esa arquitectura no designaba un portavoz permanente ni entregaba al router una lista de usuarios.

En cambio, hizo que cualquiera de los miembros pudiera acreditar el único hecho requerido en ese momento: el grupo estaba presente en la red local.

Un sorteo decidió quién gastaba el paquete

El router enviaba una Query a la dirección de todos los hosts, 224.0.0.1, con TTL uno. Cada miembro preparaba un temporizador distinto para cada grupo de la interfaz receptora. El valor se elegía al azar entre cero y diez segundos.

El primer temporizador que vencía producía un Membership Report dirigido a la dirección multicast del propio grupo. Como el informe también llevaba TTL uno, los demás miembros del enlace podían oírlo. Quien aún esperaba detenía su temporizador y no enviaba nada.

El azar repartía las respuestas a lo largo del tiempo; la escucha mutua reducía su cantidad. En condiciones normales, el router recibía un informe por grupo, no uno por host. La máquina que ganaba no adquiría representación. En la siguiente consulta podía ganar otra.

Llamar a esta operación «supresión» puede hacerla parecer una pérdida. Para el estado grupo G presente en interfaz I, no lo era. Todos los informes positivos tenían el mismo efecto. El silencio de los demás conservaba toda la información necesaria y evitaba una implosión de acuses.

El olvido era parte del contrato

El router renovaba su conocimiento mediante Queries periódicas. Si un grupo dejaba de responder durante la secuencia y los intervalos establecidos, el estado caducaba. Así podía dejar de reenviar tráfico remoto hacia un enlace sin receptores.

No había un registro eterno que cada caída de host tuviera que corregir. La pertenencia se mantenía como estado blando: persistía mientras apareciera una prueba renovada. Una avería se transformaba en ausencia después del tiempo suficiente.

La entrada se anunciaba antes. Al unirse, un host emitía de inmediato un informe no solicitado y lo repetía tras breves demoras para cubrir pérdidas. Si era el primer miembro, esperar la siguiente consulta impediría que el tráfico llegase a la LAN.

El sistema trataba la asimetría con cuidado: una presencia puede demostrarse con un testigo; la ausencia de todos exige que no aparezca ninguno después de preguntar.

Leave no quiso decir «último»

RFC 2236 publicó IGMPv2 en noviembre de 1997. Añadió Max Response Time, elección del querier, consultas de grupo y un mensaje Leave Group para reducir el tiempo de salida.

El host que recordaba haber enviado el último informe del grupo debía avisar al marcharse. El que no había sido el último podía guardar silencio: otro miembro había respondido recientemente. Esta memoria no convertía al último informante en el último receptor real.

Por eso el querier no borraba el grupo al recibir Leave. Lanzaba varias Group-Specific Queries con un intervalo corto. Si quedaba alguien, su respuesta conservaba el reenvío. Solo al agotarse la última ventana sin informe se asumía que ya no había miembros locales.

El mensaje era un detonante, no un veredicto. Permitía investigar pronto sin otorgar a una máquina la potestad de cerrar el flujo de las demás. Cuando había miembros v1, el router v2 ignoraba Leave para ese grupo porque los hosts antiguos no podían participar en la nueva comprobación de salida.

De G a una preferencia sobre S

La tercera versión cambió el dato que viajaba. RFC 3376 la especificó en 2002; RFC 9776 sustituyó ese documento en 2025 con aclaraciones compatibles y es hoy el estándar vigente.

IGMPv3 permite que un sistema reciba el grupo solo desde determinados orígenes, modo INCLUDE, o desde todos salvo una lista, modo EXCLUDE. Las peticiones de los sockets se combinan en el estado de la interfaz. Los Group Records distinguen estado actual, cambios de modo, orígenes recién permitidos y orígenes que deben bloquearse.

Dos hosts interesados en G ya no expresan necesariamente el mismo hecho. Uno puede querer S1 y otro S2. El modelo de Source-Specific Multicast de RFC 4607 lo formula como un canal (S,G): ignorar S es ignorar parte de la solicitud.

La justificación de v3 reconoce la consecuencia. Un host deja de cancelar su informe v3 por haber oído el de otro. Los routers pueden querer observaciones por host para salidas rápidas o contabilidad; la supresión encaja mal con los bridges que practican IGMP snooping; eliminarla simplifica la máquina de estados del host; además, un paquete v3 puede agrupar varios registros y recuperar eficiencia sin fundir estados diferentes.

No desapareció el control de ráfagas. Las respuestas siguen repartiéndose dentro de Max Response Time y no deben salir inmediatamente tras una General Query. V3 conservó el tiempo aleatorio y retiró solo la regla que permitía a una respuesta silenciar otra.

El switch partió la sala compartida

La supresión inicial asumía que los miembros de una LAN podían oír el mismo informe. Un switch con IGMP snooping convierte esa sala en varios segmentos observados por puerto.

Un bridge ordinario inunda multicast. El switch snooping lee IGMP y aprende por dónde debe enviar cada grupo. RFC 4541, de carácter informativo, recomienda que los Membership Reports se encaminen hacia los puertos de routers y no hacia todos los puertos de hosts.

Si un informe v1/v2 llega a otro host, este puede suprimir el suyo. El router ya sabe que G existe en la LAN, pero el switch quizá nunca aprenda el puerto del host silencioso. El tráfico puede quedar podado justo donde había un receptor.

Ningún paquete cambió de significado en el cable; cambió la decisión que se tomaba con él. Para el router, un informe establecía G en el enlace. Para el switch, debía establecer G en este puerto. Los testigos intercambiables para el primer mapa no lo eran para el segundo.

Esta fricción ayuda a entender por qué v3 envía sus informes a 224.0.0.22 y deja que un mensaje contenga múltiples registros. Ahorrar sigue importando, pero la economía se obtiene empaquetando información, no borrando observaciones distintas.

Una versión antigua puede cambiar el presente

La compatibilidad permite desplegar v3 sin sustituir todos los hosts y routers a la vez. Un host mantiene temporizadores después de oír consultas viejas y, durante ese periodo, usa el formato correspondiente. El router también recuerda miembros antiguos porque Leave y las listas de orígenes dejan de tener la misma fuerza.

Por tanto, la versión forma parte de la evidencia. Un solo participante antiguo puede hacer que el grupo funcione temporalmente con un lenguaje menos preciso. En SSM, el estándar actual exige que un host consciente de (S,G) no permita que un informe v1 o v2 suprima su registro v3.

La compatibilidad conserva servicio, pero no es gratuita. El sistema menos expresivo puede definir lo que todos logran demostrar. Un tablero que muestra «IGMP activo» sin el modo de compatibilidad oculta esa pérdida.

Interés no es identidad ni permiso

IGMP informa a routers vecinos sobre recepción multicast IPv4. No construye el árbol entre redes, no autentica a un abonado, no autoriza al emisor y no promete que un datagrama llegue.

RFC 9776 advierte que el protocolo no ofrece confidencialidad. Cualquier equipo del enlace puede observar intereses potencialmente sensibles. Un informe falso puede mantener tráfico donde no hay receptores; un mensaje de versión antigua falsificado puede prolongar un modo que empeora la salida rápida o el filtrado por origen. TTL uno, Router Alert y las comprobaciones de dirección local acotan ciertos ataques, pero no son autenticación criptográfica.

La señal es valiosa porque tiene un objeto limitado. Convertirla en registro de personas, contrato de acceso o recibo de entrega sería ampliar su autoridad más allá de la información transportada.

Fuentes y límites

RFC 1112 define los temporizadores y la cancelación por informe oído. RFC 2236 define Leave y la comprobación del último miembro. RFC 3376 conserva el razonamiento histórico de v3 y RFC 9776 es su versión normativa actual. RFC 4541 documenta las consideraciones de snooping y RFC 4607 el canal de origen específico.

Estos textos no demuestran cuota de despliegue, conformidad de productos ni identidad humana. La interpretación sobre el valor cambiante de cada informe se apoya en las máquinas de estado y en los motivos que los propios estándares exponen.