Resumo

  • RFC 10019 estabelece requisitos para um futuro alocador multicast zeroconf descentralizado: o grupo precisa ser único tanto na camada de rede quanto na de enlace, sem depender de servidor central ou conectividade externa.
  • Endereços IP multicast diferentes podem virar o mesmo destino Ethernet, enquanto segmentos isolados podem escolher o mesmo grupo e só perceber a colisão ao se reconectarem.
  • A reconciliação termina depois que há sobrevivente e migrado definidos, receptores e equipamentos convergem, o grupo antigo fica silencioso e o aplicativo confirma o conteúdo correto.

Considere um anel de rede aberto durante uma intervenção. Em uma metade, um sensor escolhe um grupo para suas amostras. Na outra, um sistema de vídeo escolhe a mesma direção. Os dois alocadores escutam, não encontram contestação e registram sucesso. Quando o anel fecha, dois significados passam a ocupar o mesmo destino.

Há ainda uma colisão menos visível: os grupos IP podem ser diferentes e, mesmo assim, produzir o mesmo endereço MAC. O software de alocação continua mostrando duas linhas únicas. Uma interface ou um switch que filtra pelo destino de enlace vê uma única identidade.

RFC 10019, publicado em julho de 2026 como RFC Informational do IETF, descreve o problema e os requisitos de uma solução futura. Não entrega protocolo completo, formato de mensagem, algoritmo de desempate nem evidência de implantação. Sua disciplina consiste em não permitir que um sucesso local seja tratado como autoridade permanente.

A compressão que o alocador não pode ignorar

RFC 1112 usa os 23 bits inferiores de um endereço IPv4 multicast para formar o destino Ethernet. Como o espaço multicast IPv4 oferece 28 bits variáveis, 32 grupos IP diferentes podem compartilhar uma MAC. O mapeamento está correto; a distinção desaparece por projeto.

Para IPv6, RFC 2464 usa o prefixo 33:33 e os 32 bits inferiores do destino. O espaço de endereçamento é maior, mas a projeção para Ethernet ainda descarta bits. Dois grupos que diferem na parte alta ficam iguais para um filtro limitado à MAC.

É por isso que REQ-1 de RFC 10019 pede unicidade nas duas camadas. Consultar só a lista de grupos IP não basta. O candidato precisa ser avaliado pelo endereço completo e pelo destino de enlace derivado.

A consequência aparece na placa de rede. Ao entrar em um grupo, o host costuma programar um filtro multicast em hardware. Se outro grupo usa a mesma MAC, quadros indesejados atravessam o filtro e precisam ser descartados em software. RFC 1112 permite que uma implementação sem capacidade suficiente abra a recepção de multicast. O resultado funcional pode continuar correto, mas CPU, largura de banda e exposição mudam.

RFC 4541 documenta diferenças de switches com IGMP/MLD snooping. Equipamentos que mantêm estado por MAC podem encaminhar um fluxo de alta taxa a uma porta que pediu outro grupo IP. Tabelas físicas finitas ou com baldes de hash podem rejeitar entradas e recorrer a flooding. Um retorno allocated não contém nenhuma dessas observações.

A concessão pertence a uma época de observação

REQ-8 exige detectar e resolver colisões em IP e enlace. O caso explícito da partição temporária torna a topologia parte da prova. Durante o isolamento, ausência de contestação significa apenas que nenhum participante alcançável contestou.

“Mais antigo vence” não é uma verdade do RFC. Relógios podem divergir e cada lado podia ignorar o outro. O fluxo posterior pode ser mais crítico. Prioridade de aplicativo, identificador determinístico, antiguidade observável e intervenção humana são políticas possíveis, não mandatos de RFC 10019.

O registro de uma reivindicação deve guardar família, grupo completo, escopo, MAC derivada, fonte em SSM, implementação e revisão da regra, instância local, aplicativo ou fluxo, época, domínio de observação e hash da transcrição. Sem domínio e época, dois fatos locais serão apresentados falsamente como um caso simples de duplicação.

Restauração de enlace, ponte nova, fusão de VLAN, mudança de interface ou de descoberta juntam domínios. A verificação precisa buscar igualdade de IP e igualdade de MAC entre IPs diferentes. Silêncio logo após a união não encerra o caso: participantes podem dormir, o snooping pode não ter convergido e uma NIC pode já aceitar tráfego amplo.

A resolução nomeia sobrevivente e migrado. O migrado recebe um grupo distinto nas duas camadas. A descoberta publica a nova associação, ouvintes mudam, tabelas convergem, o aplicativo verifica o conteúdo, o emissor antigo para e o estado velho expira. Anunciar os dois grupos durante uma janela é um padrão útil, não um algoritmo normativo definido pelo documento.

Descentralização com política visível

O futuro mecanismo deve minimizar pontos únicos de falha, funcionar sem configuração de usuário, numa sub-rede sem Internet, e atender vários aplicativos no mesmo host. Também deve coexistir com atribuição manual ou dinâmica quando possível. Baixo overhead, descoberta, portabilidade e independência de topologia são desejáveis.

RFC 2730 define MADCAP como protocolo cliente/servidor de concessões. Ele pode servir a ambientes administrados, mas um servidor indispensável não resolve sozinho o alvo sem infraestrutura. Trocar esse servidor por um controlador local único apenas muda o lugar do ponto de falha.

Sem centro não significa sem decisão. A política local precisa dizer qual evidência confirma a colisão, quem escolhe o sobrevivente e como exceções críticas são aprovadas. Ela deve ser limitada e reproduzível.

RFC 10019 alerta que colisões acidentais ou maliciosas podem causar negação de serviço ou desvio de tráfego. Detecção e resolução são obrigatórias; prevenção de uso não autorizado é recomendada; o mecanismo fica fora do escopo. Uma mensagem de conflito, portanto, não é autêntica por definição. Vincular o reclamante, limitar deslocamentos e preservar a origem evita transformar reconciliação em ataque de renumeração.

Mais espaço não equivale a mais evidência

O documento recomenda IPv6 para novos projetos dinâmicos. Se IPv4 for necessário, aconselha escolher com cuidado dentro do bloco de escopo administrativo tratado por RFC 5771. Quando mecanismos não conseguem coexistir, restringir um deles ou configurar manualmente pode ser a decisão correta.

RFC 4291 define formato e escopo multicast IPv6. Escopo limita propagação; não é concessão nem autorização. RFC 3307 organizou IDs de grupos, e RFC 10028 separou faixas dinâmicas de MADCAP, SSM por host, uso privado, experimental e Solicited-Node. A nova divisão reduz uma classe de coexistência, mas não detecta redes reunidas nem migra fluxos vivos.

SSM identifica o canal por fonte e grupo. RFC 8815 explica sua preferência operacional e os usos limitados de ASM. Preservar a fonte melhora a atribuição, mas não altera o mapeamento MAC nem prova que o hardware filtrou pela fonte.

RFC 10019 deixa o uso do grupo após a alocação fora de escopo. Um relatório IGMP/MLD mostra interesse observado, não autorização ou entrega. Uma entrada de switch mostra estado programado. Um contador mostra volume. A cadeia precisa ligar intenção, domínio, unicidade IP, unicidade de enlace, associação do receptor, estado de NIC e switch, impressão dos pacotes, resultado no aplicativo e retirada da época antiga.

A primazia do código em execução de Heng Lu faz as observações reais limitarem a afirmação do livro de endereços, sem dispensar o livro como proveniência. A especificação inicial mínima mantém requisitos comuns finos e deixa desempate e migração para decisão local. As camadas de realidade separam a unicidade formal da entrega decidida por filtros e tabelas finitos.