Resumo

  • No IGMPv1 e v2, temporizadores aleatórios espalhavam as respostas e um relatório válido ouvido no enlace cancelava os relatórios pendentes do mesmo grupo. Em geral, o roteador recebia uma única prova de presença.
  • O Leave do v2 apenas iniciava uma verificação acelerada. O v3 deixou de suprimir relatórios entre hosts porque listas de origens, mudanças de estado e encaminhamento por porta deram conteúdo próprio a cada observação.

Um sim era suficiente, desde que a pergunta fosse pequena

O roteador multicast que serve uma rede local pode perguntar por todos os integrantes, mas não precisa fazê-lo para tomar a decisão básica de encaminhamento. Se pelo menos um host ainda quer o grupo G naquele enlace, o tráfego deve continuar chegando. Os nomes e a quantidade dos ouvintes não alteram esse primeiro veredito.

O RFC 1112, de agosto de 1989, transformou essa economia de informação na primeira versão amplamente implantada do IGMP. A associação era dinâmica e vinculada a uma interface. Um emissor podia mandar ao grupo sem pertencer a ele. O protocolo não criava cadastro de pessoas nem escolhia um representante fixo.

Ele fazia algo menor: dava ao roteador vizinho evidência de que havia alguém interessado. Como qualquer membro podia fornecer a mesma evidência, um relatório pôde valer pela multidão.

O primeiro relógio encerrava a conversa

A Query geral ia para 224.0.0.1 com TTL um. Cada host preparava um temporizador aleatório, entre zero e dez segundos, para cada grupo relevante na interface de chegada. Isso impedia que todas as máquinas respondessem no mesmo instante.

Quando o primeiro temporizador expirava, o host enviava um Membership Report ao endereço do próprio grupo, também restrito ao enlace. Os demais membros ouviam. Quem ainda aguardava parava seu relógio e não emitia relatório.

O algoritmo tinha duas defesas contra a implosão: dispersão temporal e cancelamento por escuta. Na situação comum, aparecia um pacote por grupo. O vencedor não ganhava autoridade; na próxima rodada, outro atraso poderia fazê-lo calar.

A expressão host suppression precisa desse contorno. O mecanismo não apagava a associação e não impedia um aplicativo de ouvir. Ele removia uma transmissão redundante durante uma consulta. Para o estado “G está presente nesta interface”, perder o segundo sim não mudava nada.

O grupo continuava vivo por renovação

Queries periódicas atualizavam o estado do roteador. Se ninguém respondesse durante o procedimento e o intervalo previstos, o grupo expirava no enlace e o roteador podia interromper o encaminhamento vindo de fora.

Essa condição não era um registro permanente. Era soft state, mantido por confirmação. Se um host travasse e não pudesse se despedir, o tempo retiraria sua marca. A ausência, porém, nunca era inferida do silêncio de um único membro; exigia o fracasso da pergunta dirigida ao conjunto.

Um novo integrante anunciava sua chegada imediatamente com relatório não solicitado e pequenas repetições aleatórias. Talvez fosse o primeiro ouvinte, e esperar a consulta periódica deixaria o fluxo bloqueado.

Havia uma arquitetura temporal deliberada: entrada rápida, presença comprimida, ausência cautelosa. Nenhuma dessas etapas certificava entrega ou direito de acesso.

Sair era pedir ao roteador que perguntasse de novo

O RFC 2236, publicado em novembro de 1997, trouxe o IGMPv2. O protocolo ganhou Max Response Time, eleição de querier, Group-Specific Query e a mensagem Leave Group, destinada a reduzir a latência de saída.

O host que se lembrava de ter sido o último a responder por G deveria mandar Leave a 224.0.0.2. Quem não fora o último podia ficar quieto, pois havia evidência recente de outro membro. Essa memória dizia “fui o último a falar”, não “sou o último existente”.

Por isso o querier não removia G ao receber a despedida. Ele enviava um número definido de consultas específicas, com janela curta. Qualquer ouvinte restante respondia e preservava o encaminhamento. Apenas a última janela vazia autorizava a conclusão de que o grupo não tinha mais membros locais.

Leave era um gatilho de auditoria. Não delegava a um host o poder de desligar os demais. Quando um participante v1 ainda estava presente, o roteador v2 ignorava Leaves para aquele grupo, pois a versão antiga não sabia cumprir a nova sequência de saída.

A origem passou a fazer parte do interesse

