Résumé

  • Publiée le 9 septembre 2026, la révision 01 de draft-dong-sidrops-rpki-rtr-moa-pdu ajoute le retrait total ou partiel d’ensembles répartis entre plusieurs PDU, ainsi que les temporisateurs et le numéro de série du cache. Elle reste une soumission individuelle active, sans adoption par le groupe SIDROPS ni approbation de l’IETF.
  • Le texte réserve à une spécification complémentaire attendue l’ordre et le repli entre MOA et ROA IPv6. Une matrice publique des résultats sur ces deux plans est le minimum nécessaire pour que deux implémentations n’appliquent pas en silence deux politiques différentes.

Le problème tient dans un détail très concret. Un objet MOA peut autoriser un même préfixe de mapping IPv6 à représenter plusieurs préfixes IPv4. Si l’ensemble est trop grand, le cache peut l’envoyer dans plusieurs messages. Quand deux préfixes seulement doivent ensuite être retirés, faut-il reproduire à l’identique le découpage du premier envoi ?

La révision 01 répond non. Pour un retrait total, le cache peut réunir tous les préfixes dans un seul PDU ou reprendre les anciens sous-ensembles. Pour un retrait partiel, les PDU doivent, ensemble, désigner exactement les préfixes retirés. Le routeur calcule cette union et supprime les autorisations correspondantes sans exiger le même nombre de messages qu’à l’annonce.

C’est une correction de modèle, pas seulement une commodité d’encodage. Le découpage réseau ne devient pas une propriété durable de l’autorisation. Une décision sur les préfixes survit au choix momentané de paquets qui l’a transportée.

La révision 00 ne contenait pas cette discipline. La comparaison officielle montre aussi l’ajout d’un ordre canonique, d’une section sur le cycle de vie et d’une frontière explicite autour de la validation.

Le nom SIDROPS n’est pas un statut

Il faut lire l’état procédural avec la même exactitude que le retrait. La fiche Datatracker et son API documentaire placent le texte parmi les soumissions individuelles actives. Aucun flux IETF, Area Director responsable, rapporteur ni niveau normatif visé n’y figure. L’historique date la nouvelle version du 9 septembre ; la fiche de soumission en conserve l’auteur et la date documentaire.

Le mot sidrops dans le nom suggère le lieu de discussion souhaité. Il ne fait pas de ce texte un document du groupe de travail. En revanche, le profil MOA auquel il renvoie est bien un document SIDROPS. Les deux statuts ne se contaminent pas.

Cette séparation devient plus claire si l’on suit les objets dans l’ordre.

  1. Le détenteur d’adresses produit un MOA signé. Le profil MOA, révision 04, relie un préfixe de mapping IPv6 à un ou plusieurs préfixes IPv4. Plusieurs préfixes de mapping pour le même ensemble exigent plusieurs objets.
  2. Un logiciel de partie utilisatrice valide l’objet. Il applique les contrôles du RFC 6488, puis vérifie que chaque préfixe IPv4 est couvert par l’extension de ressources IP du certificat de l’entité finale. Le profil précise que cette PKI confère une autorisation, pas une authentification personnelle ni une non-répudiation.
  3. Le cache dérive du MOA validé un PDU ordonné. Le PDU est une projection destinée au routeur ; il n’est pas l’objet signé lui-même.
  4. Le routeur installe l’autorisation dans sa base locale de Mapping Origin Validation. Le RFC 8210 rappelle qu’un numéro de série est la version logique d’un cache, non une preuve universelle. Il n’est comparable ni entre caches ni entre versions de protocole, et peut perdre sa continuité après réinitialisation.
  5. Une annonce BGP 4map6 arrive. Le projet 4map6, révision 06, vérifie notamment l’accessibilité du préfixe de mapping, alimente une base locale et applique des mesures de distribution. Le résultat de routage reste un acte local supplémentaire.

Un ROA n’est pas un synonyme commode du MOA. Le RFC 9582 décrit l’autorisation donnée à un système autonome d’annoncer des routes pour des préfixes. Le MOA proposé autorise un préfixe IPv6 à être l’origine d’un mapping concernant des préfixes IPv4. Les deux objets utilisent l’infrastructure RPKI, mais ils ne gouvernent pas la même action.

Deux sorties différentes : retrait et expiration

La révision 01 emprunte aussi au RFC 8210 les temporisateurs Refresh, Retry et Expire. À l’échéance de Refresh, le routeur demande une remise à zéro complète et devrait continuer d’utiliser les données MOA présentes pendant l’attente. À Retry, il renouvelle la tentative. Si aucune actualisation ne réussit avant Expire, il doit vider toutes les données MOA et cesser de prendre des décisions MOV fondées sur elles jusqu’au rétablissement du cache.

