Bonjour : que se cache derrière l'im­plé­men­ta­tion de Zeroconf ?

Pour que les appareils en réseau puissent com­mu­ni­quer entre eux, ils doivent d'abord établir une connexion. Pour entrer en contact, ils n'ont pas besoin du nom de l'ap­pa­reil, mais de , qui est en général, dans les réseaux im­por­tants, assignée au­to­ma­ti­que­ment aux abonnés par un (Dynamic Host Con­fi­gu­ra­tion Protocol). Il fonc­tionne avec un serveur DNS. Ce serveur est res­pon­sable de la con­ver­sion du nom de domaine en une adresse IP et vice versa. Il existe une al­ter­na­tive à cette at­tri­bu­tion au­to­ma­tique, qui consiste à ajuster les de tous les par­ti­ci­pants au réseau et d'entrer ma­nuel­le­ment les noms et adresses IP, mais il s’agit d’une tâche quasiment im­pos­sible avec un réseau plus important. Aucune de ces deux options n’est donc idéale pour la mise en place d'un réseau local : d'une part, la con­fi­gu­ra­tion des serveurs DHCP et DNS implique un certain niveau d'effort et de savoir-faire, et d'autre part, la variante manuelle nécessite d’adapter un par un tous les fichiers hôtes, par exemple si l’on ajoute un nouveau pé­ri­phé­rique au réseau ou s’il est né­ces­saire d’apporter des mo­di­fi­ca­tions à des systèmes déjà intégrés. La solution à ce problème s'appelle Zero Con­fi­gu­ra­tion Net­wor­king, abrégé en Zeroconf, et repose sur l'idée d'un réseau IP con­nec­tant des pé­ri­phé­riques sans con­fi­gu­ra­tion manuelle. Le concept de réseau, élaboré entre 1999 et 2003 par un groupe de travail de l'IETF (Internet En­gi­nee­ring Task Force), a notamment été mis en œuvre dans les im­plé­men­ta­tions Bonjour et Avahi.

Lorsqu’Internet En­gi­nee­ring Task Force a lancé le projet Zero Con­fi­gu­ra­tion Net­wor­king en 1999, l'ob­jec­tif était de définir les ca­rac­té­ris­tiques suivantes pour les "réseaux sans con­fi­gu­ra­tion" : 

• Ré­so­lu­tion de noms de domaine intégrée
• At­tri­bu­tion au­to­ma­tique du masque de sous-réseau, de l'adresse IP et du routeur
• Fonction de recherche pour trouver les services réseau dis­po­nibles
• At­tri­bu­tion au­to­ma­tique d'adresses multicast pour les con­nexions mul­ti­points
• Niveau de sécurité équi­valent aux réseaux sans Zeroconf

Toutefois, le groupe de travail de l'IETF n'a pu aboutir à un consensus, c’est pourquoi il n'a publié aucun document résumant les exigences de la mise en réseau de Zero Con­fi­gu­ra­tion. Il a plutôt été décidé d'éla­bo­rer une spé­ci­fi­ca­tion pour le protocole Internet en col­la­bo­ra­tion avec Apple, Microsoft et Sun Mi­cro­sys­tems ; elle a été publiée en 2005 sous le nom de "Con­fi­gu­ra­tion dynamique des adresses IPv4 Link-Local Addresses" (RFC 3927). IPv4LL attribue au­to­ma­ti­que­ment des adresses IP aléa­toires avec le préfixe 169.254/16, c'est-à-dire comprises entre 169.254.0.0.x et 169.254.255.255.x. La première et les 256 dernières adresses sont réservées aux ap­pli­ca­tions futures. La norme RFC exige également que le gé­né­ra­teur de nombres aléa­toires inclue des in­for­ma­tions spé­ci­fiques à l'or­di­na­teur, telles que l'adresse MAC de l'in­ter­face réseau lors de la gé­né­ra­tion d'adresses Internet, ceci qui minimise la pro­ba­bi­lité que deux appareils reçoivent la même adresse IP.

En ce qui concerne l'at­tri­bu­tion au­to­ma­tique d'adresses sans protocole DHCP, IPv4 utilise le protocole Address Re­so­lu­tion Protocol (ARP), qui a été remplacé dans IPv6 par le Neighbor Discovery Protocol (NDP). Le processus d'at­tri­bu­tion comporte plusieurs étapes pour éviter les conflits entre les adresses IP des pé­ri­phé­riques réseau par­ti­ci­pants :

