Résumé

  • Un masque DHCPv4 en /32 et l’absence d’option routeur peuvent satisfaire un client ancien tout en supprimant sa route IPv4 ordinaire vers l’extérieur.
  • Le poste peut cesser ses requêtes répétées, mais il conserve un bail unique et peut encore recevoir des paquets sur son lien.

Faire taire une requête ne rend pas l’adresse au pool

Un ancien poste à double pile peut continuer à demander IPv4 alors que l’exploitant souhaite que ses applications passent par IPv6. Ne plus répondre peut laisser le client renouveler ses demandes DHCPv4 sans succès. Le billet technique publié par LACNIC le 2 octobre présente une réponse plus ciblée, tirée d’un Internet-Draft individuel : répondre avec des paramètres DHCPv4 classiques, puis configurer l’interface sans route IPv4 ordinaire vers les destinations hors lien.

L’option 1 DHCPv4 fournit le masque 255.255.255.255, soit /32. Le serveur ne transmet pas l’option 3, qui indiquerait un routeur. Avec ce masque, toute autre destination IPv4 est extérieure au lien. Sans routeur annoncé, le poste ne dispose pas du prochain saut nécessaire. Il obtient la configuration demandée et peut arrêter ses recherches répétées, mais ne gagne pas pour autant une route IPv4 utilisable vers l’extérieur.

Cela ne désactive pas complètement IPv4. L’interface configurée conserve une adresse et continue d’utiliser DHCPv4. Le poste peut avoir d’autres interfaces, une route statique, un tunnel ou des applications au comportement différent. Une application peut réessayer en IPv6 après l’échec IPv4, mais le draft décrit un comportement attendu, pas une garantie pour toutes les piles logicielles.

Une concession unique reste nécessaire

Le draft souligne le coût que le mot « presque » peut cacher : le serveur DHCPv4 doit toujours attribuer une adresse unique à chaque hôte d’un même lien. On ne peut pas normalement remettre la même adresse à tous les clients silencieux d’un segment. La détection de conflits peut sonder l’adresse avant usage. Si deux clients la reçoivent, le conflit peut apparaître ; la réattribution répétée de la même adresse peut provoquer une boucle de DHCPDECLINE.

Le bruit peut donc diminuer sans que l’allocation disparaisse. Le bail reste dans le pool jusqu’à sa libération ou son expiration. RFC 2131 définit l’allocation dynamique comme une attribution limitée dans le temps, réutilisable lorsqu’elle n’est plus nécessaire. Une concession active n’est ni une mesure de trafic ni la preuve qu’une adresse est redevenue disponible.

Le coût dépend du pool. Une adresse IPv4 publique rare conserve un coût d’opportunité tant que le bail reste actif, même si le poste ne peut pas l’utiliser pour joindre normalement une destination distante. Le draft évoque aussi les adresses link-local ou RFC1918. Un pool privé dédié peut préserver la capacité publique, mais il faut encore une adresse unique par hôte, un suivi des baux, une gestion des conflits et une vérification des chevauchements avec le plan privé existant.

La réutilisation d’un même pool entre liens distincts est limitée aux cas où le serveur DHCP est directement rattaché à chaque lien. Avec un relais DHCP, le serveur s’appuie sur l’adresse du relais pour choisir le pool ; le draft exige donc un pool unique à l’échelle du réseau relayé. Oublier cette frontière peut transformer une économie théorique en erreur d’allocation.

Un bail plus long réduit le renouvellement et prolonge la réservation

Le draft envisage des baux d’un jour ou de plusieurs semaines : ces hôtes ne devraient pas joindre de destinations externes en IPv4, et un pool local ou privé peut être vaste. Une durée plus longue réduit les renouvellements et la charge du serveur, mais prolonge aussi la réservation. Dans un pool public rare, moins de messages DHCP ne signifie pas automatiquement plus d’adresses disponibles. Il faut suivre les requêtes et les journées-adresses ensemble. C’est une déduction opérationnelle, pas un résultat mesuré dans le billet.

L’option 108 offre une autre voie. RFC 8925 normalise IPv6-Only Preferred pour les clients compatibles dans un réseau IPv6-mostly configuré à cette fin. Lorsque client et serveur prennent en charge le mécanisme, le client peut renoncer à une adresse IPv4. Cela peut préserver le pool. Le /32 sans routeur vise les clients qui ne comprennent pas l’option 108 ; le draft indique que les deux méthodes peuvent coexister. Ni l’une ni l’autre ne prouve à elle seule que les applications, DNS64/NAT64 ou services nécessaires fonctionnent.

Pas de route par défaut ne signifie pas pare-feu

L’absence d’option routeur retire le chemin habituel vers les destinations IPv4 hors lien, mais ne rend pas l’interface invisible. La section sécurité du draft précise qu’un autre hôte du lien peut encore envoyer des paquets IPv4 au poste doté du masque /32. Elle recommande un pare-feu local qui n’autorise sur cette interface que le DHCPv4 entre le client et le serveur ou le relais.

« Ne peut pas établir une connexion IPv4 routée vers l’extérieur » et « ne peut recevoir aucun paquet IPv4 » sont deux affirmations différentes. La première découle du routage proposé. La seconde ne découle pas du masque. Une politique d’entrée explicite reste nécessaire si des services locaux sont actifs ou si le même appareil est joignable autrement.

Ce que les sources montrent

Le billet LACNIC indique que son auteur, Alejandro Acosta, a essayé la méthode avec Windows 11, Fedora 43, Raspberry Pi OS fondé sur Debian Trixie, Chromecast et Google Nest. Les smartphones n’ont pas été testés et l’auteur appelle à des essais plus larges. Il s’agit d’expérimentations rapportées, pas d’une réplication indépendante, d’un échantillon représentatif ou d’une preuve de déploiement en production. Le billet précise que les opinions de ses auteurs ne reflètent pas nécessairement celles de LACNIC.

Le document cité est la version 02 d’un Internet-Draft individuel. Le Datatracker de l’IETF indique qu’il a expiré le 15 juin 2026 et n’a pas de statut formel dans le processus de normalisation de l’IETF. L’expiration ne prouve pas un rejet technique ; le draft n’est pas une norme approuvée. Les sources examinées ne publient ni baisse mesurée des broadcasts DHCP, ni évolution de l’occupation des pools, ni résultat de bascule applicative, ni audit de sécurité entrant.

Un opérateur qui teste la méthode devrait publier séparément les demandes répétées par cohorte, les baux actifs et journées-adresses par pool public, privé et link-local, les libérations, expirations et DHCPDECLINE, les limites des relais et des liens, la réussite d’applications IPv6 sur un échantillon et la politique de filtrage entrant. Bruit réseau, adresses récupérées, applications fonctionnelles et exposition maîtrisée sont des résultats différents.

Sources :