Résumé

  • Le mécanisme de sortie par défaut figurait déjà dans la révision 27 ; la révision 28 détaille davantage le retrait, la gestion des règles et le risque de boucle.
  • Une règle spécifique retirée doit cesser de servir aux nouvelles conversions ; une règle par défaut configurée peut alors prendre le relais, sinon le projet prévoit l'abandon et une erreur ICMP ou ICMPv6.
  • Le passage d'une frontière administrative requiert un accord bilatéral explicite, et la sortie choisie doit connaître l'acheminement IPv4 de tout le trafic qu'elle attire sans le renvoyer dans le mécanisme.

Une continuité qui change de responsable

Le projet décrit un domaine limité, constitué d'un seul opérateur ou de plusieurs systèmes autonomes coopérants. Les paquets IPv4 résiduels sont convertis aux bords d'un sous-réseau IPv6 seulement. Il ne s'agit ni de l'Internet ouvert ni d'un protocole de distribution prêt à être déployé partout. Coordination des préfixes de correspondance, filtrage ICMP commun, points d'entrée de confiance et accords bilatéraux préexistants définissent les conditions de coopération. Le document ne crée aucun de ces accords.

Prenons une règle qui dirigeait auparavant un bloc IPv4 vers une sortie déterminée. La révision 28 recommande sa suppression immédiate pour les nouvelles conversions après retrait. Une période de grâce configurable de l'ordre de quelques secondes peut protéger des paquets déjà engagés. Pour le paquet suivant, la question est différente : quelles règles restent réellement dans la base de correspondance ? Si la règle 0.0.0.0/0: Pref6(PE) est configurée, elle peut capter une destination sans correspondance plus spécifique. Sinon le paquet doit être abandonné et l'erreur appropriée produite. Le journal du retrait ne permet donc pas, à lui seul, de connaître la destination effective des paquets suivants.

Le repli peut être utile, mais son coût n'est pas abstrait. Une sortie moins directe dégrade le trajet. Une concentration soudaine peut charger un équipement au-delà du trafic attendu. Une règle attrape-tout attire aussi les abus et les détournements. La révision 27 décrivait déjà le principe de sortie par défaut et ces dangers. La nouveauté éditoriale de la révision 28 n'est pas l'invention d'une route de secours ; c'est la formulation plus nette des obligations de visibilité, de retrait et de contrôle de la boucle.

L'accord ne suit pas automatiquement le paquet

La section 9.4 dit qu'une règle par défaut ne doit pas être annoncée au-delà d'une frontière administrative sans accord bilatéral explicite. Même lorsqu'un opérateur a accepté de porter du trafic pour un autre, l'étendue de cet accord importe : quels préfixes, quelles sorties, quelles conditions de changement et quel sens de circulation ? Une coopération ancienne sur une règle précise ne vaut pas nécessairement acceptation permanente de tout trafic résiduel.

La distribution des règles doit préserver leurs champs, permettre leur limitation par domaine et leur filtrage, authentifier leur origine et rejeter les associations non autorisées entre bloc IPv4 et préfixe de correspondance. Mais les extensions protocolaires qui réaliseraient cette distribution sont hors du cadre du projet. Aucun registre universel de consentement entre opérateurs n'apparaît dans le texte. C'est pourquoi une trace de réception de la règle ne peut remplacer une vérification du périmètre de l'accord.

Chaque opérateur doit pouvoir confirmer ce qu'il a accepté ; l'un ne peut pas autoriser unilatéralement la sortie de l'autre.

Le paquet revenu en IPv4 oublie son voyage

Le point le plus délicat se situe après la sortie par défaut. Le paquet reconverti en IPv4 ne porte aucun marqueur indiquant qu'il a déjà traversé ce sous-réseau IPv6. Si le meilleur chemin IPv4 de la sortie mène à un autre point d'entrée participant, le paquet peut être converti de nouveau, puis revenir. La durée de vie des paquets borne une boucle, mais ne la prévient pas. Un service qui semble rester disponible au premier saut peut ainsi devenir une consommation répétée de capacité.

Le projet demande que la sortie par défaut dispose d'une vue IPv4 complète pour le trafic qu'elle attire et qu'aucun meilleur chemin ne le réintroduise dans le dispositif. Il évoque également surveillance, limitation de débit et listes de contrôle d'accès. Une vérification sérieuse examinerait les meilleurs chemins pour les destinations affectées avant le changement, puis les compteurs, les erreurs et la sortie réelle après celui-ci. Elle ne se réduirait pas à un test « le ping passe ». Il n'existe dans les sources consultées ni incident public correspondant ni preuve d'un déploiement validé par ce test.

Une pièce de changement, pas un nouvel objet IETF

La section 8 recommande des versions ou horodatages de règles, des résumés de cohérence de la base MR-DB, des notifications et des compteurs par règle. Ces éléments indiquent comment observer un changement, non que tous les réseaux les possèdent déjà.

Daniel Kade propose sur cette base une pièce de changement bilatérale et bornée : préfixe et version retirés, instant de suppression pour les nouvelles conversions, éventuelle grâce pour les paquets en vol, portée acceptée par chaque opérateur, sortie par défaut choisie, état des bases de règles, preuve de la vue IPv4 et de l'absence de réinjection, compteurs, erreurs et déclencheur de retour arrière. Ce serait une discipline d'exploitation proposée par l'article, pas un formulaire, un champ de paquet ou une obligation normative créés par l'IETF.

Une telle pièce distinguerait trois décisions. Retirer l'ancienne règle n'approuve pas la nouvelle. Conserver l'acheminement n'autorise pas nécessairement le franchissement d'une frontière. Atteindre une sortie ne prouve pas qu'elle conduise ensuite au bon réseau. En reliant l'état des règles, le consentement et le chemin de sortie, les opérateurs pourraient dire quelle continuité ils ont réellement choisie et à quel moment elle doit cesser.

Le Datatracker classait le texte comme projet actif du groupe v6ops, destiné à un RFC informatif et toujours en suivi par le directeur de zone à l'IESG, avec des positions DISCUSS à résoudre. Il ne s'agit ni d'un RFC approuvé, ni d'une constatation de déploiement. Le document peut encore changer. Sa leçon actuelle est néanmoins précise : une route par défaut est une option technique, pas une délégation silencieuse de responsabilité.

Sources