Résumé

  • APNIC-127 fixe aujourd’hui le minimum IPv4 à /24 et le plafond cumulé issu de 103/8 à /23. Pour un LIR initial, le même texte demande un besoin immédiat en /24, puis un plan détaillé d’utilisation d’au moins un /23 sous un an.
  • Prop-169, inscrit pour discussion à l’APNIC 62, remplacerait ce /23 fixe par « la délégation IPv4 en cours d’évaluation ». Son périmètre publié maintient l’évaluation du besoin, la conservation et les limites actuelles, ne crée aucun droit nouveau et ne rouvre pas les questions plus larges de délégation, de transfert ou de liste d’attente.
  • La formule gagnerait à distinguer la taille demandée, la taille retenue pour l’évaluation et la taille finalement déléguée. Une fiche versionnée et protégée peut conserver ces trois valeurs sans publier les clients, contrats ou choix d’architecture du demandeur.

Un bit, deux quantités

La notation CIDR se lit à rebours de l’intuition : plus le nombre après la barre oblique augmente, plus le bloc diminue. Un /24 représente 256 adresses IPv4. Un /23 en représente 512. La différence est petite dans la chaîne de caractères et considérable dans un test de besoin.

Les politiques actives de l’APNIC sur les ressources numériques réunissent les deux valeurs. La section 6.1 établit le minimum à /24 et le maximum cumulé provenant de 103/8 à /23. La section 6.2.1 demande ensuite au LIR initial d’avoir utilisé un /24 de son fournisseur amont ou d’en démontrer le besoin immédiat, d’avoir respecté les règles applicables à ses ressources antérieures et de présenter un plan détaillé d’utilisation d’au moins un /23 dans l’année.

Le test peut être cohérent si le dossier évalué porte sur un /23. Pour une demande en /24, le lecteur ne sait plus quelle fonction joue le deuxième nombre. Faut-il prévoir une croissance au-delà du bloc obtenu ? Prouver un besoin pour la quantité maximale ? Ou satisfaire une phrase héritée d’un état antérieur du dispositif ?

Le texte brut d’APNIC-127 identifie sans ambiguïté le droit actuellement en vigueur : version 015, datée du 20 février 2025, statut Active. Il reproduit le minimum, le plafond et la condition annuelle. La proposition n’a pas encore modifié ce document.

Cette distinction interdit une erreur classique : confondre la publication d’une amélioration avec son adoption. Une bonne explication n’est pas encore un formulaire opérationnel.

Une correction étroite, pas une nouvelle allocation

La copie publique de prop-169 sur la liste Policy SIG décrit une substitution ciblée. Le plan ne viserait plus au moins un /23, mais l’utilisation, dans l’année, de la délégation IPv4 en cours d’évaluation, sous réserve des limites applicables d’APNIC-127.

La correction est bienvenue. Une variable peut suivre la taille pertinente au lieu d’imposer le plafond dans tous les dossiers. L’horizon d’un an demeure. Aucun droit automatique au maximum n’est créé.

Son état procédural demeure tout aussi précis. La version 1 a été publiée sur la liste Policy SIG le 13 juillet 2026 et doit être discutée lors de l’Open Policy Meeting de l’APNIC 62. Discussion, consensus, commentaires finaux, action de l’EC, publication éditoriale et mise en service sont six faits différents.

Le texte archivé reste délibérément étroit. Il prévoit de revoir les notes d’évaluation, les guides et les documents destinés aux candidats qui mentionnent encore le /23. Il conserve l’évaluation du besoin, la conservation et les limites actuelles, ne crée aucun nouveau droit et refuse de rouvrir les questions plus larges de délégation, de transfert et de liste d’attente.

Une correction de phrase peut néanmoins modifier ce que le dossier de décision doit conserver. Le champ final peut rester un préfixe IPv4 tandis que le dénominateur et les preuves employés pour le choisir changent dans le dossier d’examen.

Le suivi neutre de NOG Alliance classe prop-169 parmi les textes « To be discussed at APNIC 62 ». Il s’agit d’une étape future, pas d’un résultat. L’exemple du /24 explique le défaut de rédaction ; la proposition laisse les autres questions de politique IPv4 hors de cette correction.

Il ne faut donc pas transformer cette proposition en réforme cachée de l’offre IPv4. La question est celle de la traçabilité du nom choisi.

L’article défini ne crée pas un identifiant

« La délégation en cours d’évaluation » semble désigner un objet unique. Dans un dossier, pourtant, trois valeurs peuvent se succéder.

