Zeroconf (auch Automatic Private IP Adressing oder kurz: APIPA) ist eine Technik zur konfigurationsfreien Vernetzung von Geräten in lokalen Rechnernetzen.
Die Motivation bei Zeroconf ist, einen Mechanismus zu realisieren, der ein möglichst einfaches Einrichten und den konfigurationslosen Betrieb von IP-Netzen ermöglicht. Eine einfache Anwendung wäre, zwei Notebooks mit einem Crossover-Kabel zu verbinden, beide Geräte konfigurieren dann automatisch ihre Netzwerk-Interfaces, finden sich gegenseitig in diesem gerade etablierten Netzwerk, und kommunizieren über IP. Das ganze geschieht ohne ein manuelles Eingreifen eines der Notebook-User oder durch das Verwenden von externer Netzwerkkonfiguration wie DHCP.
Dieses Problem ist nicht neu, und wurde mit AppleTalk unter Mac OS und NetBIOS unter Microsoft Windows schon gelöst. Die Zeroconf Working Group hat sich jedoch das Ziel gesetzt, einen ähnlichen Mechanismus aufbauend auf offenen, gut dokumentierten und damit einfach zu implementierenden Standards zu realisieren, und dabei drei wesentliche Problembereiche identifiziert, die durch die Spezifikation von offenen Protokollen und Mechanismen gelöst wurden:
- automatische Allokation von IP-Adressen ohne DHCP-Server
- Übersetzen von Namen und IP-Adressen ohne DNS-Server
- automatisches Finden von Services im lokalen Netzwerk ohne einen zentralen Directory-Server
Ebenfalls wichtig ist, dass durch Zeroconf konfigurierte Netzwerke schon bestehende Netzwerkinfrastruktur nicht beeinträchtigen.
Automatische IP-Allokation
Als Lösung für den ersten Punkt wurde die dynamische Konfiguration von sogenannten Link-Local IPv4-Adressen auserkoren. Dabei handelt es sich um einen auf dem Address Resolution Protocol (ARP) aufbauenden Mechanismus, um für ein Netzwerk-Interface automatisch eine freie IP-Adresse auszuwählen. Für genau diesen Zweck ist dafür von der IANA der Adressbereich 169.254.0.0/16 vorgesehen.
Wenn ein Rechner eine Link-Local IP-Adresse konfigurieren will, wählt er einfach mit Hilfe eines Zufallszahlengenerators eine IP-Adresse zwischen 169.254.1.0 und 169.254.254.255 (RFC 3330) aus. Die ersten 256 und die letzten 256 Adressen sind von der IANA für zukünftige Anwendungen reserviert, und dürfen unter keinen Umständen ausgewählt werden. Auch muss bei der Generierung der Zufallszahlen rechnerspezifische Information einfließen, wie etwa die MAC-Adresse der Netzwerkschnittstelle, um sicherzustellen, dass soweit möglich jedes Mal dieselbe IP-Adresse generiert wird.
Nach der Auswahl einer geeigneten IP-Adresse muss der Rechner auch diese für sich beanspruchen, und testen, ob diese nicht schon von einem anderen Rechner verwendet wird. Dieser Test muss unbedingt durchgeführt werden, bevor die IP-Adresse als Senderadresse in IP- oder ARP-Paketen verwendet wird, und genau dann, wenn ein Netzwerkinterface aktiviert wird. Das kann etwa das Einschalten oder Rebooten des Rechners, das Aufwachen aus einem Sleep-Modus, das Einstecken eines Ethernet-Kabels oder das automatische Einhängen eines Rechners in ein WLAN sein. Explizit verboten ist, diese Überprüfung periodisch durchzuführen, da das eine Verschwendung von Netzwerkressourcen darstellen würde, und im eigentlichen Test auf Adresskonflikte schon eine Möglichkeit vorgesehen ist, eventuelle Konflikte auch passiv zu erkennen und darauf zu reagieren.
Die Überprüfung von Adressen auf Konflikte erfolgt mit Hilfe von ARP Probes. Ein ARP Probe ist ein ARP-Paket, bei dem die Absender-IP auf 0.0.0.0 gesetzt wird, und als Empfänger-IP die zu überprüfende Adresse verwendet wird.
Sobald der Rechner bereit ist, mit der Konfliktüberprüfung zu beginnen, wartet er eine zufällig lange Zeit zwischen 1 und 2 Sekunden, und sendet dann 3 ARP Probes aus, mit einem zufälligen Zeitabstand von 1 bis 2 Sekunden. Empfängt der Rechner zwischen dem Testanfang und 2 Sekunden nach Versenden der letzten ARP Probe ein ARP-Paket, bei dem die Absender-IP der zu überprüfenden IP-Adressen entspricht, so wurde ein Konflikt gefunden, und der Rechner muss diese Prozedur mit einer anderen zufällig generierten IP-Adresse wiederholen.
Wird in diesem Zeitraum eine andere ARP Probe empfangen, die als Empfänger-IP die zu testende IP enthält, und deren Absender-MAC-Adresse keiner der MAC-Adressen der Netzwerkinterfaces des Rechners entspricht, so muss vom Rechner ebenfalls eine neue IP-Adresse generiert und überprüft werden. Das kann beispielsweise passieren, wenn zwei oder mehrere Rechner gleichzeitig probieren, dieselbe Link-Local Adresse zu konfigurieren.
Um ARP-Stürme und damit eine Überlastung des lokalen Netzwerkes zu vermeiden, wenn es zu mehreren Konflikten kurz hintereinander kommt, muss jeder Rechner nach zehn Fehlversuchen die Geschwindigkeit, mit der er neue Adressen auswählt und überprüft, auf maximal eine Überprüfung pro Minute reduzieren.
Konnte der Rechner keinen Konflikt feststellen, so hat er erfolgreich die generierte IP-Adresse für sich beansprucht, und muss diese bekanntmachen, indem er zwei sogenannte ARP Announcements versendet, mit einem Abstand von 2 Sekunden. Ein ARP Announcement unterscheidet sich von einer ARP Probe nur dadurch, dass als Absender- und Empfänger-IP die neu ausgewählte Link-Local IP-Adresse eingesetzt wird.
Die Erkennung von Konflikten muss auch nach dem Auswählen einer verwendbaren IP-Adresse stattfinden. Empfängt der Rechner ein ARP-Paket, das von einem anderen Rechner versendet wurde, und als Empfänger-IP die eigene IP-Adresse enthält, so handelt es sich um einen Adressenkonflikt.
Der Rechner hat nun zwei Möglichkeiten, nämlich eine neue IP-Adresse auszuwählen, oder seine IP-Adresse zu verteidigen. Letzteres ist besonders dann zu empfehlen, wenn der Rechner noch TCP-Verbindungen offen hat. Wurden noch keine kollidierenden ARP-Pakete empfangen, erfolgt die Verteidigung der Adresse durch den Rechner dadurch, dass dieser ein ARP-Announcement aussendet. Konnte der Rechner jedoch in den letzten Sekunden schon einen Adresskonflikt feststellen, so muss dieser eine neue IP-Adresse auswählen, um eine Endlosschleife zu vermeiden, wenn zwei Rechner mit gleicher IP-Adresse versuchen1, diese gegenüber dem anderen zu verteidigen.
Multicast DNS
| Anwendung | Multicast DNS | |||
| Transport | UDP | |||
| Netzwerk | IP | |||
| Netzzugang | Ethernet | Token Ring |
FDDI | ... |
Die Probleme, Namen und IP-Adressen ohne DNS-Server zu übersetzen, sowie einen Mechanismus zum automatischen Veröffentlichen und Finden von Netzdiensten verfügbar zu haben, wurden von der Zeroconf Working Group praktischerweise zusammengefasst, und in Form der zwei grundsätzlich unabhängigen, jedoch einander gut ergänzenden Protokolle Multicast-DNS (mDNS) und DNS Service Discovery (DNS-SD) zu Papier gebracht.
mDNS ist dabei nichts anderes als eine Beschreibung, wie Clients verfahren müssen, wenn sie DNS-Anfragen an Multicast-Adressen senden, und wie eine Gruppe an Rechnern damit umgeht, sodass die Anfrage richtig und ohne erhöhte Last auf dem Netzwerk beantwortet wird. DNS-SD dagegen führt einen neuen Typ an DNS Records ein, sodass das Browsen und Veröffentlichen von Netzwerkdiensten mit DNS ermöglicht wird.
mDNS legt fest, dass die DNS Top-Level-Domain ".local." link-lokal ist. Anfragen und Antworten, die mit ".local." zu tun haben, ergeben ähnlich IP-Adressen aus dem 169.254.0.0/16-Bereich nur im lokalen Netz Sinn. Alle DNS-Abfragen für Namen, die auf ".local." enden, müssen mit UDP und IP Multicast an die mDNS-Multicast-Adresse 224.0.0.251 Port 5353 gesendet werden. Ist kein anderer DNS-Server verfügbar, können auch Anfragen, die nicht auf ".local." enden an diese Adresse gesendet werden.
Jedem Rechner steht es übrigens frei, sich einen eigenen Rechnername aus der .local.-Domain auszuwählen. Im Gegensatz zu anderen, öffentlichen Toplevel-Domains gibt es keinerlei Formalitäten, außer dass bereits vergebene Rechnernamen nicht mehr verwendet werden sollten. Natürlich kann es in der Praxis zu Konflikten kommen, von den Erfindern von mDNS wurde das aber als sehr unwahrscheinlich angenommen. Eine Konfliktlösung wird sogar bewusst nicht diskutiert, da es sinnvolle Anwendungen für den Fall geben kann, dass mehrere Rechner den gleichen Namen tragen – etwa für Load-Balancing- oder High-Availability-Lösungen.
Soll über eine Reverse-Mapping-DNS-Abfrage der Hostname zu einer link-lokalen IP-Adresse ermittelt werden, so muss auch diese an 224.0.0.251 Port 5353 gesendet werden.
Um den Netzwerkverkehr möglichst gering zu halten, haben sich die Erfinder von mDNS ein paar Verhaltensregeln einfallen lassen, die doppelte oder gar mehrfache mDNS-Abfragen und -Antworten verhindern sollen.
Eine Möglichkeit zur Unterdrückung von bereits bekannten Antworten besteht darin, dass der Client, der eine mDNS-Abfrage versendet, schon bekannte Antworten, die noch in seinem Cache zu finden sind, als Answer Records an seine Abfrage anhängt. Sieht nun ein anderer Client, der die Abfrage beantworten könnte, seine vorgeschlagene Antwort als Answer Record, und ist die TTL (Time to live) noch mehr als die Hälfte der üblichen TTL, muss er diese nicht mehr versenden. Ist die TTL zu gering, muss der andere Client eine Antwort versenden, um die im Cache des ersten Clients gespeicherte TTL zu aktualisieren.
Wenn mehrere Clients in etwa zur selben Zeit eine Abfrage versenden wollen, würde es normalerweise zu mehrfachen Abfragen kommen. Verwenden die Clients jedoch mDNS und versendet ein Client eine Abfrage, während ein anderer die gleiche Abfrage vorbereitet, sollte der andere Client diese Abfrage als seine eigene betrachten und die Antwort darauf verwenden, anstatt eine eigene Abfrage zu versenden. Das spart Zeit und Netzwerkressourcen.
Implementierungen
Die erste Implementierung von Zeroconf wurde von Apple durchgeführt, hört auf den Namen Bonjour (Früher Rendezvous), ist seit der Version 10.2 in Mac OS X integriert und heutzutage schon in die meisten von Apple ausgelieferten Programmen integriert, soweit es sinnvoll ist.
Eine Komponente von Bonjour ist das mDNSResponder-Projekt, das von Apple im Sourcecode unter der APSL-Lizenz veröffentlicht wurde. mDNSResponder implementiert dabei mDNS und DNS-SD, und wurde von Apple portabel designt und implementiert, sodass der Sourcecode nicht nur unter Mac OS X 10.2 und 10.3, sondern auch unter Linux, FreeBSD, NetBSD, OpenBSD, Solaris, VxWorks, Mac OS 9 und Windows ohne Anpassungen übersetzt werden kann.
Mit Avahi existiert auch eine vollkommen freie (LGPL) Implementation von mDNS/DNS-SD.
In Microsoft Windows ist eine automatische IP-Addressen-Vergabe seit Windows 98 implementiert. Sie entspricht jedoch nicht der RFC der IETF. Hier kann man kann dieses Verhalten in der Registry im Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces abschalten. Dazu muss beim betroffenen Interface ein neuer DWORD-Wert mit dem Namen IPAutoconfigurationEnabled und dem Wert 0 erstellt werden.