Résumé

  • Le projet actif du groupe INTAREA, signé Remco van Mook, propose 192.0.0.11/32 comme sentinelle : un hôte mis à jour n’effectue pas d’ARP vers cette adresse et prend le MAC du routeur IPv6 sélectionné.
  • Le paquet reste un paquet IPv4 natif, sans tunnel ni traduction. Le chemin retour exige néanmoins une route /32 vers l’hôte et un prochain saut IPv6 routable.
  • La sobriété du mécanisme relie plusieurs états : configuration DHCP, annonces de routeur, cache de voisinage, transfert IPv4, route retour et compatibilité ARP des anciens hôtes.

Une consigne déguisée en adresse

Il faut résister au vocabulaire apparent. La valeur inscrite comme passerelle IPv4 n’est pas censée être jointe, testée ou annoncée comme une véritable interface. Elle agit localement sur la pile de l’hôte : pour la route par défaut, ne demande pas « qui possède cette IPv4 ? » ; consulte plutôt la liste des routeurs IPv6 de cette interface.

L’hôte conserve son adresse IPv4, les applications leurs sockets IPv4 et les routeurs leurs paquets IPv4. Seule la résolution du premier saut change. L’hôte choisit un routeur par défaut IPv6, retrouve son entrée dans le cache de voisins, puis place le MAC correspondant devant le paquet IPv4. Il n’y a ni NAT64, ni encapsulation, ni sous-réseau IPv4 caché.

Adopté comme document de travail INTAREA en août 2026, le texte demeure un Internet-Draft susceptible d’évoluer. Il rapporte des essais sans modification des applications ni du client DHCPv4 sous Windows 11, macOS, Android, iOS, Linux, FreeBSD et ChromeOS. Cette liste est une observation des auteurs, pas une certification indépendante ; elle ne transforme pas encore 192.0.0.11 en norme universelle.

Le trajet aller ne prouve pas le retour

Le bail DHCP atteste que la consigne a été livrée. Il ne dit pas qu’une Router Advertisement a été reçue. Avant la première RA, aucun routeur IPv6 légitime n’existe pour fournir le prochain saut ; l’attente doit donc être bornée. Ensuite, la préférence définie par le RFC 4191, l’état d’accessibilité et enfin le choix propre à l’implémentation départagent les candidats.

Le cache de voisinage porte une deuxième preuve. Les états reachable, stale, delay ou probe du RFC 4861 décrivent une connaissance utilisable avec des degrés différents. Un MAC encore mémorisé ne certifie pas que l’équipement transfère actuellement l’IPv4. À l’inverse, un routeur capable de le faire reste inutile si l’annonce ou l’état ND a expiré.

L’asymétrie la plus importante apparaît au retour. Une adresse IPv6 link-local suffit au premier saut sortant de l’hôte. Elle ne peut pas servir de prochain saut entre routeurs. Le réseau doit donc annoncer l’IPv4 /32 de l’hôte avec une adresse IPv6 GUA ou ULA routable. Le RFC 8950 fournit le format BGP pour une NLRI IPv4 accompagnée d’un prochain saut IPv6 ; le projet v4-via-v6 développe la mécanique entre routeurs.

Un test sortant réussi n’est ainsi qu’un reçu. Il faut aussi vérifier l’acceptation du bail, le routeur choisi, le MAC obtenu par ND, la capacité de ce routeur à transférer de l’IPv4 natif et la présence de la route /32 sur le retour.

Le masque /32 protège la frontière

Un préfixe plus large ferait croire à l’hôte que d’autres destinations IPv4 se trouvent directement sur le lien. Il recommencerait alors à émettre de l’ARP. Le /32 n’est donc pas une préférence cosmétique : il empêche le retour accidentel d’une adjacency IPv4.

De même, la sentinelle ne doit pas être redistribuée dans le routage ni apparaître comme source ou destination d’un paquet transmis. Elle n’a aucune identité opérationnelle au-delà de l’interface locale. Le projet rapproche ce modèle des adresses individuelles et passerelles hors lien utilisées dans certains hébergements, en citant Hetzner, OVH et Scaleway. Ces exemples, attribués au projet, illustrent le besoin de supprimer des contournements propres aux systèmes ; ils ne prouvent pas que ces opérateurs utilisent déjà la nouvelle sentinelle.

Le RFC 8925 propose aux clients capables de préférer un accès IPv6-only. Ici, le compromis est différent : garder un service IPv4 natif pour les hôtes dual-stack tout en retirant le sous-réseau et l’ARP IPv4 du segment. Les deux outils peuvent participer à un réseau « IPv6-mostly », sans que l’un valide automatiquement l’autre.

Deux générations d’hôtes, deux chemins

Un système ancien ne comprend pas la consigne. Il envoie un ARP vers 192.0.0.11. Le projet recommande au routeur de répondre avec son propre MAC, afin que les machines nouvelles et anciennes partagent le segment. Ce filet de compatibilité est pragmatique, mais il brouille le diagnostic si tout est agrégé.

Le succès d’un ancien client prouve que le répondeur ARP fonctionne, pas qu’un client récent a suivi la bonne RA. Le succès d’un client récent ne garantit pas que le niveau historique a été préservé. Il faut des sondes, des compteurs et des objectifs séparés.

Les minutes d’IETF 126 rendent ce risque concret. Lorenzo Colitti a demandé si l’IPv4 devait suivre les changements de routage IPv6 et a signalé qu’une mauvaise implémentation pouvait casser l’IPv4. Remco van Mook a confirmé cette dépendance. Tobias Fiebig a jugé l’idée élégante face au DHCPv4 transporté dans DHCPv6. L’élégance réduit le protocole visible ; elle ne supprime pas les jointures internes.

Le code montre aussi ce qui manque

Le dépôt public v4-with-v6-nh contient un démon Linux : il détecte la sentinelle, applique la préférence RFC 4191, installe une route IPv4 via un prochain saut IPv6, suit les changements de routeur et retire la route si la condition disparaît. Le noyau Linux sait représenter ce type de route depuis la version 5.2.

Les limites documentées comptent autant que la démonstration. Le démon ne peut pas mettre en attente chaque paquet avant la première RA ; son comportement de démarrage reste donc une approximation. L’intégration systemd-networkd passe par un correctif, la syntaxe FreeBSD a été validée sans test réel, les configurations d’équipements commerciaux n’ont pas été vérifiées sur matériel et aucun jalon de version n’est publié.

La preuve actuelle établit la plausibilité du mécanisme, non sa maturité universelle. Un banc d’essai sérieux doit provoquer l’expiration DHCP, le retard de la première RA, le retrait du routeur préféré, un voisin stale, la disparition du retour /32, deux routeurs de même préférence et la coexistence de piles anciennes et nouvelles.

Déplacer la confiance plutôt que l’abolir

Supprimer l’ARP sur les hôtes capables réduit une surface d’usurpation et une part du bruit opérationnel. La confiance migre vers les RA et Neighbor Discovery. Une annonce erronée peut désormais choisir le MAC utilisé par l’IPv4 ; une panne ND peut couper les deux familles en même temps.

RA Guard, contrôle des ports, inspection du voisinage et préférences explicites deviennent donc des protections de disponibilité IPv4. Le scénario le plus dangereux est silencieux : diffuser la sentinelle sur un segment qui n’en implémente qu’une moitié. Certains serveurs ou relais DHCP peuvent également refuser cette passerelle hors lien avant le transfert. Dans les deux cas, l’acceptation de la configuration et l’aptitude à transporter du trafic sont deux décisions différentes.

Sources