Internet Group Management Protocol (IGMP)

O IGMP (Internet Group Management Protocol) é o protocolo da Camada de Rede (RFC 3376 para IGMPv3; RFC 2236 para IGMPv2; RFC 1112 para IGMPv1) responsável por gerenciar a participação de hosts em grupos de multicast em uma rede IPv4. Ele opera entre o host (membro de um grupo) e o roteador multicast adjacente (querier) — permitindo que o roteador saiba para quais grupos ele precisa encaminhar tráfego multicast nas suas interfaces.

Diferente do Unicast (um para um) ou do Broadcast (um para todos), o Multicast permite que um único emissor envie dados a um grupo específico de receptores interessados simultaneamente, economizando banda de forma dramática em cenários como IPTV, streaming ao vivo e replicação de dados financeiros.

1. Faixa de Endereços Multicast IPv4

Endereços multicast IPv4 pertencem à Classe D, definida pela RFC 1112:

Mapeamento para MAC

Endereços multicast IPv4 são mapeados para endereços MAC multicast da faixa 01:00:5E:xx:xx:xx, copiando os 23 bits menos significativos do IP (perdendo 9 bits — colisões possíveis). Ex.: 239.1.1.1 → 01:00:5E:01:01:01.

2. Funcionamento do IGMP

O IGMP opera entre um host (cliente) e um roteador multicast local (querier):

1. Join (Entrada): o host informa ao roteador que deseja receber tráfego de um grupo IP específico.
2. Membership Query: o roteador periodicamente pergunta à rede se ainda existem membros ativos em cada grupo.
3. Leave (Saída): o host avisa que não deseja mais receber os dados daquele grupo (em IGMPv2/v3).

Formato Geral das Mensagens IGMP

Todas as mensagens IGMP são encapsuladas em um datagrama IP com Protocol = 2 e TTL = 1 (não saem do enlace local):

+---------+---------+----------+--------+
| Type    | MaxResp | Checksum | Group  |
| (1 byte)| (1 byte)| (2 bytes)| (4B)   |
+---------+---------+----------+--------+
| [IGMPv3: campos adicionais]           |
+---------+---------+----------+--------+

Os 4 primeiros bytes são comuns a todas as versões. O Type determina o tipo de mensagem; o campo Group Address identifica o grupo multicast alvo.

3. Versões do Protocolo

IGMPv1 (RFC 1112, 1989)

• Duas mensagens: Membership Query (Type 0x11) e Membership Report (Type 0x12).
• Sem mensagem Leave explícita. O host simplesmente para de responder às queries. O roteador aguarda um Group Membership Interval (default 260 s) antes de considerar o grupo sem membros e parar de encaminhar tráfego.
• Querier único não-eleito: assume-se um roteador por segmento.
• Ineficiente para churn alto de grupos (IPTV onde usuários trocam de canal a todo momento).

IGMPv2 (RFC 2236, 1997) — Mais Comum

• Adiciona Leave Group (Type 0x17) e Group-Specific Query (Type 0x11 com Group Address preenchido).
• Permite saída rápida (fast leave): o roteador envia uma Group-Specific Query e, se não houver resposta em Last Member Query Interval (default 1 s), interrompe o encaminhamento — latência de saída de ~3 s em vez de ~260 s.
• Eleição de Querier: se múltiplos roteadores multicast coexistirem no segmento, o de menor IP vence e os outros ficam em modo passivo.

IGMPv3 (RFC 3376, 2002)

• Suporta Source-Specific Multicast (SSM) — o host escolhe de quais emissores específicos deseja receber tráfego para um grupo, na notação (S,G) em vez de (*,G).
• Reports e Queries contêm listas de {Source IP, Record Type} (ALLOW, BLOCK, IS_INCLUDE, IS_EXCLUDE, TO_INCLUDE, TO_EXCLUDE).
• Base para SSM (232.0.0.0/8), útil em IPTV premium e streaming de baixa latência (libera roteadores intermediários de manter estado de fonte).
• Mensagens: Membership Query (0x11), v3 Membership Report (0x22), Leave Group não existe mais como mensagem própria — foi substituída por BLOCK com lista vazia.

4. Tabela Comparativa das Versões

5. IGMP Snooping (Camada 2)

