zurück zum Artikel

Mit Windows 7 gelingt vieles, was früher viel Fummelei erforderte: Die Remote-Unterstützung verbindet sich ohne Weiteres und ein LAN richtet sich fast von selbst ein. Die Magie beruht auf IPv6 und dem Peer Name Resolution Protocol.

Es genügt nicht, auf einem Rechner einen Netzwerkdienst anzubieten. Die anderen, die darauf zugreifen sollen, müssen ihn auch finden. Dabei gibt es drei große Schwierigkeiten: Die IP-Adresse des Servers ist eine schlecht zu merkende Zahlenfolge und durch die automatische Netzkonfiguration im LAN per DHCP und die Adresszuteilung vom Provider bei jeder Einwahl kann sie sich jederzeit ändern. Außerdem übersetzen Router meistens mehrere Adressen im LAN auf nur eine Internet-Adresse (NAT), was nur in der Richtung aus dem LAN ins Internet automatisch klappt. Wer einen Dienst im lokalen Netz aus dem Internet zugänglich machen will, muss sich deshalb mit der Konfiguration von Port-Forwardings im Router herumschlagen.

Gegen das dritte Problem und einen Teil des zweiten bringt Microsoft schon seit Vista IPv6 in Stellung: Damit kann jeder Rechner im LAN eine feste Adresse benutzen, die sich aus seiner Hardware-Adresse (MAC) ableitet oder zufällig gesetzt wird, und der riesige Adressvorrat macht NAT überflüssig. Mit Tunnel-Techniken wie Teredo durchdringen Windows-Rechner problemlos das IPv4-Internet und sind unter einer globalen IPv6-Adresse erreichbar. Doch auch die kann sich ändern, und IPv6-Adressen wie 2001:0:d5c7:a2d6:0:fbef:a649:f80e sind noch schlechter zu behalten als IPv4-Adressen.

Um den Rest der Grundprobleme zu lösen, muss also ein Namensdienst her. Das DNS eignet sich dafür nicht sonderlich, da es Server braucht. Für ein kleines LAN lohnt sich die Mühe nicht, und einen global gültigen DNS-Namen für Internet-Dienste zu bekommen ist mit einigem Aufwand verbunden. Der alte Windows Internet Naming Service (WINS) braucht ebenfalls einen Server und empfiehlt sich trotz seines Namens nur im LAN. Die noch betagteren NetBIOS-Namen, die in XP- und Vista-Heimnetzen Verwendung finden, kommen zwar ohne Server aus, sind aber als unzuverlässig bekannt und eignen sich nicht zur Namensveröffentlichung im Internet.

Bei Microsoft hat man die große Lösung gewählt und unter dem Schlagwort "Peer-to- Peer-Networking" eine ganze Reihe von Protokollen gebündelt, die auf IPv6-Basis das Netzwerken ohne Server-Infrastruktur erlauben. Die für Namen zuständige Komponente ist das Peer Name Resolution Protocol (PNRP). Es erlaubt einem Rechner, seine Adresse(n) im LAN sowie im Internet mit Namen zu verknüpfen und seine Dienste zu annoncieren. Windows-Systeme seit XP beherrschen das Protokoll [1], doch erst Vista bringt den vollen Funktionsumfang mit. Microsoft hat die Protokoll-Interna offengelegt [2], sodass PNRP-Implementierungen für andere Betriebssysteme technisch möglich sind. Aktuell ist derzeit die Version 4 des Protokolls.

Das Prinzip

Kennen wir uns nicht?

PNRP benutzt die Erkenntnis aus der Realwelt, dass "jeder jeden über fünf Ecken kennt" für das Netzwerk. Es arbeitet wie moderne File-Sharing-Programme mit einer "Distributed Hash Table" (DHT). Jeder Teilnehmer (PNRP-Node) hält einen Teil der Informationen über den Namensraum sowie Referenzen über die benachbarten PNRPNodes bereit.

