ZERO CONF Exposé option Réseaux et Interconnexion d'ordinateurs C.PERROTIN TTN 08 P.BLEDU FA 08 p1/14
ZEROCONF 1- CONCEPT 3 2-TECHNIQUE 4 2.1 Allocation dynamique d'adresse IP sans serveur DHCP 4 2.1.1 Allocation des adresses de lien-local 4 2.1.2 Vérification de l unicité de l adresse 4 2.1.3 Détection d adresse dupliquée 5 2.2 Résolution de noms et adresses IP sans serveur DNS 5 2.2.1 Différence entre LLMNR et mdns 5 2.2.2 Protocole LLMNR 6 2.2.3 Protocole mdns 6 2.3 Recherche de services sans annuaire 7 2.3.1 Protocole SLP 7 2.3.2 Protocole SSDP 8 2.3.3 Protocole DNS-SD 8 2.4 Allocation d'adresses IP multicast sans serveur MADCAP 9 3- HISTORIQUE 10 4- GLOSSAIRE 12 5-REFERENCE 13 6- CONCLUSION 14 p2/14
1- CONCEPT IP like electricity -> just plug in and it works Ensemble de technologies permettant à plusieurs ordinateurs de communiquer sans configuration. Il est destiné aux petits réseaux locaux. Concurrent : UPnP. Traditionnellement, la plupart de ce travail est réalisé par DHCP et DNS. Cependant, la conception décentralisée de zeroconf est plus appropriée dans certaines situations, comme pour les réseaux ad-hoc. De plus, cela se fait sans aucune configuration (mise à part celle de l'installation de zeroconf). Ce concept que nous allons étudier est né grâce à l impulsion de Stuart Cheshire qui réfléchissait au remplacement d Appletalk et avait eu l idée d un NBP/IP (AppleTalk Name Binding Protocol) en multicast. Un groupe de travail de l IETF a été créé : Zero Configuration Networking alias Zeroconf. Zeroconf résout actuellement trois problèmes : - Allocation dynamique d'adresse IP sans serveur DHCP - Résolution de noms et adresses IP sans serveur DNS - Recherche de services sans annuaire «Nous sommes au commencement de la seconde révolution de l Internet et ZeroConf en fait partie», Tim O REILLY, président de O REILLY OPEN SOURCE Convention. p3/14
2-TECHNIQUE 2.1 Allocation dynamique d'adresse IP sans serveur DHCP Pour IPv4, il existe un standard pour l'allocation dynamique d'adresses IP dans la plage 169.254.0.0/16. Voir RFC 3927 publié en mars 2005. Pour IPv6, l'allocation dynamique d'adresses IP est prévue dans le protocole (voir RFC 2461). 2.1.1 Allocation des adresses de lien-local L autoconfiguration a été prévue dès la conception du protocole IPv6. Mais l établissement automatique de l adresse de lien lien-local n est qu une toute petite étape dans l autoconfiguration, qui est constitué par différents mécanismes de découverte : découverte de voisins, découverte de routeurs, découverte des préfixes, détection d adresses dupliquées et de divers paramètres comme le MTU. En IPv6 l adresse de lien-local est construite à partir du préfixe FE80::/64 et de l identifiant EUI-64 lui-même calculé pour Ethernet à partir de l adresse MAC La RFC 3927 n a fait qu entériner l autoconfiguration d adresses IPv4 de lien-local qui était déjà incluse dans Mac OS depuis la version8.5 et dans Windows depuis Windows 98. En IPv4, l adresse de lien-local est sélectionnée au moyen d un générateur pseudo aléatoire dans la plage d adresses de 169.254.1.0 à 169.254.254.255 incluses. Pour que les machines utilisent, si possible, toujours la même adresse, il est conseillé de commencer la séquence pseudo aléatoire, par exemple avec une valeur dérivée de l adresse MAC, et de sauvegarder - quand c est possible - la dernière adresse IPv4 de lien-local utilisée lors de l arrêt de l équipement. Le RFC indique que les adresses de la plage 169.254/16 : ne sont pas routables et que certaines précautions doivent être respectées : elles ne doivent pas être enregistrées dans un serveur DHCP, ni configurées à la main elles ne doivent pas être résolues par le DNS, que ce soit en direct ou en reverse les clients ne doivent pas faire de requêtes DNS classique pour des noms appartenant au domaine : 254.169.in-addr.arpa. elles ne doivent jamais être envoyées à un routeur pour être relayées. 2.1.2 Vérification de l unicité de l adresse Pour IPv6, des messages ICMP de sollicitation de voisin sont envoyés à l adresse multicast spéciale, de toute façon l emploi de l adresse EUI-64 basé sur l adresse MAC évite tout problème. Par contre, si une adresse de lien local s avère dupliqué, une modification manuelle s impose. En IPv4, la vérification d unicité d adresse de lien-local fonctionne à partir de trois requêtes ARP probes qui sont diffusées sur le lien local, c est-à-dire des requêtes ARP avec l adresse source IP positionnée à zéro, afin de ne pas polluer les caches avec des informations qui ne sont pas encore valides. Si l adresse IP est déjà utilisée (ou demandée) par une autre machine, alors on tente une autre valeur d adresse fournie par le générateur pseudo-aléatoire. Lorsque la machine a trouvé une adresse libre, c est-à-dire si elle n a pas vu passer de réponse pendant les deux secondes suivant sa dernière requête ARP, alors elle diffuse en broadcast deux annonces ARP, c est-à-dire la même chose que les ARP probes mais avec cette fois l adresse source IP contenant l adresse sélectionnée. p4/14
2.1.3 Détection d adresse dupliquée Pendant toute la période où une machine utilise une adresse de lien-local sur une interface, elle doit surveiller tous les paquets ARP qu elle voit passer, qu ils contiennent des requêtes ou des réponses, car elles ont la particularité, quand elles concernent des adresses de lien-local, d être toujours envoyées en broadcast. Si cette machine y trouve une requête concernant une adresse IP qu elle utilise provenant d une autre machine alors il y a conflit. Elle ne peut l ignorer et a alors le choix entre deux solutions : elle peut choisir de changer immédiatement d adresse de lien-local, si elle souhaite garder l adresse, par exemple parce qu elle a des connexions TCP en cours, si elle n a pas vu passer de conflits ARP depuis plus de 10 secondes, elle peut alors défendre son adresse en envoyant simplement une annonce ARP en broadcast. Si au contraire ce n est pas la première annonce de conflit qu elle voit passer depuis les dix dernières secondes, alors elle doit immédiatement cesser d utiliser cette adresse. Bien qu étant en principe très peu probables, ces conflits peuvent se produire, par exemple lors de la fusion de deux réseaux. Il n est donc pas possible d empêcher totalement la coupure de connexions TCP. Les futurs équipements IPv6 seront dans leur très grande majorité équipé de cette technologie. 2.2 Résolution de noms et adresses IP sans serveur DNS Deux solutions existent : Apple Bonjour (mdns), par Apple porté par Stuart Cheshire. Link-local Multicast Name Resolution (LLMNR), par l'ietf et Microsoft. Officiellement (classement IETF), les 2 projets sont encore sous forme de draft (brouillon). Bien que le mdns est déjà disponible sous Mac OS, sous Windows et dans la plus part des imprimante Ethernet, ce n est qu une proposition individuelle alors que le LLMNR est porté par le groupe de travail dnsext. 2.2.1 Différence entre LLMNR et mdns La première chose a noter est que ces 2 protocoles ne sont pas compatibles entre-eux, on leur a attribué des adresses et des ports différents. Un autre point important a préciser concerne le TTL des trames qui est de 255 pour le mdns contre 1 pour le LLMNR. mdns LLMNR IPv4 multicast 224.0.0.251 224.0.0.252 IPv6 multicast ff02::fb ff02::1:3 port 5353 5355 TTL - Hop Limit 255 1 Les objectifs qui ont conduits à la réflexion sur ces 2 protocoles sont également très différents : mdns a été clairement conçu pour remplacer Appletalk et par conséquent pour permettre efficacement la découverte de services sur le lien local, LLMNR est conçu pour pallier uniquement l absence momentanée de serveur DNS sur un réseau. p5/14
2.2.2 Protocole LLMNR Le protocole permet de résoudre des noms dans toutes les zones du DNS : les requêtes sont envoyées en multicast et les réponses sont toujours en unicast, une seule requête est envoyée à la fois, le champ RCODE est utilisé dans les réponses qui peuvent donc être vides ou négatives, l identificateur de requête (champ ID) est recopié dans les réponses, c est dans les requêtes qu on trouve un indicateur de conflit de noms, si la réponse est trop longue pour tenir dans un seul paquet UDP, l indicateur TC permet de demander à l envoyeur de recommencer sa requête en TCP, il n y a pas de requêtes en unicast UDP, tous les TTL des RR sont positionnés à la même valeur qui est de 30 secondes par défaut. Structure de l en tête : Bit offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 ID 16 QR Opcode C TC T Z Z Z Z RCODE 32 QDCOUNT 48 ANCOUNT 64 NSCOUNT 80 ARCOUNT ID : Identifiant 16 bits permettant de numéroté les requêtes QR : Question / Réponse OPCODE : Champs de 4 bits indiquant le type de question (repris dans la réponse) C : Conflit TC : TrunCation T : Tentative Z : Réservé pour futur usage RCODE : Réponse code QDCOUNT : Nombre d entrée dans la question ANCOUNT : Nombre d enregistrement dans la réponse NSCOUNT : Nombre de Serveur de Nom ARCOUNT : Nombre d enregistrement dans la réponse additionnelle. 2.2.3 Protocole mdns Le principe de mdns et de DNS n est pas le même puisque l on veut créer des communautés de machines qui coopèrent plutôt que de vouloir définir une hiérarchie de délégations (serveur DNS). Mais la liste des différences est beaucoup plus longue : utilise le multicast pour les requêtes et les réponses, utilise le port 5353 à la place du port 53, concerne une partie précise de l espace de noms du DNS, uniquement le domaine racine.local., utilise seulement UTF-8 pour coder les noms dans des RR, définit une limite précise pour la longueur des noms des domaines (255), fixe la taille maximum des paquets UDP au MTU du lienlocal, permet plus d une question dans un paquet de requête, utilise la section Réponses dans une requête pour indiquer les réponses déjà connues, utilise le bit TC dans une requête pour indiquer qu on va y joindre des réponses déjà connues, ignore le champ ID des requêtes, ne nécessite pas la copie des requêtes dans les réponses, utilise des réponses gratuites pour les annonces de nouveaux enregistrements aux autres machines, p6/14
définit un bit de demande de réponse unicast dans les rrclass des requêtes, définit un bit de réinitialisation du cache dans les rrclass des réponses, utilise un TTL DNS de 0 pour indiquer qu un enregistrement a été supprimé, surveille les requêtes pour la Suppression des Requêtes Dupliquées, surveille les réponses pour la Suppression des Réponses Dupliquées,... détecte les conflits à la volée...... et intègre un système de cohérence de caches. Un point important concerne la restriction au domaine local, pour éviter d envoyer des requêtes en broadcast partout et pour des soucis de sécurité, bien qu en théorie, le mdns en serait techniquement capable de travailler a plus grande échelle. Un autre point qui montre que mdns diffère du DNS classique est qu il supporte trois modes de requêtes : les requêtes simples, (celles du DNS traditionnel), une requête attend une réponse, les requêtes simples avec accumulation des réponses multiples venant de plusieurs serveurs mdns répartis, les requêtes continues utilisées par les logiciels qui intègrent un explorateur ou un sélecteur réseau (IP browser). L étude approfondie du Draft de mdns montre que c est un système très sophistiqué. Il profite pleinement de la richesse du multicast quand il est utilisé à la fois pour les requêtes et les réponses pour créer un système de nommage local, avec un système de cohérence de caches très bien adapté pour des petits réseaux de machines coopérant d égal à égal. Ce sont les TTL des RR (qui ont des valeurs très courtes) ainsi que les informations contenues dans les requêtes (contenant les réponses connues) et les réponses multi-diffusées qui sont astucieusement utilisés pour assurer que toutes les machines disposent du plus grand nombre d informations à jour, tout en minimisant le trafic réseau. 2.3 Recherche de services sans annuaire Sur ce point les choses ne sont pas encore figées, il y a plusieurs propositions en cours et pas vraiment de standard. Trois solutions existent : Service Location Protocol (SLP), décrit dans la RFC 2608 (norme IETF) Simple Service Discovery Protocol (SSDP) utilisé dans Universal Plug and Play (UPnP), toujours à l état de Draft. DNS Service Discovery (DNS-SD), protocole utilisé par Apple pas encore une norme. Du point de vue technique, un point sépare nettement les deux protocoles SLP et SSDP par rapport à DNS-SD : ils utilisent tous les deux des URL pour transporter les annonces de service, alors que DNS-SD n est que du «pur DNS» qui utilise des enregistrements SRV et TXT. 2.3.1 Protocole SLP SLP est un protocole complexe, totalement indépendant du DNS. Il utilise directement du multicast avec sa propre adresse 224.0.1.22 et le port 427. Il intègre trois sortes d Agents : User Agent pour les requêtes, Service Agent pour les annonces de services, et Directory Agent pour les enregistrements de services (pour les plus grands réseaux). Il emprunte à LDAP son langage de requêtes, comprend 11 types de messages dont certains sont obligatoires et d autres optionnels. p7/14
SLP permet de rechercher les services et les différents attributs par l usage de requête au format LDAP. Exemple d URL d écrivant le service d impression d une imprimante : service:printer:lpr://myprinter/myqueue 2.3.2 Protocole SSDP Tout comme SLP, SSDP est un protocole indépendant. Il utilise aussi une adresse multicast particulière 239.255.255.250 sur le port 1900, qui est fonction de la portée (scope) des requêtes. L utilisation de l UPnP fréquent sous windows XP est basé sur SSDP et fonctionne en 4 étapes : 1- Découverte de service : quand un périphérique est connecté au réseau, il prévient les points de contrôle du réseau de ses services. Parallèlement, quand un point de contrôle est connecté au réseau, le protocole de découverte permet à ce point de contrôle de rechercher les dispositifs intéressants sur le réseau. Les échanges fondamentaux dans ces deux cas, sont des messages contenants les informations spécifiques essentielles sur le dispositif et un de ses services, comme, par exemple, son type, son identifiant ou un pointeur vers des informations plus détaillées. 2- Description : un point de contrôle doit récupérer la description du dispositif depuis l'url fournie par celui-ci dans le message de découverte. La description en XML comprend des informations spécifiques : nom, numéro de série, sites web des fournisseurs, mais également les URL des commandes et des contrôles et les paramètres pour les utiliser. 3- Contrôle : envoi de message de contrôle au format XML en utilisant le description précédente, le tout au travers du protocole SOAP (Simple Object Access Protocol). 4- Notification d évènement : Lorsque les variables de l objet change, ce dernier en informe le réseau. Les mises à jour sont toujours en XML avec des messages de type GENA, contenant le nom des variables et leurs valeurs. 2.3.3 Protocole DNS-SD Au contraire de SSDP ou de SLP, DNS-SD est un protocole poids plume! Il est basé sur le DNS, ce qui fait sa simplicité. Il peut s appuyer indifféremment sur la version classique du DNS ou sur mdns. Il n utilise donc pas de port ni d adresse IP en propre. Ce n est pas un nouveau protocole circulant sur le réseau, aucune attribution IANA n est demandée pour ce protocole. DNS-SD reprends les concepts de la RFC 2782 (DNS SRV) permettant la découverte de service, et y rajoute la découverte d instance de service. L utilisation d enregistrement de type SRV n est pas massivement utilisée dans les serveurs DNS, par contre MS Active Directory l utilise pour ses mises à jours dynamiques. le nom du service au sens Assigned Numbers RFC 1700 le poids relatif, pour une même priorité (0-65365) Nom domaine de la machine cible. _Serv. _Proto SRV Prio Poids Port Cible Structure d enregistrement SRV Protocole UDP/TCP priorité (comme pour les MX) port du service sur la machine cible p8/14
Le poids relatif est un nouveau champ dans les enregistrements DNS qui permet de donner une probabilité d accès entre les différents serveurs. Si par exemple deux machines de même priorité ont des poids de 1 et 3, alors la répartition sera de 25% et 75% respectivement. 1. Les clients demandent au DNS un service (ou un protocole) et il leur retourne la liste des machines du domaine qui le proposent. L idée principale de DNS-SD est d ajouter un niveau d indirection. Au lieu de faire une requête sur les enregistrements de type SRV sur le couple <service>.<domaine>, le client fait une requête sur les enregistrements de type PTR. Le résultat de cette requête est une liste de zéro ou plusieurs enregistrements PTR qui contiennent des Noms d Instance de Service sous la forme : <Instance>. <Service>. <Domaine>. La partie <Instance> est un simple label DNS qui contient du texte encodé en UTF-8 suivant le RFC 3629. 2. Une fois que le client a un Nom d Instance de Service et qu il veut accéder à ce service, il fait une nouvelle requête DNS en demandant cette fois l enregistrement SRV de ce nom. 3. Le résultat de cette requête est un (ou plusieurs) enregistrement(s) SRV contenant le port et la machine cible où l on peut trouver ce service. Dans le cas exceptionnel où il y a plusieurs enregistrements SRV retournés, le client doit interpréter les priorités et les poids. En général il y a un seul enregistrement SRV dont la priorité et le poids sont nuls. Le protocole spécifie aussi des règles de format pour les enregistrements de type TXT qui vont permettre de passer des paramètres supplémentaires. Attention : Les noms de Services au sens de DNS-SD peuvent porter à confusion. Bien que certains soient communs, ce ne sont pas les services du fichier /etc/services autrement dit les AssignedNumbers du RFC 1700. Le Draft propose que ce soit IANA qui prenne en charge l allocation de ces noms. En attendant la publication du RFC, un système d enregistrement provisoire pour ces noms a été mis en place sur le site de DNS-SD 2.4 Allocation d'adresses IP multicast sans serveur MADCAP Il n'existe pas de standard. p9/14
3- HISTORIQUE Dans les années 1980, on pouvait relier un groupe de Macs avec le câblage propriétaire LocalTalk, sans intervention d experts, ni besoin d installation de serveur spéciaux DHCP et DNS. Mai 2002: Apple annonce leur Zero Configuration Networking solution sous le nom du produit Rendezvous, laissant derrière eux AppleTalk qui posait des gros soucis d interaction avec IP. Rendez-vous est maintenant utilisé par ichat, itunes, iphoto, Safari, le partage de fichiers, d'impression, et à peu près tous les autres morceaux de logiciel qui fait la mise en réseau sur un Mac, y compris les vieux favoris comme telnet, SSH, et ftp. Juillet 2003: Le Groupe de travail IETF Zeroconf conclut ses travaux sur les adresses de liens locals IPV4. Août 2004: La technologie Apple Rendezvous pour Windows est maintenant disponible. Avril 2005: Apple annonce Bonjour, le nouveau nom de "Rendez-vous 2", incluant l exploitation de réseau public, étendant Rendez-vous derrière un réseau local utilisant la translation d adresse. Bonjour est fournit avec des API à usage des programmeurs et un HowTo 1 illustrant le branchement d une imprimante. Mai 2005: The Asterisk Voice-Over-IP software PBX Mai 2005, offre de l assistance aux clients utilisant la configuration zero-conf. Août 2005: Mise à jour d Avahi, une implementation complète de DNS-SD / mdns, sous licence LGPL. Avahi permet de découvrir instantanément un réseau ses périphériques et ses utilisateurs, lors de la connexion d un ordinateur. Avahi est principalement basée sur Lennart Poettering flexmdns application pour Linux, qui a été abandonnée au profit d'avahi. Novembre 2005: Stuart Cheshire fit une conference sur Zeroconf pour les ingénieurs de la société Google, disponibles sur Google Video. December 2005: Daniel Steinberg et Stuart Cheshire publient Zero Configuration Networking: The Definitive Guide chez par O'Reilly Media. Cet ouvrage regroupe l'essentiel des informations en une seule source, qui décrit comment fonctionnent les protocoles, et en donnant des exemples de programmation en C, Java, Python, et Ruby. Que vous soyez programmeur pour Mac, Windows, Linux, ou fabriquant d'un périphérique matériel exécutant un OS embarqué comme VxWorks, ce livre montre ce que vous devez savoir pour créer un produit Zeroconf complet. Janvier 2006: La socété Computer Language publie une nouvelle édition de son Encyclopédie «Computer Desktop» Encyclopedia, disponible à la fois sur CD et via le Web, avec des entrées de Zeroconf, Bonjour et Link - Adresse locale. p10/14
Juin 2006: Grâce à l aide de Bonjour d Apple, un paramétrage sur Windows XP permet de générer des fichiers au format PDF, en moins d une minute et demie. La vidéo est disponible sous Youtube. Juillet 2006: Encore plus d éloge sur l'imprimante Bonjour pour Windows, mais cette fois dans un article sur Ars Technica Parallels. Août 2006 : Stuart Cheshire, publi la 6ème realease de son document de travail sur le mdns (utlisé aujourd hui) Janvier 2007 : Publication de la RFC 4795 sur le LLMNR, Local Link Multicast Name Résolution, dont l usage n est toujours très fréquent, puisque mdns l avait largement devancé. p11/14
4- GLOSSAIRE Adresse MAC Appletalk Asterisk Avahi Adresse physique unique d'une carte Ethernet : 3 octets désignent le constructeur + 3 octets pour l'identifiant de la carte. Famille de protocoles mis au point par Apple pour mettre en place des LAN de Macintoshs, avec un débit de 1 Mbps sur un bus. leader mondial de la téléphonie d'exploitation libre et un ensemble d'outils permettant aux développeurs et aux intégrateurs de créer des solutions de communication avancées... Système qui facilite la découverte de services sur un réseau local. http://www.frameip.com/ethernet-ouiieee http://hautrive.free.fr/reseaux/architectur es/reseaux-appletalk.html www.asterisk.org http://avahi.org DCP Device Control Protocols http://jargonf.org/wiki/dcp DHCP Dynamic Host Configuration Protocol, protocole d'attribution dynamique des adresses sur un réseau IP. DNS Domain name Server, Service IP répondant aux requêtes http://www.afnic.fr/ext/dns de conversion d'un nom IP en un numéro IP correspondant. DNS-SD Draft EUI 64 ICMP IETF LDAP LGPL LLMNR un système d enregistrement provisoire pour les noms de protocoles a été mis en place sur le site de DNS-SD http://jargonf.org/wiki/dhcp Anglicisme utilisé pour désigner une ébauche de RFC Extended Unique Identifier, sur 64 bits : Constitué d'un identifiant de 24 bits du fabricant + 40 bits attribué par l IEEE Internet Control Message Protocol protocole utilisé pour véhiculer des messages de contrôle et d'erreur. Internet Engineering Task Force. Organisation préparant les principaux standards de l'internet. LDAP (Lightweight Directory Access Protocol) est un protocole d'accès à un annuaire, dérivé d' X500, au dessus de TCP/IP. Lesser General Public License : licence libre non modifiable Link-local Multicast Name Resolution : ce protocole permet de résoudre des noms dans toutes les zones du DNS. http://technet.microsoft.com/fr-fr/library/bb878128(en-us).aspx http://www.dns-sd. org/servicetypes.html. http://standards.ieee.org/regauth/oui/tut orials/eui64.html http://www.ietf.org/rfc/rfc792.txt http://www.ietf.org 95 http://www.cru.fr/ldap/ http://www.gnu.org/licenses/lgpl.html http://tools.ietf.org/html/rfc47 mdns Extension du DNS proposée par Apple à l'ietf pour http://www.multicastdns.org/ prendre en compte les réseaux de petites tailles en espace d adressages privés. Rendezvous Nom donné par Apple au protocole Zeroconf. http://www.apple.com/macosx/technolog y/bonjour.html + p12/14
RFC 2365 Utilisation du multicast sélectif de sous réseau http://tools.ietf.org/html/rfc2365 RFC 2461 Allocation dynamique d'adresses IP V6 http://tools.ietf.org/html/rfc2461 RFC 2782 DNS-SRV permet la découverte de service à travers un http://tools.ietf.org/html/rfc2782 réseau de serveur (ou de poste). RFC 3927 Allocation dynamique d'adresses IP V4 http://tools.ietf.org/html/rfc3927 SLP Service Location Protocole, permet de localiser les http://tools.ietf.org/html/rfc2608 (RFC 2608) services sur un réseau SOAP Simple Object Access Protocol est un protocole de http://www.soapuser.com/fr/ transmission de messages XML entre objet SSDP Simple Service Discovery Protocol : utilisé dans l UPnP fréquent sous windows XP. Stuart Cheshire UPnP XML Chercheur travaillant chez Apple à l origine de Zeroconf et de la RFC 3927, 4436, 3396, 3397, 3442 Universal Plus and Play. Système d'autoconfiguration de Microsoft, basé sur DCP extensible Markup Language : format de description des données selon des balises. http://support.microsoft.com/kb/317843/f r http://www.stuartcheshire.org/ http://www.upnp.org/ http://xml.com 5-REFERENCE Le jargon Français : http://www.linux-france.org/prj/jargonf/general/apropos.html Site du groupe de travail : http://www.zeroconf.org/ Conference ZeroConf 02/11/2005 Dr. Stuart Cheshire, http://www.youtube.com/watch?v=pdbtyxymf84 Wikipedia : http://fr.wikipedia.org/wiki/zeroconf Documentation Ubuntu 6.10 : http://doc.ubuntu-fr.org/zeroconf Imprimante Bonjour sur Windows XP : http://www.youtube.com/watch?v=clwh0furvx4 Article supinfo : http://www.supinfo-projects.com/fr/2003/zeroconf/ Page web ietf : http://www.ietf.org/html.charters/old/zeroconf-charter.html Implémentation zeroconf : http://www.progsoc.uts.edu.au/%7ewildfire/zeroconf/ Site informatique varié : http://arstechnica.com/index.ars p13/14
6- CONCLUSION On retrouve ZeroConf dans Apple Bonjour et dans de nombreuses distributions GNU/Linux. Les premières implémentations ont été basé sur Howl qui était parti du code fournit par Apple. Puis finalement, une approche plus Linux a été choisi par Freedesktop : avahi. Cette approche permet de tout centraliser et de limiter le nombre de démons, les logiciels voulant utiliser les services zeroconf font leurs demandes via dbus. Cette technologie peut actuellement être utilisée pour : Partager de la musique - Rhythmbox, Banshee, Amarok, itunes, mt-daapd; Echanger des fichiers - gshare, gnome-user-share ; Découvrir automatiquement les autres clients VoIP - Ekiga ; Discuter par messagerie instantannée sur le réseau local - gajim, pidgin Partager les paquets - apt-zeroconf ; Prochainement : partager des imprimantes (sous Ubuntu 7.10, dans Système Administration Impression, à l'onglet Paramètres du Serveur, cocher la case Partager les imprimantes connectées à ce système). Zeroconf s'intègre très bien avec les outils traditionnels. Par exemple, vous pouvez obtenir une adresse IP par DHCP et utiliser le service DNS pour résoudre les adresses sur internet, tout en utilisant le hostname local de MDNS (Multicast DNS) pour résoudre les adresses des autres ordinateurs sur le LAN. Par contre, l utilisation de ce mécanisme d allocation d adresses apporte de nouveaux types d attaques comme par exemple le vol d adresse. La RFC laisse le soin aux implémenteurs de faire le nécessaire! En conclusion, l attitude à avoir vis-à-vis de l autoconfiguration et de la découverte de service, dépend fortement du contexte dans lequel on se trouve. p14/14