Resumo

  • A comunicação de serviço da APNIC marca uma atualização do ambiente de rede GCP para 29 de setembro de 2026, das 10h às 12h em UTC+10. DASH, notification.apnic.net, REx e AS0 ROA Service são citados; não se espera indisponibilidade. Trata-se de previsão anterior à janela, não de registro de uma pane.
  • A política vigente, seção 5.1.4, manda publicar ROAs de origem AS0 para espaço sob administração da APNIC classificado como Available ou Reserved e retirar um prefixo do AS0 quando ele é delegado. A obrigação de retirar é atual; o texto não fixa um prazo de cinco minutos para 2026.
  • A descrição do lançamento em 2020 mencionava retirada e republicação em menos de cinco minutos em circunstâncias normais. É um parâmetro histórico de projeto, não uma medição desta manutenção nem um compromisso atual demonstrado.
  • O TAL separado para AS0 requer adesão consciente da rede. A APNIC recomenda uso consultivo ou de alerta, não bloqueio automático de rotas BGP. Um eventual efeito no encaminhamento depende também da validação e da decisão local do operador.

O que a lista não diz

A página de atualizações da APNIC registra a publicação do aviso em 24 de setembro. A intervenção descrita acontecerá cinco dias depois. O documento informa o horário, os nomes dos quatro serviços e a expectativa de que não parem. Não informa que eles compartilham o mesmo banco de dados ou que toda a cadeia AS0 roda em uma única máquina. A frase genérica de desculpas por inconvenientes de uma possível “outage”, no encerramento, tampouco prova que ocorreu uma interrupção; o trecho específico de descrição fala de uma manutenção futura sem parada esperada.

Há um precedente limitado. Um aviso de 31 de julho de 2025 apresenta os mesmos quatro nomes para uma atualização de Kubernetes, também sem parada prevista. A repetição confirma que a APNIC inclui AS0 em comunicações operacionais desse tipo. Não revela se a arquitetura continuou igual, se os caminhos de publicação são os mesmos ou se há uma dependência comum em 2026. Um inventário de produtos afetados não é um desenho de infraestrutura.

Justamente por isso, uma única luz verde de monitoramento seria pobre. É possível verificar se a interface de um serviço abre, se um endpoint responde e se o repositório AS0 entrega um objeto. Mas a entrega de um objeto responde apenas à disponibilidade daquele ponto de observação. Sua relação com o registro de delegações é outra pergunta. Um objeto antigo pode continuar sendo entregue com sucesso técnico. Essa possibilidade não é uma constatação de atraso da APNIC; é o motivo para definir qual evento permitiria testá-lo.

A mudança que importa ao AS0

Na RFC 6483, seção 4, um ROA de origem AS 0 comunica a desaprovação da origem de rotas para o prefixo que cobre e seus mais específicos. A APNIC aplica essa declaração ao espaço IPv4 e IPv6 que administra e ainda não delegou, tomando como referência as classes Available e Reserved do arquivo de estatísticas delegadas ampliado. Ao delegar um prefixo a um titular, deixa de ser correto incluí-lo na afirmação de espaço não delegado. A política atual determina sua remoção.

O relatório de implementação apresentado à APNIC 50 detalhava como o sistema de então atendia a essa necessidade. Atualizações de delegação seriam refletidas no RPKI comum e no AS0 em até cinco minutos; o componente ligado ao registro era interno, e a publicação ocorria em repositório na nuvem. O blog de lançamento descrevia a retirada e republicação em menos de cinco minutos sob condições normais. Esses documentos explicam por que o tempo é uma variável material. Não autorizam dizer que a meta, a implantação ou a latência observada sejam idênticas seis anos depois. A política vigente examinada aqui especifica a retirada, não um SLA temporal da janela futura.

Uma prova adequada precisa de uma delegação efetiva. Primeiro, quando o registro autoritativo aceitou a mudança? Segundo, em que versão a cobertura AS0 deixou de incluir o prefixo? Terceiro, quando o novo objeto assinado se tornou público? Quarto, quando um observador independente o recebeu? Por fim, se uma rede optou pelo TAL adicional, quando seu validador incorporou a nova versão? O relógio do validador não é o relógio do produtor. Uma atualização tardia no primeiro não demonstra, sozinha, que a APNIC publicou tarde. Da mesma forma, um carimbo interno de publicação não demonstra o que estava acessível em cada ponto externo.

O teste pode não ter amostra durante as duas horas. O aviso não diz que uma delegação ocorrerá no período. Se nenhuma ocorrer, duas leituras idênticas do AS0 podem estar corretas. Não seria lícito anunciar que o caminho de mudança cumpriu cinco minutos nem que o descumpriu. Uma página estática só se torna evidência de atualização quando existe uma transição que exigia outro conteúdo.

Quem escolhe usar a declaração

O AS0 da APNIC tem um Trust Anchor Locator próprio. Esse mecanismo impede que a declaração seja absorvida sem intenção junto à âncora RPKI habitual: o operador precisa adicioná-lo. A separação da confiança não garante separação física da infraestrutura, nem protege por si só contra uma eventual falha do ambiente de publicação. Em 2020, a APNIC mencionava um repositório na nuvem; em 2026, anuncia trabalho na rede GCP. É insuficiente para afirmar a topologia exata atual.

Se, em hipótese, um prefixo recém-delegado ainda estivesse coberto por um AS0 antigo, um validador que escolheu esse TAL poderia receber uma desaprovação assinada. O resultado de validação de determinada rota depende de todos os ROAs pertinentes e do comportamento do validador. Sua aceitação ou rejeição pela rede depende de política local. A APNIC alerta que erros de AS0 podem causar interrupção em algumas configurações e recomenda consulta ou alerta em lugar de filtragem automática. Não há aqui evidência de ROA desatualizado em 29 de setembro, rota inválida, bloqueio, perda de tráfego ou prejuízo a clientes.

Após o trabalho, uma prestação de contas limitada seria útil: disponibilidade observada de cada serviço; no AS0, existência ou não de uma delegação relevante, versões publicadas, momento em que puderam ser obtidas e objetivo atual de atualização, caso a APNIC tenha um. Se não houve evento, a resposta correta seria que o caminho de atualização não foi posto à prova. Isso é uma proposta editorial de documentação, não um relato de recursos já oferecidos pela APNIC nem prova de ausência de monitoramento interno.

Tudo pode transcorrer sem incidente. Ainda assim, o aviso expõe uma diferença real entre manter uma porta aberta e manter correta uma afirmação que muda com o registro. Para o AS0, as duas coisas precisam de evidências diferentes.

Fontes