Resumo

  • O manual vigente da AFRINIC separa os endereços de peering dos endereços de gestão, reserva um bloco dedicado aos IXP e prevê um /24 adjacente para permitir o crescimento até /23. Na AFRINIC-37, a equipe também relatou que alguns membros estavam trocando prefixos entre esses usos, em desacordo com a política.
  • Andrew Owens, da NAPafrica, descreveu a operação de Joanesburgo: dois blocos /23, uso próximo do limite de um /22 e a possível necessidade de mais dois /23 para chegar a um /21. Segundo ele, uma renumeração iniciada oito anos antes ainda não havia terminado. É o relato de um operador, não um levantamento da demanda africana nem um prazo típico de migração.
  • Antes de ampliar a reserva de /16 para /15, a comunidade precisa de dados sobre consumo e membros afetados, além de um desenho para crescimento contíguo e transição. Uma reserva maior pode aliviar a escassez; sozinha, ela não garante que o próximo bloco estará onde a rede precisa dele.

Análise

“Qual deve ser o tamanho?” é só uma das perguntas

A página atual do Consolidated Policy Manual identifica a versão 1.6 como vigente e informa que foi publicada em 17 de novembro de 2020. A seção 11 não trata apenas de um total. Ela diferencia a LAN de peering — o bloco contíguo pelo qual os participantes trocam tráfego na infraestrutura compartilhada — da rede de gestão, que dá suporte a monitoramento, estatísticas, correio e outros serviços. Endereços de gestão não devem vir do bloco de peering. O texto descreve um bloco dedicado e publicado para peering e reserva um /24 adjacente para que o IXP possa crescer até /23 sem receber outro bloco e renumerar a rede. A seção propõe um /16 para peering e outro /16 equivalente, separado, para gestão. O manual

Na reunião, um participante perguntou se o /16 reservado atendia à região inteira ou se um /15 seria mais apropriado. Um /15 contém o dobro de endereços de um /16, mas essa conta não revela quantas atribuições contíguas ainda podem ser feitas, a velocidade de consumo nem quais pedidos correm risco de ficar sem espaço. A equipe da AFRINIC disse que apresentaria estatísticas de consumo para embasar a deliberação. Outro participante pediu especificamente o número de membros afetados antes que a comunidade avaliasse a urgência. A ata da AFRINIC-37

Esse pedido de dados não é um detalhe burocrático. Uma reserva é, ao mesmo tempo, regra de estoque e regra de alocação. O tamanho informa quanto espaço fica separado. A unidade de atribuição e a adjacência determinam se o operador consegue expandir a rede. Os registros sobre quem recebeu recursos, para qual finalidade e com que margem constituem uma terceira questão. Decidir só sobre a primeira pode aumentar o estoque sem resolver o próximo degrau de crescimento.

Um uso fora da política ainda não explica o motivo

A ata relata que, segundo a equipe, membros trocavam prefixos de peering e gestão em desacordo com a política, e que o pessoal trabalhava com eles para alinhar o uso. Isso aponta para um problema de implementação. O documento não informa por que as trocas ocorreram, quantos membros envolveram nem se a causa principal estava no texto da regra, no cadastro, no processo administrativo ou na prática operacional. A distinção importa: alterar a política antes de identificar a falha pode mudar o texto sem mudar a conduta.

As seções 5.6.4 e 11 do manual se relacionam, mas não são a mesma regra. A primeira trata de atribuições IPv4 para infraestrutura crítica, em geral limitadas a /24, embora permita múltiplas atribuições em certas situações. A segunda diz respeito aos blocos reservados de peering e gestão dos IXP; o /24 adjacente busca permitir uma expansão até /23 sem renumeração. O manual também define um IXP como infraestrutura física de camada 2, operada por uma entidade, com pelo menos três provedores conectados e uma política aberta a novos participantes. Os critérios públicos da AFRINIC exigem comprovação de presença legal na África, ASNs e contatos de ao menos três pares ou MoUs assinados, evidência de que o intercâmbio é público e aberto e licença quando exigida no país de operação. Critérios da AFRINIC

