Résumé

  • La version 03 du brouillon individuel de Mark Smith ajoute une option pour les clients qui exigent l’option DHCPv4 Routeur 3 : leur propre adresse DHCP ou 127.0.0.1.
  • Le texte prévoit que ces valeurs garderont les paquets IPv4 non locaux dans l’hôte et déclencheront une erreur ICMP Destination Unreachable. C’est une proposition, pas un résultat d’interopérabilité publié.
  • Les tests évoqués par le blog de LACNIC le 2 octobre portaient sur la version 02, avant l’ajout de cette solution.

Analyse

Une passerelle par défaut est censée mener ailleurs. Une nouvelle révision d’un brouillon DHCPv4 suggère que, pour certains clients anciens, le champ peut au contraire renvoyer vers le client lui-même.

Le 16 octobre, Mark Smith a publié la version 03 de « Nearly IPv6 Only Dual Stack Hosts ». La version 02 avait expiré le 15 juin. Le texte mis à jour conserve l’approche initiale pour les clients qui acceptent l’absence de l’option DHCP Routeur 3, mais ajoute un autre chemin pour ceux qui l’exigent : fournir comme valeur l’adresse attribuée au poste, ou 127.0.0.1.

Ces valeurs ne sont pas des passerelles ordinaires. La RFC 2132 définit l’option 3 comme la liste des routeurs envoyée par le serveur DHCP. Le brouillon indique qu’avec un masque /32, une adresse qui renvoie à l’hôte devrait empêcher les paquets vers d’autres réseaux IPv4 de le quitter et provoquer une réponse ICMPv4 Destination Unreachable. C’est une affirmation sur le comportement du client. Le texte ne donne pas de matrice de tests montrant quels systèmes acceptent chacune des valeurs, quelles routes ils installent ou si les applications réessaient ensuite en IPv6.

Les résultats antérieurs ne peuvent pas combler ce manque. L’article d’Alejandro Acosta publié le 2 octobre sur le blog de LACNIC renvoie à la version 02. Il mentionne des essais sur Windows 11, Fedora 43, Raspberry Pi OS fondé sur Debian Trixie, Chromecast et Google Nest. Il précise que les smartphones n’avaient pas été testés et appelle à des essais supplémentaires. Ces tests sont antérieurs à la version 03 : ils ne valident pas sa nouvelle branche Routeur.

Il faut vérifier davantage que la capacité du serveur DHCP à transmettre une valeur. Un pilote devrait comparer les deux adresses proposées selon le client, la version du système et la configuration du serveur ou du relais. Il faudrait conserver le DHCP ACK, examiner la table de routage installée, capturer les paquets vers des destinations IPv4 hors hôte, vérifier l’erreur ICMP reçue par l’application et observer si celle-ci bascule vers IPv6. Les destinations du même lien méritent un contrôle séparé : bloquer l’accès routé ne prouve pas ce que les applications locales peuvent encore joindre.

Cette proposition côtoie l’option DHCPv4 108 sans la remplacer. La RFC 8925 permet à un hôte compatible d’indiquer qu’il préfère un fonctionnement IPv6 uniquement pendant une durée donnée. Le brouillon vise plutôt les clients incapables d’utiliser cette option ou qui continuent d’attendre une réponse DHCPv4. L’enjeu de la version 03 est donc la compatibilité, pas l’apparition d’une nouvelle norme.

Datatracker classe le texte comme Internet-Draft individuel actif, sans flux RFC et avec l’état IESG « I-D Exists ». Le document précise qu’il n’est pas approuvé par l’IETF et n’a aucun statut formel dans son processus de normalisation. Il indique un statut visé Informational et une expiration au 19 avril 2027. Une nouvelle version montre que la proposition est entretenue ; elle ne prouve pas son adoption par l’IETF ou les éditeurs de systèmes d’exploitation.

Pour les équipes réseau, cette branche est une hypothèse à tester, pas un réglage prêt au déploiement. Les valeurs « adresse de l’hôte » et « boucle locale » doivent rester deux cas distincts dans un pilote limité, jusqu’à la publication de résultats sur les routes et le repli des applications. Une négociation DHCP réussie prouverait seulement qu’un bail a été remis. Il reste à vérifier le comportement réel de l’hôte.

Sources