Diesen verteilten Cache nennt man bei PNRP eine Wolke (PNRP Cloud), was jedoch nichts mit dem momentan hochgekochten Cloud-Computing zu tun hat. PNRP unterscheidet verschiedene, voneinander unabhängige Wolken, entsprechend der Reichweite der IPv6-Adressen, die innerhalb der Wolke gefunden werden können: Es gibt die globale Wolke und Link-lokale Wolken, eine für jedes Interface mit IPv6-Adresse. Nur Namen in der globalen Wolke sind im ganzen IPv6-Internet sichtbar. Die Link-lokalen Wolken enthalten Namen von Rechnern innerhalb des lokalen Netzwerk-Segments. Da die Site-lokalen IPv6-Adressen schon im September 2004 per RFC 3879 [3] für veraltet erklärt wurden, gibt es die im ersten PNRP-Entwurf vorgesehene Wolke auf dieser Ebene nicht mehr. Allerdings können Netz-Admins an ihrer Stelle mit einigem Fummeln ihre eigenen Wolken aufsetzen.

Eine Anwendung, die PNRP benutzt, ist die Remote-Unterstützung in Windows 7. Der Hilfesuchende kann die Verbindung mittels "Easy Connect" anfordern und sieht dann nur ein 12-stelliges Passwort. Der PC berechnet daraus einen Namen, den er in der globalen PNRP-Wolke bekannt gibt. Das Passwort übermittelt der Hilfesuchende dem Helfer, dessen PC ebenfalls den Namen berechnet und sich mittels PNRP die IPv6- Adresse holt, um die Verbindung aufzubauen.

Um einen Namen aufzulösen, wandelt der PC ihn zunächst in eine Zahl um, die PNRP-ID genannt wird. Nun schaut der Resolver, ob er in seinem lokalen Teil der Hash-Tabelle einen passenden Eintrag hat. Falls nicht, fragt er denjenigen Node aus seiner Liste, dessen PNRP-ID am nächsten an der gesuchten liegt. Er sendet dabei eine Liste der Knoten, die er für diese Anfrage schon einmal kontaktiert hat. Dies verhindert, dass sich eine Namensauflösung im Kreis dreht, oder schon bekannte Referenzen nochmals zurückgegeben werden.

Nachgeschaut und aufgelöst

Der Knoten, der eine Anfrage bekommt, erstellt eine Liste der Knoten, deren PNRP-IDs näher an der gesuchten liegen, und sortiert sie nach dem Abstand. Dann löscht er die dem anfragenden Knoten schon bekannten IDs (diese standen ja in der Anfrage) und sendet die verbliebene Liste zurück. Der Fragende baut diese "Next Hop List" in seine ein und fragt beim nunmehr nächstliegenden an.

Es kann vorkommen, dass die verbliebene Liste leer ist, eine Sackgasse in der Auflösung (Dead End). Das kann zweierlei bedeuten: Entweder ist der befragte Knoten schon der gesuchte und die Abfrage war erfolgreich. Oder der Knoten kennt keinen weiteren, der näher am Ziel liegt. Dann versucht es der anfragende Knoten mit dem nächstbesten Eintrag aus seiner Liste.

Dieses iterative Verfahren ist seit der Version 2 der Stand der PNRP-Technik. Version 1 des Protokolls hatte noch ein inkompatibles rekursives Verfahren beschrieben, wie Microsoft es sich unter der Nummer 7 065 587 in den USA patentieren ließ.

Identitäten

Konstruierte Identitäten

Die PNRP-ID errechnet sich aus der sogenannten P2P-ID, die ihrerseits den Klartext- Namen enthält, und der "Service Location" (siehe Abbildung oben rechts). Der für Menschen verständlichen Name heißt bei Microsoft "Classifier" und darf 149 Zeichen lang sein. Erlaubt sind Unicode-Zeichen, jedoch weder Satz-, Leer- noch manche Sonderzeichen. PNRP unterscheidet hier Groß- und Kleinschreibung.

Im Prinzip kann jeder in PNRP jeden Namen registrieren. Um sicherzustellen, dass man wirklich die Adresse eines ganz bestimmten Rechners bekommt, enthält PNRP ein Public/Private-Key-Verfahren. Um einen Namen so zu sichern, bildet der registrierende Rechner den 128 Bit langen SHA1-Hash seines öffentlichen Schlüssels. Dieser Wert heißt in PNPR Authority und er bildet zusammen mit dem Classifier die P2P-ID, beispielsweise 1d55d80b110802e9f93e6a8a8a669b64791d1647.PnrpTest - Webserver.

