Resumo

  • O método atual da Reg-RWS aceita um endereço IPv4 ou IPv6 para solicitar um relatório WhoWas, e o ReadMe prevê uma faixa IPv6; isso comprova sintaxe e estrutura, não o histórico efetivamente preenchido.
  • As sugestões ACSP 2025.4 e 2026.5 pediram histórico IPv6 e foram encerradas depois de encaminhadas à priorização interna, sem prazo ou versão pública que explique sua relação com a documentação vigente.
  • Um recibo de capacidade, usando um endereço IPv6 controlado, poderia registrar versão, aceitação, conclusão do ticket, horizonte de retenção, classes de objetos, lacunas e correções sem expor dados reais.

O operador não recebe o passado quando a primeira resposta chega. Recebe um ticket. Antes disso, a Reg-RWS verificou que o parâmetro parecia uma direção IPv6 aceitável e que o pedido podia entrar no fluxo do WhoWas. É um resultado legítimo, mas administrativo: a solicitação existe.

O histórico vem depois, num anexo. Entre uma coisa e outra cabem várias incertezas. O endereço pode nunca ter mudado de registro. O evento procurado pode ser anterior à retenção disponível. Uma antiga relação com organização ou POC pode não ter sido migrada. O relatório pode ter campos corretos e poucas linhas. A própria capacidade para IPv6 pode estar limitada. O ticket inicial não diferencia esses cenários.

A documentação pública atual da ARIN aproxima as etapas o suficiente para sugerir uma resposta rápida. A página de métodos da Reg-RWS diz que IPADDRESS deve ser um endereço IPv4 ou IPv6 e apresenta exemplos dos dois. O ReadMe do WhoWas define Net Range como uma faixa formada por endereços IPv4 ou IPv6. A página principal afirma que usuários autorizados obtêm informações históricas para um endereço IP ou ASN e que o relatório contém todo o histórico público do recurso.

Dois registros do ACSP, porém, mostram usuários pedindo exatamente o histórico de IPv6 em maio de 2025 e março de 2026. A ARIN considerou a adição útil, remeteu ambas as sugestões ao processo interno de priorização e planejamento e encerrou os registros públicos. Nenhuma delas aponta para uma versão entregue. As páginas atuais de planejamento e lançamentos também não fornecem esse elo.

Pode ser que a função tenha sido implantada depois da segunda resposta e que o manual já esteja correto. Pode ser que a interface e o esquema tenham sido ampliados antes da migração completa do arquivo. Pode haver cobertura parcial por período ou classe de registro. Esta apuração não teve acesso autorizado ao WhoWas e não executou uma consulta. Portanto, não declara que o serviço funciona nem que falha. A conclusão possível é menor: falta uma evidência pública comum para três capacidades diferentes.

O problema começou quando o presente deixou de bastar

Em 9 de maio de 2025, a sugestão 2025.4 descreveu um caso de operação. Um recurso IPv6 de uma entidade downstream já não estava corretamente alocado, e o solicitante queria consultar os detalhes anteriores do registro. Segundo ele, o WhoWas suportava apenas consultas de prefixos IPv4. O pedido de paridade não era uma comparação estética entre protocolos; era uma tentativa de reconstituir responsabilidade.

Um registro Whois ou RDAP atual responde quem aparece hoje. Ele não substitui uma sequência histórica quando um bloco mudou de organização, foi devolvido, revogado ou incorporado a outra faixa. Nessas situações, a data e a relação entre rede, organização e contato são o objeto da investigação.

Em 21 de maio, a ARIN concordou que acrescentar informações IPv6 seria útil. Incluiu a ideia na lista de melhorias sugeridas pendentes de priorização e a encaminhou para planejamento de implementação. O registro passou a “Closed”. Lido isoladamente, o status pode parecer conclusão técnica. Lido com a resposta, significa o fim daquela etapa pública: a sugestão entrou em outro processo. Não havia prazo proposto e a ARIN não criou um.

Em 31 de março de 2026, surgiu a sugestão 2026.5. O autor queria ver o histórico de faixas IPv6, inclusive para atender entidades cujo espaço havia sido revogado, com detalhes equivalentes aos relatórios de IPv4 e ASN. Dois dias depois, a ARIN vinculou o pedido ao de 2025 e disse que a repetição seria considerada na prioridade do esforço de desenvolvimento. A sugestão também seguiu para o processo interno e foi encerrada.

