Résumé

  • La RFC 6334 définit une option DHCPv6 qui fournit à un B4 le nom d’un AFTR pour DS-Lite. Le nom autorise une tentative de connexion ; il ne prouve ni tunnel, ni état de traduction, ni trafic de retour.
  • Tomek Mrugalski a cosigné la RFC avec David W. Hankins. L’instruction d’extrémité reste minimale côté abonné, tandis que le fournisseur doit répartir la capacité et assurer la disponibilité du service.

Le nom reçu n’est pas la connexion

Dans un journal de passerelle, la ligne « AFTR fourni » paraît souvent décisive. Le serveur DHCPv6 a répondu, le nom est présent et l’écran passe au vert. Pourtant, cette ligne n’indique pas si le nom se résout depuis le réseau du client, si l’adresse obtenue est joignable, si un tunnel a été établi ou si l’AFTR a créé l’état de traduction nécessaire au flux. Elle ne prouve pas non plus qu’une réponse IPv4 a fait le chemin inverse. La configuration est une étape précise ; le service rendu en est une autre.

La RFC 6334 définit OPTION_AFTR_NAME, code 64 : un nom de domaine complet qui désigne un Address Family Transition Router auquel le client peut se connecter. Le B4 — la fonction d’initiation du tunnel DS-Lite — reçoit ainsi un point de départ. Le champ ne transporte pas le tunnel, ne réserve pas de capacité sur l’AFTR et ne certifie pas l’application finale. Cette modestie est importante : une option de configuration ne doit pas être lue comme un accusé de réception de toute la chaîne réseau.

Tomek Mrugalski a cosigné cette spécification avec David W. Hankins en août 2011. La RFC 6333 décrit séparément l’architecture : le B4 encapsule des paquets IPv4 dans IPv6 ; l’AFTR, dans le réseau du fournisseur, les décapsule et applique la traduction IPv4. Les deux textes permettent de suivre une répartition de responsabilité. Le client reçoit une consigne étroite. Le fournisseur choisit l’extrémité, exploite la capacité partagée et doit rendre le service disponible.

Pourquoi placer l’AFTR chez le fournisseur

DS-Lite répond à une situation de transition. Une connexion peut être configurée en IPv6 côté client tout en continuant à transporter du trafic IPv4 pour des terminaux ou des services qui en ont encore besoin. Dans l’architecture résidentielle, les appareils locaux peuvent utiliser des adresses IPv4 privées. La passerelle B4 encapsule leurs datagrammes dans IPv6 et les envoie au routeur AFTR. Celui-ci restaure le paquet IPv4 et le traduit au moyen d’adresses publiques partagées entre abonnés.

Le fournisseur déplace ainsi le point de traduction vers un service qu’il contrôle. Selon la RFC 6333, il peut regrouper des abonnés autour d’un même AFTR, puis ajouter des équipements pour augmenter la capacité ou les rapprocher du réseau d’accès. C’est une possibilité architecturale, pas une preuve que tel opérateur l’a déployée ni qu’un modèle est toujours moins coûteux. Le point essentiel est le contrôle : le nom reçu par le B4 peut l’orienter vers une fonction mutualisée dont la capacité et l’exploitation sont administrées côté fournisseur.

Cette simplicité n’est pas gratuite. Le B4 a encore besoin d’une pile IPv6 fonctionnelle et d’une implémentation capable de valider l’option, de résoudre le nom et d’associer le tunnel à la bonne interface. Le fournisseur doit maintenir l’AFTR, ses routes, ses adresses partagées et les états nécessaires au retour des paquets. Si une seule interface devient le seul endroit où l’on observe le problème, l’origine peut pourtant se trouver dans le DNS, la connectivité IPv6, le tunnel, le filtrage ou la traduction. Les limites d’administration ne coïncident pas avec le dessin de l’option.

Ce que la RFC fixe précisément

Le client ne reçoit pas automatiquement OPTION_AFTR_NAME. Un B4 conforme la demande dans OPTION_ORO, l’Option Request Option. Le serveur ne la renvoie pas si le client ne l’a pas demandée. Une réponse sans ce champ ne prouve donc pas à elle seule l’absence de DS-Lite : il faut examiner la requête, la configuration du serveur et le chemin de réponse.