Embora o IGMP seja um protocolo de Camada 3, os switches de Camada 2 usam uma técnica chamada IGMP Snooping (IEEE 802.1ak, originalmente RFC 4541) para "espiar" as mensagens IGMP trocadas entre hosts e roteadores:

• Sem snooping: o switch trata o tráfego multicast como broadcast (porque o MAC é multicast e não está na tabela MAC) e inunda todas as portas — desperdício de banda, especialmente em IPTV com 100 Mbps por canal.
• Com snooping: o switch aprende quais portas têm membros de cada grupo (via Reports interceptados) e só replica os quadros multicast para essas portas — otimização dramática da rede local.

Snooping com Proxy

Em redes grandes (IPTV com dezenas de switches empilhados), o snooping puro sobrecarrega as portas de uplink com queries repetidas. O IGMP Proxy (RFC 4605) faz com que o switch atue como roteador multicast para os hosts downstream e como host para o roteador upstream — propaga apenas mudanças de estado relevantes.

6. IGMP e o Protocolo PIM

O IGMP não é um protocolo de roteamento multicast entre roteadores — ele é puramente local (host ↔ roteador adjacente). Para distribuir tráfego multicast entre roteadores, usa-se o PIM (Protocol Independent Multicast):

• PIM-SM (Sparse Mode, RFC 7761): modo mais comum, baseado em rendezvous point (RP) para source-to-group discovery. Usa árvore compartilhada (*,G) e depois muda para shortest-path tree (S,G) se a fonte for ativa.
• PIM-DM (Dense Mode, RFC 3973): flood-and-prune, ideal para grupos densos.
• PIM-SSM (Source-Specific, RFC 4607): usa IGMPv3 para construir diretamente árvores (S,G) — eficiente para IPTV controlada.
• Bidir-PIM (RFC 5015): otimizado para grupos com muitos emissores e receptores simultâneos (ex.: conferências multiplayer).

Integração IGMP + PIM

[Host A] --IGMPv3 Report--> [Switch L2 (snooping)]
                                   |
                                   v
[Roteador Multicast] <-- PIM-SM --> [Roteador upstream] --> [Source]

7. Aplicações Práticas do IGMP

Exemplo de Captura (Wireshark)

Frame 1: IGMP V3 Membership Report
  Type: 0x22 (v3 Membership Report)
  Group Records: 1
    Record Type: IS_EXCLUDE (2)
    Group: 239.255.255.250
    Sources: 0

Esse Report indica que o host deseja receber tráfego para 239.255.255.250 (SSDP) de qualquer origem — modo Exclude vazio equivale a "Include All Sources".

8. Diagnóstico e Comandos

Em roteadores Cisco

show ip igmp groups        # grupos ativos conhecidos
show ip igmp interface     # estado IGMP por interface
show ip igmp snooping      # switches: estado do snooping
ip igmp version 3          # configura versão por interface
ip igmp query-interval 60  # intervalo de queries
ip igmp last-member-query-interval 1000

Em Linux (host)

O Linux suporta IGMPv2/v3 nativamente (configurável via /proc/sys/net/ipv4/igmp_max_memberships, force_igmp_version). Para verificar grupos ativos:

cat /proc/net/igmp          # lista grupos multicast inscritos
netstat -g                   # alternativa legada
ip maddr show                # iproute2
tcpdump -ni eth0 'igmp'     # capturar tráfego IGMP

Teste de membresia

# Inserir-se em um grupo (pinga todos os membros)
ping -I eth0 239.1.1.1

# Em outro host:
sudo ip maddr add 239.1.1.1 dev eth0

9. IPv6: Substituição por MLD

10. Conclusão

O IGMP é um protocolo frequentemente subestimado, mas essencial para qualquer infraestrutura que envolva multicast IPv4 — IPTV, streaming financeiro, vídeo-colaboração, replicação de dados. Suas três versões (v1, v2, v3) evoluíram para responder às necessidades de latência de saída, suporte a múltiplos roteadores e seleção de fonte (SSM). A combinação IGMP + IGMP Snooping + PIM forma a base operacional do multicast moderno. Em IPv6, o MLD assume o papel equivalente, integrado ao ICMPv6 — mesmo conceito, nova embalagem.