Computer können solche Zahlenmonster austauschen, um einander ihre Dienste anzupreisen, und beim Aufbau einer Home-Group tun sie das auch. Menschen kommen besser mit P2P-IDs zurecht, die nicht per Public Key gesichert sind. Die Authority ist dann 0 und Microsoft spricht von "ungesicherten P2P-IDs". In den folgenden Beispielen kommen nur unsichere P2P-IDs wie 0.mypnrpname vor. Übrigens benutzt auch Microsoft sie für Easy Connect. Anders als gesicherte P2P-IDs verweisen sie jedoch jedes Mitglied einer Wolke jede unsichere ID registrieren kann. Die Prüfung muss auf einer anderen Protokollebene stattfinden, auch dazu dient das Passwort beim Easy Connect.

Über die gesamte P2P-ID wird nun wiederum der SHA1-Hash gebildet, sodass eine 128-Bit-Zahl entsteht. Daran wird die ebenfalls 128-bittige Service Location gehängt, und fertig ist die PNRP-ID, die schließlich als Index in die verteilte Hash-Tabelle dient. Der Service-Location-Teil der PNRP-ID wird aus der IPv6-Adresse gewonnen. Sie identifiziert den Knoten eindeutig, auch wenn eine identische P2P-ID mehrfach auf mehreren Knoten-Rechnern benutzt wird. So kann die P2P-ID beispielsweise einen Dienst beschreiben, den verschiedene Rechner anbieten. Sie registrieren dann einfach dieselbe unsichere P2P-ID mit verschiedenen Service Locations.

Der anfragende Knoten kann die Service Location nicht vorher kennen, da sie ja aus der IPv6-Adresse des Knotens berechnet wird. Daher gilt die PNRP-Suche als erfolgreich, wenn einem Eintrag die ersten 128 Bit (von links gezählt) der PNRP-ID mit der gesuchten übereinstimmen. In diesem Anteil der PNRP-ID steckt ja der Hash der gesuchten P2P-ID. Daher können mehrere Anfragen nach derselben P2P-ID auch zu unterschiedlichen Antworten führen.

Der Ablauf

Wolken säen

Sobald in Windows ein IPv6-Netzwerk konfiguriert ist, kann PNRP aktiv werden. Bei aktuellen Systemen geht alles automatisch, für XP muss man etwas Hand anlegen (siehe Kasten). PNRP kommuniziert über den UDP-Port 3450, dieser Port muss für eingehende Verbindungen in der Firewall freigeschaltet sein. Die Link-lokale Kommunikation benötigt zusätzlich Zugang zum UDP-Port 1900 für das Simple Service Discovery Protocol (SSDP).

Um PNRP bei der Arbeit zuzusehen, eignet sich das Kommandozeilenprogramm netsh, das zum Lieferumfang von Windows gehört. Seine Befehle sind in eine Baumstruktur von "Kontexten" gegliedert. Bei Aufruf über die Eingabeaufforderung muss man alle Kontexte mit angeben. So ruft die Zeile c:\> netsh p2p pnrp cloud show list den Befehl show list des cloud-Kontextes innerhalb von pnrp auf, das seinerseits unter p2p hängt. Komfortabler startet man netsh ohne Parameter und wechselt in einen Kontext. Dann muss man die Befehle nur noch relativ dazu eintippen. Die folgenden Beispiele gehen davon aus, dass Sie dies einmal mit

c:\> netsh
netsh> p2p pnrp

getan haben. Als Prompt zeigt netsh immer den gerade aktiven Kontext an. Der oben gezeigte Befehl lautet dann nur noch netsh p2p pnrp> cloud show list und erzeugt eine Liste wie

Ber. Kenn. Adr. Status Name
----- ------- ----- ------------ --------
1 0 1 Virtuell Global_
3 4 1 Virtuell LinkLocal_ff00::%14/8

Die Wolken befinden sich nach dem Start des Betriebssystems bis zur ersten Anfrage im Status "virtuell". Diese verzögerte Konfiguration (Lazy Initialization) verhindert überflüssige PNRP-Kommunikation mit benachbarten Knoten, solange PNRP nicht benötigt wird. Einmal gestartet, zeigt sich das Protokoll nämlich recht gesprächig, da es regelmäßig mit den anderen Knoten über Neuigkeiten in der Nachbarschaft tratscht.

