Résumé

  • Le 18 août, l’IETF a approuvé la première version de groupe de travail du projet Unicast Local Discovery. Le contenu technique est identique à celui du projet individuel qu’elle remplace.
  • ULD propose qu’un serveur local préféré assure l’enregistrement et la découverte en unicast. Cette organisation peut réduire le poids du multicast sur le Wi-Fi, mais elle déplace aussi la dépendance vers le choix, la disponibilité et la vérification du serveur.

Le nouveau nom draft-ietf-dnssd-uld-00 peut donner l’impression d’un nouveau protocole. La réalité est plus précise : c’est un ancien texte qui entre dans une nouvelle chaîne de responsabilité.

L’historique du document de groupe horodate au 18 août, à 16 h 22 min 50 s UTC, l’approbation de la version -00, sa publication et son lien de remplacement avec draft-tlmk-infra-dnssd. Après retrait des en-têtes administratifs, des dates et du nom du fichier, les deux textes sont identiques. L’événement est donc l’appropriation formelle du travail par DNSSD, pas une modification normative cachée.

Cette appropriation arrive après une correction de procédure instructive. Dans l’historique du projet antérieur, le président du groupe explique qu’il avait d’abord considéré une démonstration à main levée lors de l’IETF 126 comme une adoption, avant de libérer le document pour organiser l’appel sur la liste de diffusion qui aurait dû précéder la décision. L’appel a été lancé le 21 juillet et l’adoption formelle enregistrée le 6 août. Le registre permet ainsi de reconstruire la décision sans transformer le consensus de groupe en validation du moindre détail technique.

Le problème décrit par le projet ULD se trouve dans de nombreux réseaux domestiques et professionnels. Avec mDNS, chaque appareil qui publie un service doit écouter et répondre en multicast. Sur un réseau Wi-Fi, ces trames ne sont ni acquittées ni retransmises au niveau MAC, ne sont pas mises en attente par le point d’accès pour une station endormie et sont émises à un débit obligatoire faible. Les terminaux sur batterie doivent se réveiller souvent ou accepter de manquer des requêtes.

ULD assemble quatre fonctions autour d’un serveur disponible en permanence : un registraire SRP, un serveur DNS faisant autorité, un proxy de découverte et un proxy de publication. Un client compatible enregistre ses services auprès de ce serveur, lui envoie ses requêtes .local en unicast et cesse normalement de participer lui-même à mDNS sur ce lien. Le serveur maintient le pont avec les appareils qui ne connaissent que le multicast.

Deux briques sont déjà normalisées. Le RFC 9665 décrit le protocole SRP, ses mises à jour signées et ses baux d’enregistrement. Le RFC 8766 décrit un proxy capable de répondre en DNS unicast à partir de services découverts sur des liens mDNS. ULD ne remplace pas ces mécanismes ; il définit comment les réunir, les annoncer et les sélectionner comme un service local cohérent.

Le RFC 6762 reste par ailleurs le socle de Multicast DNS. Le projet affirme qu’il le mettrait à jour s’il était approuvé, mais conserve .local, l’annonce du serveur par DNS-SD, les échanges avec les appareils mDNS et le retour au multicast en l’absence de serveur utilisable. Parler de « fin de mDNS » serait donc faux : le trafic courant peut migrer, pas l’ensemble du mécanisme de compatibilité.

Le choix du serveur constitue le véritable nouveau plan de contrôle. Sur un réseau administré, l’opérateur doit activer explicitement le statut de serveur d’infrastructure, et un seul équipement au plus doit annoncer l’option ULD dans ses Router Advertisements. Ce serveur reçoit la priorité la plus forte. Des serveurs ad hoc peuvent apparaître avec des priorités plus faibles ; les clients doivent continuer à rechercher un meilleur candidat, surveiller celui qu’ils utilisent et réenregistrer leurs services après une migration.

Cette convergence vers un seul serveur sert à traiter les conflits de noms. Si deux clients enregistrent le même nom auprès de deux serveurs indépendants, chacun peut accepter sa version avant que le conflit ne remonte au niveau multicast. Au lieu d’imposer une réplication entre serveurs, le projet demande aux clients de converger de façon déterministe. La complexité ne disparaît pas : elle se déplace vers la détection de panne, la préférence, la migration et la cohérence de l’état.

L’option Router Advertisement renforce cette dépendance. Les clients IPv6 doivent s’en servir pour découvrir le serveur d’infrastructure ou pour vérifier une annonce apprise via DNS-SD, de manière à ce que RA Guard puisse protéger la désignation. Les clients uniquement IPv4 ne disposent pas de ce signal et trouvent les serveurs par mDNS. Le serveur, lui, doit vérifier qu’une requête IPv4 .local provient d’un sous-réseau directement connecté.

Plusieurs éléments empêchent encore de qualifier ULD de solution achevée. La section Security Considerations contient seulement TODO. La partie relative aux routeurs SNAC n’est pas rédigée, et le nom de service demandé à l’IANA reste un paramètre fictif. Aucun résultat public ne démontre l’interopérabilité de clients et de serveurs indépendants, ni un gain mesuré d’autonomie, de temps d’antenne ou de fiabilité. Le texte reste un Internet-Draft, pas un RFC.

La charte DNSSD situe correctement l’enjeu. mDNS et DNS-SD sont largement utilisés, mais la portée locale du multicast ne répond pas seule aux réseaux routés ou composés de plusieurs liens ; élargir la découverte soulève en même temps des questions de sécurité et de vie privée. ULD commence par un service sur le lien. Même dans ce périmètre, le serveur préféré peut influencer la vue des services offerte à un terminal.

Le statut de groupe de travail ouvre donc la phase où cette influence doit devenir explicite et testable. Il ne prouve ni déploiement, ni performance, ni sécurité. Le signal vérifiable est plus modeste et plus utile : DNSSD a décidé de développer publiquement une voie unicast pour la découverte locale, et les dépendances qu’elle crée sont désormais examinables dans un document dont l’analyse de sécurité reste à compléter.

Sources