Résumé

  • Le projet 2 conserve la règle des 90 % et propose une dérogation pour des finalités techniques clés démontrées.
  • Un dossier devrait documenter la topologie, le besoin, les solutions écartées, l’utilisation et les contrôles antifraude.
  • Le consensus approximatif de la réunion et le statut Last call ne valent ni ratification du Board ni mise en œuvre.

Note de publication : Publié correspond à la date éditoriale programmée, le 7 septembre 2026. L’heure réelle de publication sur le serveur n’est pas définie.

La section 5.4.6.1 du CPM actuel exige d’un LIR ou d’un utilisateur final demandant une nouvelle allocation ou affectation IPv4 pendant la phase d’épuisement qu’il ait utilisé au moins 90 % de ses ressources antérieures. La première demande d’un nouveau LIR ou utilisateur final sans ressources antérieures est exemptée.

AFPUB-2026-IPv4-002-DRAFT02, daté du 16 juin 2026 après un premier projet soumis le 6 mai, maintiendrait cette base. Il permettrait à AFRINIC de déroger au seuil lorsqu’une finalité technique clé démontrée ne peut pas être desservie en pratique par le pool existant de l’opérateur, ou crée des contraintes techniques pour ce pool. Les exemples non exhaustifs sont la redondance et la haute disponibilité, les mécanismes de transition IPv6 et l’extension à de nouveaux sites.

La justification devrait être suffisamment documentée pour vérifier la conformité, mais le texte ne définit ni schéma public de preuves, ni dossier minimal, ni décision de cas, ni règle de publication.

Cette lacune est décisive : une finalité technique clé peut sinon englober une préférence d’exploitation. Les exemples de centre de données et de fournisseur d’accès avec plusieurs points de présence BGP utilisant 464XLAT et NAT64 sont ceux de l’auteur de la proposition, non des preuves vérifiées concernant un membre précis. L’auteur attribue aussi l’absence de risque immédiat d’épuisement à environ trois millions d’adresses IPv4 récupérées ; il s’agit d’un argument de politique attribué, pas d’un inventaire mesuré indépendamment dans ce dossier.

Le personnel d’AFRINIC considère le seuil de 90 % comme la condition de base et dit qu’une dérogation ne devrait viser que les contraintes techniques, non opérationnelles. Il prévoit une politique documentée pour les hostmasters et demande que les procédures détectent les demandes frauduleuses. Les procédures et FAQ de Member Services devraient être actualisées, sans changement identifié pour WHOIS, RDAP, MyAFRINIC, NetSuite, NMRP ou RPKI. Le personnel estime que la mise en œuvre pourrait respecter le calendrier du CPM, avec une cible de 30 jours après ratification : cela reste un plan, non une ratification ou une mise en œuvre.

Le 24 juin 2026, la réunion de politique publique AFRINIC 37 a discuté de l’utilisation à 90 % sur plusieurs sites et de la différence entre efficacité et topologie opérationnelle. La décision formelle des coprésidents constate un consensus approximatif et prévoit une définition de l’utilisation pendant le Last Call. Une intervention au micro a d’abord affirmé que la proposition n’était pas passée, avant la clarification du coprésident du PDWG. À la clôture du reporting, la page des propositions indique Last call. Cette étape de consultation reste distincte d’une recommandation au Board, d’une ratification et d’une mise en œuvre.

Analyse BTW : dossier de preuves proposé. Il devrait réunir topologie, sites et rôles de service, justification de la taille du préfixe, calcul de l’utilisation, solutions alternatives examinées, besoin limité dans le temps, contrôles antifraude, identité du réviseur, date, conditions et réexamen ultérieur. Un reçu de décision devrait indiquer la règle, les éléments déterminants, les motifs et les conditions. Il s’agit d’une recommandation BTW, pas d’une exigence AFRINIC adoptée.