Auf die erste Anfrage einer Anwendung hin besorgt sich PNRP zuerst eine Grund - füllung für die lokalen Caches der verschiedenen Wolken. Ohne diese Vorgabe könnte es mangels geeigneter Ansprechpartner mit der Namensauflösung gar nicht loslegen. Für diesen "Seeding" genannten Vorgang definiert das Protokoll verschiedene Methoden. In der globalen Wolke kontaktiert PNRP die beiden Server pnrpv2.ipv6.microsoft.com und pnrpv21.ipv6.microsoft.com (diese beiden Namen werden über klassisches DNS aufgelöst). Für die Link-lokale Wolke besorgt sich PNRP Information über das SSDP von UPnP [4] (Simple Service Discovery Protocol). Das Seeding lässt sich mit dem Befehl cloud synchronize seed (im "p2p pnrp"-Kontext) für eine Wolke auch erzwingen. Hat das Seeding geklappt, wechselt die Wolke in den Status "Aktiv" und ist bereit für die Namensauflösung. Eine Wolke im Status "Allein" konnte keine benachbarten Knoten finden (oft ein IPv6-Netzwerkproblem) und kann daher auch keine Namen auflösen.

Bekanntmachung

Jeder Teilnehmer einer Wolke kann eine neue P2P-ID registrieren, indem er einfach seinen Nachbarn Bescheid sagt. Den unge - sicherten Namen "mypnrpname" (P2P-ID 0.mypnrpname) registriert man per netsh im "p2p pnrp"-Kontext:

peer add registration 0.mypnrpname\ comment="Nur ein PNRP-Test"

Optional kann man mit cloud= den Namen auch nur in einer Wolke registrieren. Der Befehl cloud show names zeigt alle registrierten Namen an, auch die anderer Anwendungen (und allerhand weitere Statistiken über die Wolken).

Ein PNRP-Name bleibt so lange registriert, bis der registrierende Knoten ihn wieder löscht. Beim Beenden eines Prozesses geschieht das automatisch, sodass ein per netsh angemeldeter Name verschwindet, wenn man das Programm mit exit verlässt. Während der Sitzung löscht der Befehl peer delete registration den Namen. Aus einer anderen netsh-Sitzung (oder von einem anderen Rechner aus) kann die P2P-ID über den resolve-Befehl des peer-Kontextes aufgelöst werden:

peer resolve 0.mypnrpname
Auflösung wurde gestartet...
Gefunden:
Kommentar: Nur ein PNRP-Test
Adressen: [fe80:0000:0000:0000:0250:bfff:feb0:8836]%4:0
Erweiterte Nutzlast (Binärdaten):

Noch aufschlussreicher ist das traceroute-Kommando, das die einzelnen Kommunikationsschritte zeigt:

peer traceroute 0.mypnrpname Global_
Auflösungspfad:
[2001::d5c7:a2d6:0000:f3fa:a648:a70a]:3540, (0), (0)
Angenommen
[2001::cf2e:3096:189f:a6e3:2a1d:175d]:3540, (11), (2033)
Zurückgewiesen (Nicht erreichbar)
[2001::cf2e:3096:347a:30ed:3492:36c8]:3540, (10), (811)
Angenommen
[2001::d5c7:a2d6:0000:f69d:ab7c:3764]:3540, (132), (110)
Zurückgewiesen (Sackgasse)
[2001::d5c7:a2d6:0000:f69d:ab7c:3764]:3540, (0), (130)
Angenommen Endabfrage

des befragten PNRP-Knotens und dem UDP-Port die Anzahl der übereinstimmenden Bits zwischen dessen PNRP-ID und der gesuchten sowie die Round-Trip-Time in Millisekunden. Kommt innerhalb von zwei Sekunden keine Antwort, so wird dieser Knoten nicht weiter beachtet.

Falls das Resultat der Anfrage "Angenommen" (Accepted) lautet, verwies dieser Knoten auf einen weiteren, der näher am gesuchten Ziel liegt. "Zurückgewiesen (Nicht erreichbar)" (Rejected, unreachable) bedeutet, dass der Knoten nicht antwortete. Den Status "Zurückgewiesen (Sackgasse)" (Rejected, dead end) liefern Knoten, die keinen näher am Ziel liegenden Knoten kennen oder, wie eingangs erwähnt, selbst der gesuchte sind. War die Auflösung somit erfolgreich, kontaktiert der Resolver den Knoten direkt, verifiziert bei sicheren P2P-IDs die Signatur und überträgt die "Extended Payload". Der Vorgang heißt "Endabfrage" (Final Inquire). In der Extended Payload kann eine Anwendung bei der PNRPRegistration bis zu 4 KByte zusätzlicher Daten speichern. Diese Daten werden nicht im Cache von benachbarten Knoten vorgehalten, sondern nur auf Anfrage direkt an den anfragenden Knoten geliefert.

