Résumé

  • Dans la suggestion ACSP 2026.3, un opérateur a décrit une frontière vérifiable : avec un ROA /16 et maxLength /24, les préfixes de /16 à /24 du même Origin AS seraient redondants, tandis que ceux de /25 à /32 resteraient créables.
  • ARIN a répondu en cinq semaines et clos le dossier après modification de la FAQ ; l’exemple actuellement publié dit pourtant seulement « any prefix covered », sans reprendre l’intervalle ni le contre-exemple.
  • Un reçu de tests sémantiques, versionné et très court, permettrait de prouver la règle commune au Web, à l’API REST et à OT&E sans publier de données clients ni de code interne.

Une réponse rapide n’est pas un résultat négligeable

Le 13 janvier 2026, Chris Woodfield a déposé la suggestion ACSP 2026.3. Le signalement ne se contentait pas d’affirmer que la documentation prêtait à confusion. Il citait la phrase en cause, racontait un test, proposait une rédaction de remplacement et expliquait ce qu’un opérateur devait pouvoir en déduire.

ARIN a indiqué le 18 février avoir modifié la FAQ afin de répondre à cette confusion, puis a classé la suggestion comme réalisée. Cinq semaines environ séparent le dépôt de la clôture. Pour un mécanisme public de remontée des problèmes, c’est un bon délai. Le dossier attribue le signalement, conserve la réponse et ne cache pas que la question venait d’un utilisateur du service.

Le fond de la décision est également défendable. L’auto-renouvellement a supprimé la raison historique de créer un second ROA identique avant l’expiration du premier. Refuser des objets qui n’ajoutent aucun droit d’origine peut alléger l’interface, réduire les suppressions accidentelles et éviter qu’un opérateur ne croie devoir entretenir plusieurs attestations équivalentes. Une FAQ destinée à un large public n’a pas vocation à devenir un traité de calcul des préfixes.

La critique utile commence donc après ce constat. Elle ne porte ni sur la rapidité de la réponse, ni sur le droit d’ARIN de définir les entrées acceptées par son service hébergé. Elle porte sur le lien de preuve entre le problème accepté et l’état déclaré achevé.

Le signalement fournissait déjà le test de réception

L’ancien exemple, tel qu’il est reproduit dans le dossier, partait d’un ROA pour un /16 assorti d’un maxLength /24. Il affirmait qu’un autre ROA, portant sur n’importe quel préfixe à l’intérieur du /16 et utilisant le même Origin AS, serait refusé. Le déposant expliquait que ses essais ne donnaient pas une règle aussi large.

Sa proposition séparait deux ensembles. Entre /16 et /24, une nouvelle entrée pour le même AS n’ajouterait pas d’autorisation et serait donc redondante. À partir de /25 et jusqu’à /32, le préfixe reste géographiquement — au sens de l’espace d’adressage — contenu dans le /16, mais dépasse la longueur maximale déjà autorisée. Selon le test rapporté, un ROA distinct pouvait alors être créé.

Cette seconde moitié est capitale. Sans elle, « à l’intérieur » peut vouloir dire simple inclusion d’adresses ou autorisation déjà accordée. Avec elle, le lecteur sait exactement de quel côté de /24 effectuer un essai. Le texte proposé remplaçait en outre « overlapping » par « redundant », terme plus proche de l’effet réellement recherché : empêcher un objet qui ne modifie pas l’autorité existante.

La FAQ RPKI actuelle affirme que l’auto-renouvellement a rendu les doublons inutiles et que les ROA ne peuvent plus se chevaucher. Dans son exemple, le /16 avec maxLength /24 empêche un nouveau ROA du même Origin AS pour « any prefix covered in the existing ROA ». Les bornes de /16 à /24 ne sont plus écrites. Le contre-exemple de /25 à /32 a disparu lui aussi.

Ce constat textuel ne démontre pas un défaut du service. Nous n’avons pas utilisé de compte authentifié pour répéter le test en septembre. Le comportement décrit en janvier appartient au signalement, pas à une mesure indépendante de la production actuelle. Il est possible que le code et les tests internes soient parfaitement cohérents, et qu’ARIN emploie « covered in » au sens ordinaire de « déjà autorisé ». Mais le lecteur public ne dispose plus de la phrase qui permettrait de le vérifier.

Dans RPKI, « couvert » n’est pas toujours « correspondant »

