Utilisateur:ÉmilienKia/Zeroconf

Une page de Wikipédia, l'encyclopédie libre.

Zeroconf ou Zero Configuration Networking (réseau sans configuration) est un jeu de techniques qui crée un réseau IP sans configuration ou server spécial. Cela permet aux utilisateur inexpérimentés de connecter des ordinateurs, imprimantes réseaux, ou tout autre périphérique ensemble et faire qu'ils marcheront automatiquement. Sans Zeroconf ou dispositif similaire, un utilisateur expérimenté doit mettre en place des services spécifiques, comme DHCP et DNS, ou régler chaque ordinateur à la main, tâche fastidieuse, difficile pour un utilisateur non avertis.

Zeroconf résout actuellement trois problèmes :

  • Choisir les adresses numériques réseau pour chaque dispositif
  • Préciser quel ordinateur a quel nom
  • Préciser quel ordinateur fournit quel service (découverte de services)

Choix des adresses[modifier | modifier le code]

Les réseaux IPv4 et IPv6 ont chacun leur méthode de choix dynamique des adresses IP. La RFC 3927[1] spécifie que l'IPv4 doit utiliser les adresses (locales) 169.254.* . Pour l'IPv6, voir la RFC 2462[2].

La technique pour l'IPv4 est appelée IPv4 Link-Local (IPV4LL) dans la RFC, bien que Microsoft s'y réfère par Automatic Private IP Addressing (APIPA ou Adressage IP privé automatique) ou Internet Protocol Automatic Configuration (IPAC ou Configuration automatique du protocole internet).

Résolution des noms[modifier | modifier le code]

Le document décrivant comment les noms sont résolus, a été publié par Bill Manning et Bill Woodcock en 2000 ("Multicast Domain Name Service"[3]) et présente le travail réalisé par Apple et Microsoft.

Il existe deux façons très similaires de déterminer quel dispositif a quel nom. Le Multicast DNS (mDNS) d'Apple qui est publié librement, mais pas par un organisme de standardisation. Le Link-local Multicast Name Resolution (LLMNR) de Microsoft qui est peu utilisé mais qui a été publié pour information (RFC 4795[4]).

Ces deux protocoles ont des différences mineurs. mDNS permet à un dispositif en réseau de choisir un nom de domaine dans l'espace de nom ".local" et de l'annoncer en utilisant une adresse IP multicast spéciale. Ceci introduit une sémantique spéciale pour l'espace de noms .local[5], ce qui est considéré comme un problème par certains membres de l'IETF[6]. Le brouillon actuel de LLMNR permet à un dispositif réseau de choisir n'importe quel nom de domaine, ce qui est considéré comme un risque par certains membres de l'IETF[7]. mDNS est compatible avec DNS-SD décrit dans la section suivante alors que LLMNR ne l'est pas[8].

Découverte de services[modifier | modifier le code]

Le protocole d'Apple : Multicast DNS/DNS-SD[modifier | modifier le code]

Multicast DNS (mDNS) est un protocole qui utilise une API similaire à celle du système DNS unicast mais implémentée différemment. Chaque ordinateur sur le réseau local enregistre sa propre liste d'enregistrement DNS (par exemple A - A record, MX, PTR, SRV, etc) et quand un client mDNS veut connaître l'adresse IP d'un dispositif avec un nom donné, le dispositif avec le A-record correspondant répond avec son adresse IP. L'adresse multicast mDNS est 224.0.0.251.

DNS Service Discovery (DNS-SD) est l'autre moitié de la solution d'Apple, développée par dessus le Domain Name System. Il est utilisé par les produits Apple, certaines imprimantes réseau et de nombreux produits et applications tiers sur différents systèmes d'exploitation. Contrairement à la technologie concurrente de Microsoft, SSDP, il utilise DNS plutôt qu'HTTP. Il utilise les enregistrements SRV, TXT et PTR de DNS (RFC 2782[9]) pour publier les instances des services. Les hôtes offrants différents services publient les détails disponibles comme les instances, les types de services, les noms de domaines et les paramètres optionnels de configuration. Les types de services sont fournis de manière informelle selon leur ordre d'arrivée. Un registre des types de services est maintenu et publié par DNS-SD.org.

