Résumé

Quatre noms dans une même colonne

La page des mises à jour des services porte la date de publication du 24 septembre. Cinq jours plus tard doit s’ouvrir une fenêtre de deux heures pendant laquelle APNIC modifiera l’environnement réseau GCP utilisé par quatre services. La liste ne décrit ni une base de données commune, ni une chaîne de publication unique, ni un point de panne partagé. Elle ne fait qu’indiquer le périmètre annoncé de travaux dont APNIC ne prévoit pas qu’ils provoquent un arrêt.

Il serait trop facile de ne retenir qu’un test : ouvrir chacune des quatre adresses ou vérifier qu’une réponse arrive. Cela répond à une question utile, celle de l’accessibilité. Ce n’est pas le même test pour une interface consultative, pour une notification et pour une attestation cryptographique portant sur l’état d’un bloc d’adresses. Dans ce dernier cas, un objet ancien peut rester récupérable sans que sa présence prouve la mise à jour de la décision qu’il exprime. Il s’agit d’une possibilité logique à surveiller, pas d’un fait observé chez APNIC.

Une annonce du 31 juillet 2025 citait déjà exactement les mêmes services lors d’une montée de version de Kubernetes, sans interruption attendue elle non plus. La répétition de la liste signale qu’AS0 appartient au périmètre des communications de maintenance d’APNIC. Elle ne nous autorise pas à dessiner l’architecture actuelle à partir de celle d’hier. Même l’excuse générique, dans le texte de septembre, pour les problèmes pouvant résulter d’un « outage » ne transforme pas la prévision explicite en aveu d’une panne. L’intervention n’a pas encore eu lieu.

Le point où le registre change de sens

Un ROA d’origine AS 0 n’autorise pas un opérateur à annoncer un bloc. Il exprime au contraire une désapprobation de l’origine des routes pour le préfixe couvert et ses sous-préfixes, selon la section 4 de la RFC 6483. APNIC applique cet outil à l’espace IPv4 et IPv6 dont elle est administratrice et qu’elle n’a pas délégué. Sa politique renvoie aux états Available et Reserved du fichier de statistiques étendu. La délégation à un titulaire change la catégorie de la ressource; le préfixe doit sortir de l’assertion AS0. Cette exigence est actuelle. Le chiffre de cinq minutes, lui, vient des textes de déploiement de 2020.

Leur intérêt est de montrer la mécanique. APNIC expliquait alors que les événements de délégation déclenchaient une mise à jour de l’état RPKI principal et AS0 en cinq minutes au plus, avec un dépôt de publication dans le cloud et une surveillance permanente. Son billet présentait la suppression et la republication en moins de cinq minutes dans des circonstances normales comme un objectif adopté par le système livré. Six années séparent cette description de l’annonce GCP de 2026.

Le simple fait que la politique soit encore active ne prouve ni la permanence de l’architecture ni celle d’un objectif de temps, encore moins sa réalisation pendant une fenêtre future.

Pour mesurer correctement un éventuel changement, il faudrait relier plusieurs événements. Quand le registre faisant autorité a-t-il validé la nouvelle délégation ? À quelle version la couverture AS0 cesse-t-elle d’inclure le préfixe ? À quelle heure cette version a-t-elle été signée et publiée ? Quand un observateur extérieur l’a-t-il obtenue ? Les quatre heures peuvent différer sans que l’URL soit indisponible. Un récupérateur tiers qui interroge tardivement le dépôt n’apporte pas, à lui seul, la preuve d’une publication tardive par APNIC.

Inversement, une publication affirmée par l’émetteur ne dit pas quelle version était visible du dehors au même instant.

Encore faut-il qu’une délégation pertinente ait lieu pendant la fenêtre. Si aucune plage ne change d’état, deux objets identiques avant et après la maintenance peuvent être exactement corrects. Les présenter comme une réussite mesurée du délai de republication reviendrait à inventer un essai qui n’a pas eu lieu. Les présenter comme une anomalie serait tout aussi infondé. La bonne unité de contrôle n’est pas l’heure du rendez-vous technique; c’est une transition réelle du registre.

Une signature n’est pas une consigne universelle

APNIC publie l’AS0 sous un TAL distinct. Un réseau doit décider de l’ajouter à son validateur. Cette séparation évite qu’une assertion visant l’espace non délégué soit absorbée par inadvertance dans l’ancre ordinaire. Elle n’établit aucune séparation physique du dépôt et ne démontre pas que les travaux réseau GCP sont sans effet possible sur sa mise à jour.

Dans l’hypothèse d’un objet ancien couvrant une plage tout juste déléguée, le validateur qui a choisi ce TAL pourrait encore voir une désapprobation signée. On ne peut pas en déduire automatiquement une route Invalid dans tous les contextes : l’ensemble des ROA applicables compte. On peut encore moins en déduire une route rejetée ou une panne pour les utilisateurs : les politiques des opérateurs décident de l’usage du résultat de validation. APNIC avertit que certaines configurations pourraient produire des interruptions en cas d’erreur et recommande l’usage consultatif ou d’alerte plutôt que le filtrage automatique.

Ce conseil est une limite de causalité autant qu’une précaution de sécurité.

L’annonce de septembre ne rapporte ni délégation pendant les deux heures, ni retard de retrait, ni indisponibilité, ni perturbation de routes. Elle annonce des travaux et une attente de continuité. Un bilan proportionné pourrait plus tard séparer la disponibilité des quatre services de la fraîcheur d’AS0 : un événement de délégation s’est-il produit, la voie de publication a-t-elle été sollicitée, quelle version était visible, et quel objectif de délai APNIC appliquait-elle alors, s’il y en avait un ? Si aucun événement n’a sollicité cette voie, le dire vaut mieux qu’une preuve imaginaire.

Ce bilan est une proposition éditoriale, pas une obligation annoncée par APNIC ni une accusation de défaut de supervision interne.

Une fenêtre sans arrêt reste une bonne nouvelle possible. Pour un service qui prononce un jugement signé sur des ressources non déléguées, elle ne résume pourtant pas toute la qualité opérationnelle. Le lecteur doit pouvoir distinguer un service qui répond d’un service qui répond avec l’état juste.

Sources