Namenssuche

Den Namen Suchen

Die Namen nur mit netsh aufzulösen wird auf die Dauer langweilig. Damit möglichst viele Programme sie benutzen können, hat Microsoft PNRP in den DNS-Resolver des Betriebssystems integriert: Wenn ein Programm beim System nach der Adresse zu einem Namen in der Domain pnrp.net nachfragt, löst Windows ihn nicht über DNS auf, sondern per PNRP. Davon profitieren natürlich nur die Programme, die DNS-Namen nicht selbst auflösen, sondern die Dienste des Betriebssystems nutzen. Anwendungen mit eigener Resolver- Bibliothek wie nslookup oder Opera haben daher nichts von PNRP. Ein Gateway, das DNS-Anfragen für die Domain pnrp.net selbst im PNRP auflöst und die Antwort per DNS zurückliefert, betreibt Microsoft nicht. Bei der Umwandlung einer P2P-ID in einen DNS-Namen (DNS Encoding) werden aus Authority und Classifier zwei DNS-Labels, also durch Punkte getrennte Bestandteile eines Domain-Names. Eine P2P-ID wird von links nach rechts aufgelöst (erst Authority, dann Classifier). Da bei DNS-Namen die Auflösung jedoch von rechts nach links läuft, werden Authority und Classifier vertauscht. Weil der PNRP-Classifier Unicode-Zeichen enthalten kann, wird er gemäß Punycode umgewandelt [5]. Falls die Punycode-Umwandlung nicht nötig ist, wird ein p vorangestellt und "-p" angehängt. Sollte das Authority-Label mit einer Ziffer beginnen (was die DNS-Regeln verbieten), kommt auch ein p davor. Für ungesicherte P2P-IDs gibt es dann eine platzsparende Kürzung: Sofern der Classifier nicht mit Punycode bearbeitet wurde, fallen das Authority-Label p0 und die Dreingaben am Classifier-Label wieder weg.

Aus der P2P-ID 0.mypnrpname entsteht so der DNS-Name mypnrpname.pnrp.net (oder pmypnrpname-p.p0.pnrp.net), aus 0.MyPNRPName wird mittels Punycode für die Großbuchstaben yame-4kahaobt.p0. pnrp.net. Diese Umrechnung erledigt der Befehl show convertedname im peer-Kontext von netsh in beiden Richtungen.

Leuchtfeuer

Um zu zeigen, wie eine native PNRP-Anwendung funktioniert, stellen wir das Beispielprogramm Beacon (englisch für Leuchtfeuer) zur Verfügung. Es nimmt beliebig viele Schlagwörter entgegen und generiert daraus P2PIDs, die es in der globalen Wolke registriert. Im Hintergrund sucht Beacon nach denselben PNRP-Namen, um Gleichgesinnte in der IPv6-Einsamkeit zu finden. Dabei sendet es bei jeder Anfrage eine Liste der schon bekannten PNRP-Knoten für das Schlagwort mit, sodass immer neue Knoten gefunden werden. Diese präsentiert das Programm gruppiert in einer minimalen grafischen Oberfläche. Auf Klick auf ein Stichwort zeigt Beacon zu dem Knoten weitere Details wie IPv6-Adressen, Rechnername, Betriebssystem und Anzahl der Prozessoren. Diese Informationen werden in der Extended Payload übertragen.

Wer Beacon selbst kompilieren oder mit den PNRP-Funktionen herumspielen möchte, benötigt Visual Studio 2008 [6] (auch in der kostenlosen Express-Edition) und das .NET Framework 3.5 SP1, da erst diese Kombination PNRP vollständig unterstützt.