Plusieures applications réseaux de Mac OS X, comme le navigateur Safari et le client de messagerie instantannée iChat, utilisent DNS-SD pour localiser les serveurs proches. Sous Windows, les clients de messagerie instantanée et de VoIP comme Gizmo supportent DNS-SD. Certaines distributions Linux incluent également des fonctions DNS-SD.

mDNS/DNS-SD a été développé par Stuart Cheshire, un employé d'Apple, Inc. pour le passage d'AppleTalk vers l'IP.

Le protocole de Microsoft : UPnP SSDP[modifier | modifier le code]

Simple Service Discovery Protocol (SSDP) est un protocole d'UPnP utilisé dans Windows XP et sur certains équipements réseaux. SSDP utilise les annonces de notifications HTTP qui fournissent une URI de type de service et un nom unique de service (Unique Service Name - USN). Les types de services sont régulés par l'Universal Plug and Play Steering Committee.

SSDP est supporté par plusieurs pare-feu pour TPE où les ordinateurs hôtes fournissent des services devant passer à travers. Il est également utilisé dans lesmedia center où des médias sont échangés entre plusieurs ordinateurs.

Efforts vers un protocole standard IETF[modifier | modifier le code]

Service Location Protocol (SLP), le seul protocole pour la découverte de services qui a atteint le status de proposition de standard à l'IETF est supporté par les imprimantes réseaux Hewlett-Packard, Novell, Sun Microsystems, et Apple, Inc., mais est ignoré par d'autres fabricants. SLP est décrit dans la RFC 2608[10] et la RFC 3224[11] et sont implémentation est disponible sur Solaris et Linux.

Standardization[modifier | modifier le code]

Le standard pour choisir les adresses des dispositifs réseau, la RFC 3927, a été publiée en Mars 2005 par le groupe de travail Zeroconf de l'IETF qui inclue des employés d'Apple, Sun et Microsoft[12].

LLMNR a été soumis pour adoption officielle au groupe de travail DNSEXT de l'IETF, toutefois il n'a pas remporté suffisament de vote et a été publié seulement comme une RFC pour information : RFC 4795[13]. Comme le LLMNR n'est pas devenu un standard et que mDNS/DNS-SD est plus utilisé que LLMNR, Apple a été invité à soumettre leurs spécifications pour être également publiées comme RFC pour information.

Le standard SLP de recherche des services, RFC 2608, a été publié par le groupe de travail SVRLOC de l'IETF[14].

Implémentations majeures[modifier | modifier le code]

Bonjour d'Apple[modifier | modifier le code]

La solution Zeroconf la plus utilisée [citation nécessaire] est Bonjour (anciennement Rendezvous) d'Apple, Inc., qui utilise le DNS multicast et DNS-SD. Apple a migré de SLP vers mDNS et DNS-SD comme technologie Zeroconf entre MacOS 10.1 et 10.2 même si SLP continue d'être supporté.

mDNSResponder d'Apple a une interface de programmation en C et en Java[15] et est disponible sur BSD, Mac OS X, Linux, tout système d'exploitation POSIX et Windows. Le téléchargement est disponible sur le site d'Apple[16].

Howl[modifier | modifier le code]

Howl était une implémentation de Zeroconf par la société Porchdog Software. Initialement utilisée comme bibliothèque Zeroconf dans certaines distributions Linux. N'étant plus supportée par ses développeurs[17], elle a été peu-à-peu remplacée par Avahi.

Avahi[modifier | modifier le code]

Avahi est une implémentation de Zeroconf pour Linux et les BSDs. Elle implémente IPv4LL, mDNS et DNS-SD. Elle fait parti de la plupart des distributions Linux et est installée par défaut sur certaines (comme Ubuntu 6.10 et supérieures, Debian, Gentoo ou Fedora). Si Avahi est utilisée en conjonction avec nss-mdns, elle offre la résolution des noms d'hôtes[18].

Avahi implémente également une bibliothèque de compatibilité binaire qui émule Bonjour et Howl l'implémentation historique de mDNS. Les logiciels qui utilisent ces implémentations peuvent également utiliser Avahi avec l'émulation des interfaces.

