Résumé

  • L’application choisit un identifiant de groupe aléatoire, construit les destinations IPv6 et Ethernet, puis revendique cette dernière avec un PTR mDNS sous .eth-addr.arpa.
  • Un équipement réseau peut ajouter -veto au premier label de l’application : le nouvel enregistrement gagne toujours le départage mDNS et force l’émetteur à s’arrêter puis à choisir une autre adresse.
  • La révision 12 reste un Internet-Draft en Last Call ; ses allocations IANA sont demandées, non acquises, et le protocole ne chiffre ni n’authentifie le droit de veto.

Dans ce protocole, l’absence de réponse vaut disponibilité. Toute son économie dépend donc de la qualité du silence.

Publié le 22 septembre 2026, draft-ietf-pim-ipv6-zeroconf-assignment-12 propose d’attribuer des adresses multicast IPv6 locales sans serveur central. Le texte est en Last Call jusqu’au 6 octobre. Il n’est pas encore une RFC : la plage 0x90000000-0x9FFFFFFF, eth-addr.arpa et le domaine spécial 9.3.3.3.3.eth-addr.arpa. sont encore des demandes adressées à l’IANA.

L’application commence par tirer un identifiant de groupe sur 28 bits. Avec l’identifiant d’interface de la source, RFC 4489 permet de construire une adresse multicast IPv6 de portée lien. RFC 2464 fournit ensuite la destination Ethernet correspondante.

La seconde opération est décisive. Deux adresses IPv6 différentes peuvent aboutir à la même destination Ethernet. Le projet ne se contente donc pas de coordonner le nombre IPv6 : il transforme l’adresse que verront réellement le commutateur et la carte réseau en nom DNS. 33:33:9A:BC:DE:F0 devient ainsi 0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa.

Le PTR déclare, il ne possède pas

Sous ce nom, un PTR unique désigne l’identifiant de l’application suivi du nom d’hôte. L’application lance la procédure de probe de RFC 6762. Si deux candidats partent ensemble, le perdant du départage mDNS recommence avec un autre identifiant. Sans conflit, il annonce son PTR, répond aux requêtes et ouvre une requête continue destinée à détecter les conflits futurs. Il ne peut émettre qu’après cette séquence.

La valeur choisie est conservée en stockage persistant, mais elle ne devient pas un bail. Au redémarrage, toutes les étapes doivent être rejouées. Pendant l’arrêt, une partition a pu se refermer, un commutateur être remplacé ou une autre application sélectionner la même valeur. Le nombre mémorisé exprime une préférence historique, pas une autorité actuelle.

Si un conflit apparaît ensuite, le perdant arrête son flux avant de recommencer. La pile réseau peut aussi repérer deux destinations IPv6 différentes qui s’écrasent sur la même adresse Ethernet. Le projet exige alors un déplacement, sans définir comment plusieurs hôtes choisissent lequel cédera.

Le veto transforme une observation matérielle en ordre

Lorsqu’un composant d’infrastructure voit une collision qu’il ne peut pas résoudre, il publie un PTR de veto sous le même nom. Il ajoute -veto au premier label du PTRDNAME de l’application. La longueur du label apparaît avant son contenu dans la comparaison des RDATA : le label plus long se classe toujours après l’original et gagne donc systématiquement le conflit mDNS.

Le composant publie sans probe. L’application perdante s’arrête, choisit un nouvel identifiant et remplace la valeur enregistrée. Lorsque le PTR initial disparaît par expiration ou goodbye, le détenteur du veto interroge le réseau pendant cinq secondes ; sans réponse, il attend aléatoirement de 20 à 120 millisecondes puis retire son propre enregistrement.

Le résultat est une hiérarchie minimale. L’application propose. Les pairs contestent. L’infrastructure dispose d’un droit de substitution déterministe. Les récepteurs, eux, doivent toujours prouver que le nouveau flux leur parvient.

Un veto gagnant peut être faux

Comme mDNS, le mécanisme suppose des participants coopératifs. Un acteur hostile peut répondre à chaque probe ou forger des veto, provoquant arrêt et renumérotation en boucle. Un filtre mDNS produit le défaut inverse : plusieurs applications interprètent le même silence comme une permission.

Rien dans le protocole n’authentifie l’émetteur du veto comme le commutateur ayant réellement observé une collision. De même, un announce réussi ne prouve ni l’identité du producteur, ni l’autorisation du contenu, ni l’abonnement du récepteur, ni le résultat applicatif.

Il faut donc conserver la chaîne : identité du flux, group ID, interface source, destinations IPv6 et Ethernet, owner et RDATA du PTR, probe, announce, génération de la requête continue, auteur du conflit ou du veto, accusé d’arrêt, nouvelle adresse, migration des récepteurs et retrait de l’ancien enregistrement.

Une partition réparée ne réconcilie pas instantanément les faits

La requête continue aide à découvrir les doubles attributions après réparation d’une partition, mais le faible débit voulu de mDNS peut retarder la détection. Si de nouveaux flux naissent pendant l’isolement, la détection supplémentaire reste hors du périmètre du projet.

L’espace aléatoire réduit la fréquence des collisions ; il ne rend pas visible un paquet filtré et ne fusionne pas deux histoires locales. Pour plusieurs sous-réseaux, les PTR devraient être relayés et le flux utiliser une adresse multicast fondée sur un préfixe unicast plutôt que l’adresse locale. Le modèle coopératif n’est pas destiné à l’Internet mondial.

RFC 10019 avait défini le problème sans imposer de protocole ni de vainqueur. La révision 12 apporte la mécanique absente : un nom lié à l’adresse Ethernet, un cycle probe–announce–surveillance et un veto visible. À la lumière de la primauté du code en fonctionnement, chaque preuve doit rester à son étage. Le PTR décrit une prétention, le départage exécute une décision, le commutateur observe le matériel et l’application vérifie le résultat. La bonne nouvelle n’est pas la disparition du pouvoir ; c’est sa transformation en événement gouvernable.

Sources