Damit Geräte in Netz­wer­ken mit­ein­an­der kom­mu­ni­zie­ren können, müssen sie zunächst eine Ver­bin­dung mit­ein­an­der aufbauen. Zur Kon­takt­auf­nah­me benötigen sie nicht etwa den Namen des Gerätes, sondern die IP- bzw. MAC-Adresse, die den Teil­neh­mern in größeren Netz­wer­ken für ge­wöhn­lich au­to­ma­tisch durch einen zentralen DHCP-Server (Dynamic Host Con­fi­gu­ra­ti­on Protocol) zu­ge­wie­sen wird. Damit arbeitet er dem DNS-Server zu, der für die Um­wand­lung des Do­mä­nen­na­mens in eine IP-Adresse bzw. auch an­ders­her­um für die der IP-Adresse in den Do­mä­nen­na­men zuständig ist. Die Al­ter­na­ti­ve zu dieser au­to­ma­ti­schen Adress­zu­ord­nung besteht darin, die hosts-Dateien aller Netzwerk-Teil­neh­mer an­zu­pas­sen und die Namen sowie die IP-Adressen manuell ein­zu­tra­gen – ein Un­ter­fan­gen, das bei einem größeren Netzwerk schier unmöglich zu be­werk­stel­li­gen ist.

Beide Wege sind bei der Ein­rich­tung eines lokalen Netzwerks also nicht als ideal: Ei­ner­seits ist auch die Kon­fi­gu­ra­ti­on von DHCP- und DNS-Server mit einem gewissen Aufwand und Know-how verbunden, an­de­rer­seits erfordert die manuelle Variante immer wieder die Anpassung aller hosts-Dateien, wenn man dem Netzwerk bei­spiels­wei­se ein neues Gerät hinzufügt oder wenn Än­de­run­gen an bereits ein­ge­bun­de­nen Systemen notwendig sind. Die Lösung des Problems trägt den Namen Zero Con­fi­gu­ra­ti­on Net­wor­king – kurz Zeroconf – und be­zeich­net die Idee eines IP-Netzes, das Geräte ohne manuelle Kon­fi­gu­ra­ti­on mit­ein­an­der verbindet. Das Netzwerk-Konzept, mit dessen Aus­ar­bei­tung sich eine Ar­beits­grup­pe der IETF (Internet En­gi­nee­ring Task Force) zwischen 1999 und 2003 be­schäf­tigt hat, ist unter anderem in den Im­ple­men­tie­run­gen Bonjour und Avahi rea­li­siert worden.

Die wich­tigs­ten In­for­ma­tio­nen zu Zeroconf im Überblick

Als die Internet En­gi­nee­ring Task Force 1999 mit dem Projekt Zero Con­fi­gu­ra­ti­on Net­wor­king begann, setzte man sich folgende Merkmale für die „kon­fi­gu­ra­ti­ons­lo­se Ver­net­zung“ als Ziel:

  • in­te­grier­te Na­mens­auf­lö­sung
  • au­to­ma­ti­sche Zuordnung der Sub­netz­mas­ke, der eigenen IP-Adresse sowie des Routers
  • Such­funk­ti­on, um ver­füg­ba­re Netz­werk­diens­te zu finden
  • au­to­ma­ti­sche Zuweisung von Multicast-Adressen für Mehr­punkt­ver­bin­dun­gen
  • gleiches Si­cher­heits­le­vel wie Netzwerke ohne Zeroconf

