Resumo

  • O arquivo assinado de todas as transferências da APNIC registra nove prefixos M&A em 1º de setembro de 2026, de ZTNET CO., LTD (KH) para ZT INFORMATION NETWORK CO., LIMITED (HK).
  • Os prefixos transferidos somam 57.088 endereços, ou 223 unidades /24. Um /24 e um /19, com 8.448 endereços, permanecem do lado anterior; as duas parcelas fecham exatamente o /16.
  • O arquivo delegado seguinte conserva 20071203 nas onze linhas. A especificação da APNIC determina que recursos vindos de outro registro mantenham a primeira data de atribuição ou alocação recebida do RIR original.
  • Uma análise reproduzível precisa guardar separadamente a data do evento de transferência e a data de origem, vinculadas a arquivos datados, hashes e ao cálculo dos prefixos.

O perímetro da mudança fecha sem suposições

O registro transfer-all de 1º de setembro contém nove linhas com os mesmos participantes e os mesmos campos temporais. A origem é ZTNET CO., LTD, economia KH; o destino é ZT INFORMATION NETWORK CO., LIMITED, economia HK. A delegação anterior aparece como 20071203, a transferência como 20260901 e o tipo como M&A.

A especificação prop-142 define transfer_date como a data em que a organização destinatária recebeu o recurso. Também limita o significado de M&A: transferência processada sob a política de fusão e aquisição. A sigla não demonstra preço, compra e venda, contraprestação, cláusulas contratuais ou a forma societária da operação. O dado público é a categoria de processamento do registro.

Os nove prefixos são 79.109.0.0/24, 79.109.2.0/23, 79.109.4.0/22, 79.109.8.0/21, 79.109.16.0/20, 79.109.32.0/19, 79.109.64.0/18, 79.109.128.0/18 e 79.109.192.0/19. Juntos, carregam 57.088 endereços, equivalentes a 223 blocos /24.

Sobram dois intervalos do antigo /16: 79.109.1.0/24 e 79.109.224.0/19. Eles contêm 8.448 endereços, ou 33 unidades /24. A reconciliação é completa: 57.088 mais 8.448 são 65.536; 223 mais 33 são 256 /24, exatamente um /16. O cálculo mostra a fronteira pública. Não revela por que esse resto permaneceu com a organização anterior.

A data de 2007 descreve a origem do recurso

No arquivo delegado de 1º de setembro, a faixa inteira ocupa uma linha: início 79.109.0.0, valor 65.536, KH, estado allocated, data 20071203 e identificador opaco A91100B2.

O arquivo de 2 de setembro, publicado em gzip, traz onze linhas após a descompressão. Nove usam HK e A91556B2, reproduzindo os prefixos transferidos. Duas usam KH e o identificador anterior, reproduzindo o /24 e o /19 retidos. Todas continuam com 20071203.

O README-EXTENDED da APNIC explica o campo. Quando uma alocação ou atribuição foi transferida de outro registro, a data representa a primeira atribuição ou alocação recebida do RIR original. O arquivo delegado preserva a cronologia de origem; não pretende funcionar como uma tabela de última mudança de titular.

O registro cumulativo contém ainda a etapa anterior do /16 completo: uma transferência da RIPE para ZTNET CO., LTD na APNIC em 9 de outubro de 2025, com 20071203 como data de delegação anterior e tipo Unused. A linha não narra o contexto comercial de 2007, mas mostra como a data original atravessa eventos posteriores.

Assim, 2026 responde quando o destinatário recebeu os nove prefixos no processo registrado pela APNIC. 2007 responde qual primeira data do RIR original acompanha o recurso na série delegada. Um único campo chamado allocation_date não consegue carregar os dois significados sem induzir alguém ao erro.

Mais linhas não significam mais endereços

O resumo IPv4 sobe de 61.519 para 61.542 linhas, aumento líquido de 23. A própria documentação diz que o resumo conta linhas de registro, não volume de recursos.

O caso analisado explica dez: havia uma linha e passam a existir onze. As outras treze pertencem a mudanças diferentes no arquivo diário. A quantidade do /16 também não cresceu. Transformar a diferença de 23 em “23 novas alocações IPv4” misturaria cardinalidade da representação, volume de endereços e causalidade.

Os dois arquivos delegados e o registro de transferências correspondem aos respectivos MD5 publicados. As três assinaturas OpenPGP destacadas também foram validadas sobre os bytes capturados com a chave exata que a APNIC publica, impressão digital 53484F6685D112B194DD25D9CB342F01D1524E14. Isso prova validade criptográfica sob essa chave publicada. Não prova certificação externa da identidade, confiança Web-of-Trust nem imutabilidade permanente das URLs históricas.

RDAP confirma cadastro, não operação de rede

O RDAP do /24 transferido mostra ZT1-HK, HK, com registro e última alteração em 1º de setembro. O /24 retido e o /19 retido aparecem como ZTNETCOLTD-KH, KH.

É uma checagem útil do estado cadastral público. Não demonstra anúncio BGP, autorização ROA, tráfego, serviço, uso físico, clientes ou propriedade beneficiária. A documentação delegada também avisa que o código de economia identifica a organização, não a localização atual do uso do endereço. Telefones, e-mails e endereços físicos do RDAP não são necessários para essa apuração.

O recibo mínimo mantém os dois relógios

Uma análise pode preservar a prova com poucos campos: nome e SHA-256 do registro de transferências; data, tipo e delegação anterior; conjunto de prefixos e total de endereços; arquivos delegados anterior e posterior com hashes; definição do campo de origem; parcela retida; horário da consulta RDAP; e referência a qualquer correção ou substituição.

Esse recibo é uma proposta editorial para quem consome os dados, não uma exigência atual da APNIC. Ele não pede contratos, chamados de associados, faturas, aprovadores internos ou dados privados. Serve para impedir que uma data de origem finja ser a data da operação — e que a data da operação apague a origem.

O que não pode ser concluído

As fontes não provam venda, preço, motivo, desenho societário, mudança de rotas, estado RPKI, serviço, dano ou irregularidade. Não explicam a retenção de 8.448 endereços. O identificador opaco agrupa um titular dentro da série e pode mudar entre versões. A transição explica dez das 23 linhas IPv4 líquidas, não o restante.

Fontes