Résumé

  • L’option 108 permet à un client IPv6-only de demander à ne pas recevoir d’adresse IPv4 ; le serveur ne répond que sur un pool configuré IPv6-mostly.
  • Le projet ne fixe aucun test universel de compatibilité. L’opérateur choisit les appareils, la sortie de secours et les pannes qu’IPv4 masquait.

Un serveur DHCP ne peut pas examiner les applications d’un ordinateur et certifier que la journée de son utilisateur survivra sans IPv4. L’option 108 n’essaie pas. Elle permet à un client compatible de signaler qu’il est prêt à renoncer à une adresse IPv4. À l’opérateur de décider où ce signal sera accepté.

C’est le point de bascule de la version 12 du projet IETF sur les réseaux IPv6-mostly, mise à jour le 29 octobre et en dernier appel de l’IESG jusqu’au 12 novembre. Le projet place des appareils IPv4 et IPv6-only sur le même segment. Un client qui demande l’option 108 et la reçoit dans un DHCPOFFER ne devrait pas demander l’adresse IPv4 proposée. Un appareil qui ne connaît pas l’option peut toujours en recevoir une depuis un pool configuré pour IPv6-mostly.

L’option est un signal, pas un test de compatibilité. Le projet précise que « compatible IPv6-only » n’a pas de définition technique stricte. Il s’agit d’un appareil capable de fonctionner sans IPv4 native et d’offrir la même expérience à l’utilisateur. Ses applications peuvent utiliser des sockets IPv6 et joindre uniquement des destinations IPv6 ; NAT64 peut leur donner accès aux destinations IPv4-only ; ou l’appareil peut exécuter CLAT, le traducteur côté client défini par RFC 6877, pour les applications IPv4 anciennes. Dans RFC 8925, déclarer une interface compatible relève déjà d’un choix de politique. Le projet -12 reprend cette conséquence : l’échange DHCP ne révèle pas l’aptitude de l’appareil. Quelqu’un doit décider quels appareils, interfaces ou groupes d’utilisateurs peuvent l’affirmer.

Le rôle du serveur est limité. RFC 8925 exige que le client ait demandé l’option et que le pool choisi soit explicitement configuré IPv6-mostly. La valeur de quatre octets indique combien de secondes le client doit désactiver DHCPv4. Le serveur transmet le délai V6ONLY_WAIT configuré ; sans délai défini, il envoie zéro. C’est donc la configuration du pool, et non l’étiquette optimiste du client, qui détermine où l’adresse disparaît.

Les destinations IPv4-only ont toujours besoin d’un chemin. Le projet s’appuie sur NAT64 et sur le signalement du préfixe au moyen des annonces de routeur de RFC 8781, de DNS64 selon RFC 6147, ou des deux. Un client dont les applications ne prennent pas IPv6 en charge peut avoir besoin de CLAT. Si l’appareil, le DNS, le traducteur ou le réseau d’accès se trompe, le repli dual-stack qui cachait la panne a disparu.

Le calendrier de migration compte donc davantage que le numéro de l’option. Le projet -12 conseille un pilote sur inscription volontaire, puis une phase de sortie volontaire lorsque l’opérateur active le signalement PREF64 et l’option 108. Il envisage même que les utilisateurs doivent signaler un problème pour sortir du dispositif. Cela donne un signal de panne utile ; cela fait aussi de la personne touchée le premier banc de test. Le projet qualifie par ailleurs le blocage IPv4 par liste de contrôle d’accès de solution provisoire : l’opérateur doit maintenir à jour ses règles par appareil, surtout lorsque les appareils se déplacent.

Le projet ne fournit ni décompte des déploiements ni données de panne observée, donc il ne permet pas d’établir les économies d’adresses ou l’expérience vécue. Son argument est architectural : un réseau partagé peut cesser d’attribuer IPv4 aux clients prêts à s’en passer, tout en conservant cette adresse pour les autres. La question d’exploitation reste entière : comment prouver qu’un appareil est « prêt » avant que le service d’assistance apprenne la réponse application par application ?

Sources · RFC 8925 · RFC 6877 · RFC 8781 · RFC 6147