Resumo

  • O histórico do IETF registra draft-ietf-pim-gaap-23 em 3 de setembro de 2026 e coloca o documento em AD Followup; ele continua sendo um Internet-Draft Experimental, não um RFC aprovado.
  • A revisão obriga o uso de 239.0.0.0/10 em IPv4 e da faixa Experimental Use do RFC 10028 em IPv6, evitando que implementações independentes adotem espaços de cálculo incompatíveis.
  • O texto também reconhece que, durante uma partição, um lado pode escolher o candidato +1 e o outro o +2 para o mesmo nome. Como os endereços são diferentes, não existe colisão e o grupo pode continuar dividido após a recuperação da conectividade.
  • Ausência de colisão não é evidência positiva de que nome, endereço e participantes convergiram.
  • Um recibo local de convergência do nome de grupo preservaria a prova. Trata-se de uma proposta editorial de Daniel Kade, não de uma exigência do GAAP ou do IETF.

A revisão fecha uma divergência de configuração

O histórico no Datatracker data a revisão 23 do Group Address Allocation Protocol em 3 de setembro. Na mesma data, o subestado passou de Revised I-D Needed para AD Followup, e a análise da IANA retornou a Version Changed - Review Needed. São marcas de um processo em andamento. Não equivalem a aprovação pelo IESG nem à publicação de um RFC.

O registro de mudanças da revisão 23 informa que ela respondeu ao DISCUSS e aos comentários de Éric Vyncke. O fato editorial importante aparece na combinação de duas alterações: o texto remove uma fonte evitável de desacordo, mas também nomeia um desacordo de estado que ainda não consegue resolver.

O GAAP propõe que participantes multicast obtenham um endereço de grupo sem recorrer a um serviço central de alocação. A aplicação fornece um nome. O protocolo aplica SHA-256 a apenas quatro sequências permitidas: o nome original e o nome acrescido de +1, +2 ou +3. O nó envia um Claim para o primeiro candidato e aguarda cerca de um intervalo periódico, aproximadamente um minuto. Se não receber uma reivindicação na qual outro nome use o mesmo endereço de rede, a aplicação pode começar a utilizá-lo. Havendo colisão, passa ao candidato seguinte.

O desenho evita uma tabela global. Os nós não são obrigados a guardar os Claims alheios. Cada um acompanha as alocações e os temporizadores de suas aplicações locais; depois de uma reinicialização, reconstrói esse estado volátil por meio de novas mensagens. Essa economia é parte da proposta, mas exige que programas produzidos por equipes diferentes compartilhem os mesmos parâmetros básicos.

A comparação oficial entre as revisões 22 e 23 mostra a mudança. Antes, as faixas usadas pelas aplicações eram configuradas pelo operador. Agora o texto afirma que uma faixa configurável seria confiavelmente compatível apenas com outra configuração idêntica: o operador pode escolher os aplicativos de seu domínio, mas não controlar qual implementação independente do GAAP cada um incorporará.

Em IPv4, todas as implementações passam a usar 239.0.0.0/10. O projeto se apoia no RFC 2365, que relaciona blocos disponíveis para expansão do escopo Organization-Local, e no RFC 5771, que organiza as regras de endereçamento multicast IPv4. Em IPv6, a escolha é 0xFE000000–0xFEFFFFFF, a faixa de uso experimental que o RFC 10028 reserva para testar novos protocolos de alocação dinâmica. O GAAP não possui exclusividade sobre ela; outros experimentos podem usar o mesmo espaço.

Fixar essas faixas melhora a interoperabilidade. Duas implementações conformes não começarão o cálculo em universos diferentes. Entretanto, compartilhar o universo de candidatos não significa selecionar o mesmo candidato para um nome concreto.

Uma conexão restaurada pode guardar duas respostas

O mecanismo de reparo de partições trata o caso visível. Se os dois lados acabam usando o mesmo endereço para um nome de grupo, os Claims se encontram quando a conectividade retorna e o procedimento pode comparar o estado e resolver a situação.

A nova ressalva é silenciosa. Em um lado, uma colisão local sem relação com a partição pode empurrar o nome comum do candidato básico para +1. No outro, uma colisão distinta leva o mesmo nome a +2. As duas escolhas pertencem à lista fechada e podem estar corretas dentro de seus respectivos segmentos.