Esses requisitos ajudam a avaliar quem pode pedir recursos, mas não medem a demanda futura nem asseguram que os blocos disponíveis acompanhem o plano de crescimento de cada intercâmbio. E o fato de que alguns prefixos são usados em categorias diferentes não mostra se a equipe dispõe dos registros e das ferramentas necessárias para perceber a situação antes que ela se torne uma dependência operacional.

O caso de Joanesburgo revela a geometria, não a demanda continental

Owens disse que a NAPafrica tinha dois blocos /23 em Joanesburgo, aproximava-se da utilização integral de um /22 e precisaria de mais dois /23 para atingir um /21 se necessitasse de espaço adicional. Ele também relatou que a renumeração daquela operação, iniciada oito anos antes, ainda não estava concluída. A ata traz uma experiência individual. Não oferece denominador, série comparável de outros IXP, estimativa independente de custo nem cronograma que explique a duração.

O exemplo ainda é útil porque expõe o que uma contagem total de endereços esconde. Quatro blocos /23 só formam um /21 quando são contíguos e estão alinhados no limite adequado. Um IXP que cresceu com atribuições separadas pode precisar de mais do que uma quantidade de endereços: precisa de uma sequência viável de blocos adjacentes, de uma forma de manter os serviços durante a mudança e de tempo para coordenar os participantes. O mecanismo do /24 adjacente no manual foi desenhado expressamente para o primeiro passo, até /23.

O relato de Owens levanta a pergunta seguinte: como um intercâmbio que conclui essa expansão inicial pode avançar além dela? Isso não prova que a política falhou; mostra por que o passo posterior merece projeto próprio.

A reunião também ouviu a sugestão de considerar a RFC 8950 em um ambiente dual stack. O padrão da IETF permite anunciar rotas IPv4 com next hop IPv6 quando os pares BGP negociam essa capacidade. É uma opção técnica, não prova de que todos os route servers e participantes estejam prontos nem de que uma LAN IPv4 reservada para peering seja dispensável. RFC 8950

Publique as evidências antes de escolher o número maior

A ata registra duas perguntas distintas: de quanto espaço a reserva regional precisa e como um intercâmbio pode crescer sem renumerações repetidas. A equipe acolheu o pedido de estatísticas de consumo e de membros afetados e se comprometeu a compartilhar os dados relevantes na lista de discussão. O material público examinado para este artigo não permite confirmar se nem quando esse compromisso foi cumprido. Esse é um limite da apuração, não prova de que os números nunca tenham sido publicados.

O próximo registro útil poderia apresentar as questões numa só página, sem misturá-las. Para os pools de peering e de gestão, deveria mostrar tamanho inicial, atribuições, devoluções e saldo restante; número de pedidos limitados; tamanhos e contiguidade dos blocos. Também deveria separar atribuições aprovadas de demanda projetada e explicar se “uso” significa recurso atribuído, implantado, anunciado no roteamento ou apenas mantido. Uma tabela com data e método informa mais do que um percentual isolado.

Ao inventário deve se somar um plano de transição: quais degraus de crescimento a regra permite, como se mantém a adjacência, o que fazer quando já não houver um bloco contíguo, quem coordena a renumeração e quais salvaguardas operacionais ou procedimentos de exceção existem. Não se trata de garantir um bloco adjacente para toda solicitação. Trata-se de tornar visível o custo de conservar endereços frente a uma migração evitável antes que cada caso chegue à equipe e ao operador.

Se os dados mostrarem que o /16 dedicado já não comporta novas atribuições /23, ampliar o pool pode ser justificável. Se a demanda estiver concentrada em poucos intercâmbios que precisam de degraus contíguos maiores, os mesmos dados podem apontar para outra geometria de reserva ou uma transição em etapas. Se o problema principal forem as trocas entre categorias, registros melhores e apoio à conformidade podem valer mais do que duplicar o estoque. A ata, por si só, não decide entre essas alternativas.

A ordem responsável é simples: publicar o que resta no pool, quais solicitações ele não consegue atender e que trajetórias de crescimento e migração a regra permite. Com isso, a comunidade poderá escolher entre mais IPv4, outro formato de reserva, melhores registros ou uma combinação. O caso da NAPafrica torna imaginável o custo de inverter a ordem. Só dados públicos mais amplos podem mostrar à AFRINIC com que frequência esse custo pode se repetir.

Fontes