Wie die neue "Easy Connect"-Funktion der Remote- Hilfe in Windows 7 funktioniert, zeigt netsh: Wenn man mit cloud show names vor und nach der Hilfeanforderung die registrierten P2P-IDs vergleicht, entdeckt man in der globalen Wolke eine neue. Sie ist nicht signiert (Authority 0) und der Name besteht nur aus hexadezimalen Ziffern. Auf dem PC des Helfers berechnet Windows aus dem Remote-Hilfe-Passwort diese Zahl, löst die P2P-IP per PNRP auf und stellt die Verbindung per IPv6 her – an allen störenden IPv4-NAT-Routern vorbei. Beim Einrichten einer HomeGroup sieht man dagegen eine zusätzliche gesicherte P2P-ID in der Link-lokalen Wolke. Der Rest der Zauberei steckt in anderen Protokollen, die nicht Gegenstand dieses Artikels sind. Microsoft stellt sich PNRP auch als Alternative zu DynDNS vor. Das heißt dann Windows Internet Computer Name (WICN) und läuft über den "PNRP-Computernamenveröffentlichungs-Dienst", den ebenfalls netsh steuert. Mit

peer set machinename publish=start

veranlasst man ihn, eine P2P-ID bis zum nächsten Neustart zu registrieren. Soll er das immer automatisch tun, setzt man dem Befehl noch autopublish=enable hinzu. Allerdings ist die dazu automatisch erzeugte P2P-ID eine gesicherte mit leerem Friendly Name, besteht also nur aus 64 hexadezimalen Ziffern und einem Punkt. Um von anderswo auf den PC zuzugreifen, taugt das nicht, da kann man sich auch gleich die IPv6-Adresse merken. Deshalb ist es möglich, die veröffentlichte P2P-ID mit dem Parameter name= zu setzen. Am einfachsten ist das mit einer unsignierten ID. Die Windows-Kommandozeile

netsh p2p pnrp peer set machinename name="0.mypnrpname" publish=start
autopublish=enable

richtet die selbst gewählte ID "mypnrpname" dauerhaft ein. In den Tests in der c’t-Redaktion funktionierte PNRP in der Link-lokalen Wolke sehr gut. Die Auflösung einer selbst registrierten P2P-ID über die globale Wolke mit der IPv6- Verbindung über Microsofts Teredo-Tunnel schlug dagegen oft fehl. Die Wolken-Statistik cloud show statistics zeigte zwar sowohl für den registrierenden als auch für den anfragenden Rechner sinnvolle Werte an. Doch offenbar zerfällt die globale Wolke manchmal in mehrere Teile. Vielleicht liegt das ja an der geringen Zahl von Nutzern, die jedoch spätestens mit der Verbreitung von Windows 7 steigen dürfte.

Sicherheit und PNRP unter Windows XP

PNRP-Sicherheit

Ungesicherte P2P-ID werden ihrem Namen gerecht: Jeder kann einen solchen Namen in der globalen Wolke publizieren und hat gute Chancen, bei der Namensauflösung gefunden zu werden. Daher müssen sicherheitsrelevante Anwendungen unbedingt auf höheren Protokoll-Ebenen die Identität des Kommunikations-Partners überprüfen, zum Beispiel über ein Passwort (wie bei Easy Connect in der Remote-Unterstützung) oder mit SSL/TLS-Zertifikaten. Die sicheren P2P-IDs sind mit einem öffentlichen Schlüssel verbunden und nach erfolgreicher PNRP-Auflösung prüft der Resolver, ob der gefundene Knoten im Besitz des zugehörigen privaten Schlüssels ist. Um die Verteilung der Schlüssel kümmert sich nicht PNRP, sondern eins der üblichen Public- Key-Infrastructure-Protokolle (PKI). Neben PNRP-Knoten mit eigen-generierten Schlüsseln sind delegierte PNRP-Namen innerhalb einer Zertifikat-Hierarchie möglich, die aber in der Praxis noch keine Bedeutung haben. Doch die kryptografische Prüfung stellt nur sicher, dass man wirklich die Adresse des Rechners erhalten hat, der die IP ursprünglich publizierte. Dass er wirklich der gewünschte Kommunikationspartner ist, steht nur fest, wenn man die P2P-ID über einen sicheren Kanal bekommen hat. Für die Kommunikation zwischen Menschen sind die langen und komplizierten gesicherten P2P-IDs aber nicht geeignet. Außerdem finden die Prüfungsschritte in einer "Black-Box" für den Benutzer des PNRP-Systems unsichtbar statt. Der Benutzer kann nicht erkennen oder prüfen, ob dieses System fehlerfrei und sicher funktioniert.