Die Ar­beits­grup­pe der IETF konnte letztlich jedoch nicht zu einem Konsens kommen, weshalb sie zum Ende der Pro­jekt­zeit auch kein Dokument mit den An­for­de­run­gen des Zero Con­fi­gu­ra­ti­on Net­wor­kings ver­öf­fent­lich­te. Statt­des­sen entschied man sich, gemeinsam mit Apple, Microsoft und Sun Mi­cro­sys­tems, eine Spe­zi­fi­ka­ti­on für das In­ter­net­pro­to­koll aus­zu­ar­bei­ten, die 2005 unter dem Namen „Dynamic Con­fi­gu­ra­ti­on of IPv4 Link-Local Adresses“ (RFC 3927) ver­öf­fent­lich wurde. IPv4LL vergibt au­to­ma­tisch zufällige IP-Adressen mit dem Präfix 169.254/16, also aus dem Bereich 169.254.0.x bis 169.254.255.x, wobei die ersten sowie die letzten 256 Adressen für zu­künf­ti­ge An­wen­dun­gen re­ser­viert sind. Der RFC-Standard setzt zudem voraus, dass der Zu­falls­ge­nera­tor beim Erzeugen der In­ter­net­adres­sen rech­ner­spe­zi­fi­sche In­for­ma­tio­nen wie zum Beispiel die MAC-Adresse der Netz­werk­schnitt­stel­le mit­ein­be­zieht – was die Wahr­schein­lich­keit minimiert, dass zwei Geräte die gleiche IP erhalten.

So funk­tio­niert die au­to­ma­ti­sche Adress­ver­ga­be in IPv4

Für die au­to­ma­ti­sche Adress­ver­ga­be ohne das DHCP-Protokoll bedient sich IPv4 des Address Re­so­lu­ti­on Protocols (ARP), das in IPv6 durch das Neighbor Discovery Protocol (NDP) ersetzt worden ist. Dabei durch­läuft der Ver­ga­be­pro­zess mehrere Schritte, um Konflikte zwischen den IP-Adressen der teil­neh­men­den Netz­werk­ge­rä­te zu vermeiden.

  1. Zunächst wird die IP-Adresse generiert.
  2. An­schlie­ßend sieht IPv4LL so­ge­nann­te ARP-Proben vor, bei denen überprüft wird, ob die ge­ne­rier­te IP-Adresse bereits im Netzwerk genutzt wird. Zu diesem Zweck werden drei ARP-Pakete mit der Ab­sen­der­adres­se 0.0.0.0 und der zu über­prü­fen­den Adresse als Empfänger versendet.
  3. Wird in diesem Zeitraum ein ARP-Paket empfangen, bei dem die Ab­sen­der­adres­se der erzeugten IP-Adresse ent­spricht, ist diese im Netzwerk bereits vergeben und die IP-Ge­ne­rie­rung beginnt von vorne.
  4. Wird eine fremde ARP-Probe empfangen, die mit der zu testenden Adresse ge­kenn­zeich­net ist, versucht min­des­tens ein weiteres Gerät, dem Netzwerk mit dieser IP bei­zu­tre­ten, weshalb die Prozedur ebenfalls von Schritt 1 an wie­der­holt wird.
  5. Bleibt ein Konflikt aus, hat das ver­bin­den­de Gerät die Adresse er­folg­reich für sich be­an­sprucht und sendet zwei so­ge­nann­te ARP-An­nounce­ments („An­kün­di­gun­gen“) aus, in denen Absender- und Emp­fän­ger­adres­se der ge­ne­rier­ten IP ent­spre­chen.

Da die zu­ge­wie­se­ne IP-Adresse dynamisch ist, wird sie nach jedem Neustart, Aufwachen aus dem Ruhemodus, Ein­ste­cken des Ethernet-Kabels oder Einloggen in das WLAN erneut überprüft. Damit eine hohe Zahl an Kon­flik­ten nicht zu einer Über­be­las­tung des Netzwerks führt, zum Beispiel wenn sich viele Geräte gleich­zei­tig mit dem Netzwerk verbinden möchten, wird die Anzahl an Neu­ver­su­chen pro Gerät nach zehn Kon­flik­ten au­to­ma­tisch auf eine Prüfung pro Minute reduziert.

Zeroconf: Na­mens­auf­lö­sung und au­to­ma­ti­sche Ge­rä­te­er­ken­nung

