Résumé

  • RFC 2185 conservait deux calculs de routage distincts, même lorsqu’un tunnel IPv6 sur IPv4 ressemblait à une seule liaison.
  • Une route IPv6 divulguée ne décrivait pas seulement une destination : elle choisissait le routeur chargé d’encapsuler avant que le routage IPv4 ne prenne le relais.
  • Une route, une adjacence virtuelle, une décapsulation ou un succès dans un seul sens ne prouvaient ni l’autorisation de l’export, ni la symétrie du retour, ni la livraison applicative.

La décision importante précédait l’ajout de l’en-tête

Publié en septembre 1997, RFC 2185 décrivait une longue coexistence des infrastructures IPv4 et IPv6. Il nommait route leaking l’annonce de joignabilité entre deux régions de routage et maintenait une distinction stricte : les routes IPv4 provenaient des protocoles IPv4, les routes IPv6 des protocoles IPv6. Même un processus intégré transportant les deux familles ne supprimait pas la dualité du calcul.

Le registre du RFC Editor et la fiche IETF Datatracker fixent une limite essentielle : le document est informatif, non une norme Internet. Il expose une architecture issue du travail ngtrans. Il ne démontre ni son adoption, ni ses performances sur le terrain, ni l’achèvement d’une migration.

Un tunnel configuré manuellement apparaissait à IPv6 comme une liaison point à point ordinaire. Les extrémités établissaient une adjacence et pouvaient échanger des informations de routage, tandis que l’enveloppe suivait le chemin choisi indépendamment par IPv4. Le saut visible ne disait donc rien de définitif sur les routeurs intermédiaires, la capacité, les filtres ou le retour.

RFC 1933 détaillait alors les mécanismes de transition, notamment le MTU, la fragmentation et la restitution des erreurs ICMP. RFC 2003 définissait l’encapsulation IP dans IP et supposait que la sortie savait décapsuler. Ces textes expliquaient l’enveloppe. RFC 2185 demandait plutôt quelle route désignait l’endroit où l’enveloppe devait commencer.

Divulguer une route revenait à désigner un opérateur de la frontière

Dans le cas hôte-à-hôte, des adresses IPv6 compatibles IPv4 permettaient d’extraire directement les adresses externes et d’encapsuler dès l’origine. Le modèle avec routeur par défaut changeait la signification : l’hôte recevait l’adresse IPv4 d’un routeur double pile connecté au cœur IPv6, lui envoyait l’enveloppe, puis le routeur reprenait le parcours IPv6 après décapsulation. Cette adresse sélectionnait donc le point exact où la responsabilité changeait de famille.

Le cas routeur-à-hôte rendait l’autorité encore plus visible. Le routeur double devait injecter dans la région IPv6 la joignabilité correspondant aux destinations IPv6 compatibles IPv4. Les routeurs IPv6 conduisaient alors le paquet vers celui qui avait publié cette promesse; seulement ensuite, IPv4 livrait le paquet encapsulé à l’hôte.

L’échelle imposait un choix. Un petit réseau IPv4 pouvait être représenté par un préfixe résumé. À la frontière d’un grand cœur IPv4, on pouvait importer la table IPv4 entière dans le routage IPv6, au prix d’un quasi-doublement de l’état, ou choisir manuellement les destinations supposées héberger des systèmes IPv6. La première option consommait des ressources; la seconde transformait une croyance humaine en dépendance d’exploitation.

La solution de secours avait, elle aussi, une portée limitée. RFC 2185 proposait des routes d’hôte propres à chaque extrémité et un préfixe couvrant pour qu’un autre routeur reçoive le trafic après la disparition de la route préférée. Cela prouvait seulement qu’un annonceur du préfixe plus large avait accepté l’enveloppe. Rien ne garantissait qu’il possédait la même politique, le même état de tunnel, le même MTU, la même capacité ou la même continuation IPv6.

Les deux directions pouvaient même employer des formes de tunnel différentes. Une réussite aller n’était donc pas un modèle du retour. La section de sécurité du RFC restait volontairement étroite : un tunnel pouvait contourner les pare-feu de l’infrastructure sous-jacente; aucun autre problème n’y était traité. La livraison par routage n’authentifiait pas le paquet.

Une échelle de preuves, pas une histoire de victoire

Une entrée de table prouve qu’un processus de contrôle a choisi une joignabilité. Un préfixe divulgué prouve qu’une région a annoncé une revendication à une autre. Une adjacence prouve que deux nœuds échangent du contrôle sur un lien virtuel. Une décapsulation prouve qu’un paquet externe a atteint une sortie fonctionnelle. Même une réponse applicative ne vaut que pour la direction et l’intervalle observés.

Aucun de ces éléments ne prouve seul l’autorisation de l’export, l’absence de boucle, l’égalité des politiques de secours, la symétrie, la capacité durable ou la réussite de la migration.

Cette frontière distingue le sujet des textes voisins. RFC 1955 proposait ENCAPS, avec une abstraction déplacée vers des en-têtes de domaine autonome, le DNS et les routeurs de bord. RFC 4213 documenta plus tard les mécanismes de transition de base et conserva l’image révélatrice d’un tunnel qui compte pour un saut IPv6 alors que son TTL et son chemin IPv4 restent indépendants. RFC 2185 montrait surtout qui devait faire coïncider ces couches.

La primauté du code exécuté formulée par Lu Heng fournit ici une grille attribuée : publication et configuration ne sont pas exécution. Sa spécification initiale minimale invite à limiter les invariants communs et à laisser les décisions ultérieures aux opérateurs. Son analyse de la taxe permanente de la double pile donne une lecture économique aux plans parallèles; elle ne prouve pas le déploiement de RFC 2185. Enfin, son texte sur les couches de réalité rappelle qu’une annonce, un chemin exécuté et un service livré appartiennent à des niveaux de preuve différents.

La leçon durable n’est donc pas qu’un tunnel aurait résolu la transition. C’est que la promesse changeait de propriétaire à l’encapsulation : IPv6 devait atteindre le bon encapsulateur; IPv4 devait atteindre la bonne sortie; seul un résultat de bout en bout pouvait montrer que les deux engagements avaient été tenus.