A repetição é um sinal claro de demanda, mas não é telemetria. O usuário pode desconhecer uma implantação discreta, estar sem o direito necessário ou usar “histórico IPv6” para descrever uma lacuna mais estreita. A resposta da ARIN indica que havia uma melhoria a avaliar, mas não especifica se ela era o parser, a geração do anexo, a migração de eventos ou a paridade de relações. Um identificador compartilhado resolveria essa ambiguidade melhor que qualquer leitura do status.

Passar pelo parser não é voltar no tempo

O método “Request WhoWas NET Report” documenta a entrada com clareza. É preciso fornecer um endereço individual. Um handle ou um prefixo CIDR não serve. Se a chamada tiver êxito, a API devolve um Ticket Payload. O usuário consulta o ticket posteriormente e baixa o relatório anexado.

Há duas transações aí. Na primeira, o serviço reconhece e agenda o pedido. Na segunda, o sistema histórico produz um documento. O sucesso da primeira não diz quantos eventos a segunda encontrou. Um arquivo vazio pode ser o resultado correto para uma direção sem mudanças. Também pode refletir uma fronteira temporal ou uma classe não migrada. A gramática só afirma que o pedido pode ser expresso.

O formato resolve outro problema. O ReadMe prevê uma Net Range em IPv4 ou IPv6 e ações de criação, modificação e remoção de registro. Essa estrutura é capaz de representar a trajetória pedida pelos usuários. Mas o desenho de uma tabela não é uma auditoria da população. Sistemas acrescentam campos antes de terminar uma migração; um mesmo layout pode servir a gerações com profundidades diferentes. O esquema prova capacidade de representação, não cobertura.

A promessa de dados aparece na apresentação do WhoWas. A ARIN explica que uma direção pode ter integrado várias redes ao longo do tempo, que essas redes podem ter sido emitidas para diferentes organizações e que cada organização tem POCs associados. É por isso que o relatório é maior e mais complexo que uma consulta atual. Mesmo assim, a página não apresenta uma matriz IPv4/IPv6, uma data inicial de retenção ou uma direção IPv6 de teste com eventos conhecidos.

Juntar as camadas cedo demais produz erros simétricos. Um exemplo 2001:DB8:: no manual não comprova toda a história. Uma sugestão de 2026 não comprova ausência da função. Uma é evidência de sintaxe; a outra é evidência de demanda e processo. A cobertura precisa de um teste cujo passado esperado seja conhecido.

“Vazio” precisa de mais de um significado

Um arquivo histórico deve explicar suas ausências. Não encontrar evento pode significar que nada mudou. Pode significar que o endereço consultado estava dentro de uma rede pai com limites antigos diferentes. Pode revelar um horizonte de retenção. Pode decorrer de uma associação de organização ou POC que não sobreviveu à migração. Pode ser um problema de autorização. Ou pode refletir uma capacidade IPv6 ainda incompleta.

Um time de abuso usa o passado para atribuir controle no momento de um incidente. Um consultor de transferência busca continuidade entre titulares. Uma operadora tenta explicar a um cliente por que a alocação desapareceu. Um advogado quer estabelecer o estado público do registro em determinada data. Para todos, “nenhum evento ocorreu” e “nenhum evento foi preservado” são respostas opostas.

A expressão “todo o histórico público” tem limites inevitáveis. Público exclui informação protegida. Histórico começa num ponto de retenção ou migração. Todo pode significar todos os eventos públicos retidos, não cada fato operacional do mundo real. Publicar esses limites não reduz o valor do WhoWas; evita que usuários deem ao silêncio um significado que ele não possui.

Sem classificação, cada organização cria regras informais. Analistas passam a acreditar que resultados anteriores a certo ano não servem, que determinadas relações IPv6 sempre faltam ou que todo anexo vazio deve gerar um chamado. Esse conhecimento não tem versão nem proveniência. Uma correção já feita pode continuar desacreditada, enquanto uma lacuna real permanece escondida dentro da reputação geral do produto.

O roteiro público não é o sistema em execução

A página Planned Functionality se apresenta como visão geral. Para 2026, lista alta disponibilidade, redução de dívida técnica, mudanças de políticas e taxas, melhorias nos sites, SOC 2 Type 2 e novos produtos de segurança de roteamento. O histórico IPv6 do WhoWas não aparece como item separado.