Gemeinsam mit der Ar­beits­grup­pe DNS Ex­ten­si­ons ent­wi­ckel­te das Team von Zeroconf außerdem auch Lösungen für die au­to­ma­ti­sche Adress­über­set­zung und Ge­rä­te­ver­wal­tung in den kon­fi­gu­ra­ti­ons­lo­sen IPv4-Netz­wer­ken. Anstatt ein komplett neues Protokoll zu entwerfen, entschied man sich dazu, diese Funk­tio­nen durch einfache An­pas­sun­gen des Standard-DNS-Pro­to­kolls zu bieten. Dabei ar­bei­te­ten die Pro­jekt­grup­pen eng mit Apple zusammen, denn das Elek­tronik­un­ter­neh­men hatte mit seiner fir­men­ei­ge­nen Pro­to­koll­samm­lung AppleTalk bereits ent­spre­chen­de Lösungen für die eigenen Geräte, die es lediglich auf die In­ter­net­pro­to­koll­fa­mi­lie zu über­tra­gen galt. Ergebnis waren die Spe­zi­fi­ka­tio­nen Multicast DNS (RFC 6762) und DNS-Based Service Discovery (RFC 6763).

Multicast DNS (mDNS) be­schreibt, wie Geräte DNS-Anfragen an IP-Multicast-Adressen ver­schi­cken können. Zu diesem Zweck ist die Top-Level-Domain .local im mDNS-Protokoll als link-lokal definiert. Zudem müssen alle Anfragen, die auf .local enden, an die IPv4LL-Multicast-Adresse 224.0.0.251 (in IPv6 ist es die Adresse FF02::FB) geschickt werden. Alle DNS-Anfragen, die nicht auf .local enden, gelangen ebenfalls zu der Multicast-Adresse, wenn das Netzwerk nicht über einen DNS-Server verfügt. Generell können mDNS-Nach­rich­ten sowohl über UDP als auch über TCP über­tra­gen werden. Dabei wird statt des üblichen Ports 53 der Multicast-Port 5353 genutzt. Will ein Netz­werk­ge­rät nun den Hostnamen eines anderen Netz­werk­teil­neh­mers auflösen, schickt er diesem eine mDNS-Anfrage mit der Bitte um Iden­ti­fi­zie­rung. Das Zielgerät antwortet mit einem Multicast-Paket, das seine IP-Adresse preisgibt. Alle Netz­werk­ge­rä­te erhalten diese In­for­ma­ti­on und nehmen sie au­to­ma­tisch in ihrem DNS-Cache auf.

DNS-Based Service Discovery (DNS-SD) definiert, wie Dienste in einem Zeroconf-Netzwerk für alle Teil­neh­mer sichtbar und verfügbar gemacht werden können. Aus Ab­stim­mungs­zwe­cken ist es zunächst notwendig, diese Dienste bei der IANA (Internet Assigned Numbers Authority) zu re­gis­trie­ren, um einen eindeutig zu­or­den­ba­ren Ser­vice­na­men zu erhalten. Den je­wei­li­gen Namen teilen An­wen­dun­gen den Netz­werk­teil­neh­mern dann per Multicast-Be­nach­rich­ti­gung mit, wobei es keinerlei Problem darstellt, wenn mehrere Geräte den gleichen Dienst anbieten: Der zu­grei­fen­de Netzwerk-Client hat in diesem Fall einfach die Mög­lich­keit, einen der Hosts aus­zu­wäh­len.

Die beiden RFCs hat die IETF erst im Februar 2013 offiziell ver­öf­fent­licht, Apple hat als Initiator jedoch bereits 2002 damit begonnen, die Standards in seine Geräte zu in­te­grie­ren. Die zu diesem Anlass ent­wi­ckel­te Software, die heute unter dem Namen Bonjour (früher Ren­dez­vous) bekannt und Open Source ist, zählt zwei­fels­frei zu den ver­brei­tets­ten Zeroconf-Lösungen. So ist die kon­fi­gu­ra­ti­ons­lo­se Netzwerk-Ar­chi­tek­tur nicht nur für macOS und iOS, sondern auch für Windows verfügbar.

Bonjour: Apples Antwort auf mühsame Netz­werk­kon­fi­gu­ra­tio­nen