1. L’adresse IP est d’abord générée.
2. IPv4LL fournit ensuite des tests ARP, utilisés pour vérifier si l'adresse IP générée est déjà utilisée dans le réseau. Pour ce faire, il envoie trois paquets ARP en tant que des­ti­na­taires, contenant l'adresse de l'ex­pé­di­teur 0.0.0.0.0.0 et l'adresse à vérifier.
3. Si durant cette période un paquet ARP est reçu et que l'adresse de l'ex­pé­di­teur cor­res­pond à l'adresse IP générée, cela signifie que cette adresse est déjà attribuée dans le réseau, et la gé­né­ra­tion d'IP redémarre.
4. Si un échan­til­lon ARP inconnu est reçu et qu'il cor­res­pond à l'adresse à tester, un autre dis­po­si­tif essaie de joindre le réseau avec cette adresse IP, de sorte que la procédure soit également répétée à partir de l'étape 1.
5. S'il n’y a pas de conflit, le pé­ri­phé­rique de connexion a réussi à récupérer l'adresse pour lui-même, et envoie deux annonces ARP an­noun­ce­ments ("annonces") dans les­quelles les adresses ex­pé­di­teur et des­ti­na­taire cor­res­pon­dent à l'adresse IP générée.

Dans la mesure où l'adresse IP assignée est dynamique, elle est vérifiée à chaque re­dé­mar­rage, fin du mode veille, bran­che­ment du câble Ethernet ou connexion au wifi. Pour éviter qu'un grand nombre de conflits ne sur­char­gent le réseau, notamment lorsque de nombreux appareils essaient de se connecter au réseau en même temps, le nombre de ten­ta­tives par appareil est au­to­ma­ti­que­ment réduit à un par minute après dix conflits.

En col­la­bo­ra­tion avec le groupe de travail Ex­ten­sions DNS, l'équipe de Zeroconf a également développé des solutions sans con­fi­gu­ra­tion pour la tra­duc­tion au­to­ma­tique d'adresses et la gestion des pé­ri­phé­riques dans les réseaux IPv4. Au lieu de concevoir un protocole com­plè­te­ment nouveau, il a été décidé de proposer ces fonctions sim­ple­ment en adaptant le protocole DNS standard. Les groupes de projet ont travaillé en étroite col­la­bo­ra­tion avec Apple, car l’en­tre­prise avait déjà développé des solutions ap­pro­priées pour ses appareils avec sa propre col­lec­tion de pro­to­coles AppleTalk, qu'il suffisait de trans­fé­rer à la famille de pro­to­coles Internet. Ceci a donné naissance aux spé­ci­fi­ca­tions Multicast DNS (RFC 6762) et DNS-Based Service (RFC 6763).

En col­la­bo­ra­tion avec le groupe de travail Ex­ten­sions DNS, l'équipe de Zeroconf a également développé des solutions sans con­fi­gu­ra­tion pour la tra­duc­tion au­to­ma­tique d'adresses et la gestion des pé­ri­phé­riques dans les réseaux IPv4. Au lieu de concevoir un protocole com­plè­te­ment nouveau, il a été décidé de proposer ces fonctions sim­ple­ment en adaptant le protocole DNS standard. Les groupes ont travaillé en étroite col­la­bo­ra­tion avec Apple, car l’en­tre­prise avait déjà développé des solutions ap­pro­priées pour ses appareils avec sa propre col­lec­tion de pro­to­coles AppleTalk, qu'il suffisait de trans­fé­rer à la famille de pro­to­coles Internet. Ceci a donné naissance aux spé­ci­fi­ca­tions Multicast DNS (RFC 6762) et DNS-Based Service (RFC 6763).

Multicast DNS (mDNS) cor­res­pond à la façon dont les pé­ri­phé­riques peuvent envoyer des requêtes DNS à des adresses IP multicast. Pour ce faire, on définit un top level domain.local en tant que lien local dans le protocole mDNS. De plus, toutes les requêtes se terminant .local doivent être envoyées à l'adresse multicast IPv4LL 224.0.0.0.0.251 (dans IPv6 c'est l'adresse FF02::FB). Toutes les requêtes DNS qui ne se terminent pas par .local at­teig­nent également l'adresse multicast si le réseau n’est pas doté d’un serveur DNS. En général, les messages mDNS peuvent être transmis via UDP et TCP, en utilisant le port multicast 5353 au lieu du port 53 habituel. Si un pé­ri­phé­rique réseau souhaite ensuite résoudre le nom d'hôte d'un autre pé­ri­phé­rique réseau, il lui envoie une demande d'iden­ti­fi­ca­tion mDNS. Le pé­ri­phé­rique cible répond avec un paquet multicast révélant son adresse IP. Tous les pé­ri­phé­riques du réseau reçoivent cette in­for­ma­tion et l'en­re­gistrent au­to­ma­ti­que­ment dans leur cache DNS.