L’option contient un nom encodé selon les règles DHCPv6 pour les noms DNS. Le client doit vérifier sa longueur et sa structure avant de l’utiliser. L’AFTR-Name est conçu comme une option unique. Le serveur ne devrait pas en envoyer plusieurs ni configurer plusieurs noms dans un seul champ. Si le B4 reçoit plusieurs instances ou plusieurs noms, il utilise le premier. Cette règle élimine une ambiguïté ; elle ne crée pas de sélection équilibrée entre plusieurs AFTR.

Après réception, le B4 effectue une résolution DNS pour obtenir un enregistrement AAAA. Si la réponse contient plusieurs adresses IPv6, il en choisit une pour l’interface concernée. Il ne doit pas établir simultanément plus d’un tunnel DS-Lite par interface. Il serait donc imprudent de déduire qu’une liste de réponses DNS fournit automatiquement la redondance, l’équilibrage ou le basculement que l’opérateur souhaiterait. Ces mécanismes exigent une conception et des preuves de fonctionnement distinctes.

La RFC rappelle que le client DHCPv6 et le B4 peuvent être intégrés, séparés ou reliés par un logiciel intermédiaire. Une capture peut donc montrer une option reçue sans montrer qu’un agent de configuration l’a transmise au composant qui crée le tunnel. L’exploitation doit identifier cette frontière logicielle, l’interface visée et l’adresse finalement sélectionnée. Une valeur correcte dans un processus ne prouve pas sa prise en compte par un autre.

Du nom au paquet de retour

La chaîne de diagnostic commence par quatre traces distinctes : l’option demandée dans ORO, la valeur renvoyée par le serveur, l’adresse AAAA reçue par le résolveur du B4 et l’adresse retenue pour le tunnel. La suite doit montrer l’état du B4, l’acceptation de la session par l’AFTR, la création d’un état de traduction puis la réception d’un paquet de réponse. Les identifiants et horodatages doivent permettre de relier ces événements sans confondre une résolution faite depuis un poste d’administration avec celle de la passerelle du client.

Une résolution DNS réussie ne signifie pas que l’AFTR est joignable. Un tunnel établi ne garantit pas que la traduction fonctionne. Une liaison de traduction ne montre pas qu’une application externe a répondu. Ces distinctions donnent à l’assistance une progression utile : vérifier d’abord l’étape qui manque, plutôt que classer tout échec sous « panne DHCPv6 ». Le message client peut être le même, mais le propriétaire du correctif peut être l’équipe DHCP, DNS, CPE, réseau d’accès ou AFTR.

La haute disponibilité illustre cette responsabilité. La RFC 6333 indique que la simplicité du côté abonné repose sur un fournisseur qui prend en charge la disponibilité. La RFC ne spécifie pas comment ce fournisseur doit y parvenir. Il peut prévoir des équipements redondants, déplacer une affectation, synchroniser certains états ou reconstruire les sessions ; ce sont des choix d’implémentation, pas des comportements garantis par le seul nom AFTR. Une migration doit être évaluée sur les sessions réellement conservées, la durée d’interruption et la possibilité de reprendre les flux.

La RFC 6333 recommande également de conserver des journaux de création des liaisons NAT ou des informations équivalentes pour le diagnostic et les demandes légales. Un enregistrement d’adresse publique, sans contexte d’abonné, de tunnel et d’heure, peut rester ambigu dans un service où plusieurs clients partagent des ressources. Là encore, l’option n’est pas le journal. Elle ne dit qu’où le B4 peut tenter d’établir le tunnel ; la traçabilité des flux relève d’une autre couche.

Une trajectoire de spécification, sans auteur unique

En 2014, Mrugalski a aussi cosigné avec David Hankins, Marcin Siodelski, Sheng Jiang et Suresh Krishnan la RFC 7227, BCP 187, consacrée à la création de nouvelles options DHCPv6. Le texte invite les concepteurs à examiner l’adoption par les logiciels déjà déployés, pas seulement la forme des octets. Il discute des formats réutilisables, de la cardinalité, de l’ordre, de la validation, des rôles client/serveur/relais et de la demande explicite dans ORO.