La première est le préfixe demandé, inscrit par le candidat. La deuxième est le préfixe évalué, c’est-à-dire le dénominateur auquel le réviseur compare le plan annuel. La troisième est le préfixe délégué, enregistré à la fin par l’APNIC ou un NIR.

Dans le cas simple, les trois valent /24. Les conserver séparément ne surcharge pas la procédure : un code same-as-requested suffit. Il prouve que le chemin ordinaire a été parcouru au lieu de supposer que les champs étaient identiques.

Une divergence exigerait davantage. Une demande en /23 pourrait être évaluée en /24. Le candidat pourrait réviser sa quantité après une question. Le solde encore autorisé pourrait borner le résultat. Rien, dans les sources publiques examinées, ne démontre que ces scénarios se produisent actuellement. Ils servent à tester la complétude de la règle, pas à accuser les pratiques.

Le solde d’éligibilité est un quatrième nombre voisin, mais pas une quatrième valeur de transaction. Il résulte du plafond applicable moins les avoirs pertinents. Il peut limiter le dossier sans être ni la demande, ni le jugement sur les preuves.

APNIC-127 emploie déjà une formulation plus liée dans une autre voie. Pour le multihoming, la section 6.2.2 mesure 25 % immédiatement et 50 % sous un an par rapport aux « requested addresses ». Ce n’est pas le critère du LIR initial ; les pourcentages ne doivent pas migrer d’une voie à l’autre. Le seul enseignement est grammatical : le texte sait nommer la quantité à laquelle s’applique un test.

Prop-169 n’a pas besoin de nouveaux seuils. Il doit dire d’où vient la quantité, quand elle est figée et ce qui subsiste si elle change.

Trois horizons ne forment pas une seule promesse

La section 5.2.1 exige des estimations documentées pour le besoin immédiat, à un an et à deux ans. Elle donne 25 % immédiatement et 50 % sous un an comme ligne directrice générale. Lorsqu’un utilisateur final ne peut estimer avec confiance le besoin à deux ans, l’APNIC ou le NIR peut limiter la délégation au besoin d’un an.

Durée de prévision, confiance des preuves et quantité décidée ne sont pas interchangeables. Une prévision à deux ans fragile ne réfute pas forcément le besoin immédiat. Une délégation correspondant à un an ne transforme pas la projection à deux ans en fausse déclaration.

Sans moment de fixation, la « délégation en cours d’évaluation » pourrait désigner la demande d’origine, la quantité candidate après examen du besoin immédiat, ou le résultat obtenu après avoir écarté une projection trop incertaine.

La règle des délégations ultérieures offre une discipline utile. La section 7 permet de satisfaire jusqu’à un an de besoins estimés en fonction de l’usage passé, des plans et du respect des règles. Si une période plus courte est retenue, l’APNIC ou le NIR doit en communiquer la durée et les raisons. Une variable réduite doit avoir un nom et une raison. Il devrait en aller de même pour la taille.

Le guide public fixe le plafond, pas le raisonnement individuel

La page IPv4 post-exhaustion de l’APNIC explique que le maximum cumulé de 103/8 est /23, qu’un membre au plafond n’obtiendra pas d’espace supplémentaire de l’APNIC et qu’un membre en dessous peut demander via MyAPNIC. Au-delà de /23, elle oriente vers le marché des transferts.

Ce guide répond correctement aux questions de départ. Il n’a pas pour fonction d’exposer les champs privés d’un dossier, la quantité retenue pour l’examen ou le motif d’une délégation partielle. Le plafond public et la fiche de décision protégée sont complémentaires.

La rareté rend la distinction des motifs plus urgente. Un résultat inférieur peut venir du solde disponible, de l’éligibilité, d’une preuve insuffisante ou d’une révision volontaire. Ces motifs n’ont pas la même portée et ne doivent pas produire le même précédent.

Le plafond a changé en 2019, pas le plancher

La chronologie Internet de JPNIC consigne le consensus sur prop-127 à l’APNIC 47 puis son entrée en vigueur ; JPNIC a ensuite cessé les allocations maximales en /22 depuis son stock retourné et a aligné ce canal sur /23. C’est la politique active archivée, non cette chronologie, qui établit le minimum actuel en /24.

Ce document établit la chronologie des deux tailles. Il ne révèle ni l’intention de chaque phrase conservée, ni les pratiques de traitement. Il montre simplement pourquoi une demande peut légitimement se situer au plancher ou au plafond.

Une proposition ultérieure a tenté un autre réglage. Prop-152 voulait ramener le maximum à /24 après épuisement du pool alors disponible et réserver les délégations suivantes aux nouveaux titulaires. Elle n’a pas atteint le consensus à l’APNIC 56 et a été abandonnée en février 2024. Elle ne décrit pas la règle actuelle.

