Resumo

  • Pela frase anterior da seção 6.5.8.2, um site ocupava 100% dos /48 existentes em um /48 e ultrapassava o limiar de 75%, chegando literalmente ao próximo limite de nibble, /44. O exemplo, porém, só iniciava /44 em dois sites.
  • O texto recomendado estabelece primeiro o /48 e depois fecha as faixas 2–12 → /44, 13–192 → /40, 193–3.072 → /36 e 3.073–49.152 → /32. Ele ainda é Recommended Draft Policy, não política adotada ou implementada.
  • A correção útil não transforma /48 em regra universal de IPv6. Ela exige que texto normativo, tabela, teste de implementação e eventual correção produzam um só resultado versionado.

A conta simples que abria duas portas

Havia um único /48 dentro de um /48. Se a organização tinha um site, a ocupação usada pela regra era 1/1, ou 100%. A redação dizia que, acima de 75% dos /48 disponíveis, a organização se qualificava para o limite de nibble seguinte. O resultado literal era /44.

Logo abaixo, o primeiro exemplo de /44 começava em mais de um e até doze sites. Um único site permanecia, por implicação, em /48.

A revisão de fevereiro preservada pelo Mail Archive registra o conflito sem rodeios. A solução deixou de apresentar o /48 como exceção à fórmula: passou a dizer que tamanhos iniciais maiores seriam definidos pelo número de sites. Assim, a base /48 vem antes do cálculo multissite.

Durante o intervalo entre a regra defeituosa e a correção, o exemplo fez mais do que ensinar. Ele carregou um resultado normativo que a frase não entregava. A execução real precisou escolher qual objeto público valia.

O que a versão recomendada resolveu

A cópia independente da mensagem de junho contém o Recommended Draft completo. O texto de 20 de maio começa pela elegibilidade a uma alocação inicial /48 e reserva a fórmula para tamanhos maiores. Em seguida lista intervalos contíguos: 2 a 12 sites para /44, 13 a 192 para /40, 193 a 3.072 para /36, e 3.073 a 49.152 para /32.

Também troca assignment por allocation. A avaliação do Conselho Consultivo, reproduzida no arquivo, diz que a terminologia acompanha os procedimentos atuais, que a correção reflete a prática e que não há mudança operacional.

Essas últimas afirmações são evidência sobre a posição da instituição, não uma auditoria externa dos casos. O material analisado não contém amostra anonimizada, distribuição histórica de tamanhos nem testes da implementação. Não há base para afirmar que alguém recebeu o bloco errado, foi atrasado ou enfrentou tratamento desigual. Também não há base para dizer que um terceiro reproduziu a alegação de ausência de mudança.

O painel da NOG Alliance mantém ARIN-2025-7 como Recommended Draft Policy. O estágio mostra avanço, mas não adoção, vigência ou alteração de produção. A distinção impede que uma análise de proposta vire anúncio prematuro de direito.

/48 continua sendo escolha, não mandamento

Depois da correção, a tabela parece natural. RFC 6177 lembra que natural não significa obrigatório. O documento abandonou a recomendação uniforme de /48 para a maioria dos end sites. A variedade de redes exige nuance; o papel do IETF fica na orientação arquitetural e operacional; a escolha exata cabe à comunidade operacional.

O RFC ainda adverte contra transformar alguns comprimentos em classes rígidas. CIDR vale para todos os bits do prefixo.

Isso não invalida a base /48 proposta pela ARIN. Define seu caráter. A comunidade pode escolher um resultado previsível para uma classe de pedido, desde que a decisão esteja no texto público, tenha versão e possa ser revista. O número não chega do protocolo com autoridade própria.

O registro pode decidir a faixa aplicável a partir de fatos limitados. A organização continua responsável pela topologia, sub-redes, crescimento e serviços. Registrar o endereço não transfere o projeto da rede.

Quem encontra a ambiguidade paga por ela

A leitura da IPv4 Global sobre a ARIN 57 considera a emenda modesta e prevê menos idas e vindas para pequenos usuários finais. É expectativa de um analista comercial, não medição posterior. Ainda assim, a assimetria é real.

A equipe interna aprende uma interpretação uma vez e a reutiliza. Cada novo solicitante descobre essa interpretação do lado de fora. Uma empresa grande compra assessoria; uma instituição de um único site pode gastar o próprio tempo tentando saber se a frase, o exemplo ou a prática tem prioridade.

O custo não são quatro bits. É a falta de um objeto autoritativo que possa ser citado, testado e corrigido. Uma política clara elimina esse custo antes de uma conversa privada.

O espelho em tamanho reduzido

Lu Heng descreve em The Policy Mirror como o manual revela a ideia que a instituição faz de seu papel. Um registro limitado protege unicidade, exatidão, controle comprovável, segurança e continuidade. A fronteira se perde quando a prática administrativa vira autoridade não escrita sobre escolhas operacionais.

ARIN-2025-7 não precisa ser transformada em escândalo. Ela mostra, em escala pequena, um problema preciso: uma função legítima de dimensionamento tinha duas execuções públicas. O exemplo fornecia a resposta desejada, e a prática interna resolvia a diferença.

Trazer o resultado para a frase devolve a decisão ao processo público. O mesmo princípio limita a coleta: elegibilidade, número de sites comuns e justificativa de site excepcional podem ser necessários; o desenho completo da rede não é.

Uma tabela de paridade, não um dossiê

Para cada versão material, bastam oito campos públicos:

Campo Conteúdo mínimo
Identidade do texto Número, data, hash e estado no processo.
Classe de entrada Elegibilidade, sites comuns, necessidade excepcional ou correção.
Saída literal Prefixo obtido pela frase sem consultar a tabela.
Saída do exemplo Prefixo devolvido pelo exemplo publicado.
Saída prática Classe aplicada em teste ou agregado, sem expor solicitante.
Tratamento Sem diferença, texto corrigido, exemplo corrigido, prática alterada ou caso reaberto.
Motivo limitado Base de um site, limiar multissite ou necessidade especial.
Revisão Autoridade, data, versão substituta e via de contestação.

Este é um modelo proposto pelo artigo, não uma estrutura declarada pela ARIN. Ele verifica concordância sem publicar topologia.

Quatro vetores capturam a falha: 1 site retorna /48; 2 retornam /44; 12 continuam em /44; 13 passam a /40. Texto, exemplo e implementação devem ser executados com o mesmo hash. Casos de site extragrande ganham vetor próprio, para que a exceção não distorça a regra comum.

O mesmo mecanismo protege futuras limpezas. Uma troca de vocabulário deve conservar a saída. Uma mudança intencional de faixa deve aparecer como diferença aprovada.

Completar a correção com prova proporcional

O que se sabe é suficiente para reconhecer uma boa reparação. Havia contradição; o Recommended Draft a remove. Não há prova de dano, decisão errada ou mudança operacional. A uniformidade histórica tampouco foi reproduzida externamente.

O passo seguinte é levar hash e vetores à fase restante. Se o texto for adotado, publicar a versão efetiva junto dos resultados. Saídas iguais antes e depois transformam “sem mudança operacional” em observação.

O exemplo sustentou por algum tempo o /48 de um site. Agora a regra pode sustentar a si mesma.

Fontes

Limites da evidência

Verificado: conflito literal no caso de um site; faixas explícitas no texto recomendado; posição atribuída do Conselho sobre continuidade; estado recomendado no rastreador independente; rejeição de um /48 universal no RFC 6177.

Não estabelecido: adoção, implementação, caso real incoerente, atraso, dano, número de pedidos, distribuição histórica ou verificação independente de ausência de mudança operacional.