Seite 4: Der Ablauf

Inhaltsverzeichnis

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