Resumo

  • A APNIC-127 hoje estabelece /24 como delegação IPv4 mínima e /23 como total máximo vindo do 103/8. No critério para LIR inicial, exige necessidade imediata de um /24 e plano detalhado para usar ao menos um /23 em um ano.
  • A prop-169, pautada para discussão na APNIC 62, substituiria o /23 fixo pela “delegação IPv4 que está sendo avaliada”. Seu escopo publicado preserva needs assessment, conservação e limites atuais, não cria novo direito nem reabre questões mais amplas de delegação, transferência ou waiting list.
  • O novo texto deve separar prefixo pedido, prefixo usado como base da análise e prefixo delegado no fim. Um recibo protegido e versionado preserva as diferenças sem expor clientes, contratos ou arquitetura.

Um bit dobra a obrigação aparente

Na notação CIDR, um número menor depois da barra representa um bloco maior. Um /24 tem 256 endereços IPv4; um /23, 512. A diferença visual é curta. Para justificar demanda, ela duplica o denominador.

As políticas vigentes de recursos numéricos da APNIC reúnem os dois tamanhos. A seção 6.1 fixa o mínimo em /24 e o máximo acumulado do 103/8 em /23. A seção 6.2.1 pede que um LIR inicial tenha usado um /24 do upstream ou demonstre necessidade imediata de um, tenha cumprido a política sobre recursos anteriores e apresente plano detalhado para usar ao menos um /23 em um ano.

Quando o processo avalia um /23, a sequência pode fazer sentido. Se o pedido é um /24, o candidato precisa adivinhar por que planeja o dobro: crescimento futuro, condição autônoma, quantidade que receberá ou frase herdada. Uma política escassa não deveria depender dessa adivinhação.

O arquivo texto da APNIC-127 prende o retrato a uma identidade: versão 015, 20 de fevereiro de 2025, Active. Nele continuam o piso /24, o teto /23 e o plano anual em /23. A prop-169 ainda não alterou a norma operacional.

Uma proposta publicada pode estar correta e, mesmo assim, não reger nenhum formulário. Este artigo mantém separadas descoberta, decisão editorial e uso real.

A prop-169 acerta por não tentar fazer demais

A cópia pública da prop-169 na lista Policy SIG propõe retirar “ao menos um /23” e exigir plano para usar, em um ano, a delegação IPv4 em avaliação, sujeita aos limites aplicáveis da APNIC-127.

É um reparo bom. A variável acompanha o tamanho pertinente e não transforma o máximo em direito automático. O horizonte anual permanece.

O estado, porém, ainda é discussão futura. A versão 1 foi enviada à Policy SIG em 13 de julho de 2026 e está prevista para a Open Policy Meeting da APNIC 62. Reunião, consensus, período de comentários, ação do EC, edição e implementação são eventos distintos.

O texto arquivado mantém escopo deliberadamente estreito. Prevê revisar notas de avaliação, guias e materiais para candidatos que ainda mencionem o /23. Preserva needs assessment, conservação e limites atuais, não cria novo direito e não reabre os temas amplos de delegação, transferência ou waiting list.

Uma correção de redação ainda pode mudar o que a memória da decisão precisa guardar. O banco pode receber o mesmo tipo de prefixo, enquanto o denominador e as provas que levaram a ele existem apenas no processo de análise.

O rastreador neutro da NOG Alliance classifica a prop-169 como “To be discussed at APNIC 62”. É um estado futuro de reunião, não um resultado. O exemplo do /24 explica o defeito textual; as demais questões de política IPv4 ficam fora deste reparo.

Logo, a questão não é inventar uma reforma da oferta IPv4. É saber qual número ocupou o lugar da variável em cada caso.

O artigo definido não funciona como chave primária

“A delegação em avaliação” parece única. O fluxo pode conter três valores.

O prefixo solicitado nasce com o candidato. O prefixo avaliado é o denominador contra o qual o revisor testa o plano anual. O prefixo delegado é o bloco que APNIC ou NIR registra no resultado.

No caminho simples, todos podem ser /24. Três campos ainda servem: same-as-requested prova que a igualdade foi observada, não presumida depois.

Num caminho diferente, um pedido /23 poderia ser analisado como /24; o candidato poderia revisar a quantidade após perguntas; o saldo permitido por seus recursos poderia limitar a etapa final. As fontes não dizem que esses casos ocorrem hoje nem que são comuns. O teste é de expressividade: a regra consegue registrá-los sem reescrever a história?

O saldo de elegibilidade é outro número, mas é cálculo, não etapa. Ele subtrai holdings relevantes do teto aplicável. Pode limitar a oferta sem substituir o pedido ou a conclusão factual.

A mesma APNIC-127 usa gramática mais precisa para multihoming. A seção 6.2.2 pede uso imediato de 25% e uso anual de 50% dos endereços solicitados. É outra rota de elegibilidade; os percentuais não pertencem ao LIR inicial. O comparador mostra apenas que é possível ligar um teste à quantidade chamada “requested”.

A prop-169 não precisa importar percentuais. Precisa fixar origem, momento e histórico do valor avaliado.

Imediato, um ano e dois anos medem coisas diferentes

A seção 5.2.1 pede estimativas documentadas para agora, um ano e dois anos. Oferece 25% imediato e 50% em um ano como orientação geral. Quando o end user não consegue estimar o segundo ano com confiança, APNIC ou NIR pode delegar apenas o suficiente para o primeiro.

Horizonte, confiança e quantidade de decisão não devem virar uma variável só. Incerteza em dois anos não torna falsa a necessidade imediata. Delegar um ano de demanda não transforma uma projeção longa em infração.

Sem um instante de vinculação, “em avaliação” pode apontar para o pedido original, para a quantidade candidata depois de examinar o imediato ou para o bloco final após descontar incerteza de dois anos.

