Résumé

  • Le préfixe IPv6 d’un client 6rd est calculé à partir d’un préfixe de l’opérateur et d’une partie de son adresse IPv4. Le plan d’adressage ancien contribue donc à définir le nouveau produit.
  • Le domaine appartient à l’opérateur, mais les échanges entre clients du même domaine peuvent emprunter un tunnel direct. Le relais de bordure ne représente pas à lui seul toute la frontière de confiance.
  • L’absence d’état par flux simplifie le transfert, pas la responsabilité. La cohérence des paramètres, les durées annoncées et le devenir des préfixes lors du passage à IPv6 natif restent à organiser.

Une offre commerciale déjà découpée en bits

Combien de réseaux internes un client pourra-t-il utiliser ? Dans une offre fondée sur 6rd, la réponse dépend en partie d’un choix qui semble appartenir à une autre époque : le plan d’adressage IPv4 de l’opérateur. Avant même que le client configure son réseau IPv6, certains bits ont servi à le distinguer des autres clients. Ils ne sont plus disponibles pour le découpage de son site.

Le mécanisme décrit par le RFC 5969 associe le préfixe IPv6 6rd du fournisseur à un suffixe de l’adresse IPv4 du routeur client, appelé CE. Les bits de poids fort communs aux adresses IPv4 du domaine peuvent être omis. Le paramètre IPv4MaskLen indique combien.

La longueur du préfixe délégué est ainsi égale à 6rdPrefixLen plus 32 moins IPv4MaskLen. L’exemple du document utilise des adresses IPv4 appartenant à 10/8 : huit bits communs sont écartés, vingt-quatre restent à incorporer. Avec un préfixe 6rd /32, le client obtient un /56. Ce calcul ne demande pas une négociation nouvelle pour chaque flux ; c’est précisément son intérêt.

Il constitue aussi une allocation du produit. Plus l’identification des extrémités consomme de bits, moins il en reste pour organiser les sous-réseaux du client. Une réorganisation de l’espace IPv4 peut donc modifier les conditions du service IPv6, même si le nom de l’offre et le réseau d’accès physique restent inchangés.

Il faut distinguer deux contraintes. L’encodage de l’option DHCP impose que les longueurs pertinentes tiennent dans 128 bits. La partie consacrée à l’adressage recommande, elle, un préfixe délégué /64 ou plus court afin de permettre l’autoconfiguration sans état. Un paramètre peut respecter la première borne sans offrir un découpage adapté au site. La validité d’un champ ne remplace pas une décision sur le service vendu.

Ce qui a rendu le raccourci crédible

6rd transporte des paquets IPv6 à travers une infrastructure IPv4 existante. Il permet donc d’ouvrir un service sans attendre la conversion native de toute la couche d’accès. Le relais de bordure peut calculer les informations nécessaires au transfert, sans conserver une table de correspondance pour chaque flux.

Le précédent historique est concret. Le RFC 5569, document informatif consacré au déploiement initial de Free/Iliad, rapporte cinq semaines entre la décision du 7 novembre 2007 et la mise en service du 11 décembre. Plus de 1,5 million de clients étaient éligibles, à condition d’activer IPv6. Ce nombre désigne une possibilité d’accès, non des utilisateurs actifs mesurés ou un taux d’adoption.

Le récit décrit une capacité organisationnelle autant qu’une technique : l’opérateur pouvait faire évoluer le logiciel des équipements clients, installer des relais et utiliser son réseau existant. Il rapporte aussi le passage d’une allocation /32 avec des préfixes clients /64 à une allocation /26 et des préfixes /60 permettant seize LAN. Il s’agit des arrangements historiques décrits, pas d’une égalité arithmétique selon laquelle /26 augmenté de 32 bits donnerait /60.

Les errata du RFC 5569 aident à lire correctement ce passage. L’erratum éditorial vérifié 2023 remplace une formulation au futur par un constat au passé : l’évolution de l’allocation avait déjà eu lieu. Les autres corrections vérifiées sont également éditoriales. Aucune ne fournit une mesure actuelle de qualité ou une garantie sur les allocations auxquelles un opérateur aurait droit aujourd’hui.

La vitesse du lancement n’est donc pas un résultat détachable de son contexte. Elle reposait sur une maîtrise des équipements et des paramètres. Un autre opérateur peut reprendre le principe de calcul sans posséder la même latitude sur son parc installé. Le protocole offre un raccourci ; l’organisation doit encore être en mesure de l’emprunter.

Le bail IPv4 donne l’heure à IPv6

