Résumé

  • Le journal signé de tous les transferts d’APNIC contient neuf lignes M&A datées du 1er septembre 2026, de ZTNET CO., LTD (KH) vers ZT INFORMATION NETWORK CO., LIMITED (HK).
  • Les neuf préfixes représentent 57 088 adresses. Les 8 448 adresses restantes, un /24 et un /19, demeurent du côté du détenteur précédent : les deux ensembles recomposent exactement le /16.
  • Le fichier délégué suivant attribue 20071203 aux onze lignes résultantes. La documentation APNIC précise que, pour une ressource venue d’un autre registre, ce champ conserve la première date d’attribution ou d’allocation transmise par le RIR d’origine.
  • Une chronologie défendable doit donc nommer séparément la date de l’événement et la date d’origine, puis conserver les fichiers, leurs empreintes et l’arithmétique des préfixes.

Neuf lignes qui ne racontent pas un contrat

Le fichier cumulatif du 1er septembre 2026 fournit une observation étroite mais solide. Neuf préfixes IPv4 ont la même organisation source, la même organisation destinataire, la même date antérieure 20071203, la même date de transfert 20260901 et le même type M&A.

La spécification prop-142 définit la date de transfert comme le jour où l’organisation destinataire reçoit la ressource. Elle définit M&A comme un transfert traité selon la politique de fusion et acquisition. Cette étiquette n’ouvre pas le dossier privé : elle ne révèle ni prix, ni contrepartie, ni contrat, ni montage juridique. Elle atteste une catégorie de traitement du registre.

Les préfixes sont 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 et 79.109.192.0/19. Leur somme atteint 57 088 adresses, soit 223 blocs équivalents à un /24.

Deux intervalles du /16 n’apparaissent pas dans cet ensemble : 79.109.1.0/24 et 79.109.224.0/19. Ils totalisent 8 448 adresses, soit 33 unités /24. Le contrôle ferme le contour sans reste : 223 plus 33 font 256 unités /24, et 57 088 plus 8 448 font 65 536 adresses. Rien dans cette arithmétique n’explique pourquoi ce reliquat a été conservé ; elle établit seulement où se trouve la frontière publique du changement.

Le lendemain ne « remet » pas la date à 2026

Dans le fichier délégué signé du 1er septembre, l’ensemble apparaît sur une seule ligne : départ 79.109.0.0, valeur 65 536, économie KH, statut allocated, date 20071203, identifiant opaque A91100B2.

Le fichier du 2 septembre, publié sous forme compressée, remplace cette ligne par onze. Neuf portent HK et l’identifiant A91556B2 ; deux portent KH et l’identifiant précédent. La découpe est identique à celle calculée à partir du journal de transfert. Pourtant, la date des onze lignes reste 20071203.

Ce comportement suit la notice README-EXTENDED d’APNIC. Pour une allocation ou une attribution transférée depuis un autre registre, le champ date représente la première attribution ou allocation reçue du RIR d’origine. Le fichier délégué ne prétend donc pas dater le dernier changement de détenteur. Il maintient une continuité d’origine.

Le journal cumulatif contient d’ailleurs une étape antérieure pour le /16 entier : un transfert de RIPE vers ZTNET CO., LTD dans APNIC le 9 octobre 2025, avec 20071203 comme date de délégation précédente. Cette ligne ne permet pas de reconstituer l’histoire commerciale depuis 2007. Elle montre pourquoi la date d’origine peut traverser plusieurs opérations plus récentes.

Le 1er septembre 2026 et le 3 décembre 2007 ne se disputent donc pas la même colonne conceptuelle. La première date répond à « quand ce destinataire a-t-il reçu ces préfixes dans le journal APNIC ? ». La seconde répond à « quelle première date d’allocation ou d’attribution le relevé délégué conserve-t-il depuis le RIR d’origine ? ».

Une croissance de lignes n’est pas une croissance d’adresses

Le résumé IPv4 du fichier délégué passe de 61 519 à 61 542 lignes, soit plus 23. La notice APNIC avertit que ces nombres comptent des lignes et non une quantité de ressources.

La partition étudiée explique dix lignes nettes : une ligne avant, onze après. Elle ne suffit pas à expliquer les treize autres. Elle n’ajoute pas non plus une seule adresse au /16, puisque l’ensemble reste égal à 65 536. Lire le résumé comme « 23 allocations IPv4 supplémentaires » confondrait la fragmentation de la représentation, la quantité d’adresses et les autres opérations quotidiennes.

Les trois charges utiles — les deux fichiers délégués et le journal de transfert — correspondent à leurs fichiers MD5 publiés. Leurs signatures OpenPGP détachées ont également été validées sur les octets capturés avec la clé exacte publiée par APNIC, empreinte 53484F6685D112B194DD25D9CB342F01D1524E14. Cette vérification établit la validité cryptographique sous cette clé publiée. Elle n’établit ni certification d’identité par un tiers, ni confiance Web-of-Trust, ni immutabilité éternelle des URL d’archive.

RDAP confirme un état d’enregistrement, pas un réseau

Le résultat RDAP pour 79.109.0.0/24 renvoie ZT1-HK, pays HK, avec des événements d’enregistrement et de modification le 1er septembre. Les résultats pour le /24 conservé et le /19 conservé restent associés à ZTNETCOLTD-KH et KH.

C’est un contrôle cohérent de l’état public du registre. Ce n’est pas une preuve de routage BGP, d’autorisation RPKI, de trafic, de clients, d’exploitation physique ou de propriété bénéficiaire. APNIC précise aussi que le code d’économie concerne l’organisation et ne localise pas de manière autoritaire l’utilisation courante des adresses. Les coordonnées publiées par RDAP n’ont aucune utilité pour cette analyse et ne doivent pas être reproduites.

Le reçu à deux horloges

Une étude de transfert devrait conserver un petit objet de preuve : nom et SHA-256 du journal, date et type du transfert, date de délégation antérieure, liste exacte des préfixes et total d’adresses ; noms et empreintes des fichiers délégués avant et après ; définition du champ de date d’origine ; reliquat réconcilié ; heure de l’observation RDAP ; lien vers toute correction ou version de remplacement.

Ce reçu est une proposition éditoriale, pas une obligation existante d’APNIC. Il ne demande ni contrats, ni tickets membres, ni factures, ni identité d’opérateur interne. Il évite seulement qu’une date d’origine soit utilisée comme date de transaction ou qu’une date de transaction efface l’origine de la ressource.

Ce que les sources ne démontrent pas

Les fichiers ne démontrent pas une vente, un prix, un motif, un montage d’entreprise, une modification de routes, un état ROA, un incident ou une faute. Ils ne donnent pas la raison du maintien de 8 448 adresses. L’identifiant opaque groupe un détenteur dans la série mais n’est ni permanent ni une preuve de propriété. Cette transition explique dix des 23 lignes IPv4 nettes ajoutées, pas la totalité.

Sources