Résumé

  • draft-ietf-pim-ipv6-zeroconf-assignment-12 autorise une application à présumer une adresse libre lorsqu’aucune indication d’occupation ne lui parvient. Cette preuve négative s’arrête aux interfaces, liens et relais mDNS réellement observables.
  • Un identifiant conservé en mémoire stabilise la configuration sans dispenser de sonder, annoncer, interroger en continu et défendre le PTR. Après la réparation d’une partition, le perdant doit couper le flux, changer d’identifiant et le mémoriser à nouveau.

Le texte date du 22 septembre 2026. Dans la copie figée de Datatracker, il s’agit d’un Internet-Draft actif du groupe PIM, transmis à l’IESG et en Last Call jusqu’au 6 octobre, avec Proposed Standard comme statut visé. Il ne s’agit ni d’un RFC, ni d’attributions IANA achevées, ni d’une validation d’interopérabilité.

La mécanique commence par un tirage aléatoire. Pour un nouveau flux, ou après une collision, l’application choisit un identifiant dans la plage proposée 0x90000000–0x9FFFFFFF. Elle en déduit une adresse multicast IPv6 de portée lien, liée à l’interface source, puis l’adresse multicast Ethernet correspondante. Dans l’exemple du projet, 9abc:def0 conduit à 33:33:9A:BC:DE:F0.

Cette adresse Ethernet est ensuite écrite à rebours, chiffre hexadécimal par chiffre, sous .eth-addr.arpa. L’application construit un PTR unique, le sonde au moyen de mDNS, l’annonce, répond aux questions, maintient une requête continue et le défend. L’ambition est limitée et utile : obtenir une unicité locale sans serveur d’allocation central.

Le point de contrôle est toutefois fondé sur une absence. La révision 12 nomme ce choix « implicit availability ». Si l’application ne reçoit aucun signe d’utilisation, elle suppose que l’adresse est disponible. Le paragraphe suivant prévient que tout filtrage de mDNS par l’hôte ou par le réseau empêche la coordination et peut produire une collision.

Une absence de réponse n’a donc de valeur qu’accompagnée de son périmètre. Elle dit qu’aucun PTR contradictoire n’a traversé tel ensemble d’interfaces et de chemins pendant telle fenêtre. Elle ne dit rien d’un émetteur masqué par un filtre, d’un relais défaillant ou d’un segment isolé. La probabilité n / 2^28 donnée par le projet concerne le tirage aléatoire ; elle ne mesure pas la qualité de l’observation.

La partition révèle la différence. Une panne de commutateur sépare le réseau. D’un côté, un équipement reprend l’identifiant sauvegardé de son flux. De l’autre, un nouvel émetteur choisit le même. Les deux sondages aboutissent sans conflit parce que le message adverse ne franchit plus la coupure. Chacun dispose d’une vérité locale cohérente.

Lorsque la connectivité revient, les deux vérités deviennent incompatibles. La requête PTR continue est obligatoire précisément pour repérer cette collision après réparation. Le règlement mDNS désigne un perdant ; celui-ci arrête le flux, retourne à la sélection aléatoire et remplace la valeur stockée par la nouvelle.

Le projet reconnaît un délai gênant. mDNS est conçu pour consommer peu de bande passante et peut mettre un temps important à détecter la collision après le rétablissement. Aucun délai maximal universel n’est promis. Dans un environnement où de nouveaux flux apparaissent à tout moment, la fenêtre est plus préoccupante que dans un réseau où tous les identifiants ont été fixés avant la partition.

Pendant cette fenêtre, les tableaux de bord peuvent montrer deux succès. Au niveau Ethernet, deux destinations IPv6 différentes peuvent partager la même adresse multicast. Un voyant « PTR annoncé » ne distingue pas une attribution réellement unique d’une attribution simplement isolée de sa contradiction.

La révision 12 permet alors un second capteur. La pile réseau de l’hôte peut observer des paquets ayant la même adresse Ethernet de destination mais une autre destination IPv6. Si elle les voit, l’application doit cesser d’émettre et choisir un nouvel identifiant. Une seule partie doit céder, les deux peuvent le faire, et le projet ne définit aucun arbitrage entre les hôtes.

L’infrastructure dispose aussi d’un veto. Un composant qui détecte une collision qu’il ne peut résoudre publie un PTR dont la première étiquette cible reçoit le suffixe -veto. Cette construction le rend toujours postérieur dans l’ordre lexical utilisé par la résolution de conflit mDNS ; le veto gagne donc. Il est publié sans sondage et force l’application à migrer.

Ce pouvoir s’éteint lorsque son motif disparaît. Après la disparition ou l’expiration du PTR en cause, l’émetteur du veto interroge le réseau pendant cinq secondes. Faute de réponse, il attend aléatoirement 20 à 120 millisecondes puis envoie un goodbye. Le veto n’a pas besoin d’être conservé : l’application déplacée a déjà mémorisé son nouvel identifiant.

Le même mécanisme ouvre une voie au déni de service. Un acteur malveillant peut fabriquer des réponses conflictuelles pendant le sondage ou opposer des veto à des adresses déjà utilisées. Il peut provoquer des arrêts et des sélections répétées. S’il contrôle un filtre mDNS, il peut neutraliser la prévention des collisions. Le protocole suppose des participants coopératifs ; il ne leur confère pas cette qualité.

La persistance mérite la même discipline. Réutiliser l’identifiant d’un flux évite une agitation inutile lorsque le réseau n’a pas changé. Mais la révision 12 précise que la valeur stockée ne permet d’omettre aucune étape antérieure. L’application doit sonder et annoncer à nouveau, lancer sa requête continue et défendre le PTR. La mémoire atteste un usage passé, pas la continuité du domaine d’observation.

C’est là que la primauté du code en fonctionnement apporte une lecture plus exigeante. Le fait décisif n’est pas une ligne de base de données marquée « attribuée », mais une suite d’actions vérifiables : sélection, dérivation, sondage, annonce, surveillance, défense, arrêt et remplacement. Un identifiant stable peut masquer une topologie devenue instable.

Il faut aussi séparer coordination et découverte. Le PTR sert ici à coordonner une adresse. Le projet ne prescrit pas la publicité de l’adresse du flux ; DNS-SD avec un service _udp et un TXT n’est qu’une option naturelle. Une découverte réussie ne prouve ni l’adhésion d’un récepteur, ni l’état de transfert, ni la livraison, ni le traitement applicatif.

Sur plusieurs sous-réseaux, les PTR doivent être distribués, par exemple avec un réflecteur mDNS, domaine que le projet qualifie encore de recherche. Les flux acheminés au-delà du lien doivent employer une adresse multicast IPv6 fondée sur un préfixe unicast. Enfin, la dépendance à des hôtes coopératifs rend le mécanisme impropre à l’Internet mondial.

La couche commune doit rester mince. Elle peut produire une coordination locale tant que les participants s’entendent. Elle ne doit pas devenir une autorité générale sur la disponibilité du service. Le registre d’exploitation doit conserver l’identifiant, l’interface source, les deux adresses dérivées, l’époque de persistance, les interfaces sondées, la portée des relais, les filtres, la partition, le conflit ou veto, l’arrêt et la nouvelle sélection. L’adhésion, le transfert, les paquets et le résultat applicatif viennent ensuite, chacun avec sa propre preuve.

Le silence n’est exploitable qu’avec la liste de ceux qui auraient pu le rompre. Sans cette liste, une adresse ne reste libre que jusqu’au moment où le réseau redevient entier.

Sources