Résumé

  • Dans 6to4, l'adresse IPv4 extérieure et l'adresse IPv6 intérieure formaient ensemble une preuve limitée ; après décapsulation, la première quittait le chemin normal d'observation.
  • La vérification du préfixe incorporé réduisait certaines usurpations, mais ne prouvait ni l'identité du relais, ni son mandat, ni la livraison. Il fallait journaliser l'association avant de retirer l'enveloppe.

Une plainte arrive avec une adresse IPv6. Le relais se souvient peut-être d'un volume. Le routeur d'entrée ne conserve que le paquet intérieur. Qui a vu l'enveloppe ? C'est la question que RFC 3964 posait en 2004, longtemps avant que l'observabilité distribuée ne devienne un vocabulaire courant.

L'architecture venait de RFC 3056. Un site disposant d'une adresse IPv4 publique pouvait former le préfixe IPv6 2002:V4ADDR::/48. Entre deux sites 6to4, la valeur IPv4 incorporée indiquait la destination du tunnel protocole 41. Entre un site 6to4 et l'Internet IPv6 natif, un relais décapsulait dans un sens et encapsulait dans l'autre.

La facilité était réelle. Nul besoin de négocier chaque tunnel ni d'attendre une allocation IPv6 pour commencer. Mais le paquet portait deux récits : l'en-tête extérieur indiquait le dernier expéditeur IPv4 visible ; l'en-tête intérieur affirmait une origine IPv6. Le passage du premier au second n'était pas une authentification. C'était une transformation de représentation.

Quatre adresses deviennent deux

L'annexe de RFC 3964 décrit un échange direct. Avant la décapsulation, on voit une source et une destination IPv6, plus une source et une destination IPv4. Après retrait de l'enveloppe, seules les deux adresses IPv6 demeurent dans le traitement ordinaire. Le texte avertit que les adresses IPv4, traitées comme une sorte de couche liaison, sont perdues.

« Perdues » ne signifie pas qu'elles étaient vraies. La source IPv4 pouvait être usurpée. Elle pouvait désigner un relais plutôt que l'émetteur initial. Dans le cas de l'anycast, elle pouvait même être une adresse commune à plusieurs machines. Mais elle restait l'observation la plus proche du point d'entrée. Une preuve imparfaite et une preuve absente ne sont pas équivalentes.

Le contrôle central consistait à comparer les deux couches quand la source intérieure appartenait à 2002::/16. La valeur V4ADDR incorporée devait correspondre à la source IPv4 extérieure. Une discordance imposait le rejet. Les implémentations devaient aussi refuser les valeurs IPv4 impropres à un tunnel global : multidiffusion, diffusion, boucle locale, plages privées ou autres blocs spéciaux, en s'appuyant sur les règles de routeur de RFC 1812 et, aujourd'hui, sur le registre IANA des adresses IPv4 à usage spécial.

Ce test liait deux déclarations. Il ne liait pas une personne, une organisation ou une autorisation. Si le test réussissait, le relais savait que la source extérieure et le préfixe 6to4 racontaient la même valeur IPv4. Il ne savait pas qui avait envoyé le paquet, si cette adresse était encore attribuée au même titulaire, ni si l'opération applicative était légitime.

Le filtrage à l'entrée pouvait renforcer ce lien. RFC 2827, BCP 38, puis RFC 3704, BCP 84 pour les réseaux multihomés, visaient à empêcher une source IPv4 invraisemblable de quitter son voisinage. Pourtant, un filtre réussi ne crée pas une identité : il établit une conformité à une topologie ou à une politique locale pendant une certaine période.

Le relais ne portait pas de certificat de fonction

Le cas natif-vers-6to4 était plus difficile. La source intérieure était une adresse IPv6 native, sans valeur IPv4 incorporée à comparer. L'adresse extérieure identifiait normalement le relais, mais RFC 3964 constatait qu'un routeur 6to4 distinguait mal un relais légitime d'un tiers qui en prenait l'apparence. Recevoir un paquet protocole 41 prouvait une arrivée ; cela ne prouvait pas le mandat de l'émetteur.

