Résumé

  • L’option « IPv6-Only Preferred » de la RFC 8925 laisse un terminal compatible indiquer qu’une adresse IPv4 est facultative. Seul un pool explicitement configuré comme « IPv6-mostly » peut lui renvoyer l’option 108 et l’inviter à ne pas demander l’adresse proposée.
  • Le délai minimal est de 300 secondes ; la valeur par défaut de la RFC est de 1 800 secondes. À l’expiration ou lors d’un nouvel attachement, DHCPv4 peut reprendre. Il s’agit d’un disjoncteur de retour, non d’une suppression permanente d’IPv4.

Un message DHCPv4 qui ne cherche pas de bail

La scène paraît contradictoire. Un client émet un DHCPDISCOVER, reçoit un DHCPOFFER et termine volontairement l’échange sans adresse. Pourtant, c’est exactement le comportement recherché. Dans la liste des paramètres demandés, le client a placé le code 108. Il ne transmet pas lui-même la valeur de quatre octets : il signale seulement qu’il sait fonctionner sans adresse IPv4 sur cette interface si le réseau fournit les services nécessaires.

Le serveur doit respecter deux conditions. Le client a demandé l’option, et le pool choisi a été configuré comme majoritairement IPv6. Dans ce cas, le serveur renvoie V6ONLY_WAIT. Il devrait utiliser 0.0.0.0 comme adresse proposée. Si son infrastructure ne l’accepte pas, il peut annoncer une adresse réelle encore disponible, sans la réserver, puisque le client n’est pas censé la réclamer.

Cette réponse négative évite de doubler les réseaux. Les équipements qui ignorent l’option poursuivent DHCPv4 normalement. Ceux qui la demandent peuvent rester en IPv6 seul. Des terminaux IPv4, double pile et capables d’IPv6 seul cohabitent ainsi sur le même segment sans être classés à l’avance par un portail d’admission omniscient.

La portée est volontairement étroite. Le serveur ne décide pas si l’appareil est moderne. Le terminal ne décide pas si le réseau doit abandonner IPv4. Chacun exprime une capacité locale, et l’échange n’a d’effet que lorsqu’elles se rencontrent.

Le compteur protège l’erreur

La durée renvoyée est un entier de 32 bits. Une valeur inférieure à MIN_V6ONLY_WAIT est relevée par le client au minimum de 300 secondes. La valeur par défaut définie par la RFC est de 1 800 secondes. Pendant cette période, le client devrait arrêter la configuration DHCPv4 ; il peut aussi désactiver complètement la pile IPv4 sur l’interface concernée.

Deux événements remettent la question sur la table : l’expiration du délai et un nouvel attachement réseau. Le changement de lien est déterminant, car la capacité n’est pas une propriété absolue de la machine. Un même ordinateur peut disposer d’un CLAT sur une interface, trouver NAT64 sur un site et rencontrer ailleurs un réseau purement IPv4.

La version 07 du projet 6MOPS propose de commencer avec 300 secondes afin de revenir vite en arrière. Ce texte, daté de mars 2026, reste un Internet-Draft : il n’a pas le statut d’une RFC. Sa recommandation a néanmoins une logique d’exploitation vérifiable. Si l’activation révèle un VPN défaillant ou une application contenant des littéraux IPv4, arrêter l’envoi de l’option permet aux clients de redemander une adresse après le compteur ou une reconnexion.

Un petit délai augmente cependant la fréquence des DHCPDISCOVER. Sur un très grand parc, le retour toutes les cinq minutes peut devenir une charge. Il faut donc arbitrer entre une erreur brève et un serveur calme à partir de mesures : population compatible, fréquence des échecs, capacité DHCP et temps réel de résolution des incidents.

Le registre des six preuves

Une console qui affiche « option 108 activée » ne dit presque rien. Un dossier exploitable sépare six objets.

Le premier est la politique de l’interface. Qui a déclaré le terminal capable d’IPv6 seul, sur quelle interface et après quels tests ? La RFC qualifie explicitement cette déclaration de décision de politique. Elle ne sonde pas chaque logiciel installé.

Le deuxième est la demande observée. Le code 108 figurait-il réellement dans la liste du paquet ? Sans demande, le serveur ne doit pas l’imposer.

Le troisième est le périmètre serveur. Le pool qui a répondu était-il celui configuré comme IPv6-mostly ? Un paramètre général de l’équipement ne prouve pas la configuration de ce pool précis.

Le quatrième est l’offre : longueur valide, valeur du compteur, 0.0.0.0 ou adresse réelle non réservée. Une capture contrôlée permet d’en garder la preuve.

Le cinquième est l’état du client. A-t-il effectivement refusé l’adresse, interrompu DHCPv4 et respecté la durée ? Les transitions INIT-REBOOT, renouvellement et reconnexion méritent des traces distinctes.

Le sixième est l’expérience utile. Le terminal a-t-il découvert PREF64, atteint NAT64, activé CLAT lorsque le logiciel l’exigeait et accompli les tâches réelles de l’utilisateur ? Un bail absent ne répond à aucune de ces questions.

Dire « IPv4 est coupé » fusionne ces six lignes et détruit le diagnostic. Dire « ce client a refusé ce bail dans ces conditions pendant cette durée » produit une preuve réutilisable.

Le chemin de traduction doit arriver à temps

