Resumo

  • draft-ietf-pim-ipv6-zeroconf-assignment-12 permite presumir que um endereço está disponível quando a aplicação não recebe indicação de uso. Essa evidência negativa vale apenas no alcance em que interfaces, enlaces e refletores mDNS puderam transportar uma contestação.
  • Persistir o ID do grupo reduz mudanças, mas não elimina sondagem, anúncio, consulta contínua ou defesa. Depois da reparação de uma partição, o perdedor precisa interromper o fluxo, selecionar outro ID e gravá-lo no lugar do anterior.

A revisão 12 foi publicada em 22 de setembro de 2026. No registro congelado do Datatracker, é um Internet-Draft ativo do grupo PIM, submetido ao IESG e em IETF Last Call até 6 de outubro, com Proposed Standard como status pretendido. Ainda não é RFC, ação IANA concluída, relatório de interoperabilidade nem prova de implantação.

O procedimento começa quando a aplicação prepara um fluxo multicast IPv6. Na primeira transmissão ou após uma colisão, escolhe aleatoriamente um ID na faixa proposta 0x90000000–0x9FFFFFFF. Com ele e o identificador da interface de origem, deriva um endereço multicast IPv6 de escopo de enlace e, em seguida, o endereço multicast Ethernet correspondente. No exemplo do texto, 9abc:def0 resulta em 33:33:9A:BC:DE:F0.

Os nibbles do endereço Ethernet são então invertidos sob .eth-addr.arpa. A aplicação monta um PTR único, faz a sondagem mDNS, anuncia o registro, responde a consultas, mantém uma consulta contínua e o defende. Trata-se de uma coordenação local sem alocador central.

O pressuposto decisivo aparece agora de forma explícita: disponibilidade implícita. Se a aplicação não recebe qualquer indício de que o endereço está em uso, presume que pode usá-lo. A própria revisão acrescenta que a filtragem de mDNS no host ou na rede impede a coordenação e pode causar colisões.

Silêncio, portanto, não é um fato absoluto. Ele significa que, durante determinada janela, nenhuma contradição atravessou as interfaces e os caminhos observados. Não informa sobre um transmissor escondido por ACL, refletor incompleto ou trecho desconectado. A probabilidade n / 2^28 indicada para a escolha aleatória não mede a cobertura daquela sondagem.

Uma partição de rede transforma essa distinção em operação. Um switch cai e separa dois lados. De um deles volta uma aplicação com o ID salvo. No outro, um novo fluxo escolhe o mesmo valor. Cada um sonda e não ouve o outro. Ambos anunciam uma alocação que parece correta localmente.

Quando o switch retorna, as duas afirmações passam a coexistir no mesmo domínio. O rascunho obriga a manter uma consulta PTR contínua justamente para encontrar a colisão depois da reparação. Detectado o conflito, aplicam-se as regras mDNS; o perdedor para o fluxo, volta à seleção, escolhe novo ID e sobrescreve o que estava salvo.

Não há promessa de descoberta imediata. O texto reconhece que mDNS foi desenhado para baixa largura de banda e pode levar tempo significativo para encontrar uma colisão após a reconexão. Não define um teto universal. O risco é maior onde fluxos podem surgir a qualquer momento.

Durante esse intervalo, os dois transmissores podem aparecer como saudáveis. O mesmo destino multicast Ethernet pode transportar destinos multicast IPv6 diferentes. Um painel que registra apenas “PTR anunciado” não consegue separar unicidade de isolamento.

A revisão permite um segundo detector no host. A pilha pode observar tráfego com o mesmo endereço Ethernet multicast de destino, mas outro destino IPv6. Nesse caso, a aplicação precisa parar e selecionar outro ID. Basta um lado mudar, embora os dois possam fazê-lo; o documento não coordena quem cede.

A infraestrutura possui ainda um veto. Quando um componente encontra uma colisão que não consegue resolver, publica um PTR cujo primeiro rótulo recebe -veto. A construção fica sempre mais tarde na ordenação lexicográfica da disputa mDNS e vence. O veto é publicado sem sondagem e obriga a aplicação a migrar.

Ele não é permanente. Quando o PTR causador some ou expira, o emissor consulta a rede por cinco segundos. Sem resposta, espera aleatoriamente de 20 a 120 milissegundos e envia um goodbye para invalidar o veto. Como a aplicação já gravou o ID substituto, persistir o veto seria desnecessário.

A autoridade desse registro pode ser abusada. Um agente hostil pode responder falsamente às sondagens e impedir a escolha, ou gerar vetos sucessivos contra endereços em uso. Filtrar mDNS neutraliza a prevenção de colisões. O projeto depende de participantes cooperativos; não fornece prova dessa cooperação.

O valor persistido tem limite semelhante. Reutilizá-lo ajuda uma rede inalterada a se estabilizar. Mas a revisão 12 declara que isso não permite pular nenhuma etapa anterior. É obrigatório sondar novamente, anunciar, consultar continuamente e defender. O armazenamento comprova uso anterior, não a continuidade do alcance de observação.

É uma aplicação direta da primazia do código em funcionamento. O recibo confiável é a sequência executada: seleção, derivação, sondagem, anúncio, monitoramento, defesa, parada e substituição. Um campo estável no banco pode coexistir com topologia, filtros e vizinhança completamente diferentes.

Também não se deve confundir alocação com descoberta. O PTR coordena o uso do endereço, mas o rascunho não define como o receptor descobre o endereço do fluxo. DNS-SD com _udp e TXT é apenas uma alternativa natural. Mesmo essa descoberta não prova ingresso do receptor, encaminhamento, entrega nem consumo pelo aplicativo.

Em múltiplas sub-redes, os PTRs precisam ser distribuídos, por exemplo com refletor mDNS, algo que o texto ainda chama de área de pesquisa. O fluxo encaminhado deve usar multicast IPv6 baseado em prefixo unicast, não o endereço de escopo de enlace. A dependência de hosts cooperativos torna a proposta inadequada para a Internet global.

A camada comum pode permanecer pequena: coordenar unicidade local enquanto os participantes se escutam. O livro operacional deve registrar ID, interface de origem, endereços derivados, época do armazenamento, interfaces e sub-redes sondadas, filtros, refletores, partição, conflito ou veto, parada, substituto e nova sondagem. Ingresso, encaminhamento, pacotes e resultado são recibos posteriores.

A pergunta de controle não é “o mDNS estava ligado?”. É “quem poderia ter respondido?”. Sem essa lista, disponível significa apenas que nenhuma parte visível ainda se opôs.

Fontes