Utilisateur:EmilienKia/Zeroconf

Un article de Wikipédia, l'encyclopédie libre.

Pile de protocoles
7  Application
6  Présentation
5  Session
4  Transport
3  Réseau
2  Liaison de données
1  Physique
Modèle OSI

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)

Sommaire

[modifier] Choix des adresses

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

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).

[modifier] Résolution des noms

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"[1]) 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).

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[2], ce qui est considéré comme un problème par certains membres de l'IETF[3]. 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[4]. mDNS est compatible avec DNS-SD décrit dans la section suivante alors que LLMNR ne l'est pas[5].

[modifier] Découverte de services

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

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.0251.

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) 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.  Service types are given informally on a first-come basis.  ⇔  Les types de services sont fournis de manière informelle. 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.

[modifier] Le protocole de Microsoft : UPnP SSDP

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.

[modifier] Efforts vers un protocole standard IETF

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 et la RFC 3224 et sont implémentation est disponible sur Solaris et Linux.

[modifier] Standardization

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[6].

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[7]. 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[8].

[modifier] Implémentations majeures

[modifier] Bonjour d'Apple

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[9] 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[10].

[modifier] Howl

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[11], elle a été peu-à-peu remplacée par Avahi.

[modifier] Avahi

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[12].

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.

[modifier] Windows CE 5.0

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

[modifier] Adresses IPv4LL

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[13].

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[14].

 Neither of these implementations addresses kernel issues like the broadcasting of ARP replies[15] or closing of existing network connections.  ⇔  merci d'apporter votre expertise, et de préciser

[modifier] Références

  • (en) Erik Guttman, « Autoconfiguration for IP Networking: Enabling Local Communication », dans IEEE Internet Computing, 2001, 5 (3), p. 81-86
  1. ↑ http://www.watersprings.org/pub/id/draft-manning-dnsext-mdns-00.txt
  2. ↑ http://www1.ietf.org/mail-archive/web/ietf/current/msg37126.html
  3. ↑ http://www1.ietf.org/mail-archive/web/ietf/current/msg37773.html
  4. ↑ http://www1.ietf.org/mail-archive/web/ietf/current/msg37740.html
  5. ↑ Plus de détails sur les différences
  6. ↑ http://www.ietf.org/html.charters/OLD/zeroconf-charter.html
  7. ↑ http://www.ietf.org/html.charters/dnsext-charter.html
  8. ↑ http://www.ietf.org/html.charters/OLD/svrloc-charter.html
  9. ↑ http://www.macdevcenter.com/pub/a/mac/2004/08/31/osx_java.html
  10. ↑ http://www.apple.com/support/downloads/bonjourforwindows.html
  11. ↑ http://www.porchdogsoft.com/products/howl/
  12. ↑ http://0pointer.de/lennart/projects/nss-mdns
  13. ↑ http://www.zeroconf.org/AVH-IPv4LL.c
  14. ↑ http://udhcp.busybox.net/lists/udhcp/2005-May/000124.html
  15. ↑ http://www.science.uva.nl/research/air/wiki/LinkLocalARPMeasurements

[modifier] Voir aussi

[modifier] Liens internes

[modifier] Liens externes