Resumo

  • O RFC 3019 expôs tabelas de interface e cache de MLD, mas também deu à gerência meios para habilitar o protocolo, criar ou destruir entradas, marcar o sistema local como membro, regular prazos e escolher uma interface proxy.
  • Por isso, uma linha, o endereço do último relator ou um SET aceito demonstravam apenas o estado representado pelo agente — não um ouvinte remoto atual, forwarding, entrega ou recepção pela aplicação.

Uma linha de cache costuma parecer evidência passiva. Algo aconteceu no protocolo; o equipamento apenas registrou.

No RFC 3019, essa leitura era incompleta. A mesma superfície que mostrava os grupos multicast de uma interface também aceitava comandos capazes de criar e remover as linhas. O gerente podia ainda dizer que o próprio sistema era membro do grupo.

O documento de janeiro de 2001 não montou um cartório de ouvintes. Montou uma interface de administração para MLD. Essa diferença explica tanto a utilidade quanto o limite probatório da MIB.

A interface reunia política, contagem e tempo

A MLD Interface Table tinha uma linha por interface com MLD habilitado. A MLD Cache Table tinha uma linha por par endereço multicast IPv6–interface para o qual o agente mantinha estado de participação. Hosts e routers podiam implementar ambas, com alguns objetos exclusivos de router.

Na interface apareciam intervalo de Query, atraso máximo de resposta, versão de MLD, endereço do Querier, total acumulado de joins, quantidade atual de grupos, Robustness Variable, intervalo da consulta ao último ouvinte, interface proxy e timers do Querier.

Esses campos não formavam um único snapshot. O contador de joins acumulava eventos. O gauge de grupos media linhas atuais. O expiry do Querier projetava uma mudança futura se nada novo chegasse. Parâmetros graváveis expressavam política.

Na cache, mldCacheSelf indicava a participação local. mldCacheLastReporter guardava a origem do último Report recebido. Uptime e expiry descreviam o ciclo da linha. mldCacheStatus permitia administrá-la.

Uma tela podia juntar tudo. Uma conclusão séria precisava preservar as diferenças.

O último relator podia já ter saído

mldCacheLastReporter não prometia mais do que o nome dizia: o endereço IPv6 de origem do último Membership Report visto para aquele grupo naquela interface. Sem Report recebido, o valor era 0::0.

MLD, segundo o RFC 2710, precisava descobrir se havia pelo menos um ouvinte no link. Hosts podiam cancelar respostas redundantes ao ouvir outro Report. Assim, o endereço visível não enumerava todos os participantes. Ele podia ser apenas a última voz que o mecanismo de supressão deixou passar.

Depois, esse host podia sair enquanto outro mantinha a participação. O sistema local também podia sustentar a linha. Nada em “last” significava “ainda presente”.

mldCacheExpiryTime informava o menor tempo restante antes do envelhecimento. Zero podia indicar que apenas mldCacheSelf mantinha a entrada e que a saída local a eliminaria imediatamente. A implementação ainda podia tratar seus próprios Reports como os demais, dispensando o zero nesse caso.

Logo, um endereço e um timer não bastavam para provar identidade, contagem ou presença atual. Muito menos provavam que packets chegaram a uma aplicação.

A gerência podia ser a origem da linha

O ponto decisivo era mldCacheStatus, declarado read-create. Um gerente podia criar uma entrada e apagar outra. A descrição do grupo básico de conformidade dizia de forma explícita que ele permitia a criação e a remoção de entradas da cache MLD.

mldCacheSelf também era read-create e tinha default true.

Uma linha podia então nascer de um Report remoto, de um join local, de um comando administrativo ou da sobrevivência temporária de um estado antigo. O valor atual não carregava necessariamente essa genealogia.

Se uma automação criasse uma entrada para uma medição e depois a lesse, a resposta confirmaria o estado guardado pelo agente. Não seria uma segunda testemunha de que um host remoto enviou Report. O autor e o verificador usaram o mesmo registro.