Avahi utilise une approche plus Linux : un service centralise les requêtes et les réponses Zeroconf. Les applications dialoguent avec le démon par l'intermédiaire de D-Bus.

Windows CE 5.0[modifier | modifier le code]

Microsoft Windows CE 5.0 inclue une implémentation propre à Microsoft de LLMNR.

Adresses IPv4LL[modifier | modifier le code]

Il existe plusieurs implémentation :

  • Windows et Mac OS supportent tous les deux les adresses IPv4LL depuis 1998. Apple a fournit son implémentation ouverte dans le paquet bootp de Darwin.
  • Avahi fournit une implémentation de grande qualité d'IPv4LL dans l'outil avahi-autoipd.
  • zcip (Zero-Conf IP).
  • BusyBox embarque une implémentation simple de IPv4LL.
  • Stablebox, un fork de Busybox, offre une version modifiée de l'implémentation d'IPv4LL nommée llad.
  • zeroconf, un paquet basé sur Simple IPv4LL, une implémentation simple par Arthur van Hoff[19].

Les implémentations citées ci-dessus sont toutes des daemons ou des greffons pour des clients DHCP qui ne traitent que des adresses IP locales. Un autre approche est de modifier les clients DHCP existants :

  • Elvis Pfützenreuter a écrit un patch pour le client/serveur uDHCP[20]. Aucune de ces implémentation n'adresse les sorties du noyau lors d'émissions de réponses ARP[21] ou lors de clôtures de connexions réseaux existantes.

Références[modifier | modifier le code]

  • (en) Erik Guttman, « Autoconfiguration for IP Networking: Enabling Local Communication », IEEE Internet Computing, vol. 5, no 3,‎ , p. 81-86
  1. ↑ (en) « Dynamic Configuration of IPv4 Link-Local Addresses », Request for comments no 3927,
  2. ↑ (en) « IPv6 Stateless Address Autoconfiguration », Request for comments no 2462,
  3. ↑ http://www.watersprings.org/pub/id/draft-manning-dnsext-mdns-00.txt
  4. ↑ (en) « Link-Local Multicast Name Resolution (LLMNR) », Request for comments no 4795,
  5. ↑ http://www1.ietf.org/mail-archive/web/ietf/current/msg37126.html
  6. ↑ http://www1.ietf.org/mail-archive/web/ietf/current/msg37773.html
  7. ↑ http://www1.ietf.org/mail-archive/web/ietf/current/msg37740.html
  8. ↑ Plus de détails sur les différences
  9. ↑ (en) « A DNS RR for specifying the location of services (DNS SRV) », Request for comments no 2782,
  10. ↑ (en) « Service Location Protocol, Version 2 », Request for comments no 2608,
  11. ↑ (en) « Vendor Extensions for Service Location Protocol, Version 2 », Request for comments no 3224,
  12. ↑ http://www.ietf.org/html.charters/OLD/zeroconf-charter.html
  13. ↑ http://www.ietf.org/html.charters/dnsext-charter.html
  14. ↑ http://www.ietf.org/html.charters/OLD/svrloc-charter.html
  15. ↑ http://www.macdevcenter.com/pub/a/mac/2004/08/31/osx_java.html
  16. ↑ http://www.apple.com/support/downloads/bonjourforwindows.html
  17. ↑ http://www.porchdogsoft.com/products/howl/
  18. ↑ http://0pointer.de/lennart/projects/nss-mdns
  19. ↑ http://www.zeroconf.org/AVH-IPv4LL.c
  20. ↑ http://udhcp.busybox.net/lists/udhcp/2005-May/000124.html
  21. ↑ http://www.science.uva.nl/research/air/wiki/LinkLocalARPMeasurements

Voir aussi[modifier | modifier le code]

Liens internes[modifier | modifier le code]

Liens externes[modifier | modifier le code]

v · m
7. Application
6. Présentation
5. Session
4. Transport
3. Réseau
2. Liaison
1. Physique

Zeroconf

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Utilisateur:ÉmilienKia/Zeroconf&oldid=134364283 ».