Le lien ne concerne pas uniquement la taille du préfixe. Il en concerne aussi la stabilité. Lorsque l’adresse IPv4 du CE change, le préfixe IPv6 qui en est déduit change également. Le RFC 5969 prévient que ce changement peut se répercuter dans le réseau du client et recommande des durées d’attribution IPv4 longues.

Quand la durée du bail IPv4 est connue, les durées de vie annoncées aux hôtes ou associées aux préfixes délégués par DHCPv6 ne doivent pas la dépasser. Quand elle n’est pas connue, le texte recommande les valeurs par défaut du RFC 4861. Une durée inconnue n’autorise pas à présenter le préfixe comme durable sans limite.

Le bail évoqué ici appartient au protocole d’attribution d’adresses. Il ne s’agit pas du contrat commercial de location d’un bloc IPv4. La différence est importante : un opérateur peut conserver la maîtrise de son bloc tout en réattribuant une adresse particulière à un autre client. C’est cette attribution individuelle, utilisée dans le calcul, qui gouverne la continuité du préfixe 6rd concerné.

Il serait excessif d’en conclure que chaque client doit bénéficier d’une adresse fixe à vie. Le texte établit une dépendance, pas un produit commercial universel. Il oblige en revanche à regarder les conséquences d’une réduction des durées IPv4 ailleurs que dans le tableau de rendement du pool d’adresses.

Un service IPv6 peut ainsi être affecté par une décision prise au nom de l’efficacité IPv4. L’équipe qui décide n’est pas nécessairement celle qui reçoit les appels des clients. Ce décalage suffit à créer un problème de responsabilité, même lorsque chacun respecte ses objectifs locaux et que le calcul du préfixe fonctionne exactement comme prévu.

Le domaine ne se résume pas à sa porte de sortie

Contrairement à 6to4 et à son préfixe global fixe, 6rd utilise le préfixe propre de l’opérateur dans un domaine défini. Le fournisseur reprend donc une part explicite de maîtrise sur le service. Il serait pourtant erroné de dessiner tous les clients comme s’ils ne pouvaient communiquer qu’à travers une seule porte centrale.

Deux CE appartenant au même domaine peuvent échanger directement par encapsulation IPv4. Le relais de bordure, ou BR, intervient pour le trafic qui traverse la limite entre le domaine 6rd et le réseau IPv6 extérieur. La distinction n’est pas décorative : elle change les paquets qu’un client doit accepter et les chemins qu’une vérification doit couvrir.

L’erratum technique vérifié 3049 du RFC 5969 corrige précisément la formulation de sécurité. Un CE doit pouvoir recevoir des paquets non seulement des BR connus, mais aussi des autres CE du même domaine. Appliquer littéralement l’ancienne formulation limitée aux relais peut donc bloquer un chemin légitime.

La même page présente l’erratum technique 3869, rejeté. Il ne faut pas appliquer la modification proposée. Le contrôle compare l’adresse IPv4 incorporée dans l’adresse IPv6 source interne à l’adresse IPv4 source externe. Il ne compare pas l’adresse IPv6 entière comme s’il s’agissait d’une adresse IPv4. Une incohérence entraîne rejet et comptage comme tentative potentielle d’usurpation ; elle ne constitue pas, à elle seule, une attribution d’attaque.

Le domaine exige par ailleurs des paramètres communs cohérents : masque IPv4, préfixe 6rd et sa longueur, adresses des relais. L’option DHCP 212 permet de transmettre la configuration d’un domaine. Un CE qui reçoit une option valide se configure normalement automatiquement, mais doit offrir la possibilité de désactiver ce comportement et d’ignorer l’option.

Le mot « automatique » ne retire donc pas le pouvoir de configuration. Il augmente la portée de certains paramètres partagés. De même, plusieurs domaines peuvent employer des espaces IPv4 privés qui se chevauchent à condition de disposer de préfixes 6rd distincts. Une adresse ne peut pas être interprétée indépendamment de son domaine. Cela n’équivaut pas à répartir un même préfixe client entre plusieurs utilisateurs au moyen de plages de ports.

Le résultat d’un test a une portée limitée

L’absence d’état par flux permet à plusieurs BR d’utiliser une adresse IPv4 anycast. Le service bénéficie d’un point d’adressage commun, mais les observations faites sur ce point doivent rester précises. Une réponse ne prouve pas le comportement de tous les relais, de tous les chemins ou de toutes les tailles de paquets.

Le RFC 5969 avertit que des vérifications périodiques traitées par le plan de contrôle du BR peuvent devenir coûteuses lorsqu’un grand nombre de CE les envoient. Si la détection de joignabilité CE–BR est nécessaire, elle doit employer une méthode de plan de données ne demandant pas de traitement particulier au plan de contrôle du relais. Le mécanisme de retour décrit dans le texte vérifie ce trajet de transfert. Il ne certifie pas tous les accès au réseau IPv6 extérieur.