O IGMPv3 ampliou a pergunta. O RFC 3376 o especificou em 2002; o RFC 9776 tornou-se o texto atual em 2025, corrigindo e esclarecendo a norma anterior sem quebrar compatibilidade.

No modo INCLUDE, um sistema pede G somente de origens listadas. No modo EXCLUDE, aceita todas menos uma lista. Solicitações de sockets são agregadas em estado de interface. Os relatórios distinguem estado atual, mudança de modo, novas origens permitidas e origens que deixaram de ser desejadas.

Agora dois membros de G podem discordar sobre S. No Source-Specific Multicast descrito pelo RFC 4607, o canal é (S,G). Um relatório referente a S1 não substitui o interesse de outro host em S2.

O próprio racional do v3 registra a virada: a supressão de Membership Reports entre hosts foi removida. Roteadores podem querer acompanhar observações por host para fast leave ou contabilização; bridges com IGMP snooping tornam a supressão problemática; a máquina de estados do host fica mais simples; e um único pacote v3 agrega vários Group Records, economizando cabeçalhos sem reduzir estados distintos a um só.

Os atrasos aleatórios continuaram. Respostas a General Query ainda se espalham pelo Max Response Time e não podem sair todas imediatamente. O v3 abandonou o cancelamento causado pelo relatório alheio, não a disciplina contra rajadas.

O switch precisava saber em qual porta estava o ouvinte

Na LAN compartilhada imaginada pelo v1, os membros ouviam a mesma sala. Um switch que pratica IGMP snooping observa outra unidade: a porta.

Uma bridge convencional inunda multicast. O snooping examina IGMP e limita o fluxo às portas que parecem interessadas. O RFC 4541, informativo, recomenda encaminhar Membership Reports para portas de roteadores, e não para toda porta que contém hosts.

Se um relatório v1/v2 for ouvido em outro segmento, um host pode suprimir o seu. O roteador já conhece G no enlace, mas o switch talvez não aprenda a porta daquele host silencioso. O fluxo corre o risco de não alcançar quem o pediu.

O relatório não mudou; mudou a granularidade da decisão. Um testemunho bastava para G na LAN, mas não para G nesta porta. A economia no plano do roteador virava falta de informação no plano do switch.

O v3 passa a enviar relatórios a 224.0.0.22, endereço dos roteadores compatíveis, e permite vários registros no mesmo pacote. Continua buscando eficiência, porém desloca a compressão para o empacotamento, onde diferenças importantes podem sobreviver.

Compatibilidade também é perda temporária de vocabulário

Uma migração real mistura versões. Um host v3 que ouve uma Query antiga mantém um modo de compatibilidade por temporizador e responde no formato esperado. O roteador também registra membros antigos, porque seu aparecimento altera a interpretação segura de Leave e das listas de origem.

Assim, um único equipamento antigo pode reduzir por algum tempo a precisão do grupo inteiro. É um preço pela continuidade, não um detalhe de cabeçalho. Para SSM, o RFC 9776 determina que um host consciente de origem específica não permita que relatório v1/v2 suprima seu registro v3.

Uma tela que informa apenas “IGMP ligado” esconde a parte mais relevante: qual versão está decidindo o que o silêncio significa.

Interesse local não virou credencial

IGMP comunica vontade de receber multicast IPv4 a roteadores vizinhos. Não cria a árvore ampla, não autentica assinante, não concede permissão ao remetente e não confirma entrega.

O padrão atual afirma que não há confidencialidade. Um dispositivo no enlace pode observar grupos sensíveis. Relatórios forjados podem manter tráfego sem receptor real; mensagens antigas falsas podem prolongar compatibilidade e enfraquecer fast leave ou estado de origem. TTL um, Router Alert e verificações de endereço local restringem alguns caminhos, mas não equivalem a prova criptográfica.

O sinal é útil quando permanece estreito. Se virar identidade, cobrança ou autorização sem evidência adicional, a organização concede ao protocolo um mandato que ele nunca recebeu.

Fontes e limites

Os RFCs 1112 e 2236 definem temporizadores, supressão, Leave e consulta do último membro. O RFC 3376 guarda o racional histórico do v3; o RFC 9776 é a especificação vigente. O RFC 4541 trata de snooping e o RFC 4607 do modelo (S,G).

Essas fontes não comprovam implantação universal, conformidade de equipamentos ou identidade dos ouvintes. A tese sobre equivalência de evidências é uma inferência apoiada pelas máquinas de estado e pelos motivos declarados nos documentos.