Résumé

  • L'IESG a ouvert le 22 septembre une dernière consultation sur la version 12 du projet d'attribution automatique d'adresses multicast IPv6, en vue d'une norme proposée. Les observations sont attendues au plus tard le 6 octobre.
  • Le logiciel sonde un enregistrement PTR par mDNS et déduit de l'absence de conflit que l'adresse est libre. Un filtrage sur l'hôte ou dans le réseau peut masquer la réponse qui aurait contredit cette déduction.
  • Le texte juge les collisions peu probables dans la plupart des réseaux ; il ne décrit ni panne constatée ni attaque courante.

Une réponse qui n'arrive pas et une réponse qui n'existe pas produisent le même résultat à l'écran. C'est là que se situe l'enjeu du projet examiné par l'IETF. L'application tire au sort un identifiant de groupe multicast, interroge le voisinage au moyen de mDNS puis avance si aucun conflit ne lui est signalé. La fiabilité de cette démarche repose sur la visibilité des autres participants, non sur la seule qualité du tirage.

La version 12 précise le mécanisme : l'identifiant IPv6 correspond à une adresse multicast Ethernet ; un enregistrement PTR est construit sous 9.3.3.3.3.eth-addr.arpa, domaine spécial dont la réservation est demandée, et non déjà acquise. Après la sonde viennent l'annonce et une interrogation continue pour repérer les conflits ultérieurs. Le perdant d'un conflit détecté cesse d'émettre sur le flux concerné et choisit un autre identifiant.

Le projet appelle « disponibilité implicite » l'hypothèse selon laquelle aucune objection reçue vaut adresse disponible. Il avertit explicitement qu'un filtrage des messages mDNS par l'hôte ou le réseau empêche la coordination et peut provoquer une collision. L'absence d'autorité centrale ne signifie donc pas absence de maîtrise locale : l'administrateur qui décide quels messages traversent le réseau agit aussi sur la qualité de l'information disponible pour les applications.

La portée du risque doit rester mesurée. La section sécurité estime qu'une collision est déjà peu probable dans la plupart des réseaux, si bien qu'un acteur filtrant mDNS ne dispose généralement pas d'une attaque pratique. Le protocole suppose des hôtes coopératifs. Après réparation d'une partition, la détection d'un conflit peut aussi tarder ; ce délai particulier ne doit pas être confondu avec la perte préalable des messages de sonde.

La consultation ouverte le 22 septembre se termine le 6 octobre. Elle n'a pas encore produit de RFC approuvé. Pour qui envisage le dispositif, la question utile est de savoir si les sondes PTR, annonces et réponses de conflit atteignent réellement les appareils appelés à partager la même plage. La promesse « sans configuration » reste conditionnelle à cette circulation.

Sources