DNS-Based Service Discovery (DNS-SD) définit la façon dont les services d'un réseau Zeroconf sont  rendus visibles et ac­ces­sibles à tous les abonnés. Pour une meilleure coor­di­na­tion, il est d'abord né­ces­saire d'en­re­gis­trer ces services auprès de l'IANA (Internet Assigned Numbers Authority), afin d'obtenir un nom de service prêt à être assigné sans ambiguité. Les ap­pli­ca­tions com­mu­ni­quent  ensuite leurs noms aux uti­li­sa­teurs du réseau grâce à une no­ti­fi­ca­tion multicast. Ceci ne pose aucun problème si plusieurs appareils offrent le même service : dans ce cas, le client qui accède au réseau peut sim­ple­ment sé­lec­tion­ner l'un des hôtes.

L'IETF n’a pas of­fi­ciel­le­ment publié les deux RFC avant février 2013, mais Apple, qui a initié le projet, a commencé à intégrer les normes dans ses appareils en 2002. Le logiciel open source ainsi développé, désormais connu sous le nom de Bonjour (an­cien­ne­ment Ren­dez­vous), est sans aucun doute l'une des solutions les plus connues de Zeroconf. L'ar­chi­tec­ture réseau sans con­fi­gu­ra­tion est ainsi dis­po­nible non seulement pour MacOS et iOS, mais aussi pour Windows.

Lorsqu’Apple est passé au noyau hybride XNU en 2001 avec Mac OS X 10.0, AppleTalk, le groupe de pro­to­coles réseau qui était jus­qu'alors très utilisé, n’a pas été im­plé­menté sur le nouveau système d'ex­ploi­ta­tion. Cette idée de ne pas dé­ve­lop­per un suc­ces­seur adapté n’était pas du tout du goût de Mac Stuart Cheshire, un uti­li­sa­teur ex­pé­ri­menté ; il a donc mis en place une boucle de dis­cus­sion par email dans lequel, avec d'autres uti­li­sa­teurs, il a abordé les points faibles de la con­fi­gu­ra­tion manuelle né­ces­saire du réseau. Ceci a incité Apple à repenser son projet : Stuart Cheshire a été engagé pour dé­ve­lop­per une variante de protocole adaptée au nouveau système d'ex­ploi­ta­tion, conçue en col­la­bo­ra­tion avec l'In­ter­net En­gi­nee­ring Task Force. 

Avec Mac OS X 10.2, Apple a publié en août 2002 la première version des nouvelles spé­ci­fi­ca­tions du protocole, sous le nom de Ren­dez­vous. Pour des raisons ju­ri­diques, il a fallu trouver un nouveau nom pour le projet : la version 10.4 du  logiciel réseau s'appelle donc encore aujourd’hui Bonjour. mDNS­Res­pon­der est le composant principal du paquet : c’est un programme de fond qui s’active au démarrage et im­plé­mente DNS-Based Service Discovery ainsi que le DNS multicast. Par ailleurs, la spé­ci­fi­ca­tion IPv4LL (ou IPv6LL) en est devenue l'un des prin­ci­paux com­po­sants. La solution Apple couvre ainsi les trois domaines es­sen­tiels d'un réseau sans con­fi­gu­ra­tion :

• L‘adressage
• La ré­so­lu­tion de noms de domaine
• La détection de service réseau

Grâce à cette ar­chi­tec­ture, il est possible de connecter fa­ci­le­ment votre appareil à d'autres com­po­sants des réseaux locaux utilisant également Bonjour (il peut s’agir d’un PC, d’une im­pri­mante ou d’une ap­pli­ca­tion). Par exemple, le service de musique iTunes d'Apple utilise cette tech­no­lo­gie pour trouver au­to­ma­ti­que­ment d'autres uti­li­sa­teurs qui partagent leur musique sur le réseau. Le logiciel Bonjour est au­to­ma­ti­que­ment installé sur les systèmes MacOS et iOS actuels. Les uti­li­sa­teurs Windows peuvent té­lé­char­ger une version spé­ci­fique pour les services d’im­pres­sion. Il est également possible d’installer une ap­pli­ca­tion com­pre­nant le logiciel, par exemple iTunes, Skype ou Adobe Photoshop (à partir de CS3).

Il existe une al­ter­na­tive à la solution Zeroconf d'Apple, qui fonc­tionne également sur les systèmes Linux. Il s’agit d’Avahi, installée par défaut sur Debian et Ubuntu, et dis­po­nible sous licence libre LGPL. La mise en œuvre a d'abord été soutenue par l'ini­tia­tive à but non lucratif free­desk­top.org, mais s'est depuis dé­ve­lop­pée pour devenir un projet in­dé­pen­dant.