Als Apple im Jahr 2001 mit Mac OS X 10.0 auf den hybriden XNU-Kernel umstieg, entschied man sich dazu, die bis dato typische Netz­werk­pro­to­koll­grup­pe AppleTalk nicht auf das neue Be­triebs­sys­tem zu portieren. Dass der Elek­tronik­rie­se be­ab­sich­tig­te, keinen adäquaten Nach­fol­ger zu ent­wi­ckeln, passte dem Mac-Nutzer Stuart Cheshire nicht im Ge­rings­ten, weshalb er eine E-Mail-Dis­kus­si­ons­run­de ins Leben rief, in der er gemeinsam mit anderen Usern die Schwächen der notwendig ge­wor­de­nen manuellen Netz­werk­kon­fi­gu­ra­ti­on ansprach. Das brachte Apple zum Umdenken: Kur­zer­hand stellte man Stuart Cheshire ein und be­auf­trag­te ihn mit der Ent­wick­lung einer Pro­to­koll­va­ri­an­te für das neue Be­triebs­sys­tem, woraus die bereits erwähnte Zu­sam­men­ar­beit mit der Internet En­gi­nee­ring Task Force re­sul­tier­te.

Mit Mac OS X 10.2 ver­öf­fent­lich­te Apple im August 2002 die erste Version der neuen Pro­to­koll­spe­zi­fi­ka­tio­nen unter dem Namen Ren­dez­vous. Aufgrund recht­li­cher Probleme war man gezwungen, einen neuen Titel für das Projekt zu finden, weshalb die Netzwerk-Software seit Version 10.4 den noch heute gültigen Namen Bonjour trägt. Die Haupt­kom­po­nen­te des Pakets ist der mDNS­Re­spon­der, ein beim Boot-Prozess star­ten­des und im Hin­ter­grund ab­lau­fen­des Programm, das Multicast DNS und DNS-Based Service Discovery im­ple­men­tiert. Ferner gehört mitt­ler­wei­le natürlich auch die In­ter­net­pro­to­koll-Spe­zi­fi­ka­ti­on IPv4LL (bzw. IPv6LL) zu den Haupt­be­stand­tei­len. Damit deckt die Apple-Lösung die drei ele­men­ta­ren Bereiche des kon­fi­gu­ra­ti­ons­lo­sen Netzwerks ab:

  • Adres­sie­rung
  • Na­mens­auf­lö­sung
  • Netz­werk­dienst­er­ken­nung

Dank dieser Ar­chi­tek­tur stellen Sie mit Ihrem Gerät einfach und un­kom­pli­ziert Ver­bin­dung zu anderen Kom­po­nen­ten in lokalen Netz­wer­ken her, die ebenfalls auf Bonjour zu­rück­grei­fen – egal, ob es sich um einen PC, einen Drucker oder eine Anwendung handelt. So verwendet unter anderem der Apple-Mu­sik­dienst iTunes die Tech­no­lo­gie, damit au­to­ma­tisch andere Nutzer gefunden werden, die ihre Musik im Netzwerk freigeben. Auf gängigen macOS- und iOS-Systemen ist die Bonjour-Software au­to­ma­tisch in­stal­liert. Windows-User können entweder eine spe­zi­fi­sche Version für Druck­diens­te her­un­ter­la­den oder al­ter­na­tiv eine Ap­pli­ka­ti­on in­stal­lie­ren, in deren Umfang die Software enthalten ist. Hierzu zählen unter anderem das genannte iTunes, Skype und Adobe Photoshop (ab CS3).

Eine Al­ter­na­ti­ve zu Apples Zeroconf-Lösung, die auch auf Linux-Systemen funk­tio­niert, unter Debian und Ubuntu stan­dard­mä­ßig in­stal­liert ist und unter der freien Lizenz LGPL zur Verfügung steht, ist Avahi. Die Im­ple­men­tie­rung erfuhr zunächst Un­ter­stüt­zung durch die ge­mein­nüt­zi­ge free­de­sk­top.org-In­itia­ti­ve, hat sich mitt­ler­wei­le aber zu einem ei­gen­stän­di­gen Projekt ent­wi­ckelt.

Zum Hauptmenü