La chronologie interdit une causalité simple : RFC 6334 date de 2011, RFC 7227 de 2014. La seconde ne peut pas avoir dicté la première. Elle donne plutôt un angle ultérieur sur le coût durable d’une option. Le format doit pouvoir traverser les interfaces d’administration, la configuration du serveur, les messages, le code client et le logiciel qui applique la valeur. Une option lisible dans une capture mais impossible à saisir proprement ou à relier à une interface peut rester difficile à exploiter.

Le DHCPv6 actuel est décrit par la RFC 9915, publiée en janvier 2026 et qui remplace RFC 8415. Elle conserve l’extension par de nouvelles options, renvoie leurs auteurs aux recommandations de RFC 7227 et relie les valeurs de code à la liste tenue par l’IANA. Cette continuité compte parce qu’une option peut vivre longtemps dans des clients et des serveurs différents. Il est préférable de définir dès le départ le nombre de valeurs permises, leur ordre et la façon de vérifier une réponse plutôt que de laisser ces décisions aux implémentations.

Le parcours public de Mrugalski relie cette question aux logiciels. L’IETF Datatracker répertorie ses contributions RFC, notamment RFC 6334, RFC 7227, RFC 8415 et RFC 9915, toutes réalisées en collaboration. Le profil de l’Internet Systems Consortium décrit son travail antérieur sur le serveur DHCPv6 Dibbler et ses responsabilités d’ingénierie DHCP chez ISC. Ces sources biographiques situent son activité ; elles ne mesurent ni l’adoption des RFC, ni la part de marché d’un produit.

Cette distinction évite une biographie exagérée. La RFC 6334 ne documente pas la motivation privée de Mrugalski, son contrôle personnel de la conception finale ou une implantation particulière. Elle permet d’affirmer qu’il a cosigné une spécification qui transmet un nom AFTR à un B4. Son travail ultérieur avec d’autres auteurs sur les recommandations d’options montre une activité à la fois au niveau d’une option et de son environnement de conception. Le standard reste un produit collectif, et chaque déploiement reste une décision de ceux qui exploitent les logiciels.

Ce que les documents publics ne prouvent pas

Les RFC décrivent un modèle et des comportements ; ils ne fournissent pas de décompte actuel des abonnés DS-Lite, de matrice indépendante des équipements compatibles, de taux de panne ou de parts de marché des mécanismes IPv4-sur-IPv6. Le registre IANA confirme que le code 64 est attribué à OPTION_AFTR_NAME, qu’il peut figurer dans ORO et que l’option est singleton. Il ne mesure pas combien de passerelles l’utilisent.

La RFC 9313 compare plusieurs technologies IPv4-as-a-Service. Elle permet de rappeler que DS-Lite n’est qu’une architecture parmi d’autres. Elle ne suffit pas à conclure qu’un mécanisme est partout préférable, dominant ou obsolète. Un choix doit se faire à partir des équipements installés, du réseau IPv6 disponible, de la capacité IPv4, de la gestion des états et des exigences des applications dans un contexte précis.

Le point n’est pas qu’un nom DNS soit trop petit pour porter une décision importante. Il désigne une extrémité candidate ; il ne tient pas lieu de test de service. Le fournisseur peut répartir les abonnés et augmenter la capacité, mais il doit prouver que l’AFTR nommé est joignable, dimensionné et disponible. Le B4 doit montrer qu’il a validé et utilisé la valeur. Les équipes doivent pouvoir relier ces événements à l’état de traduction et aux réponses effectivement revenues.

La contribution de Mrugalski se comprend donc dans une chaîne, pas dans un numéro de RFC isolé. Le client demande un champ ; le serveur choisit de le fournir ; le B4 le résout et sélectionne une adresse ; l’AFTR accepte le tunnel et traite le trafic ; l’abonné obtient enfin une réponse IPv4. Si l’un des liens manque, le document reste une spécification et le journal prouve seulement une configuration.

Sources