Il ne faut pas confondre cette expiration avec un retrait. Le retrait est une information reçue au sujet d’autorisations déterminées. L’expiration est la conséquence locale d’une impossibilité prolongée à rafraîchir la vue entière du cache. La première peut viser un sous-ensemble ; la seconde retire la base MOA du processus de décision.

Le numéro de série rend les changements repérables dans une session comparable. Il ne prouve ni le contenu cryptographique, ni la validité de la route IPv6, ni l’effet dans la table de transfert. De même, supprimer une entrée MOV ne démontre pas qu’une route 4map6 a disparu partout ni que les paquets ont retrouvé leur destination.

Cette granularité est la réussite de la nouvelle version. Elle évite que « retiré », « expiré », « non rafraîchi », « absent de la base » et « non acheminé » deviennent un seul état imprécis.

La fourche de validation reste invisible

Le profil MOA décrit lui-même le second risque. Un détenteur IPv4 peut avoir signé une autorisation correcte, tandis qu’un tiers annonce abusivement le préfixe IPv6 sous-jacent. Le profil recommande donc de déployer aussi la validation ROA IPv6.

Le nouveau PDU reprend ce point, puis s’arrête. L’interaction détaillée entre les deux validations — ordre et comportement de repli compris — est déclarée hors périmètre. Elle doit, selon le texte, être traitée par une spécification de vérification MOA attendue aux côtés du profil.

À la date de clôture de cette recherche, les recherches publiques du Datatracker sur les noms MOA et les titres « Mapping Origin » retrouvaient le profil, le PDU et des supports de réunion, mais aucun document actuel portant cette fonction de vérification annoncée. Cela décrit la documentation visible ; cela ne permet pas d’affirmer qu’aucun développeur ne possède de règle privée ni qu’un futur texte ne paraîtra pas.

La lacune porte sur des cas ordinaires : MOA valide et ROA IPv6 Invalid ; MOA valide et ROA NotFound ; données MOA encore dans la fenêtre Expire mais route IPv6 nouvellement invalide ; cache resynchronisé alors que la route a changé ; retrait partiel au milieu d’une mise à jour. Faut-il bloquer, dégrader la préférence, laisser le résultat indéterminé ou appliquer un profil opérateur ? Quel contrôle doit être retesté avant réinstallation ?

Ni le numéro de série ni l’ordre canonique ne répondent. Ils organisent une vue du cache. Ils ne donnent aucune préséance entre deux plans de preuve et ne choisissent pas une politique de routage.

Le contexte 4map6 limite pour l’instant la portée. Son projet vise d’abord un réseau contrôlé par un opérateur ou un petit nombre d’opérateurs coopérants. Il admet qu’une extension plus large demanderait un mécanisme d’authentification spécifique défini ailleurs. Une fédération fermée peut convenir d’une règle locale ; elle doit la nommer avant de la faire passer pour une propriété du protocole.

Une matrice à deux plans suffit pour commencer

Le PDU n’a pas besoin d’absorber toute cette politique. Une spécification complémentaire, ou un profil opérateur public, peut publier une matrice de résultat à deux plans.

Chaque ligne devrait conserver le résultat et la raison de validation du MOA ; l’adresse du cache ; la version du protocole ; l’identifiant de session ; le numéro de série et l’heure d’observation ; puis le résultat ROA IPv6 du préfixe de mapping. Elle devrait ensuite indiquer l’ordre des contrôles, préciser si un résultat bloque, dégrade ou empêche l’évaluation de l’autre, nommer l’état local conservé ou supprimé, la version de politique, l’action et la condition de rétablissement.

La table doit au minimum distinguer les associations MOA valide / IPv6 valide, MOA valide / IPv6 invalide et MOA valide / IPv6 introuvable, ainsi que MOA invalide ou expiré, cache encore toléré avant Expire, cache expiré, retrait partiel, retrait complet, réinitialisation et resynchronisation. NotFound n’est pas Valid, et « non évalué » n’est pas une réussite.

La proposition suit la logique de la Spécification initiale minimale de Heng Lu : rendre commun le plus petit bord nécessaire à l’interopérabilité, sans centraliser le choix de chaque réseau. Running Code Primary ajoute l’exigence d’une preuve de ce qui a réellement été exécuté. Cette matrice est ma proposition éditoriale, pas une obligation de l’IETF ou des auteurs.

La révision 01 mérite donc son progrès : elle donne à l’autorisation une sortie exacte. Le travail suivant doit rendre visible le carrefour qui décide si cette autorisation devient une action.

Sources