Resumo

  • O aplicativo sorteia um group ID, deriva os destinos IPv6 e Ethernet e reivindica este último com um PTR mDNS sob .eth-addr.arpa.
  • Um equipamento de rede pode acrescentar -veto ao primeiro rótulo do aplicativo; o registro resultante sempre vence o desempate e obriga o emissor a parar e escolher novamente.
  • A revisão 12 ainda está em Last Call, as alocações IANA são apenas pedidos e o protocolo não autentica respostas de conflito ou veto.

O veto nasce sem probe e morre com um temporizador. Entre esses dois momentos, ele manda mais do que o aplicativo que iniciou o fluxo.

O draft-ietf-pim-ipv6-zeroconf-assignment-12 foi publicado em 22 de setembro de 2026 e está em IETF Last Call até 6 de outubro. Ele propõe uma forma de escolher endereços multicast IPv6 locais sem servidor central. Ainda não é RFC: a faixa 0x90000000-0x9FFFFFFF, eth-addr.arpa e o domínio especial correspondente continuam pendentes de IANA.

Um fluxo novo começa com um valor aleatório de 28 bits. Pela RFC 4489, o aplicativo combina esse valor com o identificador da interface de origem e forma o endereço IPv6 de escopo de enlace. A RFC 2464 gera o destino Ethernet. Endereços IPv6 distintos podem cair no mesmo sufixo Ethernet; por isso o objeto coordenado é o endereço que o hardware realmente filtra.

Cada nibble é invertido para formar um nome. No exemplo do draft, 33:33:9A:BC:DE:F0 vira 0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa. Um PTR nesse nome aponta para um identificador do aplicativo e o hostname.

O silêncio autoriza só dentro do alcance ouvido

O aplicativo faz probe conforme a RFC 6762. Se houver disputa simultânea, o perdedor volta ao sorteio. Sem conflito, anuncia o PTR, responde consultas e mantém uma consulta contínua. Só então pode transmitir.

A disponibilidade é implícita: não ouvir oposição significa prosseguir. Se o host ou a rede filtrar mDNS, porém, dois candidatos podem interpretar o mesmo silêncio como permissão. O probe comprova apenas o domínio de observação que recebeu e respondeu à mensagem.

O group ID fica em armazenamento persistente, mas não vira lease. Toda reinicialização repete construção, probe, anúncio e vigilância. A rede pode ter mudado durante a ausência. O número salvo é preferência, não propriedade.

Se surgir conflito, o perdedor para o stream e escolhe outro ID. A pilha do host também pode detectar dois destinos IPv6 mapeados ao mesmo Ethernet; alguma aplicação deve se mover, embora o draft não coordene qual host cede.

Cinco bytes dão precedência à infraestrutura

Ao detectar uma colisão irrecuperável em tabela ou filtro, um componente de rede publica um PTR de veto no mesmo owner name. Ele acrescenta -veto ao primeiro rótulo do PTRDNAME original. Como o comprimento do rótulo entra primeiro na comparação do RDATA, o rótulo maior fica lexicograficamente depois e sempre vence a regra mDNS.

O veto é publicado sem probe. O aplicativo para, escolhe outro ID e atualiza o valor persistente. Quando o PTR original expira ou envia goodbye, o titular do veto consulta por cinco segundos. Sem resposta, espera aleatoriamente entre 20 e 120 milissegundos e retira o veto com um goodbye.

É uma divisão explícita de autoridade: o aplicativo propõe; peers contestam; a infraestrutura anula; receptores ainda verificam o resultado.

Vencer não autentica a observação

O mecanismo pressupõe participantes cooperativos. Um agente hostil pode responder a todos os probes ou fabricar vetos, impedindo alocação e causando trocas repetidas. No sentido oposto, filtrar mDNS neutraliza a prevenção de colisões.

O protocolo não prova que o autor do veto é o switch que viu a colisão. Anúncio bem-sucedido também não autentica o produtor, autoriza o conteúdo, comprova adesão do receptor ou entrega ao aplicativo.

A trilha operacional precisa ligar identidade do stream, group ID, IID de origem, destinos IPv6 e Ethernet, owner e RDATA, probe, anúncio, geração da consulta, emissor do conflito, confirmação de parada, novo ID, migração dos receptores e retirada do registro antigo.

Após reparar uma partição, a consulta contínua ajuda, mas o mDNS de baixo volume pode demorar a perceber duplicatas. Detecção suplementar para redes que criam streams durante a separação ficou fora do escopo. Aleatoriedade reduz probabilidade; não restaura visibilidade nem reconcilia automaticamente histórias isoladas.

RFC 10019 definiu o problema sem entregar protocolo ou vencedor. A revisão 12 preenche esse espaço com uma reivindicação concreta e um veto observável. Pela primazia do código em funcionamento, cada recibo conserva seu limite: PTR é declaração, desempate é controle, switch é observação física e aplicativo é resultado. A contribuição não elimina o poder; torna uma parte dele registrável.

Fontes