La parenté avec les modèles de menace de Neighbor Discovery dans RFC 3756 est instructive. Un voisin capable de parler sur un lien n'est pas nécessairement autorisé à exercer une fonction de routeur. Avec 6to4, le « lien » pouvait être l'Internet IPv4 entier. L'accessibilité et l'autorité restaient deux faits différents.

RFC 3964 recommandait donc plusieurs contrôles indépendants : vérifier la cohérence extérieure/intérieure lorsqu'elle était définie ; ne pas renvoyer du trafic 6to4 vers 6to4 par un relais ; refuser un paquet destiné au préfixe d'un autre site ; exclure les adresses IPv4 invalides ; limiter l'étendue des routes et la charge. Chaque verdict répondait à une question précise. Aucun ne garantissait que le paquet serait livré, accepté ou attribué au bon acteur.

L'anycast simplifiait la sélection, pas la reddition de comptes

RFC 3068 avait créé 192.88.99.1 pour que le routage IPv4 choisisse automatiquement un relais proche. Un relais défaillant pouvait retirer la route, laissant le réseau en sélectionner un autre. Ce mécanisme réduisait la configuration, mais le document reconnaissait qu'il devenait difficile d'identifier le relais particulier utilisé.

Une route vers l'adresse anycast ne prouvait donc qu'une possibilité de sélection. Elle ne prouvait pas la disponibilité IPv6 native du relais, sa volonté de transporter ce trafic, la bonne exécution des contrôles, sa capacité ou l'identité du relais de retour. La symétrie n'était pas prévue.

En 2011, RFC 6343 a dressé le constat opérationnel : trous noirs, relais non gérés ou réticents, chemins aller et retour différents, filtrage avec état perturbé par les adresses extérieures et difficulté à transformer l'annonce d'une route en service fiable. Ce n'était pas simplement un problème de paquets. La responsabilité était fragmentée entre le site, l'opérateur IPv4, le relais aller, le relais retour et le domaine IPv6 natif.

RFC 7526 a finalement déconseillé formellement l'anycast 6to4 et l'adresse 192.88.99.1 en 2015. Il n'a pas abrogé le mécanisme de base de RFC 3056 ni 2002::/16. Cette nuance interdit un raccourci commode : un statut de dépréciation n'est pas une observation de disparition. Des routes, hôtes ou flux résiduels peuvent persister et exigent encore des preuves.

La chaîne de preuve dépassait le tunnel

RFC 3964 distingue les attaques par déni de service, réflexion, « blanchiment » de paquets, diffusion IPv4 locale, vol de service et abus administratif. Un relais pouvait sembler être la source d'un abus qu'il n'avait fait que transporter. Un paquet pouvait passer le contrôle de préfixe, échouer ensuite à une règle IPv6, atteindre la destination puis être refusé par l'application.

Une chaîne exploitable sépare donc au moins neuf étapes : choix de route IPv4 ; réception sur une interface concrète ; capture conjointe des deux en-têtes ; verdicts de politique ; décapsulation ; décision de transfert IPv6 ; réception distante ; effet applicatif ; attribution à un acteur autorisé. La réussite de l'étape cinq ne remplace aucune des quatre suivantes.

La généralisation est confirmée par RFC 6169 : un réseau qui transporte l'enveloppe ne filtre pas automatiquement les adresses internes ; les extrémités doivent appliquer des contrôles équivalents, et les dispositifs non conscients du tunnel perdent de la visibilité. RFC 3964 montre le coût historique exact : le système pouvait annoncer une décapsulation réussie au moment même où disparaissait sa meilleure possibilité de corrélation.

Corpus et prudence

La base primaire comprend le texte, la notice RFC Editor et le registre d'errata. Deux errata techniques vérifiés corrigent une destination d'exemple et une faute dans 192.88.99.0/24; ils ne démontrent aucun incident réel. Le contexte historique repose sur RFC 3056 et 3068, le contexte de filtrage sur RFC 2827 et 3704, l'expérience ultérieure sur RFC 6343 et 7526, et les limites de sécurité sur RFC 6169, 1812 et 3756.

Ce corpus établit des mécanismes et des recommandations. Il ne mesure ni le nombre de relais, ni l'adoption universelle du filtrage, ni une attaque nommée, ni les pratiques d'un fournisseur.