Résumé

  • ARIN-2026-2 est un projet de politique en discussion, et non une règle adoptée ou mise en œuvre.
  • Le texte remplacerait des formules et seuils d’utilisation publics par des plans documentant unités d’affectation, hiérarchie, agrégation et croissance.
  • BTW recommande un relevé comparable entre plan et décision ; l’opérationnalisation par le personnel et la charge de preuve pour les demandeurs restent inconnues.

Le texte de la proposition est daté du 4 mai 2026 et elle est devenue un Draft Policy le 24 juin 2026. Au gel du reportage, le 5 septembre 2026, elle restait en discussion. L’index cité ne montrait ni examen du personnel ou du service juridique, ni entrée de présentation communautaire. Les sources ne montrent ni recommandation, ni consensus, ni last call, ni adoption par le Board, ni mise en œuvre ; le texte ne fait pas partie du NRPM actuel.

Le projet déplacerait les décisions d’allocation initiale des LIR hors des mécanismes actuels fondés sur une formule et l’utilisation. Chaque demande décrirait les tailles habituelles d’affectation aux sites distants ou aux clients, la hiérarchie et la structure logique de l’adressage, ainsi que l’utilisation projetée des unités d’adressage à environ un, deux et cinq ans. ARIN examinerait le nombre et le type d’affectations en aval, les besoins d’agrégation et la capacité à assurer une croissance contiguë.

L’espace initial serait dimensionné pour le plan documenté et une expansion efficace, sans que le projet publie une nouvelle formule de dimensionnement déterministe.

Pour les demandes LIR ultérieures, le texte proposé prendrait en compte une mise en œuvre conforme au plan antérieur, des projections actualisées et la possibilité d’étendre le bloc existant. Les demandes PI seraient également examinées selon les besoins des sites, la hiérarchie et la segmentation internes, l’agrégation, la croissance et l’évitement d’un renumérotage. Les réaffectations ou réallocations à des entités externes de /64 ou plus seraient enregistrées dans les services d’annuaire ARIN selon le texte proposé.

La référence actuellement en vigueur est différente. Le NRPM 6.5.2.1 utilise des limites sur des frontières de quartet, un plancher par défaut de /32 avec des options /36 ou /40, des conditions de détention IPv4 pour /40, un plafond de /16 et une formule liée aux sites desservis, au plus grand site et à une norme de 75 %. Le NRPM 6.5.2.2 prévoit notamment une qualification IPv4 antérieure, le multihoming IPv6 ou une justification technique, des affectations projetées à un, deux et cinq ans, et au moins 50 affectations en cinq ans.

Le NRPM 6.5.3 utilise, pour les allocations LIR ultérieures, une utilisation totale de 75 %, une utilisation supérieure à 90 % sur un site desservi, ou une allocation supérieure à 90 % aux sites desservis. Le NRPM 6.5.8 fixe une échelle pour l’utilisateur final : /48 pour un site, /44 pour 2 à 12, /40 pour 13 à 192, /36 pour 193 à 3 072 et /32 au-delà de 3 072 sites.

Le problème de gouvernance n’est ni l’épuisement ni la rareté économique d’IPv6. Il concerne l’allocation proportionnée, l’agrégation, la fragmentation de la table de routage, la continuité et une gestion reproductible. Un plan peut mieux représenter l’architecture réelle d’un opérateur qu’une équation rigide. Mais si plusieurs seuils publics disparaissent, la qualité des décisions dépend davantage d’une interprétation constante des plans et de la comparaison entre mise en œuvre et projections antérieures.

C’est une déduction sur la conception du projet, pas une accusation de conduite arbitraire du personnel ni l’idée que toute discrétion serait abusive.

BTW recommande un registre compact pour chaque classe d’évaluation. Il devrait consigner les hypothèses sur les unités d’affectation, la hiérarchie, les projections à un, deux et cinq ans, l’écart par rapport au plan antérieur, la justification de la croissance contiguë et la raison pour laquelle le préfixe attribué est proportionné. Ce registre est une recommandation de cette analyse, non un système ARIN existant ou promis.

Note de publication : « Publié » désigne la date éditoriale programmée, le 6 septembre 2026, en Asie/Shanghai. L’heure effective de publication sur le serveur reste indéfinie jusqu’à l’action publish-now.