A página de releases registra o nascimento do WhoWas em março de 2012 e os relatórios por Reg-RWS em maio daquele ano. Nas entradas visíveis de 2025 e 2026, não há anúncio explícito da ampliação histórica de IPv6. Várias versões, contudo, agrupam pequenas melhorias e correções sem detalhá-las.

Essa ausência não prova que nada foi implantado. Um panorama não é a lista integral do backlog, e notas resumidas não são um diff. Uma alteração pode ter sido absorvida por uma entrega maior ou documentada entre datas. O máximo que essas páginas permitem dizer é que a ligação pública não está visível no conjunto analisado.

Se a implantação já ocorreu, um link das sugestões para o release e a revisão do manual encerraria a dúvida. Se a cobertura é parcial, uma tabela por período e classe de objeto seria mais honesta que um selo binário. Se o texto atual descreve apenas a interface pretendida, basta separar o que o endpoint aceita do que o arquivo retém. Nenhuma opção exige divulgar um registro real.

Uma prova sintética preserva a privacidade

O WhoWas exige aprovação e termos de uso porque o relatório histórico pode incluir organizações e contatos. Seria ruim pedir que clientes demonstrassem a capacidade publicando seus anexos. O caso de teste deveria pertencer à documentação: um endereço IPv6 controlado, com uma sequência pública preparada — criação de rede, mudança de organização, alteração de POC e remoção ou substituição do registro.

O recibo anotaria a versão, a data, o endereço usado, a aceitação do pedido, o fim do ticket, a existência do anexo, o evento mais antigo esperado e as classes observadas. Também listaria períodos ou relações não garantidos. Uma revisão posterior preservaria o resultado anterior e acrescentaria data e motivo da correção.

O cenário e o resultado esperado poderiam ter um hash de proveniência. Isso importa porque uma URL estável pode esconder diferentes gerações do parser, do banco histórico e do gerador de relatórios. Fixar a expectativa impede que o exemplo seja ajustado depois de ver a saída e apresentado como se sempre tivesse sido aquele.

O recibo não prometeria que todo endereço real tem passado rico. Não certificaria cada linha e não mudaria a restrição contra consultas em volume. Ele provaria apenas que, numa geração identificada, entrada IPv6, ticket, esquema e eventos conhecidos funcionaram de ponta a ponta. É justamente a afirmação que os documentos, separados, não conseguem sustentar.

O poder de testar acompanha o poder de restringir

A ARIN controla autorização, dados históricos, produção do relatório, documentação, releases e ACSP. O operador controla o endereço investigado e as evidências externas. Uma entidade antiga pode figurar no arquivo sem controlar retenção ou acesso. O público lê a descrição do serviço, mas não consegue reproduzir o resultado.

Essa assimetria é justificável e concentra a responsabilidade de provar a capacidade. A ARIN consegue usar um cenário sintético sem expor ninguém. Usuários isolados não conseguem oferecer a mesma segurança nem garantir que suas permissões e seus casos sejam comparáveis.

A lacuna provavelmente não pertence a uma única equipe. APIs têm donos de parâmetros; o arquivo tem responsáveis por migração; ACSP encerra a etapa comunitária; releases selecionam mudanças de maior visibilidade. Cada superfície pode estar correta em sua lógica local. A investigação atravessa todas elas e precisa saber se pertencem à mesma versão.

Um veredito limitado é o veredito correto

Não há base para afirmar que o WhoWas rejeita IPv6: o método atual aceita a entrada. Não há base para afirmar que a história está completa: nenhum relatório controlado foi examinado. As respostas do ACSP não prometeram data, portanto não se pode acusar atraso. E “Closed” não equivale a “Released”.

O que se sabe é suficiente para uma cobrança precisa. Usuários pediram história IPv6 duas vezes. A ARIN tratou o pedido como melhoria útil a priorizar. A documentação atual aceita IPv6 e prevê seu formato. As páginas públicas não mostram a versão ou o teste que reuniu essas afirmações.

Um recibo de capacidade encerraria o problema no tamanho certo. Se a função já está ativa, ele comprova a entrega. Se continua em desenvolvimento, define um critério observável sem inventar prazo. Se é parcial, transforma lacunas em informação de decisão. A porta continuará sendo uma porta; o recibo dirá o que o arquivo foi capaz de devolver depois que ela se abriu.

Fontes