L’anycast complique aussi l’interprétation des erreurs ICMP. Une erreur destinée à l’adresse source IPv4 commune peut arriver sur un autre relais que celui ayant émis le paquet initial. L’apprentissage dynamique de la MTU du chemin peut alors échouer et laisser un trou noir. Les BR anycast doivent positionner le bit interdisant la fragmentation lors de l’encapsulation, notamment pour éviter la confusion de réassemblage entre fragments issus de relais partageant une adresse source.

Le document donne l’exemple d’une MTU de tunnel de 1480 octets lorsque le chemin IPv4 bien maîtrisé accepte 1500 octets. Il recommande 1280 quand la MTU pertinente est inconnue. Ce sont des conditions et des recommandations de conception, non des mesures réalisées pour cet article. Une petite sonde réussie ne ferme pas la question du transport de paquets plus grands.

Une adresse calculable n’est pas un agrément

Le RFC 6324, analyse informative de 2011, examine les boucles que peuvent former certains tunnels automatiques IPv6-sur-IPv4 lorsque les hypothèses de routage et d’interprétation des adresses ne concordent pas. Il met en évidence une différence essentielle : pouvoir calculer une adresse de destination ne prouve pas qu’une extrémité de tunnel autorisée s’y trouve.

Pour 6rd, les contrôles doivent connaître les préfixes propres au fournisseur. Il n’existe pas un préfixe global unique qui permettrait de reconnaître tous les domaines. L’usage d’adresses IPv4 privées ajoute une question de portée. Une règle générique, détachée de cette connaissance, ne suffit pas à établir une frontière correcte.

Le rapport privilégie l’évitement opérationnel des combinaisons problématiques et discute, selon les cas, d’informations de voisinage cohérentes ou d’ensembles limités d’extrémités. Une règle visant spécifiquement ISATAP ne devient pas pour autant une solution 6rd. Fusionner les recommandations sous l’étiquette vague de « tunnel IPv6 » ferait perdre leur champ d’application.

Il s’agit de mécanismes conditionnels, non d’un constat selon lequel tous les réseaux 6rd seraient attaqués. La limite de sauts IPv6 demeure finie. Aucun paquet d’attaque n’a été envoyé et aucune installation n’a été testée pour cette enquête. La recherche d’errata du RFC 6324 n’a renvoyé aucune entrée correspondante lors de la consultation ; cela ne vaut pas audit de sécurité contemporain.

Le RFC 5969 demande également d’organiser les frontières, notamment en limitant les accès indésirables aux relais et en tenant compte d’autres relais connus dans le domaine IPv4. Appartenir au réseau d’un même fournisseur ne prouve pas que ces mesures sont effectivement appliquées. La documentation permet de poser la question, pas d’inventer la réponse pour un opérateur nommé.

La sortie rend la dette visible

Passer à IPv6 natif ne signifie pas nécessairement renuméroter tous les clients 6rd. Le RFC 5969 décrit le recours à un nouveau bloc, mais aussi la possibilité de conserver les préfixes délégués en les injectant dans le routage natif. Le numéro du client peut rester stable alors que son mode d’acheminement change.

Cette seconde voie est une possibilité technique, pas une disparition du travail. La relation autrefois calculée à partir de l’adressage doit être portée autrement. Quant à la récupération du bloc 6rd, elle doit tenir compte des utilisateurs restants. Le retrait du relais le plus visible ou l’arrivée d’un nouvel équipement d’accès ne prouvent pas que toutes les dépendances ont cessé.

La Note 32 de Lu Heng sur le problème d’agence fournit ici une grille de lecture : la maîtrise d’une décision doit être rapprochée de l’exposition à ses conséquences. Dans ce cas précis, qui peut modifier les attributions IPv4, et qui supporte les changements de préfixes IPv6 ? C’est une application analytique de cette grille, non la preuve que Lu Heng aurait étudié 6rd ou critiqué un déploiement donné.

Sa Note 36 sur la raison d’être de BTW invite à décrire la structure sans transformer le reportage en plaidoyer. Le raccourci n’a pas besoin d’être condamné pour que ses conditions soient examinées. Il a rendu un service possible ; il a aussi laissé une dépendance à administrer.

L’ancien plan d’adressage demeure influent parce qu’il continue de rendre ce service. La question de gouvernance est de savoir si cette contribution, et son coût de retrait, figurent encore dans les décisions après que le lancement a été déclaré réussi.