Impression

Transcription

Impression

ZERO CONF
Exposé option Réseaux et Interconnexion d'Ordinateurs
C.PERROTIN
TTN 08
ZeroConf : P.BLEDU, C.PERROTIN Elève ingénieur TELECOM LILLE1 2008.
P.BLEDU
FA 08
p1/14
ZEROCONF
1- CONCEPT ________________________________ 3
2-TECHNIQUE ______________________________ 4
2.1
2.1.1
2.1.2
2.1.3
Allocation dynamique d'adresse IP sans serveur DHCP ________________________ 4
Allocation des adresses de lien-local_______________________________________________ 4
Vérification de l’unicité de l’adresse_______________________________________________ 4
Détection d’adresse dupliquée____________________________________________________ 5
2.2 Résolution de noms et adresses IP sans serveur DNS ______________________________ 5
2.2.1
2.2.2
2.2.3
2.3
2.3.1
2.3.2
2.3.3
2.4
Différence entre LLMNR et mDNS _______________________________________________ 5
Protocole LLMNR ____________________________________________________________ 6
Protocole mDNS ______________________________________________________________ 6
Recherche de services sans annuaire ________________________________________ 7
Protocole SLP ________________________________________________________________ 7
Protocole SSDP_______________________________________________________________ 8
Protocole DNS-SD ____________________________________________________________ 8
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.
IPv4 multicast
IPv6 multicast
port
TTL - Hop Limit
mDNS
224.0.0.251
ff02::fb
5353
255
LLMNR
224.0.0.252
ff02::1:3
5355
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 HowTo1 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
DCP
DHCP
DNS
DNS-SD
Draft
EUI 64
ICMP
IETF
LDAP
LGPL
LLMNR
mDNS
Rendezvous
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.
Device Control Protocols
Dynamic Host Configuration Protocol, protocole
d'attribution dynamique des adresses sur un réseau IP.
Domain name Server, Service IP répondant aux requêtes
de conversion d'un nom IP en un numéro IP
correspondant.
un système d’enregistrement provisoire pour les noms de
protocoles a été mis en place sur le site de DNS-SD
http://www.frameip.com/ethernet-ouiieee
http://hautrive.free.fr/reseaux/architectur
es/reseaux-appletalk.html
www.asterisk.org
http://avahi.org
http://jargonf.org/wiki/DCP
http://jargonf.org/wiki/DHCP
http://www.afnic.fr/ext/dns
http://www.dns-sd.
org/ServiceTypes.html.
Anglicisme utilisé pour désigner une ébauche de RFC
http://standards.ieee.org/regauth/oui/tut
Extended Unique Identifier, sur 64 bits : Constitué d'un
orials/EUI64.html
identifiant de 24 bits du fabricant + 40 bits attribué par
l’IEEE
http://www.ietf.org/rfc/rfc792.txt
Internet Control Message Protocol protocole utilisé
pour véhiculer des messages de contrôle et d'erreur.
http://www.ietf.org
Internet Engineering Task Force. Organisation préparant
les principaux standards de l'Internet.
http://www.cru.fr/ldap/
LDAP (Lightweight Directory Access Protocol) est un
protocole d'accès à un annuaire, dérivé d' X500, au dessus
de TCP/IP.
http://www.gnu.org/licenses/lgpl.html
Lesser General Public License : licence libre ‘non
modifiable’
http://tools.ietf.org/html/rfc47
Link-local Multicast Name Resolution : ce protocole
95
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.multicastdns.org/
Extension du DNS proposée par Apple à l'IETF pour
prendre en compte les réseaux de petites tailles en espace
d’adressages privés.
http://www.apple.com/macosx/technolog
Nom donné par Apple au protocole Zeroconf.
y/bonjour.html
p12/14
RFC 2365
RFC 2461
RFC 2782
RFC 3927
SLP
(RFC 2608)
SOAP
SSDP
Stuart
Cheshire
UPnP
XML
Utilisation du multicast sélectif de sous réseau
Allocation dynamique d'adresses IP V6
DNS-SRV permet la découverte de service à travers un
réseau de serveur (ou de poste).
Allocation dynamique d'adresses IP V4
Service Location Protocole, permet de localiser les
services sur un réseau
Simple Object Access Protocol est un protocole de
transmission de messages XML entre objet
Simple Service Discovery Protocol : utilisé dans l’UPnP
fréquent sous windows XP.
http://www.soapuser.com/fr/
http://support.microsoft.com/kb/317843/f
r
Chercheur travaillant chez Apple à l’origine de Zeroconf
et de la RFC 3927, 4436, 3396, 3397, 3442 …
http://www.stuartcheshire.org/
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://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

Impression

Transcription

Documents pareils

Réseau IP sans configuration « Bonjour » : avancée

business objects desktop intelligence xi expert

1-Le matériel requis 2-Configuration de Logiciel Gigabyte

Business Objects Desktop Intelligence XI

Service Hébergement

TÊTES de liste

Administration de Windows Server 2012 (70-411)

Les requêtes des français sur Google pendant l`été

4 SERVEUR DNS

Rponses aux Questions sur Win Design - win

Calendrier ZADIG HYPERVISION AGENCE DE NANTERRE

Serveurs DNS des FAI 9 Telecom / 9Online DNS primaire

Gouvernance Technique de L`Internet:

Questions les plus fréquentes des participants

Structure de l`IETF et établissement des normes de l`Internet