Depois da reconexão, um lado anuncia um endereço e o outro anuncia outro. Como não há “mesmo endereço, nomes diferentes”, o predicado de colisão do GAAP não dispara. A revisão 23 diz que o grupo continua dividido após a recuperação e chama sua resolução de questão aberta para o experimento.

Vyncke havia formulado justamente essa dúvida em seu comentário de ballot do IESG: se redes particionadas usarem +1 e +2, a condição será detectada e todos convergirão? A nova redação incorpora o limite. Não entrega ainda o mecanismo de convergência.

Com isso, “zero colisões” pode descrever dois resultados opostos. No primeiro, um nome leva a um endereço e os participantes se reencontram. No segundo, o mesmo nome leva a dois endereços e a população permanece separada, embora nenhum lado dispute o endereço do outro. A colisão é um evento negativo. Não observá-la não demonstra a propriedade positiva de rendezvous.

O RFC 10019, citado pelo GAAP como formulação do problema, exige que uma solução descentralizada detecte e resolva colisões surgidas durante uma partição temporária. Isso continua indispensável. A revisão 23 expõe uma condição vizinha, porém diferente: divergência no mapeamento do mesmo nome. “Colisão resolvida” e “nome convergente” precisam ser campos separados no resultado experimental.

O experimento deve registrar uma prova de reencontro

O projeto é explícito sobre sua maturidade. Ele diz que a alocação multicast descentralizada baseada em hash não foi implantada. O experimento deve descobrir se a detecção e a resolução de colisões bastam em redes práticas, quais taxas surgem em diferentes escalas e como cresce o tráfego periódico de Claims. O ciclo termina quando a experiência operacional sustentar uma proposta para Standards Track ou revelar limitações fundamentais que exijam revisão.

O novo caso precisa entrar nessa contabilidade. Somar colisões informa quantas vezes dois nomes chegaram ao mesmo endereço e quantas vezes o reparo reagiu. Não informa quantas vezes um nome ficou em dois endereços, pois esse estado não passa pelo contador. A observação precisa acompanhar o mapeamento e testar se os membros pretendidos voltaram a trocar tráfego em um só grupo.

É possível guardar a evidência localmente, sem criar um alocador central. Um recibo de convergência vincularia um identificador do nome protegido contra exposição desnecessária, as coortes dos dois lados, o índice do candidato, os endereços escolhidos, os instantes de separação e recuperação, o caminho de detecção, a alcançabilidade da aplicação e o resultado do reparo. O revisor escolheria entre três conclusões: convergência observada, divergência observada ou observação insuficiente.

Esse recibo é uma proposta analítica minha. Não integra o GAAP e não representa uma regra do IETF, da IANA ou do grupo PIM. Seu objetivo é impedir que a ausência de um sinal ruim seja transformada em evidência de uma qualidade que não foi medida.

Em Minimum Initial Specification, Localized Future Decision, Lu Heng separa a regra comum mínima da evolução local futura. A faixa fixa é essa regra pequena, necessária para que softwares independentes se encontrem. A forma de detectar, registrar e reparar a exceção pode evoluir durante o experimento, desde que o resultado continue comparável e auditável.

Running Code Primary fornece o critério de prova. Uma mudança no estado do documento, uma alocação da IANA ou o encerramento de um DISCUSS alteram o registro institucional. Não demonstram o que acontece quando duas implementações sofrem colisões locais diferentes. Essa afirmação exige um teste que crie a partição, produza +1 e +2, restaure o caminho e preserve o mapeamento realmente utilizado.

A revisão 23 melhora o desenho ao dizer onde a solução termina. Governar o experimento agora significa resistir à tentação de usar a faixa fixa como atalho para uma conclusão maior. Convergência precisa virar um resultado observável por direito próprio.

Fontes

  1. Registro do GAAP no Datatracker
  2. Histórico do documento GAAP
  3. GAAP, revisão 23
  4. GAAP, revisão 22
  5. Diferenças oficiais entre as revisões 22 e 23
  6. Ballot do IESG para o GAAP
  7. RFC 10019: problema da alocação multicast zeroconf
  8. RFC 10028: Group IDs multicast IPv6 dinâmicos
  9. RFC 2365: multicast IP com escopo administrativo
  10. RFC 5771: diretrizes da IANA para endereços multicast IPv4
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision
  12. Lu Heng — Running Code Primary