Résumé

  • Microsoft a annoncé Windows CLAT pour Windows 11 Client 25H2, à partir de la build 26200.9550. Son billet décrit deux déclencheurs de découverte : l’absence de connectivité IPv4 et le signal IPv6-only de l’option DHCP 108.
  • À RIPE 93, Wilhelm Boeddinghaus a dit que l’option 108 active WinCLAT. Sans réponse DHCPv4, Windows signalait plutôt une erreur APIPA. Il comptait encore tester un service local qui envoie l’option sans attribuer d’adresse IPv4.

Analyse

« Généralement disponible » est un statut de version. Une réponse DHCP, elle, passe sur le réseau. Une entreprise ne peut pas prendre le premier pour preuve de la seconde.

Le besoin vient des applications anciennes. Un programme qui sait ouvrir une socket IPv6 peut joindre une destination IPv4 à travers NAT64. Celui qui exige une socket IPv4 a besoin d’un traducteur côté client. Dans 464XLAT, CLAT traduit sur le terminal et le PLAT/NAT64 du réseau achève le trajet. Windows nomme sa fonction WinCLAT.

Le billet Microsoft du 27 octobre place la fonction dans Windows 11 Client 25H2, build 26200.9550. Il parle de découverte de configuration quand IPv4 est indisponible, ou quand l’option DHCPv4 108 signale une préférence IPv6-only. Deux jours plus tard, Boeddinghaus a expliqué au groupe IPv6 de RIPE que la fonction avait quitté la préversion, mais qu’un administrateur devait encore la configurer. Il citait netsh et la stratégie de groupe Active Directory ; l’interface graphique ne proposait pas encore le réglage.

L’option 108 de la RFC 8925 est un message DHCPv4. Le client capable la demande ; un pool IPv6-mostly peut la lui renvoyer pour lui demander de renoncer à une adresse IPv4 pendant une durée bornée. Mais le client doit d’abord pouvoir parler au serveur.

Voilà le paradoxe de démarrage d’un bureau IPv6-only : si le serveur DHCPv4 est central et que le poste n’a plus de route IPv4, comment lui faire parvenir l’option ? Boeddinghaus a cité trois voies : un tunnel IPv4, qu’il juge peu élégant ; DHCPv4 transporté par DHCPv6, selon la RFC 7341 et le relais défini par la RFC 9928 ; ou un service DHCPv4 sans état sur chaque commutateur, qui envoie l’option 108 sans distribuer d’adresse.

La troisième solution attend encore son test sous Windows. Boeddinghaus disait qu’elle fonctionnait avec un autre client et qu’il voulait vérifier le comportement des différentes versions de Windows. En réponse à une question, il a indiqué qu’en l’absence de relais DHCPv4, Windows interprétait l’adresse APIPA comme une erreur et ne lançait pas CLAT. Le transcript ne nomme pas la build ni ne fournit de capture réseau.

La formule de Microsoft laisse une distinction ouverte. « Découverte de configuration » peut désigner la recherche du préfixe NAT64 après l’activation du traducteur ; dans le débat de RIPE, l’option 108 est le déclencheur de WinCLAT. Ces deux étapes peuvent être distinctes, ou dépendre de la build. Le compte rendu public ne tranche pas le cas d’une interface IPv6 sans aucune réponse DHCPv4.

Ce n’est pas la même question que le délai de retour d’IPv4 après l’option 108. Le compte à rebours commence une fois le signal reçu. Avant cela, il faut savoir si Windows active CLAT sans DHCPv4 et, sinon, quel service doit rester pour livrer l’option.

Avant de retirer un relais, l’opérateur doit reproduire l’essai sur la build qu’il déploie : relever la requête DHCPDISCOVER, une éventuelle réponse avec l’option 108, l’état IPv4, la découverte du préfixe NAT64, l’état de CLAT et un essai d’application IPv4 ancienne. Si l’absence de réponse suffit, la documentation doit le dire. Sinon, il faut transporter l’option par DHCPv6 ou la servir au niveau du commutateur.

Sources