La RFC 8925 suppose que NAT64 relie l’hôte IPv6 aux destinations uniquement IPv4. Elle ne négocie pas la technologie de traduction et ne communique pas le préfixe utilisé. C’est un contrat avec son environnement, pas une fonction cachée de l’option 108.

La RFC 8781, également coauteurisée par Jen Linkova, place PREF64 dans une option de Router Advertisement. Le terminal peut ainsi apprendre le préfixe NAT64 avec le reste de sa configuration IPv6. La RFC 9872 recommande cette méthode pour les nouveaux déploiements et conserve la découverte par DNS en solution de repli lorsque l’annonce RA n’existe pas ou n’est pas comprise. Elle précise qu’avant l’obtention du préfixe, les applications uniquement IPv4 et les communications vers des destinations uniquement IPv4 sont dégradées.

464XLAT peut présenter une interface IPv4 à une application ancienne et traduire ses paquets au bord du terminal. Mais la RFC 6877 prévient qu’il ne remplace pas toutes les fonctions d’IPv4 : les connexions entrantes et certains échanges entre pairs restent hors de son modèle limité.

Une panne peut donc se loger entre les étapes sans contredire l’option 108. Le terminal a correctement refusé le bail, mais PREF64 n’est pas annoncé. Le préfixe est bon, mais le routage vers le traducteur est cassé. NAT64 répond, mais une politique bloque des en-têtes d’extension IPv6. Un navigateur réussit en IPv6 natif tandis qu’une application métier attend un socket IPv4 que CLAT n’a pas créé.

Le protocole a fourni un choix ; le système n’a pas fourni le service. L’incident doit nommer cette différence.

Ce que la double pile masquait

Avec la double pile, Happy Eyeballs peut contourner une mauvaise route IPv6 sans que l’utilisateur le remarque. Cette tolérance est utile, mais elle transforme parfois la réussite en faux certificat de santé. Lorsque le bail IPv4 disparaît, le défaut ancien devient visible.

Le projet 6MOPS organise cette découverte en étapes : annoncer PREF64, activer ensuite l’option côté serveur, puis, si l’administration des terminaux le permet, avancer appareil par appareil. Il avertit que certains systèmes traitent déjà l’option 108 par défaut ; l’activation sur le serveur les fait basculer immédiatement. Une modification apparemment limitée au DHCP peut donc toucher tout un sous-réseau.

La présentation de Jen Linkova à l’IETF 118 racontait un déploiement dans des bureaux Google : sites pilotes, extension graduelle et pourcentages augmentés par paliers. Les réductions d’utilisation DHCP et les récupérations d’adresses qu’elle annonçait sont des résultats attribués à cette présentation, non des statistiques universelles. L’enseignement généralisable est le dispositif d’essai : petite cohorte, observation, élargissement, retour disponible.

La mise en œuvre devient ainsi une critique de la documentation. Si la séquence recommandée échoue, le journal explique où. Un texte, même normatif, ne transforme pas une mauvaise application en succès par simple publication.

Mesurer une demande conditionnelle

Chaque bail refusé laisse une adresse disponible. Sur un réseau où les terminaux reçoivent des IPv4 publiques, le gain porte directement sur la consommation publique. Avec des adresses privées RFC 1918, il peut retarder l’épuisement interne ou une couche supplémentaire de NAT. Un nouveau segment peut démarrer avec un pool plus petit ; un ancien segment doit parfois être renuméroté avant que l’espace libéré puisse être réaffecté.

Mais la donnée économique demeure conditionnelle. Elle signifie qu’une interface, avec ce logiciel, cette politique et ces services de traduction, n’a pas pris d’adresse pendant un intervalle. Elle ne signifie ni que toutes ses applications ont fonctionné, ni qu’elle refusera sur un autre réseau, ni que les appareils restants n’ont plus de besoin légitime. Plus le refus devient fréquent, plus la valeur de l’adresse peut se concentrer sur les usages qui ne peuvent pas l’éviter.

Le tableau de bord doit donc éviter le pourcentage unique. Compter les demandes d’option 108, les offres valides, les adresses effectivement refusées, les retours ultérieurs, les pannes par classe d’application, la santé de NAT64 et le volume d’espace rendu réellement réutilisable. Un bail libéré mais prisonnier d’un plan d’adressage inchangé n’est pas encore une ressource récupérée.

L’horloge de cinq minutes a une vertu analytique : elle oblige le réseau à reposer la question. La demande IPv4 n’est ni niée ni présumée. Elle est observée, sous conditions et avec une porte de retour.

La place documentée de Jen Linkova

La RFC 8925 porte quatre noms : Lorenzo Colitti, Jen Linkova, Michael C. Richardson et Tomek Mrugalski. Linkova apparaît aussi sur la RFC 8781, la RFC 9872 et le projet 6MOPS avec d’autres auteurs. Cette continuité établit une contribution collective aux mécanismes d’exploitation IPv6. Elle ne prouve ni une invention individuelle, ni un contrôle sur les systèmes d’exploitation, ni une autorité sur les réseaux qui les déploient.

Cette limite est cohérente avec le mécanisme. Aucun organisme ne certifie qu’un terminal doit renoncer à IPv4. Le client demande, le pool configuré répond, le code s’exécute et les résultats apparaissent dans les baux et les incidents. Les appareils non participants continuent comme avant.

La contribution durable n’est donc pas une prophétie sur la mort d’IPv4. C’est un moyen minimal de demander, pendant une durée limitée, si une adresse peut rester en réserve — et d’accepter la réponse du réseau lorsqu’elle est non.

Sources