[7]PNRP in XP

Ein Teil der Funktionen von PNRP ist schon in Windows XP ab dem Service Pack 2 verfügbar. Zwei Schritte aktivieren sie: Zunächst installiert man IPv6, über den Knopf "Installieren" in den "Eigenschaften" der LAN-Verbindung, wo es sich als zusätzliches Protokoll hinzufügen lässt. Kommandozeilen- Fans nutzen stattdessen den Befehl netsh interface ipv6 install. Dann geht es in die Systemsteuerung und dort ins "Software"-Applet. Links leuchtet der Knopf "Windows-Komponenten …", der einen Auswahldialog öffnet, unter anderem mit der Zeile "Netzwerkdienste", in dessen "Details" (Knopf unten rechts) sich endlich der sinnlos übersetzte Punkt "Peer-zu-Peer" findet. Anschließend funktionieren PNRP-Programme wie unser Beispiel "Beacon", doch der Dienst zum Veröffentlichen des Computernamens fehlt und damit der Befehl set machinename. Über peer add registration lassen sich zwar Namen registrieren und die Auflösung mit peer resolve geht auch. Doch die pnrp.net- Pseudo-DNS-Namen funktionierten unter XP nicht. Offenbar hat Microsoft PNRP erst im Resolver von Vista eingebaut. Auch scheint das Löschen einer einzelnen Registrierung mit peer delete registration nicht zu funktionieren, sodass sich nur mit dem Stern als Platzhalter alle Namen auf einen Streich entfernen lassen.

PNRP zusehen

Wer dem Netzwerkverkehr von PNRP zusehen möchte, greift am besten zu Microsofts kostenlosem Network Monitor [8], der anders als Wireshark bereits einen Parser mitbringt, der PNRP-Pakete analysiert. Es muss allerdings noch aktiviert werden: Rufen Sie über das Tools-Menü den Options-Dialog auf und wechseln Sie auf den Reiter "Parsers". Ganz unten in der Liste steht "Windows" und daneben "Stubs". Markieren Sie diesen Eintrag, stellen Sie ihn mit dem Knopf "Stubs" in der Symbolleiste des Dialogs auf "Full" um und laden Sie mit dem Knopf "Save and Reload Parsers" die Parser neu.

Die Paketaufzeichnung startet man über den Link "New capture tab" auf der Startseite. Die Filter sind wie bei Wireshark Schlüsselwörter; so schneidet beispielsweise der Ausdruck ipv6 als "Capture Filter" nur IPv6-Verkehr mit, und der "Display Filter" pnrp zeigt nur die PNRP-Pakete an. Die Filterausdrücke muss man mit dem "Apply"-Knopf ausdrücklich aktivieren. Allerdings erkennt man an PNRP-Paketen nur sehr wenig, da ja an Stelle von Namen nur die Hashes übertragen werden.

Literatur (rek [9])

• Dr. Cai Ziegler, Smarte Schwärme, Die Technik hinter modernen Peer-to-Peer-Netzen, c’t 16/05, S. 160 [10]

• Reiko Kaps, Wohnzimmer-WAN, IPv6 für kleine Netze, c’t 12/07, S. 134 [11], überarbeitete Fassung auf heise Netze: IPv6 für kleine Netze [12]

URL dieses Artikels:
https://www.heise.de/-221542

Links in diesem Artikel:
[1] #WinXP-u5
[2] http://msdn.microsoft.com/en-us/library/cc239047.aspx
[3] http://www.heise.de/netze/rfc/rfcs/rfc3879.shtml
[4] http://www.heise.de/netze/Netzwerke-mit-UPnP-einrichten-und-steuern--/artikel/126602/2
[5] http://www.heise.de/netze/Punycode-Umlaute-und-Sonderzeichen-in-Domainnamen--/artikel/119723
[6] http://www.heise.de/software/download/visual_studio_express_editions/32737
[7] 
[8] http://www.heise.de/software/download/microsoft_network_monitor/44899
[9] mailto:rek@ct.de
[10] http://www.heise.de/kiosk/archiv/ct/05/16/160_Smarte_Schwaerme
[11] http://www.heise.de/kiosk/archiv/ct/07/12/134_Wohnzimmer-WAN
[12] http://www.heise.de/netze/IPv6-fuer-kleine-Netze--/artikel/98759

Copyright © 2009 Heise Medien