A seção 7 dá uma pista para delegações posteriores. Ela usa consumo passado, planos e compliance para atender até um ano de necessidade; se APNIC ou NIR escolher período menor, deve informar período e razões. Redução de variável exige valor e motivo. O prefixo merece o mesmo padrão.

Orientação pública e recibo protegido não competem

A página de IPv4 pós-exaustão explica que o total máximo do 103/8 é /23, que quem o atingiu não pode obter mais da APNIC e que membros abaixo dele podem pedir via MyAPNIC. Quem precisa de mais é encaminhado à transferência.

Essa orientação cumpre sua função pública. Não pretende mostrar o valor declarado, a base usada pelo analista ou por que um resultado ficou abaixo do pedido. O teto deve ser público; o raciocínio individual pode ser protegido.

Escassez torna os códigos de razão mais valiosos. Saldo insuficiente, rota de elegibilidade, prova insuficiente e revisão voluntária produzem o mesmo tamanho menor, mas não o mesmo precedente.

O teto caiu em 2019; o piso não

A linha do tempo da Internet da JPNIC registra o consensus sobre a prop-127 na APNIC 47 e sua posterior entrada em vigor; a JPNIC então encerrou alocações máximas /22 do inventário devolvido e alinhou esse canal a /23. A política ativa arquivada, e não essa cronologia, estabelece o mínimo atual /24.

Essa história comprova a faixa de dois tamanhos. Não explica a intenção de cada frase sobrevivente e não revela prática interna.

Depois, a prop-152 tentou reduzir o máximo a /24 quando acabasse o pool então disponível e reservar novas delegações a contas novas. Não alcançou consenso na APNIC 56 e foi abandonada em fevereiro de 2024. Não define o teto vigente.

Sua avaliação alertou contra escrever números vivos de inventário na política, porque eles mudam durante a discussão. A lição é estreita: uma variável dura mais que uma constante perecível. Mas só dura se sua fonte, versão e instante também forem identificados.

Dezesseis campos bastam

Não é necessário publicar projetos de rede. Evidência sensível fica protegida; a projeção pública contém esquema, reason codes limitados e agregados sem identidade.

O recibo mínimo tem dezesseis campos.

  1. Identidade e horário do pedido. ID estável, submissão e ligação explícita a revisão ou substituição.
  2. Identidade da regra. Versão da APNIC-127, seção, vigência e versão de implementação aplicada.
  3. Autoridade da decisão. APNIC ou NIR, papel do revisor e canal de delegação.
  4. Classe e rota de elegibilidade. LIR inicial, multihoming, infraestrutura crítica, IXP ou outra rota autorizada.
  5. Holdings relevantes. Recursos 103/8, demais espaços pertinentes e cálculo do saldo com escopo de cada entrada.
  6. Prefixo solicitado. Comprimento, número de endereços e revisão declarada como faces verificáveis de um valor.
  7. Base da necessidade imediata. Quantidade, função e referências protegidas, sem eleger um diagrama como arquitetura obrigatória.
  8. Denominador do plano anual. Prefixo e número exatos usados na comparação.
  9. Estado da previsão de dois anos. Fornecida, não estimável com confiança ou não aplicável, com fundamento.
  10. Custódia da evidência. IDs, hashes, acesso, retenção, privacidade e correções.
  11. Prefixo avaliado. Quantidade, instante em que vira denominador e regra que a autoriza.
  12. Código de diferença. Razão limitada e ligada ao fato; same-as-requested quando não houver diferença.
  13. Histórico de perguntas e respostas. Trocas materiais, horários e campo alterado.
  14. Prefixo delegado final. Quantidade, bloco, evento registral, tempo e diferença diante da avaliação.
  15. Resultado e correção. Granted, parcial, declined, withdrawn ou pending, com razões e revisão.
  16. Projeção agregada com privacidade. Caminhos pedido→avaliação→delegação, tempos, razões, retiradas e correções sem identificar ninguém.

Hash não publica contrato. O código remaining-entitlement-limit não revela cliente. Repetibilidade e confidencialidade podem coexistir.

A camada comum deve ser pequena e exata

A Minimum Initial Specification não pede vaguidão; pede que só os fatos necessários sejam comuns, e que eles sejam determinísticos. Decisões posteriores que não alteram unicidade ou interoperabilidade ficam com quem opera a rede.

ID, versão da regra, quantidade, autoridade e transição registral são fatos comuns. Clientes, fornecedores, roteadores, plano de endereçamento, tecnologia de transição e cronograma comercial são locais. Mesmo verificando necessidade antes de emitir espaço raro não delegado, a APNIC não precisa aprovar arquitetura.

O limite vincula os dois lados. O solicitante não substitui fatos por “crescimento futuro”. O revisor não transforma “detalhado” em autorização infinita para exigir dados privados. Cada pergunta e resultado volta à mesma regra e quantidade.

O Policy Development Process da APNIC se declara aberto, transparente e bottom-up, mantendo registro público de discussões e decisões. Isso exige identidade do objeto discutido. Consenso sobre uma variável não é consenso sobre qualquer valor que um processo privado possa inserir nela.

O texto da política pode ser curto. O registro da aplicação precisa ser legível.

Fontes

O que não foi demonstrado

Nenhuma fonte deste conjunto mostra pedido recusado, atrasado ou reduzido por causa do /23. Não há contagem por tamanho solicitado, avaliado e delegado, nem formulário interno. A conclusão é textual: falta um objeto de decisão público o bastante para ser entendido, não há prova de conduta indevida.

O resultado da APNIC 62 também é desconhecido. Outra versão pode prender melhor o valor, manter o texto ou alterar o escopo. O futuro não entra neste retrato como fato.