Son évaluation contient néanmoins une leçon de rédaction : les chiffres d’inventaire changeants ne devraient pas être figés dans une politique pendant un débat. Remplacer une constante périssable par une variable est judicieux ; identifier la source, la version et l’instant de cette variable l’est tout autant.

Seize champs, avec une partie publique réduite

La solution n’est pas un manuel de quarante pages. Les preuves sensibles restent protégées. Le public reçoit le schéma, quelques codes bornés et des agrégats non identifiants.

La fiche minimale comporte seize champs.

  1. Identité et heure de la demande. Identifiant stable, heure de dépôt et liens explicites vers révision ou remplacement.
  2. Identité de la règle. Version d’APNIC-127, paragraphe, date d’effet et version d’implémentation appliquée.
  3. Autorité de décision. APNIC ou NIR concerné, rôle du réviseur et canal de délégation.
  4. Classe du candidat et voie d’éligibilité. LIR initial, multihoming, infrastructure critique, IXP ou autre voie autorisée.
  5. Avoirs pertinents. Espace 103/8, autres ressources pertinentes et calcul du solde, chacun relié à son champ politique.
  6. Préfixe demandé. Longueur, nombre d’adresses et révision déclarée du dossier.
  7. Base du besoin immédiat. Quantité, fonction et références de preuve protégées, sans imposer un schéma réseau unique.
  8. Dénominateur du plan annuel. Préfixe et nombre exacts contre lesquels la projection est évaluée.
  9. État de la prévision à deux ans. Fournie, impossible à estimer avec confiance ou non applicable, avec le fondement retenu.
  10. Garde des preuves. Identifiants, hachages, classe d’accès, conservation, confidentialité et historique de correction.
  11. Préfixe évalué. Quantité exacte, moment où elle devient le dénominateur et règle qui l’autorise.
  12. Code d’écart. Motif borné et lié au fait si l’évaluation diffère de la demande ; sinon same-as-requested.
  13. Historique des questions et réponses. Questions matérielles, réponses, dates et champ modifié.
  14. Préfixe finalement délégué. Quantité, préfixe, événement de registre, heure et différence éventuelle avec l’évaluation.
  15. Résultat et voie de correction. Accord, accord partiel, refus, retrait ou attente, avec motifs et réexamen.
  16. Projection agrégée respectueuse de la vie privée. Comptes des chemins demande→évaluation→délégation, délais, motifs d’écart, retraits et corrections.

Un hachage ne publie pas le contrat qu’il protège. Un code remaining-entitlement-limit n’a pas besoin d’un nom de client. La répétabilité d’une décision n’impose pas l’exposition d’un plan commercial.

Être strict sur le registre, modeste sur le réseau

Le principe de Minimum Initial Specification sépare la précision de l’expansion d’autorité. La couche commune doit définir strictement les quelques faits qui doivent être partagés. Les choix ultérieurs qui n’altèrent ni l’unicité ni l’interopérabilité restent chez l’opérateur.

Identité de demande, version de règle, quantité, autorité et transition du registre sont des faits communs. Clients, fournisseurs, routeurs, plan d’adressage, technique de transition et calendrier commercial ne le sont pas. Même si l’APNIC maintient une évaluation du besoin pour un pool libre rare, elle peut vérifier les éléments pertinents sans homologuer l’architecture.

Cette limite lie les deux parties. Le candidat ne peut remplacer les faits par « croissance future ». Le réviseur ne peut transformer « détaillé » en demande illimitée de données privées. Toute question et toute conclusion reviennent à une quantité et une règle nommées.

Le Policy Development Process de l’APNIC revendique ouverture, transparence et dynamique bottom-up, avec un dossier public des discussions et décisions. Ces qualités supposent que l’objet débattu conserve son identité. Un consensus sur une variable ne vaut pas approbation de toutes ses substitutions internes possibles.

Le texte commun peut rester court. La décision, elle, doit être lisible après coup.

Sources

Ce que les sources ne prouvent pas

Aucune source publique de ce dossier ne montre qu’une demande a été refusée, retardée ou réduite à cause de la phrase en /23. Aucun relevé ne compte les demandes, évaluations et délégations par taille. Les formulaires internes et notes des réviseurs ne sont pas publiés ici. Le constat porte donc sur le texte et la mémoire de décision, non sur une faute observée.

Le résultat de l’APNIC 62 est également inconnu à cette date. Une nouvelle version pourrait préciser le référent, conserver la proposition ou en changer la portée. Il faudra traiter chacune comme un nouveau fait.