Le problème ne serait qu’éditorial si le vocabulaire voisin n’était pas déjà défini techniquement. Le RFC 6811 appelle un préfixe de route Covered par un VRP lorsque le préfixe du VRP est identique ou moins spécifique et que les bits pertinents de l’adresse coïncident. La longueur maximale n’intervient pas à cette étape. Pour être Matched, la route doit aussi respecter le maxLength et présenter le même ASN d’origine.

La FAQ n’écrit pas « Covered » avec une majuscule normative et ne prétend pas reprendre ce lexique. Reste qu’un technicien habitué à RPKI rencontre deux lectures plausibles. Un /25 placé sous le /16 est couvert du point de vue des adresses. Il ne correspond pas à un VRP /16 dont la longueur maximale est /24, même avec le même AS. C’est précisément la frontière que le contre-exemple supprimé rendait visible.

Le RFC 6482 décrit pour sa part l’objet signé. maxLength fixe la longueur de préfixe la plus spécifique que l’AS peut annoncer ; en son absence, seul le préfixe exact est autorisé. Le RFC admet qu’un ROA valide contienne une entrée englobée par une autre, voire deux préfixes identiques. Il déconseille le doublon dont le maxLength plus court n’accorde rien de plus.

Cela n’oblige nullement ARIN à accepter toutes ces formes dans son produit. La validité d’un objet RPKI, l’effet d’un VRP sur une route et la règle d’admission d’une interface sont trois niveaux distincts. Un service peut choisir un sous-ensemble plus simple. En revanche, ce choix gagne à être décrit comme une règle du service, avec des exemples qui en fixent les limites.

Le Web et l’API décrivent les pièces, pas la décision

Le guide ARIN consacré aux ROA énumère les trois éléments — Origin AS, préfixe et longueur maximale — puis répète que doublons et chevauchements ne sont plus autorisés. Pour le détail, il renvoie à la FAQ. Il ne donne pas de matrice de cas limites.

Le guide de l’API REST RPKI est plus précis sur la forme. Une transaction unifiée peut créer, modifier et supprimer des ROA ; elle peut aussi être couplée à des modifications ASPA de manière atomique. Les ressources envoyées contiennent notamment startAddress, cidrLength et, facultativement, maxLength. La page renvoie les erreurs vers la documentation générale, mais la copie figée ne contient pas la règle qui décide qu’une proposition est un doublon ou un chevauchement.

L’atomicité ajoute un cas que la FAQ simple ne peut résoudre. Si une même transaction supprime une ancienne autorisation et en crée une nouvelle, le contrôle de redondance s’applique-t-il à l’état initial, à l’état final voulu ou à une succession interne ? Il existe forcément une réponse dans l’implémentation. Le client qui construit un précontrôle doit connaître cette réponse, car une seule ligne rejetée peut faire échouer l’ensemble.

ARIN propose un terrain d’essai. La page sur l’environnement OT&E indique qu’il offre le même ensemble de fonctions que la production, sans être relié à celle-ci. On peut y créer des ROA de test et vérifier des charges utiles de transactions avant de toucher à une configuration réelle. Les données sont néanmoins remplacées chaque mois par un instantané, les courriels ne sont pas pris en charge et l’environnement n’est pas surveillé activement par le personnel.

OT&E permet de reproduire ; il ne remplace pas la spécification. Un essai dont on ne conserve ni les tuples, ni la version, ni l’état initial redevient une anecdote au prochain rafraîchissement.

Cinq lignes suffiraient à fermer la boucle

Le reçu proposé peut rester minuscule. Son en-tête nommerait la suggestion, la révision de la documentation, la version de la règle et sa date d’effet. Chaque ligne préciserait le canal, l’Origin AS existant, le préfixe, le maxLength, la nouvelle demande, le résultat attendu et un code de motif stable. La date et la version d’OT&E rendraient le test répétable ; un lien de remplacement indiquerait quand la règle change.

Les cinq lignes seraient : préfixe identique et même AS ; préfixe plus spécifique mais encore dans maxLength ; préfixe au-delà de maxLength ; même espace mais autre Origin AS ; transaction atomique qui retire l’ancien ROA et ajoute le nouveau. Des préfixes de documentation et des ASN réservés suffisent. Aucune donnée client, clé ou logique interne ne doit être publiée.

La FAQ peut alors conserver sa brièveté. Le reçu porte la précision. Il sépare trois affirmations souvent confondues : le texte a changé ; le service traite tels tuples de telle façon ; la clôture a bien livré la clarification demandée.