Esse é um problema de evidência, não uma acusação contra controle programável. A operação pode ser legítima; a atribuição posterior precisa conservar sua origem.

Destruir a linha de interface desabilitava MLD

mldInterfaceStatus exercia controle direto: ativar a linha habilitava MLD; destruí-la desabilitava o protocolo na interface.

Também eram ajustáveis o intervalo geral de Query, o atraso máximo, a robustez diante de perdas e o intervalo usado para verificar a saída do último membro. Um valor menor reduzia a leave latency, mas alterava a janela em que um Report poderia preservar o estado.

mldInterfaceProxyIfIndex podia transformar participação aprendida numa interface em Reports enviados por outra. Zero significava ausência de proxy; um valor não nulo ligava o estado local a uma ação upstream.

Um SET bem-sucedido podia, portanto, mudar descoberta, expiração e sinalização. Sua resposta não provava que a próxima Query foi transmitida, que o vizinho a recebeu, que o forwarding mudou ou que o receptor obteve dados úteis.

read-create não dizia o que todo produto fazia

A declaração máxima de acesso não obrigava toda implementação conforme a oferecer escrita.

Os statements de conformidade de host e router permitiam acesso mínimo read-only a mldInterfaceStatus. A escrita não era exigida. Era preciso separar capacidade descrita no módulo, capacidade implementada pelo agente, autorização da view VACM e efeito observado da operação.

RFC 2579 definiu a convenção RowStatus, mas uma linha active continuava sendo estado de gerência. Não provava persistência após reboot, sincronização com o motor MLD ou efeito no plano de dados.

Uma investigação deve perguntar quatro vezes: o padrão permite, o agente implementa, o principal pode, o sistema fez? A MIB responde apenas à primeira pergunta sem evidência adicional.

Ler revelava participantes; escrever podia negar serviço

O RFC 3019 reconheceu que objetos legíveis podiam expor informação sobre sessões multicast. mldCacheSelf e mldCacheLastReporter podiam ajudar a identificar máquinas associadas a um grupo. O texto chamou a leitura indevida de relativamente inócua — uma avaliação histórica, não uma regra universal de privacidade.

As escritas indevidas podiam causar denial of service. Habilitar SET sem proteção apropriada afetaria negativamente a operação da rede.

SNMPv1 sozinho era citado como ambiente inseguro. Mesmo proteger o transporte com IPsec não decidia quem tinha direito sobre cada objeto. Por isso, o RFC recomendou o User-based Security Model de RFC 2574 e o View-based Access Control Model de RFC 2575.

Canal protegido, principal autenticado, view autorizada, SET aceito, mudança protocolar, forwarding e recepção são fatos sucessivos. Nenhum herda automaticamente a força do anterior.

O sucessor adicionou distinções, não fatos de implantação

RFC 5519 tornou RFC 3019 obsoleto em 2009. Unificou IGMP e MLD numa MIB MGMD, separou tabelas de host e router e incorporou listas de fontes para IGMPv3 e MLDv2.

A evolução mostrou limites do modelo anterior. Não permite projetar as novas colunas sobre uma linha de 2001. Tampouco prova que algum equipamento implementou, migrou ou operou qualquer versão.

Os RFCs documentam uma linhagem de projeto. A execução continua sendo fato do sistema em produção.

As ideias de Lu Heng aparecem aqui como lentes declaradas. Running-Code Primacy separa módulo e agent em execução. Reality Layers separa linha, Report, política, forwarding e resultado. Minimum Initial Specification explica o valor de uma primeira superfície pequena sem preenchê-la retroativamente com a versão posterior.

Lu Heng não escreveu nem endossou RFC 3019.

A linha podia estar perfeitamente correta. Só não podia testemunhar, sozinha, um mundo maior que o estado do agente.

Sources