Résumé

  • draft-ietf-v6ops-framework-md-ipv6only-underlay-28 propose une conversion IPv4/IPv6 sans état aux bords d’un socle IPv6-only multi-AS, pilotée par des règles distribuées.
  • L’absence de table par flux ne supprime ni l’origine de la règle, ni sa version, ni la résolution récursive de Pref6, ni le retrait, ni la décision de sortie par défaut.
  • Le reçu exploitable doit relier accord, règle authentifiée, import local, route IPv6, conversion, vue IPv4 de sortie, retour et résultat applicatif.

Une règle spécifique disparaît d’un PE. Le trafic continue pourtant : la règle 0.0.0.0/0 l’envoie vers une sortie par défaut. Le tableau reste vert et l’incident semble absorbé. En réalité, le réseau vient de transformer une absence d’information en décision de transfert, sans expliquer pourquoi la règle précise manque ailleurs.

La révision 28, son dossier Datatracker, son historique et sa fiche courante décrivent un Internet-Draft V6OPS informatif, publié le 28 septembre 2026 et en évaluation IESG. Ce n’est ni un RFC, ni un protocole de distribution achevé, ni une preuve de déploiement.

Le mécanisme est net. Le PE d’entrée cherche la destination IPv4 dans son MR-DB. La règle associe le bloc à un Pref6(PE) de sortie et à un Conversion Type. Le PE construit des adresses IPv6 contenant les adresses IPv4 selon le RFC 6052, traduit selon le RFC 7915, puis le cœur ne transporte que de l’IPv6. Le PE de sortie restaure IPv4 et consulte sa propre table.

Le traitement des paquets ne mémorise pas chaque flux. Le contrôle, lui, demeure distribué. Le cadre suppose des accords bilatéraux préexistants, une allocation coordonnée des préfixes, des règles ICMP communes et des PE d’entrée dignes de confiance. Comme le montre le concept de domaine limité du RFC 8799, une frontière peut limiter la portée ; elle ne fabrique ni confiance ni filtrage.

Un PE ne peut annoncer une règle précise que pour les blocs dont il est la sortie autorisée ou agrégatrice : clients directs, pools locaux, agrégats de site. Il ne doit pas transformer des routes de transit externes en annonces d’autorité. Le futur mécanisme de distribution doit garantir l’intégrité des champs, le périmètre administratif, l’authentification de l’origine et le rejet d’une liaison hors du champ autorisé.

Une origine authentifiée ne prouve pourtant pas la propriété actuelle du bloc, l’implémentation du mode annoncé, l’import par tous les PE ou la disponibilité de la sortie. Elle prouve une assertion bornée. Le verdict de politique d’import doit rester un reçu distinct.

Le Pref6 doit en outre se résoudre récursivement vers le PE qui a émis la règle. Si cette joignabilité disparaît, la règle doit être retirée ou désactivée. Un MR-DB identique sur deux routeurs n’implique donc pas deux FIB identiques. La règle peut être juste et le prochain saut faux.

La sortie par défaut concentre la dette. Elle reçoit les destinations sans règle précise, peut éviter une perte immédiate, mais masque une panne de distribution et attire un volume indéterminé. Au-delà d’une frontière administrative, elle exige un accord explicite. Ses compteurs doivent être lus comme un signal d’exception, non comme un simple indicateur de capacité.

Le risque de boucle est structurel. Après restauration d’IPv4, aucun marqueur n’indique que le paquet a déjà traversé le cadre. Si la meilleure route IPv4 de la sortie renvoie vers un autre PE participant, le paquet est remappé. TTL et Hop Limit bornent le gaspillage sans l’empêcher. La sortie par défaut doit posséder une vue IPv4 complète du trafic attiré et interdire la réentrée.

Le retrait n’est pas instantané partout. Le draft recommande de supprimer immédiatement la règle pour les nouvelles conversions, d’autoriser éventuellement quelques secondes aux paquets déjà engagés, de basculer vers le défaut s’il existe, sinon de rejeter et signaler. Origine, distribution, MR-DB, transfert en cours et défaut peuvent donc diverger. Version, horodatage et intervalle effectif sont indispensables.

La validation de source constitue une autre décision : préfixe d’entrée autorisé, IPv4 incorporée compatible avec la politique, arrivée depuis le réseau participant attendu. Le RFC 2827 fournit le principe anti-usurpation. Un succès ne prouve ni droit métier ni livraison.

Enfin, la cohérence des règles ne résout pas le MTU. Les en-têtes traduits grandissent ; des politiques ICMP différentes entre domaines peuvent supprimer Packet Too Big et créer un trou noir PMTUD. Le RFC 6791 traite la source d’une erreur traduite, pas son passage contractuel. Un petit test peut réussir pendant que les flux réels échouent.

Les limites des travaux voisins expliquent ce nouvel objet : le RFC 6992 traite un cas OSPFv3 dans un AS ; le RFC 8950 transporte un NLRI IPv4 avec prochain saut IPv6 ; le RFC 5565 documente les limites multi-AS du Softwire Mesh. Les RFC 8585 et RFC 9313 cadrent l’IPv4aaS d’accès, pas un MR-DB commun à plusieurs opérateurs.

Le reçu opérationnel relie donc l’accord, le champ IPv4 autorisé, le préfixe, la règle authentifiée, son import, sa version locale, la résolution vers l’origine, la validation, les compteurs, le retrait, le défaut, la non-réentrée IPv4, le retour et l’application.

Les couches de réalité interdisent de confondre contrat, assertion, installation et résultat. La spécification initiale minimale fixe le plus petit contrat vérifiable sans absorber les choix futurs. La primauté du code en fonctionnement donne le dernier mot aux versions, routes, compteurs, erreurs et résultats observés.

Sources