Résumé

  • La version v004 de prop-165 propose une seule délégation IPv4 /24 aux organisations admissibles à une allocation IPv6 initiale, pour des fonctions de transition associées à un déploiement IPv6-only.
  • Le dispositif combine déclaration de déploiement, examen périodique sans inspection technique obligatoire, conditions de restitution et deux seuils qui mettraient fin aux nouvelles délégations.
  • Il s’agit d’une proposition : le rapport d’APNIC 62 indique qu’aucun appel au consensus n’a eu lieu, et l’évaluation d’impact publiée sur la page de la proposition porte sur v003, pas sur v004.

La sortie d’un pont se mesure au besoin qu’il cesse de couvrir

Scénario opérationnel, sans opérateur identifié ni résultat observé : imaginons un réseau qui fonctionne en IPv6-only, mais dont le collecteur de supervision doit encore joindre en IPv4 un service de gestion hérité. Tant que ce lien reste inaccessible en IPv6, les équipes ne peuvent pas recevoir sur leur réseau cible les alertes émises par ce service. Le /24 envisagé serait alors une passerelle temporaire vers cette fonction précise, pas la preuve que la transition est terminée. Le test décisif devient moins « combien d’adresses sont utilisées aujourd’hui ? » que « quel changement rendrait ce lien inutile et permettrait de rendre le bloc ? ».

Cette question donne à prop-165 son enjeu institutionnel. APNIC cherche à ménager une exception limitée pour des fonctions comme les résolveurs DNS, les passerelles de courrier, la supervision, la journalisation ou l’accès à des services IPv4 historiques, sans élargir le plafond de ressources IPv4 auquel l’organisation peut prétendre. La proposition ne présente donc pas l’IPv4 comme une nouvelle capacité générale. Elle décrit un pont étroit, rattaché à un déploiement IPv6 et à des conditions de sortie.

Le texte v004, publié le 27 août 2026 pour discussion, réserve l’accès aux organisations admissibles à une allocation IPv6 initiale selon la politique APNIC en vigueur. Une organisation pourrait demander un seul bloc IPv4 /24. Elle devrait fournir une déclaration décrivant le déploiement IPv6-only envisagé, les services de transition nécessitant une connectivité IPv4 et son acceptation des conditions applicables. La proposition écarte une justification détaillée fondée sur le nombre d’hôtes.

APNIC pourrait toutefois demander des éléments complémentaires raisonnablement nécessaires pour établir que le déploiement déclaré existe déjà ou est en cours de mise en œuvre.

Cette distinction est importante. Une déclaration n’est pas dépourvue de toute preuve possible : le texte envisage des documents sur le déploiement, des éléments montrant que les équipements réseau prennent en charge IPv6, ou des preuves de services fonctionnant dans l’environnement décrit. Mais la finalité indiquée est circonscrite. Ces éléments serviraient à montrer que le déploiement déclaré existe ou avance, et non à imposer une inspection technique du réseau. V004 prévoit au contraire un réexamen périodique fondé sur les déclarations et précise qu’il n’exige pas d’inspection technique du réseau du membre.

Le cycle d’allocation doit tenir ensemble plusieurs contraintes. Le bloc proviendrait du pool Final /8, compterait dans le plafond IPv4 déjà applicable au bénéficiaire et n’augmenterait pas le total qu’il est autorisé à détenir. Les registres APNIC devraient l’identifier comme relevant de cette disposition et le relier à l’allocation IPv6 qui a servi à établir l’admissibilité. Son usage principal devrait soutenir le fonctionnement du réseau IPv6-only et les fonctions de transition décrites. Le transfert serait interdit, tout comme la mise à disposition du bloc au bénéfice d’une autre organisation.

Le point de contrôle le plus exigeant est la persistance du besoin. Lors d’un réexamen périodique, APNIC pourrait demander confirmation que l’allocation IPv6 associée reste valide, que le déploiement IPv6-only fonctionne encore et que les ressources IPv4 restent nécessaires à la transition. Une déclaration actualisée et des éléments complémentaires pourraient faire partie de l’examen. Si le membre ne fournit pas cette confirmation, la délégation pourrait être révoquée. Le texte laisse donc une marge d’appréciation à l’administration, mais pose une limite explicite sur la forme du contrôle : déclaratif, sans inspection technique obligatoire.

La restitution répond à une logique distincte du réexamen. Elle serait exigée si l’allocation IPv6 associée est rendue, si le déploiement IPv6-only cesse, si les ressources IPv4 ne sont plus nécessaires à des fins de transition, ou si les conditions de la politique ne sont plus respectées. Une telle liste rattache la durée de vie de l’IPv4 à l’état du déploiement plutôt qu’à une échéance arbitraire. Pour l’exploitant hypothétique, la disparition du service IPv4-only ou son remplacement par une solution accessible en IPv6 modifierait donc le fait central sur lequel repose la délégation.

À l’échelle du pool, v004 prévoit deux conditions d’arrêt des nouvelles délégations. La première serait atteinte si, sur la base du rythme mensuel moyen observé pendant les douze mois précédents, APNIC projetait l’épuisement dans les six mois de l’espace disponible à la délégation sous la politique Final /8. La seconde dépendrait d’un seuil minimal de réserve que la communauté APNIC devrait déterminer ; le texte ne donne pas sa valeur. APNIC publierait au moins chaque trimestre une projection de la date d’épuisement et le volume restant dans le Final /8.

L’arrêt ne rendrait pas automatiquement non conformes les blocs déjà attribués. La proposition prévoit que les délégations existantes puissent se poursuivre tant que leurs conditions restent respectées. Elle prévoit aussi que les demandes approuvées avant le déclenchement du seuil continuent d’être traitées normalement, tandis que celles qui ne seraient pas encore approuvées seraient évaluées selon les politiques alors en vigueur. Il s’agit des dispositions proposées, et non d’une procédure déjà mise en œuvre.

Le dispositif est ainsi plus précis sur les bornes que sur la preuve de la nécessité au quotidien. Il fixe une taille maximale, une source de ressources, un lien avec l’allocation IPv6, une interdiction de transfert, des motifs de restitution et deux mécanismes de fin des nouvelles attributions. En revanche, le mot « principalement » et le niveau de détail acceptable pour démontrer qu’une transition existe restent des questions de jugement opérationnel. Un examen trop léger pourrait prolonger une ressource après la disparition de son motif.

Un contrôle qui s’apparenterait à une inspection technique ajouterait une exigence que v004 exclut expressément.

Le statut de la proposition doit rester séparé de son architecture. Le rapport officiel d’APNIC 62 classe prop-165 parmi les propositions pour lesquelles aucun appel au consensus n’a eu lieu. Cela décrit un fait de procédure ; cela ne signifie ni adoption, ni rejet, ni approbation des participants. La page de la proposition identifie l’évaluation d’impact du Secrétariat affichée comme portant sur v003. Elle ne peut donc pas être présentée comme une évaluation de v004. Le dossier public ne permet pas non plus de chiffrer le nombre d’organisations admissibles, le volume de demandes attendu ou les résultats d’un déploiement réel.

L’idée d’une ressource provisoire peut se juger par la qualité de son cycle complet : l’accès initial est limité, le besoin reste rattaché à une déclaration, la révision ne franchit pas la limite annoncée, la restitution suit la fin du besoin et la réserve commune détermine quand les nouvelles attributions cessent. Si l’un de ces liens devient flou, le « pont » risque de survivre à la transition qu’il était censé faciliter. C’est à cette cohérence de cycle, plutôt qu’à la seule taille du bloc, que devra répondre toute décision future sur prop-165.

Sources